Amazon Detective

Amazon Detective は、AWS 環境のさまざまなログを自動的に取り込んで関連付け、エンティティ間の関係や時系列の挙動を可視化することで、セキュリティインシデントの原因調査を支援するマネージド型サービスです。調査に必要なデータの収集・正規化・相関付けをサービス側が担うため、利用者は分析基盤を自前で構築せずに調査作業に集中できます。

解決する課題

セキュリティの脅威が検知された後、その原因や影響範囲を特定する調査（インシデントレスポンスのトリアージ）には多くの手間がかかります。攻撃の起点となった認証情報はどれか、どのリソースが関与したか、いつから異常な挙動が始まったかといった問いに答えるには、VPC フローログ、CloudTrail、各種検出結果などを横断的に突き合わせる必要があります。

これらのログを手作業で収集・結合・分析するのは負荷が高く、調査の属人化や見落としにつながりがちです。Detective は、必要なログを継続的に取り込んで関係性をグラフ構造として整理し、視覚的な分析ビューを提供することで、原因究明にかかる時間を短縮します。検知（脅威の発見）の次に来る「調査」のフェーズを支援する点が特徴です。

主要概念と用語

• 動作グラフ（Behavior graph）: Detective が取り込んだログから構築する、エンティティとその関係を表すグラフ構造。調査の基盤となるデータモデル。
• エンティティ（Entity）: グラフ上のノードに相当する分析対象。IAM ロール、ユーザー、EC2 インスタンス、IP アドレスなどが該当する。
• 検出結果（Finding）: GuardDuty などが生成した脅威の兆候。Detective ではこれを調査の起点として利用できる。
• 検出結果グループ（Finding group）: 関連する複数の検出結果やエンティティをまとめ、一連のインシデントとして俯瞰できるようにした単位。
• プロファイルパネル: 特定のエンティティや検出結果について、時系列の挙動やアクセス傾向を集約して表示するビュー。
• データソース: 動作グラフの構築に使う入力。VPC フローログ、AWS CloudTrail の管理イベント、GuardDuty の検出結果などが基盤となる。
• 管理者アカウント / メンバーアカウント: マルチアカウント構成で動作グラフを統括するアカウントと、その配下で分析対象となるアカウント。
• 委任管理者アカウント: AWS Organizations 連携時に、組織全体の Detective を統括するために指定するアカウント。

仕様・制限・クォータ

Detective はリージョンごとに有効化するサービスであり、調査したいリージョンそれぞれで動作グラフを構築する必要があります。基盤となるログソースは Detective が内部的に取り込むため、利用者が VPC フローログなどを別途有効化しておく必要はありません。有効化後、取り込んだデータが蓄積されて分析可能になるまでには一定の準備期間がかかります。

動作グラフには取り込んだデータの保持期間があり、一定期間より前のデータは分析対象から外れます。1 つの動作グラフに含められるメンバーアカウント数や、アカウントあたりの動作グラフ数などにはサービスクォータが設定されています。具体的な保持日数やクォータの上限値は変動しうるため、最新の公式ドキュメントとサービスクォータの値を確認してください。

内部の仕組み

Detective は、対象アカウント・リージョンのログを継続的に取り込み、機械学習や統計的な手法を用いて、エンティティ間の関係や通常時の挙動の傾向を抽出します。これらを動作グラフとして集約し、ベースラインからの逸脱や時間的な変化を可視化できる形に整理します。基本機能ではエージェントのインストールは不要で、AWS 側のテレメトリを利用するエージェントレスな構成です。

調査時には、検出結果や特定のエンティティを起点として動作グラフをたどり、関連するリソースやアクティビティを視覚的に追跡できます。たとえば、ある IAM ロールの API 呼び出し回数の推移や、あるインスタンスの通信先 IP の傾向を時系列で確認し、いつ異常が始まったかを把握できます。GuardDuty や AWS Security Hub と統合されており、それらの画面から該当する検出結果を Detective の調査ビューへ引き継いで分析を続けられます。

設計パターン / ベストプラクティス

