セクション 02 · タスク 1.2 · SAP-C02-021

マルチアカウントのセキュリティ監視を一元化する

マルチアカウントセキュリティ / 検出結果の一元管理 / 集中ログ記録 / イベント通知 / 監査アカウント / AWS Firewall Manager / セキュリティ運用

このページのゴール

多数のAWSアカウントで発生するセキュリティ検出結果とログを、監査 / セキュリティツール群アカウントへ集約し、通知・調査・対応・中央セキュリティポリシーまで一貫して運用できるアーキテクチャを設計できることをゴールにします。

1. マルチアカウントでは「各アカウントで監視」だけでは運用できない

AWS Organizations配下に本番、開発、サンドボックス、共有サービスなど多数のAWSアカウントがあるとします。各アカウントでセキュリティサービスを有効化しても、検出結果をアカウントごとにログインして確認する設計では、アカウント数が増えるほどセキュリティ運用の負荷が増えます。

本番     → GuardDuty 検出結果
開発      → Inspector 検出結果
サンドボックス  → アクセス 検出結果
              │
              ▼
各アカウントを個別確認

さらにアカウントごとにセキュリティサービスの有効化状況や設定が異なると、セキュリティの適用範囲にもばらつきが生まれます。マルチアカウントセキュリティでは、検知は各ワークロードで行い、管理と監視を中央化するという考え方が基本です。

2. 検知ポイントと運用ポイントを分ける

セキュリティ問題が発生する場所と、セキュリティチームが監視・管理する場所は同じである必要はありません。

アプリケーションアカウント
        │
        │ セキュリティテレメトリ
        ▼
     GuardDuty
        │
        │ 検出結果
        ▼
セキュリティツール群アカウント

ワークロードアカウントで検出結果を生成し、セキュリティチームは専用アカウントから組織全体を監視できます。これにより、アプリケーション運用とセキュリティ運用の責任を分離できます。

3. セキュリティサービスの日常運用を管理アカウントから分離する

AWS Organizationsの管理アカウントで、組織管理と日常セキュリティ運用をすべて行うことを基本にはしません。Organizationsと統合する多くのセキュリティサービスでは、メンバーアカウントを委任管理者として指定できます。

Organizations管理 アカウント
          │
          │ 委任
          ▼
セキュリティツール群 / 監査アカウント
          │
          ├─ GuardDuty
          ├─ Amazon Inspector
          ├─ IAM Access Analyzer
          ├─ AWS Security Hub / CSPM
          └─ AWS Firewall Manager

AWS Security Reference Architecture（AWS SRA）でも、セキュリティツール群アカウントを複数セキュリティサービスの委任管理者として使用し、管理アカウントの責任とセキュリティ運用を分離する構成が推奨されています。

4. 監査アカウントはセキュリティチームの運用ポイント

監査アカウントは、セキュリティチームがセキュリティサービスを管理し、検出結果を監視し、調査や対応を行うための専用アカウントとして捉えます。AWS Control Towerではセキュリティ OU内のこの用途のアカウントを監査アカウントと呼び、AWS SRAではより一般的にセキュリティツール群アカウントとして整理されています。

監査 / セキュリティツール群アカウント
├─ セキュリティサービス 管理
├─ 組織全体の検出結果可視性
├─ イベント通知
├─ 調査 / 対応
└─ 中央セキュリティポリシー

名前そのものより、ワークロードからセキュリティ運用を分離する責任を理解することが重要です。

5. 監査アカウントとログアーカイブアカウントを分ける

監査 / セキュリティツール群アカウントとログアーカイブアカウントは同じ責任ではありません。

アカウント	主な責任
監査 / セキュリティツール群	セキュリティサービス管理、検出結果監視、通知、調査、対応
ログアーカイブ	生ログの中央保管、保持期間、根拠保護

AWS SRAもセキュリティ OU内にセキュリティツール群アカウントとログアーカイブアカウントを分けています。例えば、GuardDutyやInspectorの検出結果はセキュリティツール群側で扱い、CloudTrailなどの生ログはログアーカイブへ長期保管する、と責任を分離できます。

6. セキュリティサービスごとに委任管理を利用する

Organizationsと統合されたセキュリティサービスでは、セキュリティツール群アカウントを委任管理者として利用できます。例えばGuardDuty、Amazon Inspector、IAM Access Analyzer、AWS Security Hub / Security Hub CSPM、AWS Firewall Managerなどです。

AWS Organizations
       │
       ▼
委任管理者
       │
       ├─ サービス設定
       ├─ メンバーアカウント 管理
       └─ 組織全体の可視性

委任管理者は検出結果を生成する検知エンジンではありません。 組織全体のサービス管理をセキュリティチームへ委任する仕組みです。

