10. 参照アーキテクチャと演習設計

本章は特定製品の構成図ではない。組織が自らの環境をレビューするための、境界と責任の参照図である。実装は、規模、規制、クラウド利用、運用能力、既存契約に応じて変える。

10.1 参照アーキテクチャ：信頼を分け、観測をつなぐ

この参照図で検討すべきことは、矢印の数を減らすことではない。各矢印に対して、誰が使うか、何の認証か、最小権限か、ログは残るか、期限はあるか、異常時に止められるかを答えられるようにすることだ。

10.2 重要な分離パターン

日常利用と管理利用の分離

日常のメール・Web閲覧・文書作成に使う端末と、高権限のID管理、クラウド設定、バックアップ操作を行う端末を同一にすると、日常利用のリスクが管理面へ直結する。完全に別の物理端末が難しい場合でも、専用アカウント、端末健全性条件、時間制限、管理操作の記録を段階的に強化する。

本番とバックアップの分離

バックアップが本番と同じID、同じネットワーク、同じ管理者、同じ暗号鍵に依存すると、バックアップはコピーであっても独立した復旧資産にならない。アクセス経路、削除権限、保持変更、鍵、管理コンソール、監視を分ける。

組織と委託先の分離

委託先が必要な時だけ、必要な対象へ、記録を残してアクセスできるようにする。恒久VPN、共有ID、無期限トークンは、利便性と引き換えに調査・遮断・説明を難しくする。

10.3 演習シナリオ1：特権IDの異常

状況

休日の深夜、通常使用しない地域・端末から特権IDの認証成功が観測され、直後に複数の権限変更が記録された。データ暗号化や身代金ノートは確認されていない。

演習で問うこと

1. このアラートは誰に届き、何分以内に人が確認するか。
2. アカウント停止、セッション無効化、特権ロール撤回を誰が承認するか。
3. 正常な管理端末・緊急アカウントをどの根拠で信頼するか。
4. クラウド、オンプレミス、バックアップ、委託先のどこまで同じIDが届くか。
5. 事実と仮説を分けた初報を、経営へいつ送るか。

成功基準

• 影響を受け得る管理面を一時間以内に列挙できる。
• 正常な別経路で調査と封じ込めを始められる。
• 証拠を失わずに、必要な権限停止を行える。
• 事業部への影響説明に、未確認事項が明記されている。

10.4 演習シナリオ2：バックアップ管理面の不信

状況

重要サーバーで異常なファイル変更が見つかり、バックアップ管理コンソールへの管理者ログインも同時刻に記録された。バックアップジョブは成功表示のままである。

演習で問うこと

1. バックアップが安全だと判断する証拠は何か。
2. 本番ネットワークを停止した場合に、どの経路で復元資産を確認できるか。
3. どの時点のバックアップを、どの隔離環境で、誰が検証するか。
4. アプリケーション・ID・DNS・証明書・データ整合性をどの順番で確認するか。
5. 業務再開の検収者は誰で、何をもって再開可とするか。

成功基準

• バックアップ成功通知だけに依存せず、保持・変更履歴・復元を確認できる。
• 復元のためのIDや鍵が、本番の侵害範囲と独立している。
• 限定再開から通常再開までの判定が業務部門と共有されている。

10.5 演習シナリオ3：委託先接続を含む情報窃取の疑い

状況

委託先アカウントが通常より多くのデータへアクセスした後、外部共有設定の変更が確認された。暗号化は未確認で、委託先は保守作業中だったと説明している。

演習で問うこと

1. 契約上、どのログ・証跡・連絡先を要求できるか。
2. 委託先接続を止めた場合の業務影響と代替手順は何か。
3. 外部共有されたデータの範囲を、組織・委託先双方の記録で照合できるか。
4. 顧客・規制当局への通知判断に必要な事実は何か。
5. 委託先への責任追及と、共同の封じ込め・証拠保全を混同していないか。

成功基準

• 接続停止、証拠保全、契約連絡、事業代替を並行して開始できる。
• 攻撃者の主張や委託先の初期説明を、確定事実として扱わない。
• 委託先接続の最小権限・期限・ログに改善を戻せる。

10.6 経営机上演習の進め方

経営演習では、技術的な細部を再現する必要はない。次の意思決定点を時系列で与え、誰が何を根拠に決めるかを確認する。

演習で「正解」を出すことは目標ではない。誰が権限を持つか、どの情報がないと判断できないか、どの連絡が詰まるかを見つけることが成果である。

10.7 改善の追跡テンプレート

課題を「教育不足」で終わらせない。人、手順、技術、権限、資産、契約、予算のどこに不足があるかを分け、再現可能な検証方法を置く。