代表的な構成は、AWS Organizations と連携し、委任管理者アカウントから組織全体の Detective を一元管理するパターンです。GuardDuty や Security Hub と同じ委任管理者に揃えておくと、検知から調査までの流れがスムーズになり、運用も統一できます。

Detective は単独で使うよりも、脅威検知サービスと組み合わせて「検知の次の調査」を担わせるのが効果的です。GuardDuty の検出結果をきっかけに Detective で深掘りし、影響範囲を特定したうえで対応につなげる流れを定型化しておくと、インシデント対応の再現性が高まります。調査の対象に合わせて、必要なリージョンで動作グラフを用意しておくことも重要です。

運用・監視

日々の運用では、GuardDuty や Security Hub で発生した検出結果のうち、深掘りが必要なものを Detective に引き継いで調査します。検出結果グループを使うと、関連する複数の兆候を一連のインシデントとして俯瞰でき、全体像の把握に役立ちます。プロファイルパネルで時系列の挙動を確認し、異常の起点や波及範囲を特定します。

Detective が有効化されているリージョンや、組織内のメンバーアカウントの取り込み状況を定期的に点検し、調査対象に漏れがないようにします。インシデント対応のプロセスの中に Detective を使った調査ステップを組み込み、調査手順を文書化しておくと、対応の品質が安定します。

コスト

Detective の料金は、主に動作グラフへ取り込んで分析したデータの量に基づく従量課金です。VPC フローログや CloudTrail、検出結果といったログの取り込み量が多い環境ほど、分析対象のデータ量が増え、コストも増加します。アカウント数やトラフィックの規模が大きい組織ほど取り込み量が増える傾向があります。

新規利用者向けには一定期間の無料トライアルが提供されることが一般的で、本格運用前にデータ量とコスト感を把握できます。これを活用して有効化範囲を判断すると安全です。

セキュリティ

Detective は調査に特化したサービスであり、ログを取り込む際に対象リソースの設定を変更することは基本的にありません。動作グラフや調査ビューへのアクセスは AWS IAM のポリシーで制御し、管理者アカウントとメンバーアカウントの権限を最小権限の原則に沿って設計します。

調査の過程で扱うデータには、アクセス元 IP や API 操作の履歴など機密性の高い情報が含まれます。これらを参照できる担当者を適切に限定し、調査担当者のロールに必要な権限のみを付与します。Detective は検知・防御の各サービスと組み合わせ、インシデント対応のライフサイクル全体を支える一要素として位置づけます。

Well-Architected の観点

セキュリティの柱の観点では、Detective はインシデント発生後の調査と原因究明を支援し、対応の質とスピードを高めます。検知（GuardDuty）、集約（Security Hub）、調査（Detective）という役割分担を明確にすることで、検知から対応までの一連の流れを体系化できます。

調査手順を定型化し、必要なログを継続的に取り込んでおくことは、インシデント対応の準備態勢の強化につながります。原因や影響範囲を素早く特定できる仕組みを整えておくことで、被害の拡大を抑え、復旧までの時間を短縮できます。

試験で問われるポイント

関連サービス・比較

Amazon GuardDuty は、ログを継続分析して脅威を自動検知するサービスです。GuardDuty が脅威を「見つける」役割を担うのに対し、Detective はその検出結果を起点に原因や影響範囲を「調べる」役割を担います。両者は競合ではなく、検知から調査へとつなげて組み合わせて使うのが一般的です。

ハンズオン / CLI例

次の例は、現在のリージョンで Detective を有効化して動作グラフを作成し、その一覧やメンバー状況を確認するものです。

# Detective を有効化して動作グラフを作成
aws detective create-graph

# 作成済みの動作グラフ（GraphArn）の一覧を確認
aws detective list-graphs

# 動作グラフの ARN を変数に格納
GRAPH_ARN=$(aws detective list-graphs --query 'GraphList[0].Arn' --output text)

# 動作グラフに含まれるメンバーアカウントの状況を確認
aws detective list-members --graph-arn "$GRAPH_ARN"