AWS のセキュリティ監視は Config（設定監査）、Security Hub（統合管理）、GuardDuty（脅威検知）、 Macie（データ分類） の 4 つを組み合わせて設計します。本記事ではこれらを統合したセキュリティ監視アーキテクチャを SAA / SAP 両面から整理します。

SAA レベル：基礎概念

4 つのサービスの役割

サービス	役割	一言説明
AWS Config	設定変更の記録・監査	「何がどう変わったか」
Security Hub	セキュリティ状況の統合管理	「セキュリティスコアの統合表示」
GuardDuty	脅威検知（IDS/IPS 相当）	「不正行動の検知」
Macie	機密データの発見・分類	「どこに機密データがあるか」

SAA レベル：基礎概念

4 つのサービスは 「設定監査 + 統合管理 + 脅威検知 + データ分類」 の補完関係にあります。

Config は 過去の設定変更履歴 を記録
GuardDuty は 現在の不正行動 を検知
Macie は 機密データの所在 を特定
Security Hub はこれらを 統合して可視化 この役割分担が SAA の基礎です。

AWS Config の基本

Config は リソースの設定変更を記録・評価 するサービスです。

設定記録 (Configuration Recording): リソースの設定変更を継続記録
Config Rules: 設定がルールに違反していないか評価
修復アクション: 違反時の自動修復 (SSM Automation)
変更通知: EventBridge 経由で変更イベントを通知

SAA 試験のポイント

Config は 「過去の設定状態にいつでも戻れる」 ことを可能にします。「あるセキュリティグループがいつ誰によって変更されたか」を追跡するのが Config の代表ユースケース。 SAA では「設定変更の監査」ツールとして押さえます。

GuardDuty の基本

GuardDuty は 脅威検知サービス で、AWS 環境内の不正行動を検知します。

入力ソース: CloudTrail ログ、VPC Flow Logs、DNS ログ
検知内容: 不正ログイン、マルウェア C2 通信、権限昇格、 cryptomining 等
機械学習ベース: 異常検知、脅威インテリジェンス連携
検知結果 (Finding): EventBridge 経由で通知・自動対応

SAA 頻出

GuardDuty は CloudTrail + VPC Flow Logs + DNS ログ を入力に使いますが、 これらのログを自分で有効化する必要はありません（GuardDuty が自動で取得）。「VPC Flow Logs を別途有効化する必要があるか？」というひっかけが SAA で出ます。

Security Hub の基本

Security Hub は 複数のセキュリティサービスの検知結果を統合 します。

統合対象: GuardDuty, Macie, Inspector, IAM Access Analyzer, Config Rules 等
セキュリティスコア: CIS AWS Foundations Benchmark 等の準拠状況をスコア化
Findings 統合: 全サービスの検知結果を一箇所に集約
優先度付け: 検知結果を重大度で優先順位付け

Macie の基本

Macie は S3 バケット内の機密データを自動発見・分類 します。

対象: S3 バケット内のデータ
検知内容: 個人情報 (PII)、クレジットカード番号、AWS 認証情報等
機械学習ベース: パターン認識で機密データを特定
評価: バケットのアクセス権限も評価（公開リスクの検知）

Macie の対象範囲

Macie は S3 バケット内のデータが対象 です。 RDS のデータや EBS 上のファイルは直接対象外（S3 にエクスポートすれば対象）。 SAA では「S3 内の機密データ発見」ツールとして押さえます。

SAP レベル：高度な設計シナリオ

委任管理者 (Delegated Administrator) 設計

SAP では セキュリティサービスの管理権限を Audit アカウントに委任 します。

SAP レベル：高度な設計シナリオ

Organizations 環境では GuardDuty / Security Hub / Macie / Inspector の管理権限を Audit アカウントに委任 するのが定石です。これにより、管理アカウントの権限集中を避けつつ、 全メンバーアカウントのセキュリティ状況を Audit アカウントから一元管理 できます。

[管理アカウント]
  (委任設定のみ)
       │
       ▼ (Delegated Administrator)
[Audit アカウント]
  ├── GuardDuty 管理者 ── 全メンバーアカウントの脅威検知
  ├── Security Hub 管理者 ── 全メンバーアカウントの統合管理
  ├── Macie 管理者 ── 全メンバーアカウントのデータ分類
  └── Inspector 管理者 ── 全メンバーアカウントの脆弱性スキャン
       │
       ▼ (自動的にメンバーアカウントへ)
[各ワークロードアカウント] (メンバーとして自動参加)

Config Aggregator によるマルチアカウント集約

Config は Aggregator 機能で複数アカウント・複数リージョンの設定を集約します。

集約方式	説明	設計論点
組織集約	Organizations 配下の全アカウントを自動集約	新規アカウント自動対象
個別アカウント集約	指定アカウントを集約	段階導入向け

Config Aggregator の論点

組織集約を使うと 新規アカウントが組織に追加された瞬間に Config 集約対象に自動追加 されます。「新規アカウントの監査漏れ」を構造的に防げるため、SAP では組織集約が推奨です。