7. 新しいアカウントもセキュリティベースラインへ取り込む

新しいアカウントが増えるたびにセキュリティサービスを手作業で有効化する運用では、設定漏れが起こりやすくなります。Organizations 統合、中央設定、自動有効化、組織ポリシーなど、そのサービスが提供する中央ガバナンス機能を使って新アカウントをセキュリティベースラインへ取り込みます。

新しい AWSアカウント
      │
      ▼
AWS Organizations
      │
      ▼
中央設定 / 自動有効化
      │
      ▼
セキュリティベースライン

GuardDutyでは組織の自動有効化を設定でき、Amazon InspectorでもOrganizations ポリシーや委任管理者による中央ガバナンスを利用できます。SAP-C02では個々の設定手順より、新アカウントを自動的に保護対象へ取り込む設計を判断します。

8. 検出結果をセキュリティツール群アカウントへ中央化する

各アカウントで生成された検出結果を中央から確認できれば、セキュリティチームはアカウント境界をまたいで重要度や影響を受けるリソースを比較し、対応優先度を決められます。

アカウント A ─┐
アカウント B ─┤
アカウント C ─┼─→ セキュリティツール群 / 中央 表示
アカウント D ─┘

例えばAmazon Inspectorの委任管理者は組織全体の集約検出結果と、メンバーアカウントの検出結果の詳細を確認できます。集中型検出結果は、セキュリティチームが組織全体の可視性を得るための設計です。

9. 集中型検出結果は検知エンジンの統合ではない

検出結果を中央化しても、各送信元サービスの検知責任は変わりません。

IAM Access Analyzer → アクセス 検出結果 ─┐
Amazon Inspector   → 脆弱性 ───┼─→ 中央セキュリティ表示
Amazon GuardDuty   → 脅威検出結果 ──┘

つまり、集中型検出結果とは「1つのサービスがすべてを検出する」という意味ではなく、異なる検知サービスが生成したシグナルをセキュリティ運用側から中央確認できるようにすることです。

10. Security Hub CSPMでアカウント / リージョンを中央設定する

Security Hub CSPMはAWS Organizationsとの統合と中央設定を利用でき、委任管理者から組織ルート、OU、アカウントへ設定ポリシーを適用できます。Security Hub CSPMの有効化、セキュリティ標準、セキュリティ制御などを中央設定できます。

Security Hub CSPM
委任管理者
       │
       ▼
設定ポリシー
       │
       ├─ 組織ルート
       ├─ OU
       └─ アカウント

アカウントごと・リージョンごとに手作業で設定するのではなく、Organizations構造に沿って中央ガバナンスを適用する判断が重要です。

11. ホームリージョンへマルチリージョンの検出結果を集約する

Security Hub CSPM 中央設定ではホームリージョンを指定し、必要に応じてリンク済みリージョンを設定します。設定ポリシーはホームリージョンとリンク済みリージョンへ適用され、リンク済みリージョンの検出結果やインサイトなどもホームリージョンへ集約されます。

東京 ──────┐
バージニア北部 ───┤
フランクフルト ──┼─→ ホームリージョン
シドニー ─────┘

マルチアカウントだけでなくマルチリージョンも対象なら、アカウントの集中化とリージョンの集中化を別々に確認します。

12. AWS Security Hubでセキュリティシグナルを中央から優先する

現在 AWS Security Hubでは、複数のセキュリティシグナルを相関して露出の検出結果を生成し、潜在的な攻撃経路や影響範囲を含むリスクを優先できます。セキュリティツール群アカウントをAWS Security Hub / Security Hub CSPMの委任管理者として利用することで、組織全体のセキュリティ運用へつなげられます。

送信元検出結果
      │
      ▼
中央セキュリティ表示
      │
      ▼
相関 / 優先順位付け
      │
      ▼
セキュリティ運用

ここでも、GuardDutyやInspectorなど送信元検知サービスを置き換えるのではなく、中央からリスクを把握し、優先順位付けする役割として使います。

13. 検出結果と生ログは同じものではない

セキュリティ検出結果は「何が問題か」を要約したセキュリティシグナルです。一方、フォレンジックではCloudTrail、VPC フローログ、DNS ログ、アプリケーションログなどの生ログを確認する必要があります。

情報	主な役割
セキュリティ検出結果	問題の発見、重要度、優先順位付け
生ログ	詳細調査、時系列確認、フォレンジック、根拠

したがって、検出結果を中央化したから生ログが不要になるわけではありません。

14. セキュリティツール群とログアーカイブを連携する

セキュリティ運用では、検出結果を起点に調査し、必要に応じてログアーカイブの生ログへ進みます。

