AWS: CloudTrail は「記録」、GuardDuty が「判断」、Config が「構成の逸脱」
CloudTrail を有効にしただけでは、危ない操作が起きても誰も教えてくれない。検知は GuardDuty、設定のずれは Config に任せる、という役割分担で組む。
どんなときに使う？
- 「CloudTrail を入れたから監査・検知は大丈夫」と思っているアカウントを見直すとき
- AWS Organizations でセキュリティ系サービスの土台を決めるとき
- インシデント後に「ログはあったのに気づけなかった」を防ぎたいとき
考え方
| サービス | 仕事 | しないこと |
|---|---|---|
| CloudTrail | API 操作を記録する（誰が・いつ・何をしたか） | 操作が危ないかどうかの判断・通知 |
| GuardDuty | 記録やネットワークの挙動から脅威を判断して検知結果を出す | 構成が社内ルール通りかの評価 |
| AWS Config | リソース構成の変化を追い、ルールからの逸脱を評価する | 攻撃っぽい振る舞いの検知 |
- 「記録」「判断」「構成」を別のサービスが担うので、どれか一つでは穴が残る
- 調査（後から追う）には CloudTrail、気づく（今起きている）には GuardDuty、ずれを防ぐ・直すには Config、と目的で選ぶ
注意点
- 投稿は役割の整理。具体的な組み方（委任管理者、全リージョン有効化、通知先など）は投稿者の『AWSの薄い本８ AWS Organizationsと愉快な仲間たち』や公式ドキュメントで確認する
- 同じ投稿者は、Secrets Manager に移したのにエージェント用プロファイルに
GetSecretValueが残っていて生値が取れた、という失敗談も書いている AI エージェント時代のシークレット受け渡し: 4 段階の考え方と道具
関連
- AWS 設計の定石メモ: 人は Identity Center・システムは IAM ロール／VPC エンドポイント／Route 53 Resolver
- AWS IAM: 評価は「明示 Deny → 明示 Allow → 暗黙 Deny」