Amazon SCS-C02: 脅威検出とアラート — 学習ガイド

By Laurynas Brazys · 25 July 2026 · #amazon #scs-c02 #certification #exam-prep #study-guide

こちらの一部です： AWS Security Specialty SCS-C02 — 学習ガイド. 検証済みの解答で練習： Amazon試験ハブ, または時間制限付き模擬試験に挑戦： ExamRoll.io.

組織全体でのGuardDutyの集中管理

Amazon GuardDutyは、CloudTrailの管理イベントとデータイベント、VPCフローログ、DNSクエリログ、EKS監査ログ、RDSログインアクティビティ、およびランタイムテレメトリを分析する継続的な脅威検出サービスです。脅威の目的（Backdoor、CryptoCurrency、Recon、UnauthorizedAccess、PenTest、Policy、Stealth、Trojan、Impact）とリソースタイプ（EC2、IAMUser、S3、Kubernetes、RDS、Lambda、Runtime）によって分類された検出結果を生成します。

GuardDutyをアカウントごとに運用するのはスケールしません。AWS Organizations環境における正しいアーキテクチャは、Organizationsの管理アカウントを使用して、委任された管理者（通常は専用のセキュリティまたは監査アカウント）を指定することです。委任された管理者から、組織全体でGuardDutyを有効にし、自動有効化を切り替えることで、新しいメンバーアカウントや新しいリージョンが作成されると同時に自動的に保護されるようになります。自動有効化がない場合、新しくプロビジョニングされたアカウントは、オペレーターが手動で検出を有効にするまで監視されない状態となり、これはまさに攻撃者がオンボーディング中に悪用する隙となります。

実践的な問題：ユースケースシナリオ

シナリオ： Meridian Financialは、本番、開発、共有サービス用に28のアカウントにまたがるマルチアカウントAWS環境を運用しています。管理アカウントはAWS Organizationsを通じてアカウントを管理し、CloudTrailとS3のロギングは一元化されていますが、セキュリティアラートと調査データはメンバーアカウントに分散しており、インシデントのトリアージが遅く、一貫性がありません。

課題： あるアカウントで最近検出されたラテラルムーブメントにより、GuardDutyの検出結果が中央のSOCツールに迅速に表示されず、封じ込めとフォレンジック調査が遅れました。

推奨アプローチ：

管理アカウントで委任されたGuardDuty管理者を指定し、AWS Organizations経由で組織全体のGuardDutyを有効にして、すべてのメンバーアカウントが検出結果を中央の検出器に転送するようにします。
管理アカウントで中央集権的なAWS Security Hubをアグリゲーターとしてオンにし、すべてのアカウントとリージョンでSecurity Hubを有効にして、GuardDutyの検出結果を他のセキュリティ基準とともに正規化します。
管理アカウントでAmazon EventBridgeルールを設定し、GuardDutyとSecurity Hubの検出結果をキャプチャして、ページング用のAmazon SNS、アーカイブ用のAmazon Kinesis Data FirehoseへのS3転送、またはSIEMへの直接配信など、中央集権的なターゲットにルーティングします。
自動化された封じ込めアクション（例：EC2 APIを介してEC2インスタンスを隔離し、AWS Systems Managerインシデントを作成する）のためにEventBridgeによってトリガーされるLambdaレスポンダーを展開し、調査のために検出結果にタグを付けます。
中央集権的な調査のためにAmazon Detectiveを統合し、S3にアーカイブされた検出結果を長期的な相関分析とレポート作成のために分析/SIEMに転送します。

論理的根拠： 委任されたGuardDuty管理者をSecurity HubおよびEventBridgeと共に使用することで、検出を一元化し、アラートを正規化し、組織全体の脅威検出とタイムリーなインシデント対応に関するAWSのベストプラクティスに従って、監査可能な自動レスポンスを可能にします。

# From the Organizations management account
aws organizations enable-aws-service-access \
  --service-principal guardduty.amazonaws.com

aws guardduty enable-organization-admin-account \
  --admin-account-id 111122223333

