Ransomware Frontline Report

9. 対策を継続できる運用にする

V2 | 日本語版 | Full Report

ランサムウェア耐性は、年度末に一度だけ診断して完成するものではない。資産、利用者、委託先、SaaS、脆弱性、組織改編、業務優先順位が変化するため、対策を通常運用に埋め込む必要がある。本章では、シニアエンジニアが運用を評価・改善するための実装枠組みを示す。

9.1 成熟度は「製品数」ではない

成熟度を、EDR・SIEM・CASB・ゼロトラスト等の保有数で測ると、例外運用や復旧不能性を見落とす。ここでは、次の五段階を使う。

段階	状態	典型的な証拠	次の焦点
0 未把握	資産・ID・復旧の範囲を説明できない	個人の知識、古い資料のみ	所有者と棚卸しを作る。
1 部分管理	個別の製品・手順はあるが、例外が見えない	台帳・手順が分散、復元未試験	重要業務と管理面を結ぶ。
2 基準化	最低限の基準、担当、例外記録がある	MFA、更新、バックアップ、連絡網	実際のログ・復元で確認する。
3 検証済み	演習と測定で改善が回る	復元演習、検知検証、課題台帳	委託先・クラウド・全社対応を統合する。
4 適応的	変更と脅威情報を継続的に反映する	変更連動のレビュー、経営指標	複雑化を抑え、効果を維持する。

段階4をすべての組織が目指す必要はない。重要なのは、現在地を正しく把握し、業務リスクに見合う次の一段を選ぶことだ。

9.2 経営指標と技術指標を接続する

例えば技術チームが「パッチ適用率98%」と報告しても、経営が知りたいのは「重要業務がいつ戻るか」「顧客影響をどう抑えるか」「残る重大リスクは何か」である。この98%は説明用の仮例であり、特定調査の実測値ではない。両者をつなぐ指標を設ける。

領域	技術指標	事業に翻訳した指標
外部公開面	未所有資産数、期限超過の公開例外	不明な入口が重要業務へ届く可能性
ID	特権IDのMFA率、恒久特権数、例外数	管理面を一つの侵害で失う可能性
更新	重大脆弱性の対応時間、未更新例外	公開・重要資産が既知の危険に晒される期間
バックアップ	成功ジョブ率、復元テスト率	優先業務を復旧目標内に戻せる確度
検知	高重大度の確認時間、ログ欠損率	攻撃拡大前に判断できる時間
演習	連絡・復元・業務再開の達成率	重大障害時の説明・再開能力

数値は罰則のためではなく、判断材料のために使う。例えばパッチ適用率が低い原因が、医療・製造・旧業務の停止リスクなら、更新率だけを上げる施策は業務を壊す。隔離、代替システム、更改、保守契約、リスク受容を含む意思決定に変換する。

9.3 例外管理は防御の中心である

実際の環境では、「今月だけ」「ベンダーが必要」「古い機器なので」「障害が怖い」という例外が生じる。例外そのものを禁止すると、現場は見えない運用を作る。よい例外管理は、例外を正当化することではなく、危険を見える化し、期限を持たせ、代替策を選ぶことである。

例外記録の必須項目

対象資産・サービス・ID・接続先。
例外の理由と業務上の必要性。
想定される攻撃面と影響業務。
代替的な低減策（アクセス制限、監視、隔離、時間制限等）。
承認者、開始日、失効日、再評価日。
根本解決（更改・廃止・再設計）の所有者と予定。

例外台帳をセキュリティ部門だけで持つと、現場の変更とずれる。変更管理、調達、資産管理、監査、BCPのいずれかとリンクさせ、期限切れを検知できるようにする。

9.4 委託先・SaaSのライフサイクル

調達前のセキュリティ質問票は有用だが、それだけでは接続後の運用を守れない。以下の段階で確認する。

段階	最低限の確認
選定前	データ分類、管理権限、地域・法的要件、インシデント通知、監査可能性
導入時	最小権限、SSO/MFA、ログ、管理者の分離、データ持出し設定
運用中	アカウント棚卸し、設定変更、接続ログ、障害通知、演習参加
重大事案時	証拠保全、連絡窓口、影響範囲、代替業務、共同発信
終了時	アカウント・トークン・証明書・連携・データの廃止確認

第三者が関与する侵害の増加というDBIRの指摘は、第三者を排除せよではなく、このライフサイクルを管理せよという実務課題として受け取るべきである。[S03]

図8　第三者接続が作る一対多の影響

図は集中管理が常に危険だと示すものではない。分離、最小権限、時間制限、操作ログ、緊急停止、共同対応を設計しない場合に、単一の侵害が複数の顧客・部門へ波及し得ることを示す。

9.5 変更管理にセキュリティを接続する

ランサムウェア耐性を壊す変更は、大規模な新システム導入だけではない。緊急のVPN公開、監視除外、特権の恒久付与、バックアップ保持変更、クラウドの共有設定、委託先の一時アカウントなど、小さな変更の蓄積が危険になる。

変更申請に次の質問を入れるだけでも、危険な見落としを減らせる。

外部から到達可能になるか。
新しい特権・共有権限・トークンが生じるか。
ログ、監視、バックアップ、復旧手順に変更が必要か。
期限付きの例外か。終了時に誰が戻すか。
重大インシデント時に、この変更を停止・隔離できるか。

9.6 技術債務をランサムウェアリスクとして説明する

技術債務は「古くて保守が面倒」という話ではない。サポート終了OS、属人化した管理者、共有ID、文書化されないネットワーク、未試験バックアップは、侵入の確率、横展開の規模、復旧の時間、説明責任の難しさを同時に増やす。

経営へは、脆弱性の名前だけではなく、次の形で説明する。

この資産は外部公開され、更新不能で、管理者IDが共有され、バックアップ復元を試験していない。侵害された場合、停止する業務はXで、代替手順はY時間しか維持できない。隔離・更改・廃止の三案と費用・期限を提示する。

この説明は、恐怖で予算を取るためではない。選ばない場合の残存リスクを、組織が明示的に受容できるようにするためである。

9.7 年間運用カレンダーの例

頻度	取り組み	成果物
毎日	高重大度の認証・管理面・保護停止の確認	対応記録、エスカレーション
毎週	新規公開資産、重大更新、例外期限の確認	差分一覧、責任者への通知
毎月	特権・委託先アカウント、バックアップ失敗、ログ欠損のレビュー	是正チケット、経営向け要点
四半期	重要業務の復元テスト、接続先レビュー	演習結果、RTO/RPOとの差分
半年	机上演習、連絡網、契約・外部連携の更新	改善計画、承認記録
年次	全体リスク評価、BCP更新、全社演習	取締役会等への報告、翌年計画

9.8 90日実装を失敗させないために

先の90日計画を成功させる鍵は、作業を「セキュリティ部門の宿題」にしないことだ。各行動に業務オーナー、技術オーナー、期限、完了証拠、残存リスクを付ける。

行動	業務オーナー	技術オーナー	完了証拠	残存リスク
最重要業務の依存関係確認	業務部長	アプリ責任者	依存表・RTO/RPO・検収者	未確認の委託先依存
特権IDの分離	システム責任者	IAM担当	ID一覧・認証テスト・例外台帳	緊急IDの運用負荷
バックアップ復元	業務責任者	インフラ担当	復元演習結果・業務検収	最終データの補正手順
公開面の是正	サービス責任者	ネットワーク担当	到達性確認・設定レビュー	期限付き公開例外

「やった」と言うための完了ではなく、第三者または別担当者が再確認できる証拠を残す。これが、担当者交代や有事での再現性を支える。