ワークロードアカウント
      │
      ├──── 検出結果 ───→ セキュリティツール群
      │                       │
      │                       │ 調査
      │                       ▼
      └──── 生ログ ───→ ログアーカイブ

監査 / セキュリティツール群アカウントは監視と対応、ログアーカイブアカウントは保持期間と根拠保護という責任を持たせます。

15. 集中型検出結果と集中型ログ記録を組み合わせる

検出結果だけでは詳細なフォレンジック情報が不足する場合があり、生ログだけではセキュリティチームが大量のイベントをすべて手作業で分析することになります。

検知サービス
      ↓
   検出結果
      ↓
優先順位付け

      +

集中管理された 生ログ
      ↓
調査 / 証跡

検出結果で問題を絞り込み、生ログで詳細を調査するという組み合わせが効率的です。

16. 重大検出結果をイベントとして通知する

重大検出結果が発生しても、セキュリティチームがコンソールを見に行くまで待つ設計では対応が遅れます。AWS Security Hub / Security Hub CSPMの検出結果はAmazon EventBridgeへほぼリアルタイムにイベントとして送信でき、条件に一致するイベントから通知やワークフローを起動できます。

セキュリティ検出結果
       │
       ▼
Amazon EventBridge
       │
       ├─ Amazon SNS
       ├─ Amazon SQS
       ├─ AWS Lambda
       ├─ AWS Step Functions
       └─ チケット / SIEM / インシデント管理ツール

つまり、検出結果の生成とイベント通知は別の責任として設計します。

17. 通知ポリシーで必要な検出結果だけをルートする

LOWからCRITICALまでの検出結果をすべて同じ方法で通知すると、アラート疲れにつながります。EventBridge ルールで重要度、アカウント、リソース、検出結果タイプなどを条件にし、対応すべきイベントだけをルートします。

検出結果
  │
  ▼
重要度 / アカウント / リソース / タイプ
  │
  ▼
EventBridge ルール
  │
  ▼
通知 / ワークフロー

セキュリティサービスは検出結果を生成し、セキュリティ運用側がどの検出結果で誰を呼ぶかを決めます。

18. 通知と自動化された対応を分ける

EventBridgeの対象は人への通知だけではありません。SNSやチケット管理ツールへ送るほか、LambdaやAWS Step Functionsなどから自動化された対応を開始できます。

検出結果
  ↓
EventBridge
  ├─ SNS / チケット → 人による対応
  └─ Lambda / AWS Step Functions → 自動対応

ただしセキュリティ検出結果が出たら何でも自動停止・削除するのではなく、ビジネス影響と誤検知リスクに応じて、通知のみ、承認付き対応、自動修復を選びます。

19. AWS Firewall Managerは制御側の中央統制を担う

AWS Firewall Managerは、Organizations環境でネットワークセキュリティポリシーを中央管理し、対象アカウントやリソースへ継続的に適用する制御を担います。

セキュリティツール群アカウント
        │
        ▼
AWS Firewall Manager
        │
        ▼
組織 / OU / アカウント / リソース
        │
        ▼
中央セキュリティポリシー

AWS Security Hubなどがセキュリティリスクを可視化するのに対し、Firewall Managerはネットワークセキュリティポリシーを中央統制します。

20. Firewall Managerポリシー範囲で適用範囲を決める

Firewall Managerポリシーは組織全体または一部のアカウント / リソースへ適用できます。新しいアカウントやリソースがポリシー範囲へ入ると、Firewall Managerはポリシー設定に基づいて評価・適用します。

中央ポリシー
    │
    ▼
ポリシー範囲
    │
    ├─ 組織
    ├─ OU / アカウント
    └─ リソース
         │
         ▼
継続的ポリシーアプリケーション

100 アカウントへルールを手作業でコピーするのではなく、範囲を定義した中央ポリシーとして管理します。

21. Firewall Managerの管理もセキュリティアカウントへ委任できる

Firewall ManagerはOrganizationsと統合し、メンバーアカウントをFirewall Manager管理者として利用できます。管理者範囲はアカウント / OU、リージョン、ポリシータイプなどで制限でき、最小権限な分担も可能です。

Organizations管理 アカウント
          │
          │ 委任
          ▼
Firewall Manager管理者
          │
          └─ 管理上の範囲
              ├─ アカウント / OU
              ├─ リージョン
              └─ ポリシータイプ

中央セキュリティポリシーの管理責任をセキュリティチームへ委任することで、管理アカウントの日常運用責任とセキュリティ運用を分離できます。

22. セキュリティ運用は検知から対応までつなげる