GuardDuty の検知と自動対応

GuardDuty が検知した Findings を EventBridge → Lambda / SSM で自動対応します。

[GuardDuty] ──(Finding)── [EventBridge]
                              │
                ┌─────────────┼─────────────┐
                ▼             ▼             ▼
          [Lambda]      [SSM Automation]  [SNS]
          (IAM 削除)    (SG 隔離)        (通知)

Finding 種別	自動対応アクション	設計論点
UnauthorizedAccess /…	IAM アクセスキー無効化	即時隔離
UnauthorizedAccess /…	セキュリティグループ隔離	ネットワーク遮断
Backdoor /…	EC2 インスタンス停止	被害拡大防止
CryptoCurrency /…	インスタンス終了	コスト被害防止

自動対応の設計上の注意

自動対応は強力ですが 誤検知による影響 に注意が必要です。例えば「正規の保守作業が不正ログインと誤検知」されると、正規 IAM が無効化される事故に。段階導入（まず通知のみ → 検知精度確認 → 自動対応）が SAP の定石です。

Security Hub のカスタム標準

Security Hub は AWS 標準 (CIS, PCI DSS 等) に加え、カスタム標準 を定義できます。

カスタム標準: 組織独自のセキュリティ要件をルール化
標準の統合: 複数標準（CIS + 社内標準）を同時適用
結果の優先度付け: Findings を重大度で分類

カスタム標準の活用

「自社コンプライアンス要件」を Security Hub のカスタム標準として実装すると、 全アカウントで一貫したセキュリティ評価 が可能になります。例: 「全 S3 バケットはバージョニング有効」「全 IAM ユーザーは MFA 必須」等をルール化。 SAP のガバナンス設計で重要な手法です。

Macie によるデータ分類と自動対応

Macie が機密データを検知した際の対応フロー：

[Macie] ──(Finding: S3 バケットに PII 検出)
       │
       ▼
[EventBridge] ── [Lambda]
                    │
                    ├── バケット公開状態確認
                    ├── 必要に応じてパブリックアクセス遮断
                    └── 所有者へ通知

Macie とデータガバナンス

Macie で 「どの S3 バケットに PII があるか」 を継続スキャンし、公開バケットに PII があれば即座に遮断する構成が SAP のデータガバナンス定石です。「機密データがどこにあるか分からない」状態を構造的に防げます。

統合セキュリティアーキテクチャ

4 つのサービスを統合した SAP の全体アーキテクチャ：

[各ワークロードアカウント]
  ├── Config (設定記録) ─────┐
  ├── GuardDuty (脅威検知) ──┤
  ├── Macie (データ分類) ────┤
  └── Inspector (脆弱性) ────┘
                              │ (全て集約)
                              ▼
                      [Security Hub (Audit アカウント)]
                              │
                              ├── 統合ダッシュボード
                              ├── CIS スコア
                              └── Findings → EventBridge → 自動対応

SAP レベル：高度な設計シナリオ

SAP の統合セキュリティの完成形は 「4 サービスの検知結果を Security Hub に集約 → EventBridge で自動対応 → CloudTrail で全プロセスを監査」 です。「検知 → 対応 → 監査」の閉ループを設計できるかが SAP の核心論点です。

自動修復の設計パターン

検知	自動修復	実装
SG が 0.0.0.0/0 を許可	SG ルール削除	Config Rule + SSM Automation
IAM ユーザーが MFA なし	MFA 設定を要求	Config Rule + Lambda 通知
S3 バケットがパブリック	パブリックアクセス遮断	Config Rule + Lambda
GuardDuty 脅威検知	対象リソース隔離	EventBridge + Lambda

修復の設計上の原則

自動修復は 「安全な状態に戻す方向」 で設計します。「検知したら即削除」ではなく「検知したら隔離して人間が確認」が基本姿勢。過剰な自動削除は本番ワークロードを停止させるリスクがあります。SAP の慎重設計論点です。

制約とコスト

サービス	課金モデル	コスト論点
Config	設定項目ごとの課金	記録対象を絞らないと高額
GuardDuty	分析イベントごとの課金	全アカウント有効化で増大
Security Hub	評価ごとの課金	標準数で変動
Macie	分析データ量ごとの課金	対象バケット絞り込みが重要

コスト最適化の論点

これらのサービスは 全アカウント・全リージョン有効化 で効果を発揮しますが、コストも比例して増大します。SAP では「どのアカウント・どのリージョンで有効化するか」の費用対効果判断が求められます。本番・セキュリティ重要アカウントを優先する段階導入が定石です。

まとめ

SAA: 4 つのサービスの役割分担（Config=監査, GuardDuty=脅威検知, Macie=データ分類, Security Hub=統合）を理解する。
SAP: 委任管理者設計、Config Aggregator、GuardDuty 自動対応、カスタム標準、統合アーキテクチャの閉ループ設計が求められる。

次は ログ集約設計 で、CloudTrail / CloudWatch / OpenSearch の統合ログ基盤を学びましょう。