AWS Certified CloudOps Engineer - Associate (SOA-C03) #13 Domain 5-2 セキュリティ — Config・CloudTrail・GuardDuty・Security Hub・KMS
#12 でアイデンティティとガバナンスを押さえたなら、この記事は 何が起きたかを追跡し (監査)、誤った状態を検知・修復し、データを暗号化する 運用ツールを扱います。セキュリティドメインの中核サービスがここに集まっており、名前が似ていて紛らわしいため、それぞれが何を見るのか で区別するのが試験のポイントです。
4 つのサービスの役割の区別 #
まず全体像から押さえます。混乱の半分は、この 4 つの境界を曖昧にしか理解していないために生じます。
| サービス | 見るもの | 一言で |
|---|---|---|
| CloudTrail | 誰がどの API を呼び出したか | 行為の記録 (監査ログ) |
| Config | リソースがどの構成で、ルールを守っているか | 構成状態・コンプライアンス |
| GuardDuty | 悪意ある・異常な行為があるか | 脅威検知 |
| Security Hub | 上の結果をまとめたセキュリティスコア | 統合ダッシュボード |
CloudTrail: API 監査 #
アカウントで起きる すべての API 呼び出しを記録 します。誰が (主体)、いつ、何を (アクション)、どこから (ソース IP) 行ったかを残します。
- 管理イベント: リソースの作成・削除・設定変更など。デフォルトで記録
- データイベント: S3 オブジェクトの読み書き、Lambda 実行など高ボリューム。デフォルトで無効 (個別設定)
- 組織トレイル (Organization Trail): 全アカウントのイベントを一箇所に収集
- ログの完全性: ログファイルの検証 (integrity validation) で改ざんを検知
- CloudTrail ログを CloudWatch Logs へ送り メトリクスフィルター・アラーム (#3) をかけてリアルタイム警告
「誰がこのリソースを削除したか追跡せよ」の答えが CloudTrail です。「ルートログイン・権限変更時に即座に通知」は CloudTrail → CloudWatch Logs → アラームです。
AWS Config: 構成コンプライアンス #
Config は リソースの構成を時間に沿って記録し、ルール (Rule) でコンプライアンスを評価 します。
| 機能 | 説明 |
|---|---|
| Configuration Recorder | リソース構成の変更を継続的に記録 (タイムライン) |
| Config Rule | 「S3 は暗号化されているべき」のようなルールでコンプライアンスを評価 |
| Remediation | 違反を SSM Automation で自動修復 |
| Conformance Pack | ルールのまとまりを標準として一括デプロイ |
CloudTrail との違いが核心です。CloudTrail は 行為(誰が呼び出したか)、Config は 状態(今の構成がルールに合うか)を見ます。「暗号化されていないボリュームを見つけて自動で修復せよ」の答えが Config Rule + 自動修復です。「構成がいつどう変わったか履歴を見よ」も Config です。
GuardDuty: 脅威検知 #
GuardDuty は CloudTrail・VPC Flow Logs・DNS ログを 機械学習で分析して脅威を検知 します。ログを直接オンにしたり管理したりする必要はなく、オンにするだけで動作します。
- 異常な API 呼び出し、既知の悪意ある IP との通信、暗号通貨マイニング、認証情報の流出の兆候などを検知
- 結果 (Finding) を EventBridge で受け取り 自動対応(隔離・通知)につなぐ
- マルチアカウントは委任管理者で全アカウントを統合
「侵害の兆候・悪意ある活動を自動検知せよ」の答えが GuardDuty です。Config (コンプライアンス)・CloudTrail (記録) と違い、能動的な脅威検知 という点が区分線です。
Security Hub: 統合セキュリティ管理 #
複数のセキュリティサービス (GuardDuty・Inspector・Macie・Config) の結果を 一箇所に集めて標準化しスコア化 します。
- CIS・AWS のベストプラクティスのような セキュリティ基準 (standard) に対するコンプライアンススコア
- 全アカウントのセキュリティ結果を統合ダッシュボードで確認できます
- 結果を EventBridge で受け取り自動対応
「複数のセキュリティサービスの結果を一画面で見てベストプラクティスのコンプライアンスを点検せよ」の答えが Security Hub です。
一緒にまとめられる補助ツール #
| サービス | 検知対象 |
|---|---|
| Inspector | EC2・コンテナ・Lambda の ソフトウェア脆弱性 (CVE) を自動スキャン |
| Macie | S3 の 機密データ (個人情報) を検知 |
「S3 に個人情報があるか検知」は Macie、「インスタンス・イメージの脆弱性スキャン」は Inspector です。#9 の ECR スキャンとともに脆弱性運用の軸です。
KMS: 暗号化運用 #
データ暗号化の中心です。運用ポイントだけ押さえます。
| キーの種類 | 管理主体 |
|---|---|
| AWS マネージドキー | AWS が管理。自動ローテーション |
| カスタマーマネージドキー (CMK) | ユーザーがポリシー・ローテーション・削除を制御 |
- キーポリシー (Key Policy): キーに誰がアクセスするかを定義。クロスアカウントのキー共有の核心
- 自動ローテーション: カスタマーマネージドキーも年 1 回の自動ローテーションを設定可能
- エンベロープ暗号化: データキーでデータを、KMS キーでデータキーを暗号化
- S3・EBS・RDS などは 保存時の暗号化 (at rest) に KMS キーを指定
「暗号化キーを直接制御しクロスアカウントで共有せよ」の答えがカスタマーマネージドキー + キーポリシーです。
試験での出題パターン #
- 誰がリソースを削除したか → CloudTrail
- 構成がルールに合うか / 自動修復 → Config Rule + Remediation(SSM)
- 悪意ある・異常な行為を自動検知 → GuardDuty
- 複数のセキュリティ結果を統合・スコア化 → Security Hub
- EC2・イメージの脆弱性スキャン → Inspector
- S3 の機密データ検知 → Macie
- 暗号化キーを直接制御・クロスアカウント → KMS カスタマーマネージドキー + キーポリシー
よくある落とし穴 #
1) CloudTrail と Config の混同 #
CloudTrail は 行為(API 呼び出し)、Config は 状態(構成コンプライアンス)です。「誰が変えたか」は CloudTrail、「今ルールに合うか」は Config です。
2) GuardDuty がログ設定を要求すると思い込む #
GuardDuty はソースログを 直接オンにする必要なく 分析します。有効化するだけです。
3) S3 データイベントがデフォルトで記録されると仮定する #
CloudTrail はデフォルトでは管理イベントのみを記録します。S3 オブジェクトレベルのデータイベント は別途オンにする必要があります。
4) Security Hub が直接検知すると誤解する #
Security Hub は検知器ではなく 集約・標準化・スコア化 です。実際の検知は GuardDuty・Inspector・Config などが行います。
まとめ #
この記事で押さえたこと:
- 4 つのサービスの境界: CloudTrail (行為の記録)・Config (構成コンプライアンス)・GuardDuty (脅威検知)・Security Hub(統合スコア)
- CloudTrail は管理/データイベント、組織トレイル、完全性の検証。CloudWatch Logs 連携でリアルタイムアラーム
- Config は構成タイムライン + ルール + SSM 自動修復 + Conformance Pack
- GuardDuty はログ設定なしで 能動的な脅威検知、EventBridge で自動対応
- Inspector(脆弱性)・Macie(S3 機密データ)が補助の軸
- KMS カスタマーマネージドキー + キーポリシーで暗号化の制御・クロスアカウント共有
次: 試験のヒントとよく間違えるパターン #
5 つのドメインをすべて終えました。次は試験直前のまとめです。
#14 試験のヒントとよく間違える運用シナリオパターン では、ドメインを横断する定番の落とし穴、似たサービスを分けるキーワード、時間配分と設問の読み方、そして最後の点検リストまで整理します。