集中型監視は検出結果を一画面へ集約して終わりではありません。セキュリティ運用では、検知から対応までを一続きのワークフローとして設計します。

検知
  ↓
集約
  ↓
優先順位付け
  ↓
通知
  ↓
調査
  ↓
対応
  ↓
証跡を保持

例えばGuardDuty 検出結果をセキュリティツール群アカウントで受け、EventBridgeでチケットを作成し、セキュリティアナリストがログアーカイブのCloudTrailやネットワークログを調査し、必要な対応へ進む、という流れです。

23. 集中化と職務分離を両立する

集中化は「すべてを1アカウントへ置く」という意味ではありません。責任を分けたうえで、可視性とガバナンスを中央化します。

アカウント	主な責任
Organizations管理	組織そのものの管理
監査 / セキュリティツール群	セキュリティ監視、検出結果、対応、ポリシー管理
ログアーカイブ	生ログ、保持期間、根拠
ワークロード	アプリケーション / ビジネスワークロード

これにより、中央可視性と職務分離を両立できます。

24. 要件からアーキテクチャを選ぶ

要件	基本判断
多数アカウントのセキュリティサービスを中央管理	Organizations + 委任管理者
セキュリティチーム専用の管理点を作る	監査 / セキュリティツール群アカウント
メンバーアカウントの検出結果を中央確認	委任管理者 / AWS Security Hub等
複数リージョンのSecurity Hub CSPM 検出結果を集約	ホームリージョン + リンク済みリージョン
生ログをワークロードから分離して長期保管	ログアーカイブアカウント
高重要度検出結果を即時通知	EventBridge + SNS等
検出結果から自動対応を開始	EventBridge + Lambda / AWS Step Functions等
ネットワークセキュリティポリシーを組織へ適用	AWS Firewall Manager
新アカウントもセキュリティベースラインへ取り込む	中央設定 / 自動有効化 / 組織ポリシー
検出結果を調査・対応までつなぐ	セキュリティ運用ワークフロー

25. 混同ポイント

集中型セキュリティ = 管理アカウントですべての日常運用：委任管理者を利用して責任を分離できます。
監査アカウント = ログだけを置くアカウント：セキュリティ監視 / 管理 / 対応側の役割です。
監査 / セキュリティツール群 = ログアーカイブ：運用と長期保管は別責任です。
集中型検出結果 = 1つのサービスがすべてを検出：検知は送信元サービスが担当します。
AWS Security Hubを使えば生ログ不要：フォレンジックや根拠には生ログが必要です。
検出結果生成 = 自動通知済み：EventBridgeなどのルーティングを別途設計します。
EventBridge = セキュリティ検知サービス：イベントを条件に応じてルートするサービスです。
Firewall Manager = 検出結果集約機能：組織全体のセキュリティポリシーの中央統制を担います。
集中型監視 = コンソールを1つにするだけ：検知から対応までの運用を設計します。

26. SAP-C02判断フロー

マルチアカウントセキュリティが必要
        │
        ▼
セキュリティサービスを誰が管理する？
        │
        ▼
委任管理者
        │
        ▼
監査 / セキュリティツール群アカウント
        │
        ├───────────────┐
        │               │
        ▼               ▼
集中管理された          中央セキュリティポリシー
検出結果              │
        │             ▼
        │        AWS Firewall Manager
        ▼
組織全体の可視性
        │
        ▼
重大検出結果？
        │
       はい
        ▼
Amazon EventBridge
        │
        ├─ 通知
        ├─ チケット
        └─ 自動対応
        │
        ▼
調査
        │
        ▼
集中管理されたログ
(ログアーカイブ)

27. まとめ

マルチアカウントセキュリティ
→ 検知は各アカウント
→ 管理 / 監視は中央化

監査 / セキュリティツール群アカウント
→ 委任管理者
→ 検出結果監視
→ セキュリティポリシー
→ 対応

ログアーカイブアカウント
→ 生ログの中央保管
→ 保持 / 証跡

検出結果の一元管理
→ 組織全体の可視性

AWS Security Hub / CSPM
→ アカウント / リージョン横断の中央管理・可視化

EventBridge
→ 検出結果をイベントとしてルート
→ SNS / チケット / Lambda等

AWS Firewall Manager
→ 組織全体のセキュリティポリシー

セキュリティ運用
→ 検知 → 集約 → 優先順位付け
→ 通知 → 調査 → 対応

最重要ポイントは、「セキュリティ検出結果を中央に集める」で終わらず、誰がセキュリティサービスを管理するか・ログをどこへ保存するか・検出結果をどう通知するか・誰が調査してどう対応するかまで設計することです。

28. 主要AWS公式資料

理解確認

このページの内容を14問で確認します。

理解確認14問へ →