導入
数十のアカウントを運用していると、「どこかのアカウントで異常なAPI呼び出しが起きていないか」「機密データが誤って公開されていないか」を、アカウントごとにチェックするのは非現実的です。脅威検知・監査も組織全体で一元化する必要があります。
説明
AWSのセキュリティ検知サービスは役割が異なり、組み合わせて使います。
| サービス | 役割 |
|---|---|
| Amazon GuardDuty | CloudTrail・VPC Flow Logs・DNSログ等を機械学習で分析し、不審な挙動（異常なAPI呼び出し、既知の悪性IPとの通信等）を検知 |
| AWS Security Hub | GuardDutyを含む複数のセキュリティサービスの検出結果を集約し、セキュリティ標準（CISベンチマーク等）への準拠状況をスコア化 |
| Amazon Detective | GuardDutyなどで検知した異常について、根本原因調査のためにログを可視化・相関分析 |
| Amazon Macie | S3内のデータを機械学習でスキャンし、個人情報（PII）などの機密データの所在を検出 |
これらは組織のセキュリティ運用の流れの中で、それぞれ異なる段階を担います。
flowchart LR
G["GuardDuty<br/>脅威を検知"] --> H["Security Hub<br/>全体を集約・可視化"]
H --> D["Detective<br/>根本原因を調査"]
M["Macie<br/>機密データの所在を検出"] --> H
複数アカウントで運用する場合は、委任管理者アカウント（Delegated Administrator） を1つ指定し、GuardDuty・Security Hub・Macieの結果をそのアカウントに一元集約するのが定石です（AWS Organizationsとの統合により、メンバーアカウントを自動的に有効化できます）。管理アカウント自体をセキュリティ運用の日常業務に使わないという原則（第2章）とも整合します。
具体例
30アカウントを運用する企業のセキュリティチームが、脅威対応を組織全体で一元化します。もし各アカウントを個別にチェックしていたら、見落としだらけで破綻します。
そこで委任管理者アカウントを1つ用意し、Organizations統合でこう組みます。
- GuardDutyが全30アカウントのログを機械学習で分析し、「アカウントXのEC2が既知の悪性IPと通信」という脅威を検知
- その検知結果は、各アカウントを見に行かずSecurity Hubが委任管理者アカウントに一元集約。CISベンチマークへの準拠スコアも一覧化
- 気になる事案はDetectiveでログを相関分析し、根本原因を調査
- 並行してMacieがS3を走査し、個人情報が公開状態のバケットを検出しSecurity Hubへ
新しいアカウントが増えてもOrganizations統合で自動的に有効化されます。「何を検知するか（GuardDuty/Macie）」と「どう集約・調査するか（Security Hub/Detective）」の役割分担を押さえ、組織全体は委任管理者への集約で見る——これが定石です。
読んでみよう
「組織全体の脅威検知結果を1箇所で確認したい」という要件が出たら、各サービスを個別に集計するのではなく、Organizations統合＋委任管理者アカウントへの集約という構成をまず思い浮かべてください。「何を検知するか（GuardDuty/Macie）」と「検知結果をどう集約・調査するか（Security Hub/Detective）」の役割分担を混同しないことが重要です。