# From the delegated admin
aws guardduty update-organization-configuration \
  --detector-id abc123 \
  --auto-enable-organization-members ALL \
  --features '[{"Name":"RDS_LOGIN_EVENTS","AutoEnable":"NEW"},
               {"Name":"EKS_AUDIT_LOGS","AutoEnable":"NEW"},
               {"Name":"RUNTIME_MONITORING","AutoEnable":"NEW"}]'

GuardDutyはリージョナルであるため、委任された管理者の関係と自動有効化の設定は、運用しているすべてのリージョンで確立する必要があります。これは頻繁に発生する死角の原因です。あるチームがus-east-1でGuardDutyを有効にし、グローバルにカバーされていると想定してしまうのです。

サービス固有の保護機能

基本的なGuardDutyは基盤となるデータソースをカバーしますが、いくつかの保護プランはコストと追加のテレメトリ取り込みを伴うため、明示的に有効にする必要があります。

RDS Protection: Aurora MySQL/PostgreSQLおよびRDSエンジンのログインアクティビティをプロファイリングし、未知のユーザーがDBエンドポイントに認証した場合などにCredentialAccess:RDS/AnomalousBehavior.SuccessfulLoginのような検出結果を生成します。これは不審なデータベースログインを検出するための正しいソースです。RDS Protectionがネイティブに検出結果を生成してくれるので、DB監査ログに対してカスタムのCloudWatchメトリクスフィルターを構築しないでください。
EKS Protection: Kubernetesの監査ログを取り込み、異常なAPIアクセス、特権ポッドの作成、公開されたダッシュボードの使用を検出します。
Runtime Monitoring: EC2、ECS/Fargate、またはEKSに軽量なeBPFベースのエージェントを展開し、プロセス、ファイル、ネットワークイベントを表面化させます。これは、ファイルレスマルウェアやリバースシェルをランタイムで検出するために必要です。
Malware Protection: 他の検出結果によってフラグが立てられたインスタンスにアタッチされたEBSボリュームをスナップショットスキャンするか、アップロード時にS3オブジェクトをオンデマンドスキャンします。
Lambda ProtectionとS3 Protection: それぞれ、関数の呼び出しパターンとデータプレーンのS3アクセスをカバーします。

基本サービスのみを有効にして、DBログインの異常が検出されることを期待するのは一般的な設定ミスです。対応する機能がオンにされるまで、その検出結果タイプは生成されません。

集約プレーンとしての Security Hub

Security Hub は、GuardDuty、Inspector、Macie、IAM Access Analyzer、Firewall Manager、Config、Health、およびサードパーティ ISV 製品からの検出結果を取り込み、AWS Security Finding Format (ASFF) に正規化します。また、独自のコンプライアンス標準 (AWS Foundational Security Best Practices、CIS、PCI DSS、NIST 800-53) も実行します。

Organization 全体で一元管理するには：

Organizations で サービスとして Security Hub を有効化し、委任された管理者を指定します (通常、GuardDuty と同じセキュリティアカウント)。
新しいアカウントの自動有効化をオンにして、メンバーが自動的に登録されるようにします。
検出結果の集約リージョン (ホームリージョンとも呼ばれる) を設定し、他のすべてのリージョンをそこにリンクします。リージョン間の集約を行わない場合、各リージョンは独立した Security Hub インスタンスを維持し、アナリストはコンソールを切り替える必要があります。

したがって、グローバルな組織展開のパターンには、集約リージョンのリンクと、組織全体の自動有効化トグルの2つの連携した設定が必要です。一方を有効にせずに他方を有効にすると、新しいアカウントがカバーされないか、新しいリージョンがサイロ化されるかのどちらかになります。

重要な制約：Security Hub は集約と優先順位付けは行いますが、修復は行いません。これを修復プラットフォームとして扱うのは根本的な誤解です。修復は後続の EventBridge を通じて行われます。

自動化ファブリックとしての EventBridge

GuardDuty と Security Hub はどちらも、デフォルトのイベントバスに検出結果をパブリッシュします。aws.guardduty は GuardDuty Finding イベントを発行し、aws.securityhub は Security Hub Findings - Imported (Hub によって作成/更新) と Security Hub Findings - Custom Action (オペレーターによってトリガー) を発行します。

{"source": ["aws.securityhub"]} のような過度に広範なルールは、すべてのプロバイダーからのすべての検出結果の更新でターゲットを呼び出し、すぐに SNS トピックを氾濫させ、情報ノイズでオンコールのエンジニアを呼び出してしまいます。正しいアプローチは、severity.Label、ProductArn、Types、または特定の Title の値でフィルタリングすることです。

{
  "source": ["aws.guardduty"],
  "detail-type": ["GuardDuty Finding"],
  "detail": {
    "severity": [{ "numeric": [">=", 7] }],
    "type": [{ "prefix": "CredentialAccess:RDS/" }]
  }
}

ノイズの多いサードパーティ ISV 製品を無視しつつ、重大度の高い GuardDuty の検出結果に対してのみ実行される Security Hub 中心のパターンの場合：

{
  "source": ["aws.securityhub"],
  "detail-type": ["Security Hub Findings - Imported"],
  "detail": {
    "findings": {
      "Severity": { "Label": ["HIGH", "CRITICAL"] },
      "ProductArn": [
        { "wildcard": "arn:aws:securityhub:*::product/aws/guardduty" }
      ],
      "Workflow": { "Status": ["NEW"] }
    }
  }
}

一般的なターゲットには、メール/SMS/Slack 通知用の SNS トピック、セキュリティグループを交換してインスタンスを隔離する Lambda 関数、SSM Automation ランブック、または複数ステップのレスポンスをオーケストレーションする Step Functions ステートマシンが含まれます。Aurora のログイン異常のユースケースでは、最も労力の少ない方法は、GuardDuty RDS Protection → RDS の検出結果タイプでフィルタリングされた EventBridge ルール → メールサブスクリプション付きの SNS トピック、という流れです。カスタムポーリング、Lambda、サードパーティの SIEM は不要です。

Security Hub のカスタムアクション

カスタムアクションは、オペレーター主導のトリガーです。Security Hub コンソールで、アナリストが1つ以上の検出結果を選択し、カスタムアクション (例: “Quarantine EC2”) を選択します。Security Hub は、選択された検出結果の ARN を含む Security Hub Findings - Custom Action イベントを発行します。EventBridge ルールがカスタムアクションの ARN にマッチし、レスポンスを実行する Lambda を呼び出します。これにより、専用の UI を構築することなく、人間の介入を可能にするボタンを実現できます。

aws securityhub create-action-target \
  --name "Quarantine EC2" \
  --description "Attach isolation SG and snapshot volumes" \
  --id QuarantineEC2

結果として得られる ARN (arn:aws:securityhub:us-east-1:111122223333:action/custom/QuarantineEC2) は、EventBridge ルールの resources フィールドのマッチ値になります。

抑制とシグナル管理

ノイズ管理は、一度きりのフィルターではなく、継続的な規律です。Security Hub の自動化ルールや GuardDuty の抑制ルールを使用して、既知の良性である検出結果 (例えば、ペネトレーションテストツールによる想定内の Recon:EC2/Portscan 検出結果など) を自動的にアーカイブします。ProductArn で EventBridge ルールをフィルタリングして、ノイズの多いサードパーティ統合を完全に無効化することなくサイレントにします。Severity.Label と Workflow.Status = NEW を組み合わせて、再オープンされた、または通知済みの検出結果が再度ページングされないようにします。目標は、人間に届くすべてのアラートが、対応可能で信頼性の高いイベントを表すようにすることです。それ以外のものは、対応準備体制を蝕みます。

調査のピボット

重大度の高い検出結果 (例: Backdoor:EC2/C&CActivity.B!DNS) が発生した場合、最も迅速な調査方法は、CloudTrail や Flow Logs に対して手動で Athena クエリを作成することではありません。Amazon Detective を GuardDuty とともに有効にすると、CloudTrail、VPC Flow Logs、および GuardDuty の検出結果からエンティティグラフを事前に構築します。検出結果から Detective の IAM ロールや EC2 インスタンスプロファイルに直接ピボットすることで、カスタムクエリの作業なしで、関連する期間にわたる API アクティビティ、ネットワークピア、成功/失敗した接続数を表示できます。

← アイデンティティとアクセス管理 · すべてのドメイン · ロギング、監査、フォレンジック →

これらの問題を練習する → · ExamRoll.ioで時間制限付き練習 →