Amazon Detective 完全ガイド v2.0

初心者から実務者向けの包括的解説

Amazon Detective は、機械学習、統計分析、グラフ理論を駆使して AWS 環境全体の 継続的なセキュリティ調査・インシデント対応を自動化するグラフベースフォレンジック分析サービス です。CloudTrail・VPC フローログ・GuardDuty 検出結果・EKS 監査ログ・Route 53 Resolver クエリログを自動相関分析し、複数のエンティティ（IAM ロール・EC2 インスタンス・IP アドレス・S3 バケット）間の関係性と時系列を可視化します。GuardDuty で検出されたアラートから Detective へのワンクリック遷移で、根本原因調査・影響範囲特定・インシデント対応時間を 90% 削減できるため、SOC（Security Operations Center）・SRE・DevSecOps チームの必須基盤として採用されています。本ドキュメントは、Detective の仕組み・Behavior Graph・Investigation ワークフロー・マルチアカウント対応・ベストプラクティス・2025-2026 最新動向を体系的に解説する完全ガイドです。

ドキュメントの目的

本ガイドは以下を対象としています。

• セキュリティ初心者向け： Detective とは何か、GuardDuty との違いを学びたい方
• クラウドアーキテクト向け： マルチアカウント環境でのインシデント対応自動化を設計したい方
• DevSecOps/SRE 向け： GuardDuty Findings から Detective Investigation、EventBridge 自動対応までのパイプライン構築
• セキュリティ管理者向け： Organization 統合、複数アカウント Detective 管理、Findings グルーピング
• インシデント対応者向け： Behavior Graph 解釈、Investigation 実行、MITRE ATT&CK マッピング活用
• 意思決定者向け： Detective vs Splunk/Datadog/Sumo Logic との選択基準

2025-2026 年の Detective エコシステム

• Detective Investigation GA： ML ベース IOC（Indicators of Compromise）検出、自動リスク評価
• Security Lake 深度統合： CloudTrail・VPC Flow Logs・EKS Audit Logs の直接クエリ
• Findings Group 自動生成： 関連 GuardDuty Findings の自動グループ化・時系列ビジュアライゼーション
• Organization管理の簡素化： 管理アカウント一元管理、メンバーアカウント自動有効化
• MITRE ATT&CK 自動マッピング： Detective findings を ATT&CK フレームワークに自動対応付け
• Real-time Threat Correlation： 複数データソースのリアルタイム相関分析

定義

AWS 公式による定義：

“Amazon Detective helps you analyze, investigate, and quickly identify the root cause of security findings or suspicious activities. Detective automatically collects log data from your AWS resources and uses machine learning, statistical analysis, and graph theory to generate visualizations that help you conduct faster and more efficient security investigations.”

目次

1. 概要
2. Detective が解決する課題
3. 主な特徴
4. アーキテクチャ
5. Behavior Graph 完全解説
6. Investigation ワークフロー
7. Finding Groups・自動グループ化
8. エンティティプロファイル・ベースライン分析
9. データソース完全解説
10. Security Lake 統合
11. マルチアカウント・Organization 管理
12. 主要ユースケース（12+）
13. 設定・操作の具体例（Console/CLI/SDK/IaC）
14. GuardDuty・Security Hub との統合
15. EventBridge・Lambda との自動対応
16. 類似サービス比較表
17. ベストプラクティス
18. トラブルシューティング表
19. 2025-2026 最新動向
20. 学習リソース・参考文献
21. 実装例・導入ロードマップ
22. 実装チェックリスト
23. コスト・プライシング
24. まとめ

概要

初心者向けメモ： Detective は「GuardDuty で検出したアラートの根本原因を追跡・調査する専門家アナリスト」です。GuardDuty が「何が起きたか」を教えたら、Detective は「なぜ・どのように・どの範囲に影響したか」を自動分析。CloudTrail・VPC ログから自動的にデータを吸収し、機械学習で正常行動パターンを学習してから、異常を検出すると Finding を生成します。複数エンティティの関係性を Behavior Graph という知識グラフで可視化し、攻撃者の行動経路・侵害されたリソース全体・金銭的影響をグラフで可視化できます。

Detective は、以下を実現する統合フォレンジック分析プラットフォームです。

Detective が解決する課題

1. GuardDuty アラート後の手動調査負担

課題：GuardDuty が「IAM ロール X で不正 API 呼び出し検出」と報告 → セキュリティ担当者が CloudTrail・VPC ログを手動検索して原因特定に数時間要費 Detective の解決：1 クリックで Behavior Graph を表示、過去 90 日間のロール X の全活動・通信先・アクセスリソース・異常スコアを即座に可視化。調査時間を数分に短縮

2. 単一アラートでは全容が見えない

課題：複数の GuardDuty Findings（「不正 IP からのログイン」「Lambda から S3 データ流出」「Crypto mining 検出」）が同一攻撃か別事象かが不明瞭 Detective の解決：Finding Groups が自動グループ化、関連 Findings を時系列でビジュアル化。同一攻撃者による一連の行動として可視化でき、誤検知の除外・優先度判定が効率化

3. 影響範囲の把握が困難

課題：侵害されたIAM ロール / EC2 が他にどのリソースへアクセスしたか、データ流出スコープが定量化できない Detective の解決：Behavior Graph でエンティティ間の関係を追跡。「ロール A → 引き受け元 λ → アクセス先 S3 バケット B」という経路をグラフで表示、影響リソースを最小限化

4. 複雑なマルチアカウント環境での統一見解の欠如

課題：複数 AWS アカウント環境で各アカウントの Detective を個別チェック、全体像が見えない Detective の解決：Organization 統合で管理アカウント一元管理、全メンバーアカウントの Finding を集約。MITRE ATT&CK マッピングで戦術レベルの脅威を統一分析

5. 人手に頼る検査プロセスのスケーリング困難

課題：SOC チーム 3 名で月 500 件の GuardDuty Finding をトリアージ → 本当の脅威見落とし・対応遅延 Detective の解決：Investigation で ML ベース IOC 検出・リスク自動評価。本当のインシデント候補を自動ランク付け、SOC は高リスク案件に専念可能

主な特徴

1. Behavior Graph（行動グラフ）

Detective の核となるデータ構造。CloudTrail・VPC ログから抽出したイベント（API 呼び出し・ネットワーク通信・ロール引き受け）をグラフモデル化。

ノード（Vertices）：AWS リソース（IAM ロール・EC2 インスタンス・IP アドレス・S3 バケット・ログイングループ） エッジ（Edges）：エンティティ間のアクション（ロール A がロール B を引き受け、EC2 C が IP D と通信、等） 時系列属性：各エッジにタイムスタンプを記録、異常な時刻・量・頻度を検出

2. Investigation ワークフロー

1. IoC（Indicators of Compromise）の自動検出：ML が通常行動からの逸脱を分析
2. リスク自動評価：IOC の信頼度スコア（0-100）を自動算出
3. 時系列ビジュアライゼーション：疑わしい活動を時間軸で表示
4. エンティティプロファイル参照：該当リソースの過去 90 日ベースライン比較
5. 根本原因推定：初期侵害・C&C 通信・データ流出といった MITRE 戦術を自動マッピング

3. Finding Groups（自動グループ化）

複数の GuardDuty Findings を自動グループ化、一連の攻撃活動として可視化。

グループ化ロジック：

• 同一 IP・ロール・リソースへの複数 Findings
• 時間的に隣接した複数イベント
• MITRE ATT&CK 脅威カテゴリの関連性

4. Entity Profile（エンティティプロファイル）

すべての AWS リソース（IAM ロール・EC2 インスタンス・IP）の行動ベースラインを ML で自動学習。

学習対象データ：

• API 呼び出しの種類・量・時間帯
• ネットワーク通信先・量・プロトコル
• ロール引き受けの頻度・源
• S3 オブジェクトアクセスパターン

異常検出：ベースラインから逸脱すると Finding として記録

アーキテクチャ

┌─────────────────────────────────────────────────────────┐
│                    AWS 環境全体                         │
├─────────────────────────────────────────────────────────┤
│                                                         │
│  ┌──────────────┐  ┌──────────────┐  ┌──────────────┐ │
│  │ CloudTrail   │  │ VPC Flow Log │  │ GuardDuty    │ │
│  │ (API呼び出し) │  │ (ネット通信)  │  │ Findings     │ │
│  └──────┬───────┘  └──────┬───────┘  └──────┬───────┘ │
│         │                 │                 │         │
│  ┌──────────────────┬──────────────────┬───────────────┐
│  │   Route 53       │  EKS Audit Log   │ CloudWatch    │
│  │   Query Logs     │  (K8s API)       │ Logs          │
│  └──────┬───────────┴──────┬───────────┴──────┬────────┤
│         │                  │                  │        │
│         └──────────────────┴──────────────────┘        │
│                     │                                  │
│         ┌───────────▼──────────────┐                  │
│         │  Detective Data Ingestion│                  │
│         │  (自動ログ取得・正規化)     │                  │
│         └───────────┬──────────────┘                  │
│                     │                                  │
│         ┌───────────▼──────────────┐                  │
│         │  Behavior Graph          │                  │
│         │  (グラフモデル構築)       │                  │
│         │  - Nodes (IAM,EC2,IP)    │                  │
│         │  - Edges (関係性)        │                  │
│         │  - Timeline             │                  │
│         └───────────┬──────────────┘                  │
│                     │                                  │
│         ┌───────────▼──────────────┐                  │
│         │  ML & 統計分析            │                  │
│         │  - 異常検出              │                  │
│         │  - IoC生成               │                  │
│         │  - MITRE マッピング      │                  │
│         └───────────┬──────────────┘                  │
│                     │                                  │
│  ┌──────────────────▼──────────────────┐              │
│  │      Detective コンソール             │              │
│  │  ┌─────────────────────────────┐   │              │
│  │  │ Investigation Result        │   │              │
│  │  │ - Finding Groups            │   │              │
│  │  │ - Entity Timeline           │   │              │
│  │  │ - Behavior Baseline         │   │              │
│  │  │ - Related Findings          │   │              │
│  │  └─────────────────────────────┘   │              │
│  └──────────────────┬───────────────────┘              │
│                     │                                  │
│         ┌───────────▼──────────────┐                  │
│         │  EventBridge integration │                  │
│         │  ↓自動対応               │                  │
│         │  - Lambda 実行           │                  │
│         │  - SNS 通知              │                  │
│         │  - リソース隔離          │                  │
│         └──────────────────────────┘                  │
│                                                       │
└─────────────────────────────────────────────────────────┘

Behavior Graph 完全解説

グラフ構築プロセス

1. データ取得：CloudTrail（API）・VPC Flow Logs（ネットワーク）・GuardDuty Findings（脅威シグナル）を自動吸収
2. イベント正規化：異なるログ形式を統一スキーマに変換
3. エンティティ抽出：ログから IAM ロール・EC2・IP・リソースを識別
4. リレーション構築：エンティティ間の関係性（API 呼び出し・通信・ロール引き受け）をエッジで表現
5. タイムライン付与：各イベントに正確なタイムスタンプを記録
6. グラフストレージ：構築グラフを Detective バックエンド DB に永続化

グラフクエリ例

Q: 「ロール X が過去 90 日間にアクセスしたすべてのリソースを追跡」
→ Behavior Graph から ロール X のすべての「出次数エッジ」を取得
→ API 呼び出し先リソース・S3 バケット・DynamoDB テーブルをリスト化

Q: 「IP Y から侵害されたロール経由でアクセスされたリソースを追跡」
→ IP Y ノード → 引き受け元ロール → API アクション先リソース
→ 3 段階のパスを可視化、データ流出スコープを定量化

Q: 「正常な EC2 インスタンス A と比べ、疑わしい EC2 インスタンス B の通信先の異常度を比較」
→ A のベースライン通信先リスト（許可リスト）と B の実際通信先をグラフで比較
→ 許可リスト外の通信を異常度スコアで表示

Investigation ワークフロー

ステップバイステップガイド

Step 1: Investigation 対象を選択

Console から対象 IAM ロール / EC2 インスタンスを選択、または API で StartInvestigation を呼び出し。

# AWS CLI
aws detective start-investigation \
  --graph-arn arn:aws:detective:us-east-1:123456789012:graph/12a345b6-78cd-9012-3456-789012345678 \
  --entity-arn arn:aws:iam::123456789012:role/SuspiciousRole

Step 2: ML 分析 & IoC 検出

Detective が対象エンティティの 30-90 日の行動を ML 分析。

• 通常行動ベースラインとの比較（API 呼び出し種・量・時間帯）
• 脅威インテリジェンスとの照合（既知悪意 IP・ドメイン）
• MITRE ATT&CK マッピング（初期侵害・C2・データ流出等）

Step 3: Finding Groups 自動生成

関連 GuardDuty Findings を自動グループ化。

Finding Group: "Possible Crypto Mining Activity"
├── Finding 1: "CryptoCurrency.Behavior!CryptoCoinMiningBehavior"
│   └── Time: 2026-04-20 14:32:15Z
├── Finding 2: "UnauthorizedAccess.Behavior!UnauthorizedAccess"
│   └── Associated IP: 198.51.100.42 (Known Crypto Mining ISP)
└── Finding 3: "Impact.Behavior!S3DataExfiltration"
    └── 450 GB transferred to suspicious S3

Step 4: Entity Timeline 表示

対象エンティティの時系列活動を可視化。

Timeline for Role: SuspiciousRole
└─ [2026-04-20 10:00:00] AssumeRole from 198.51.100.1 (Unusual IP)
└─ [2026-04-20 10:05:23] AssumeRole 成功 → AccessKeyId created
└─ [2026-04-20 10:15:47] EC2 Instance i-1234567890abcdef0 へのSSH接続試行 ✗
└─ [2026-04-20 10:22:14] GetObject 1000+ S3 bucket-name オブジェクト (異常な量)
└─ [2026-04-20 10:28:45] GetSecretValue for DB credentials
└─ [2026-04-20 10:35:12] RDS データベース クエリ実行（権限外のアカウント列取得）
└─ [2026-04-20 10:42:38] PutObject to arn:aws:s3:::exfil-bucket/ (外部リージョン)

Step 5: Behavior Baseline 比較

SuspiciousRole の行動ベースライン（過去 60 日正常時）
├─ 平均 API 呼び出し / 日：120
├─ 通常アクセス時間帯：09:00-17:00 JST
├─ 通常通信先：内部 VPC のみ
└─ 許可 API：DescribeInstances, ListBuckets, GetObject

異常な活動（2026-04-20）
├─ API 呼び出し / 日：2,400 (ベースラインの20倍!)
├─ アクセス時間帯：深夜 10:00-10:45 (異常)
├─ 通信先：外部 IP 198.51.100.* (異常)
└─ 新規 API：GetSecretValue, CreateAccessKey (権限外)

Step 6: Related Findings & Correlated Entities

Related Findings (関連検出)
├─ GuardDuty Finding: "Trojan.Behavior!Trojan"
├─ GuardDuty Finding: "CryptoCurrency.Behavior!CryptoCoinMiningBehavior"
└─ Security Hub Finding: "PCI-DSS Compliance Violation"

Correlated Entities (関連エンティティ)
├─ IP Address: 198.51.100.42 (Communication Source)
│   └─ First Seen: 2 hours ago
│   └─ Threat Intelligence: "Known Crypto Mining ISP"
├─ EC2 Instance: i-1234567890abcdef0 (Laterally Compromised)
├─ S3 Bucket: sensitive-data-bucket (Data Exfiltration Target)
└─ IAM User: developer-john (Potential Initial Compromise Point)

Step 7: Severity & Actionability スコア

Overall Risk Score: 94/100 (CRITICAL)
├─ Confidence Level: 96% (Very High)
├─ Potential Impact: 450 GB data breach exposure
├─ Attack Chain: Initial Access → Lateral Movement → Data Exfiltration
└─ Recommended Actions:
    1. Immediately revoke all access keys for SuspiciousRole
    2. Isolate EC2 instance i-1234567890abcdef0
    3. Audit all accessed S3 buckets for unauthorized reads
    4. Monitor external IP 198.51.100.42 & related IPs

Finding Groups・自動グループ化

Finding Group の構成要素

graph TD
    A[GuardDuty Findings<br/>複数件] -->|自動相関| B[Finding Group]
    B -->|ビジュアライゼーション| C[関連検出<br/>リスト]
    B -->|時系列分析| D[攻撃経路<br/>タイムライン]
    B -->|エンティティ追跡| E[影響リソース<br/>マッピング]
    C --> F{セキュリティ<br/>判定}
    D --> F
    E --> F
    F -->|本脅威| G[インシデント<br/>エスカレーション]
    F -->|誤検知| H[Findings<br/>除外/抑制]

Finding Group の例

{
  "GroupId": "group-abc123def456",
  "Severity": "HIGH",
  "CreatedAt": "2026-04-20T10:32:15Z",
  "Findings": [
    {
      "FindingId": "finding-1",
      "Type": "UnauthorizedAccess.Behavior.CryptocurrencyMining",
      "Severity": "HIGH",
      "Resource": "arn:aws:iam::123456789012:role/SuspiciousRole",
      "Time": "2026-04-20T10:22:14Z"
    },
    {
      "FindingId": "finding-2",
      "Type": "Behavior.S3DataExfiltration",
      "Severity": "HIGH",
      "Resource": "arn:aws:s3:::sensitive-data-bucket",
      "Time": "2026-04-20T10:35:12Z",
      "Details": "450 GB transferred to external IP"
    },
    {
      "FindingId": "finding-3",
      "Type": "Impact.Behavior.UnauthorizedAPICall",
      "Severity": "MEDIUM",
      "Resource": "arn:aws:rds:us-east-1:123456789012:db:production",
      "Time": "2026-04-20T10:42:38Z"
    }
  ],
  "AttackSequence": [
    "Initial Access: Compromised IAM credentials (IP 198.51.100.42)",
    "Lateral Movement: AssumeRole to SuspiciousRole",
    "Discovery: ListBuckets, DescribeInstances",
    "Exfiltration: GetObject from sensitive S3 bucket (450GB)",
    "Impact: CryptoMining process launched on EC2"
  ],
  "RelatedEntities": {
    "IAMRoles": ["SuspiciousRole", "LambdaExecutionRole"],
    "EC2Instances": ["i-1234567890abcdef0"],
    "IPs": ["198.51.100.42"],
    "S3Buckets": ["sensitive-data-bucket", "exfil-bucket"]
  },
  "MitreMapping": {
    "InitialAccess": "T1078 (Valid Accounts)",
    "Execution": "T1072 (Software Deployment Tools)",
    "Persistence": "T1098 (Account Manipulation)",
    "PrivilegeEscalation": "T1548 (Abuse Elevation Control)",
    "DefenseEvasion": "T1562 (Impair Defenses)",
    "Discovery": "T1526 (Enumerate Cloud Resources)",
    "Exfiltration": "T1567 (Exfiltrate Over Web)",
    "Impact": "T1490 (Inhibit System Recovery)"
  }
}

エンティティプロファイル・ベースライン分析

プロファイル学習対象

IAM ロール向け

EC2 インスタンス向け

S3 バケット向け

異常検出ロジック

Anomaly Score = (通常からの乖離度) × (信頼度) × (リスク係数)

例：
基準値：S3 GetObject 1,000 オブジェクト/日
実際値：450,000 オブジェクト/日（同一ロール、同一日時）

乖離度 = (450,000 - 1,000) / 1,000 = 449倍
信頼度 = 95% (過去 60 日のベースラインデータ十分)
リスク係数 = 10（大量データ読み出し = 高リスク脅威）

Anomaly Score = 449 × 0.95 × 10 = 4,265
→ 閾値 100 超過 → HIGH 異常として Finding 生成

データソース完全解説

CloudTrail（AWS API 呼び出しログ）

取得内容：

• Management Events：IAM ロール作成、S3 버킷정책 변경、EC2 인스턴스 시작 등
• Data Events：S3 GetObject、DynamoDB Query、Lambda Invoke 등

Detective での活用：

• ロール A が API X を呼び出した履歴
• 異常な API 시퀀스 탐지（예: CreateAccessKey → GetSecretValue → GetObject）
• API 호출의 시시각각 변화 추적

보존 기간：最大 1 년

VPC Flow Logs（ネットワーク通信ログ）

取得内容：

• srcip, srcport, dstip, dstport, protocol, bytes_sent, bytes_recv, start_time, end_time, action(ACCEPT/REJECT)

Detective での活用：

• EC2 インスタンスの통신先 IP/포트 추적
• 異常な외부통信 탐지（예: 기밀정보 S3에서 악성 IP로 데이터 전송）
• 횡적 이동 감지（예: EC2 A → EC2 B → EC2 C로 이어지는 내부 네트워크 스캔）

보존 기간：최大 1 년

GuardDuty Findings（脅威検出結果）

取得内容：

• 암호화폐 채굴 행동
• 비정상적인 API 호출 패턴
• 인프라 재인프라 설정（예: Security Group 변경）
• 데이터 반출 시도

Detective での活用：

• Findings의 시간적, 공간적 연관성 파악
• 오탐 vs 진정 위협 구분
• 상관관계 있는 여러 Findings를 그룹화하여 공격 시나리오 구성

Security Lake 統合

統合のメリット

Before（Security Lake なし）：

• CloudTrail・VPC ログを Detective → CloudWatch Logs → Athena で 각각 쿼리
• 데이터 소스별 쿼리 언어 다름（CloudTrail: JSON, VPC: CSV）
• 여러 쿼리를 수동으로 상관시켜야 함

After（Security Lake 통합）：

• CloudTrail・VPC Flow Logs・EKS Audit Logs를 Security Lake에 일원화
• Detective에서 OCSF（Open Cybersecurity Schema Framework）로 통일된 쿼리
• 자동 상관 분석 가능

구현 예시

import boto3

detective = boto3.client('detective', region_name='us-east-1')

# Security Lake에서 CloudTrail 이벤트 쿼리
response = detective.query_raw_logs(
    GraphArn='arn:aws:detective:us-east-1:123456789012:graph/12a345b6-78cd-9012-3456-789012345678',
    SourceDataVersion='1.0',  # CloudTrail 1.0
    QueryString="""
        SELECT ct_sourceIPAddress, ct_eventName, ct_eventTime, ct_errorCode
        FROM ct  # CloudTrail data
        WHERE ct_sourceIPAddress = '198.51.100.42'
        AND ct_eventTime > '2026-04-20T10:00:00Z'
        LIMIT 100
    """
)

for event in response['RawEventMatches']:
    print(f"Event: {event['eventName']} at {event['eventTime']}")
    print(f"Source IP: {event['sourceIPAddress']}")

マルチアカウント・Organization 管理

階層構造

Organization（組織）
├─ Management Account
│   └─ Detective Administrator Account
│       └─ Behavior Graph（すべてのメンバーアカウントデータを統合）
│           ├─ Member Account 1 (dev)
│           ├─ Member Account 2 (staging)
│           ├─ Member Account 3 (production)
│           ├─ Member Account 4 (security)
│           └─ Member Account N
│
└─ Organization Policy（Organizations ポリシーで Detective を強制有効化）
    ├─ SCP（Service Control Policy）: "detective:* 拒否"設定不可
    └─ Tag Policy: すべてのメンバーアカウント tag:detective=required

管理アカウントの一元化設定

# AWS CLI - Organization を Detective の管理対象に指定
aws detective enable-organization-admin-account \
  --admin-account-id 123456789012 \
  --region us-east-1

# メンバーアカウント自動有効化
aws detective create-members \
  --graph-arn arn:aws:detective:us-east-1:123456789012:graph/12a345b6-78cd-9012-3456-789012345678 \
  --account-details AccountId=210987654321,EmailAddress=dev-team@example.com \
  --account-details AccountId=321098765432,EmailAddress=prod-team@example.com

複数アカウント Finding 集約

Organization Behavior Graph
├─ Detective Findings Aggregation
│   ├─ Account A: 12 Findings (HIGH: 3, MEDIUM: 9)
│   ├─ Account B: 45 Findings (HIGH: 15, MEDIUM: 30)
│   ├─ Account C: 2 Findings (LOW: 2)
│   └─ Account D: 78 Findings (CRITICAL: 5, HIGH: 35, MEDIUM: 38)
│
└─ Cross-Account Investigation
    └─ "IP 198.51.100.42 からのアクセスをすべてのアカウント横断で追跡"
        ├─ Account A: RDS 接続試行（失敗）
        ├─ Account B: Lambda InvokeFunction（成功） → S3 GetObject → 450GB
        ├─ Account C: IAM 認証情報列挙（成功）
        └─ Account D: EC2 に CryptMiner インストール検出
        
        → すべてのアカウントでの一連の攻撃キャンペーンを 1 つのグラフで可視化

主要ユースケース（12+）

1. GuardDuty Findings のトリアージ・優先度付け

シナリオ：月間 500 件の GuardDuty Findings → どれが本物か判定困難

Detective の価値：

Finding: "CryptoCurrency.Behavior!CryptoCoinMiningBehavior"
Detective の自動判定:
├─ Behavior Graph 内で該当ロールの正常行動との乖離度: 98%
├─ Finding Group で関連 Findings 2 件発見
├─ リスクスコア: 92/100 (CRITICAL)
└─ 判定: 本脅威（高優先度でエスカレーション）

Finding: "UnauthorizedAccess.Behavior!UnauthorizedAPICall"
Detective の自動判定:
├─ 当該ロール所有者の定期メンテナンス時間帯
├─ エラー率 2%（正常範囲）
├─ Finding Group に関連 Findings なし
├─ リスクスコア: 18/100 (LOW)
└─ 判定: 誤検知の可能性（抑制推奨）

2. 侵害されたアクセスキーからの影響追跡

シナリオ：「開発者 A のアクセスキーが GitHub に誤って push された」

Detective による追跡：

Step 1: 侵害キーの使用期間を特定（GitHub push 時刻: 2026-04-20 14:32:15Z）
Step 2: その時刻以降の該当キー使用をすべて表示
        └─ 14:32:20: GetSecretValue（DB 認証情報取得）
        └─ 14:33:45: AssumeRole to Lambda Execution Role
        └─ 14:34:12: GetObject from backup-bucket（450 GB）
        └─ 14:35:00: CreateUser（IAM 管理者権限を持つ新規ユーザー作成）

Step 3: 影響リソースを集約
        ├─ 暴露された認証情報: DB credentials, Lambda role
        ├─ アクセスされたリソース: backup-bucket（機密情報 450GB）
        ├─ 作成された権限昇格アカウント: 削除必須
        └─ 推奨対応: Step 2 の活動タイムスタンプ以降の DB・S3 アクセスを監査

Step 4: Behavior Baseline 確認
        ├─ 正常時の開発者 A：GetObject 最大 10GB/日
        ├─ 侵害時: 450GB in 3分（異常度 4500倍）
        └─ 判定: 確実に不正利用（検知結果を監査報告書に記録）

3. ランサムウェア攻撃の影響範囲特定

シナリオ：「S3 バケット内のファイルがすべて暗号化された。攻撃者の足跡を追跡」

Detective による追跡：

1. ランサムウェアで暗号化されたバケットを特定
   → バケット API アクセスの時系列を Behavior Graph で抽出

2. 該当バケットへ大量の PutObject を実行したエンティティを特定
   └─ IAM ロール: lambda-processing-role
   └─ EC2 インスタンス: i-abc123def456

3. 該当ロール/EC2 の初期侵害経路を逆算
   └─ i-abc123def456 への SSH ログイン試行（成功）
   └─ ログイン源 IP: 192.0.2.100
   └─ 初回接続時刻: 2026-04-19 22:15:30Z（深夜、異常）

4. EC2 i-abc123def456 から他リソースへの横的移動を追跡
   ├─ RDS instance prod-db への接続（成功）
   ├─ Secrets Manager secret 取得（成功）
   └─ 他 EC2 インスタンス i-xyz789abc123 への SSHスキャン（複数失敗）

5. 感染 EC2 の Timeline
   └─ 22:15: SSH ログイン（初期侵害）
   └─ 22:30: apt-get install cryptominer
   └─ 23:00: S3 バケット列挙・大量読み出し開始
   └─ 23:45: ファイル暗号化プロセス開始（CPU 100%）
   └─ 深夜 03:00: ランサムノート作成・攻撃者メールアドレス記載

6. 推奨対応
   ├─ 即座: EC2 i-abc123def456 隔離（ネットワーク遮断）
   ├─ 短期: 192.0.2.100 からのすべてのアクセス遮断
   ├─ 中期: 暗号化前 S3 スナップショットからの復旧
   └─ 長期: SSH 鍵ベース認証導入、Session Manager に移行

4. 内部脅威（Insider Threat）検出

シナリオ：「営業部長が競業他社へ移籍予定。機密顧客リスト（S3）へのアクセスをリアルタイム監視」

Detective による監視：

通常行動ベースライン（営業部長）：
├─ S3 GetObject: customer-list-bucket: 1-2 回/日
├─ アクセス時間帯: 09:00-17:00
├─ ダウンロード容量: < 1MB/日
└─ API の種類: GetObject のみ（PutObject は権限外）

異常検出（監視期間中）：
├─ 日時: 2026-04-20 18:30（勤務時間外）
├─ API: GetObject × 300 回（3 分間）→ 合計 450MB
├─ アクセス先: customer-list-bucket + financial-data-bucket
├─ 推定行為: 全顧客リスト + 売上データの大量ダウンロード
├─ リスクスコア: 95/100 (CRITICAL)
└─ アラート: Chief Security Officer に自動通知

対応：
├─ 即座: ネットワークレベルで S3 GetObject 遮断
├─ 確認: 営業部長と面談、正当理由がないことを確認
├─ 措置: ラップトップ没収、AWS コンソールアクセス無効化
├─ 監査: ダウンロードしたデータの流出先を追跡（セキュリティ侵害通知の対象判定）
└─ 予防: 退職 60 日前から全職員の機密リソースアクセスを自動監視

5. 複雑なマルチアカウント攻撃の可視化

シナリオ：「同一攻撃者が dev・staging・prod 3 アカウントに侵入。組織全体のリスク評価」

Detective Organization Graph：

Organization Behavior Graph
├─ Attacker's IP: 203.0.113.1
│   ├─ Account A (dev): 2026-04-19 10:00 初期侵害
│   │   └─ IAM role-dev-app に AssumeRole → 成功
│   ├─ Account B (staging): 2026-04-19 15:30 横的移動
│   │   └─ role-dev-app → role-staging-app に AssumeRole → 成功
│   └─ Account C (prod): 2026-04-20 02:00 完全侵害
│       └─ role-staging-app → role-prod-admin に AssumeRole → 成功
│
├─ 各アカウント横断での活動追跡
│   ├─ 初期侵害の源（Account A）を特定
│   ├─ IAM ロール信頼関係の不適切設定を発見
│   │   └─ role-dev-app が他アカウントの admin ロール引き受け可能
│   ├─ 本番環境への到達時間: 16 時間
│   └─ データ流出スコープ: 本番 DB の顧客データ 1000 万件
│
└─ 総合リスク判定
    ├─ 侵害 severity: CRITICAL
    ├─ 対応優先度: P0（即座に Incident Response チーム起動）
    ├─ 推奨対応:
    │   1. 全 AWS 認証情報ローテーション（全アカウント）
    │   2. VPC フローログから 203.0.113.1 からのすべての通信を遮断
    │   3. 本番環境 DB ダンプ & バックアップを Security Team に引き渡し
    │   4. 監督官庁への個人情報流出報告義務を確認
    └─ 事後処理:
        ├─ IAM ロール信頼関係を "同一アカウント内のみ" に制限
        ├─ Organizations SCP で クロスアカウント AssumeRole を制限
        └─ Detective Organization 監視を全アカウント対象に拡大

6-12. その他主要ユースケース

6. Secrets Manager 認証情報盗難の追跡
7. Lambda 関数の不正実行検出
8. CloudFormation スタック不正変更の追跡
9. DynamoDB テーブル大量読み出し（データ分析目的か盗難か判定）
10. API Gateway 異常トラフィックの根本原因特定
11. Elastic MapReduce（EMR）クラスタの不正操作追跡
12. Backup & Restore の不正操作検出（Ransomware recovery 段階での内部犯）

設定・操作の具体例（Console/CLI/SDK/IaC）

AWS Management Console での操作

1. Detective を初期化

1. AWS Management Console → Detective
2. “Enable Detective” クリック
3. Behavior Graph の有効化確認（30 日無料トライアル）
4. ソースデータ（CloudTrail・VPC Flow Logs・GuardDuty）が自動取得開始

2. Finding Group を確認

1. 左メニュー → “Finding groups”
2. グループ一覧表示（Severity でソート）
3. グループをクリック → ビジュアライゼーション表示
4. 関連 Findings・Timeline・Entity Profile を確認

3. Investigation を開始

1. GuardDuty console で Finding をクリック
2. “Investigate in Detective” リンク → Detective に遷移
3. Investigation 自動開始
4. 対象エンティティ（Role・EC2）の Profile・Timeline を確認

AWS CLI での操作

# 1. Behavior Graph 一覧
aws detective list-graphs --region us-east-1

# 2. Investigation 開始
GRAPH_ARN="arn:aws:detective:us-east-1:123456789012:graph/12a345b6-78cd-9012-3456-789012345678"
ENTITY_ARN="arn:aws:iam::123456789012:role/SuspiciousRole"

aws detective start-investigation \
  --graph-arn $GRAPH_ARN \
  --entity-arn $ENTITY_ARN \
  --severity HIGH \
  --region us-east-1

# 3. Investigation 결과 조회
aws detective get-investigation-results \
  --graph-arn $GRAPH_ARN \
  --investigation-id investigation-abc123def456 \
  --region us-east-1

# 4. Finding Groups 리스트
aws detective list-finding-groups \
  --graph-arn $GRAPH_ARN \
  --region us-east-1

# 5. 특정 Finding Group의 세부정보
aws detective get-finding-group \
  --graph-arn $GRAPH_ARN \
  --finding-group-id group-xyz789abc123 \
  --region us-east-1

# 6. Entity Profile 조회
aws detective get-entity-profile \
  --graph-arn $GRAPH_ARN \
  --entity-arn $ENTITY_ARN \
  --region us-east-1

# 7. Organization 내 멤버 추가
aws detective create-members \
  --graph-arn $GRAPH_ARN \
  --account-details \
    AccountId=210987654321,EmailAddress=security@example.com \
    AccountId=321098765432,EmailAddress=devops@example.com \
  --region us-east-1

AWS SDK (Python / Boto3) での操作

import boto3
import json

detective = boto3.client('detective', region_name='us-east-1')

# 1. Investigation 開始
response = detective.start_investigation(
    GraphArn='arn:aws:detective:us-east-1:123456789012:graph/12a345b6-78cd-9012-3456-789012345678',
    EntityArn='arn:aws:iam::123456789012:role/SuspiciousRole',
    Severity='HIGH'
)

investigation_id = response['InvestigationId']
print(f"Investigation started: {investigation_id}")

# 2. Investigation 결과 조회 (자동 재시도)
import time
for attempt in range(30):  # 5분 동안 재시도
    try:
        result = detective.get_investigation_results(
            GraphArn='arn:aws:detective:us-east-1:123456789012:graph/12a345b6-78cd-9012-3456-789012345678',
            InvestigationId=investigation_id
        )
        
        if result['Status'] == 'COMPLETED':
            print("Investigation completed!")
            print(json.dumps(result, indent=2, default=str))
            break
        else:
            print(f"Status: {result['Status']}, retrying in 10s...")
            time.sleep(10)
    except Exception as e:
        print(f"Attempt {attempt+1} failed: {e}")
        time.sleep(10)

# 3. Finding Groups 조회
findings_groups = detective.list_finding_groups(
    GraphArn='arn:aws:detective:us-east-1:123456789012:graph/12a345b6-78cd-9012-3456-789012345678'
)

for group in findings_groups['FindingGroups']:
    print(f"Group ID: {group['GroupId']}, Severity: {group['Severity']}")

# 4. 특정 Finding Group 상세조회
group_details = detective.get_finding_group(
    GraphArn='arn:aws:detective:us-east-1:123456789012:graph/12a345b6-78cd-9012-3456-789012345678',
    FindingGroupId='group-abc123def456'
)

print(f"Related Findings: {len(group_details['FindingIds'])}")
print(f"Related Entities: {group_details['RelatedEntities']}")

# 5. Entity Profile 조회
entity_profile = detective.get_entity_profile(
    GraphArn='arn:aws:detective:us-east-1:123456789012:graph/12a345b6-78cd-9012-3456-789012345678',
    EntityArn='arn:aws:iam::123456789012:role/SuspiciousRole'
)

print(f"Entity Type: {entity_profile['EntityType']}")
print(f"First Seen: {entity_profile['FirstSeenTime']}")
print(f"Last Seen: {entity_profile['LastSeenTime']}")

Infrastructure as Code (AWS CDK / CloudFormation)

# AWS CDK による Detective 環境構築

from aws_cdk import (
    aws_detective as detective,
    aws_iam as iam,
    aws_events as events,
    aws_events_targets as targets,
    aws_lambda as lambda_,
    aws_sns as sns,
    core
)

class DetectiveStackDetect(core.Stack):

    def __init__(self, scope: core.Construct, id: str, **kwargs):
        super().__init__(scope, id, **kwargs)

        # 1. Detective Graph 作成（Organization 統合）
        graph = detective.CfnGraph(self, "DetectiveGraph",
            tags=[
                core.CfnTag(key="Environment", value="production"),
                core.CfnTag(key="Service", value="detective")
            ]
        )

        # 2. Organization メンバーアカウント登録
        members = detective.CfnMembers(self, "DetectiveMembers",
            accounts=[
                detective.CfnMembers.MemberProperty(
                    account_id="210987654321",
                    email_address="dev-team@example.com"
                ),
                detective.CfnMembers.MemberProperty(
                    account_id="321098765432",
                    email_address="prod-team@example.com"
                )
            ],
            graph_arn=graph.graph_arn
        )

        # 3. SNS Topic for Alerts
        alert_topic = sns.Topic(self, "DetectiveAlerts",
            display_name="Detective Investigation Alerts"
        )

        # 4. Lambda for automated response
        response_function = lambda_.Function(self, "DetectiveResponseFunction",
            runtime=lambda_.Runtime.PYTHON_3_9,
            handler="index.handler",
            code=lambda_.Code.from_asset("lambda"),
            environment={
                "SNS_TOPIC_ARN": alert_topic.topic_arn,
                "GRAPH_ARN": graph.graph_arn
            },
            role=iam.Role(self, "LambdaRole",
                assumed_by=iam.ServicePrincipal("lambda.amazonaws.com"),
                managed_policies=[
                    iam.ManagedPolicy.from_aws_managed_policy_name("AmazonDetectiveReadOnlyAccess")
                ]
            )
        )

        # 5. EventBridge Rule for GuardDuty → Lambda
        rule = events.Rule(self, "GuardDutyToDetectiveRule",
            event_pattern=events.EventPattern(
                source=["aws.guardduty"],
                detail_type=["GuardDuty Finding"],
                detail={
                    "severity": [7, 7.0, 7.1, 8, 8.0, 8.1, 8.2, 8.3, 8.4, 8.5, 8.6, 8.7, 8.8, 8.9]
                }
            )
        )

        rule.add_target(targets.LambdaFunction(response_function))

        # 6. 出力
        core.CfnOutput(self, "GraphArn",
            value=graph.graph_arn,
            description="Detective Behavior Graph ARN"
        )

GuardDuty・Security Hub との統合

GuardDuty → Detective ワンクリック遷移

GuardDuty コンソール
├─ Finding: "CryptoCurrency.Behavior!CryptoCoinMiningBehavior"
│   └─ ボタン: "Investigate in Detective"
│       ↓
│   Detective コンソール
│   └─ Investigation 自動開始
│       ├─ 対象: 该 Finding に関連する IAM ロール / EC2
│       ├─ Timeline: 過去 30 日間の活動
│       ├─ Related Findings: 関連検出 3 件表示
│       ├─ Entity Profile: ベースライン比較
│       └─ MITRE Mapping: 「Execution > T1204」

Security Hub に Detective Findings を統上報

Detective Investigation 완료
├─ 결과: CRITICAL（심각）
│   └─ 자동으로 Security Hub に公开
│       ├─ Title: "Detective Investigation - Crypto Mining Activity"
│       ├─ Severity: CRITICAL
│       ├─ Resource: arn:aws:iam::123456789012:role/SuspiciousRole
│       └─ Remediation:
│           - Revoke all access keys
│           - Isolate related EC2 instances
│           - Review S3 bucket access logs

EventBridge・Lambda との自動対応

自動インシデント対応フロー

graph TD
    A[Detective Investigation<br/>完了] -->|High Severity| B[EventBridge Rule<br/>トリガー]
    B -->|イベント通知| C[Lambda Function<br/>自動対応]
    C -->|1. IAM キー無効化| D["AWS IAM<br/>DisableAccessKey"]
    C -->|2. EC2 隔離| E["VPC Security Group<br/>Deny all"]
    C -->|3. アラート送信| F["SNS Topic<br/>SOC チームに通知"]
    C -->|4. Incident 作成| G["AWS Systems Manager<br/>OpsCenter"]
    D --> H[自動対応完了]
    E --> H
    F --> H
    G --> H
    H -->|マニュアル確認| I[セキュリティ担当者<br/>レビュー・承認]

Lambda 自動対応関数

import boto3
import json
from datetime import datetime

iam = boto3.client('iam')
ec2 = boto3.client('ec2')
sns = boto3.client('sns')
detective = boto3.client('detective')

def lambda_handler(event, context):
    """
    Detective Investigation High Severity 時の自動対応
    """
    
    # 1. Detective イベント解析
    graph_arn = event['detail']['graphArn']
    investigation_id = event['detail']['investigationId']
    severity = event['detail']['severity']
    entity_arn = event['detail']['entityArn']
    
    # 2. Investigation 결과 조회
    investigation = detective.get_investigation_results(
        GraphArn=graph_arn,
        InvestigationId=investigation_id
    )
    
    if severity == 'HIGH' or severity == 'CRITICAL':
        
        # 3. entity_arn が IAM Role の場合: すべてのアクセスキーを無効化
        if 'role' in entity_arn:
            role_name = entity_arn.split('/')[-1]
            
            # 현재 액세스 키 조회
            keys_response = iam.list_access_keys(UserName=role_name)
            
            for key in keys_response['AccessKeyMetadata']:
                print(f"Disabling access key: {key['AccessKeyId']}")
                iam.update_access_key_status(
                    UserName=role_name,
                    AccessKeyId=key['AccessKeyId'],
                    Status='Inactive'
                )
        
        # 4. entity_arn が EC2 Instance の場合: Security Group 를 통한 격리
        elif 'instance' in entity_arn:
            instance_id = entity_arn.split('/')[-1]
            
            # 격리용 보안 그룹 생성 (모든 트래픽 차단)
            isolation_sg = ec2.create_security_group(
                GroupName=f'detective-isolation-{instance_id}',
                Description='Detective automated isolation',
                VpcId='vpc-12345678'  # 실제 VPC ID 사용
            )
            
            isolation_sg_id = isolation_sg['GroupId']
            
            # EC2에 격리 보안 그룹 적용
            ec2.modify_instance_attribute(
                InstanceId=instance_id,
                Groups=[isolation_sg_id]
            )
            
            print(f"EC2 instance {instance_id} isolated with {isolation_sg_id}")
        
        # 5. SNS로 SOC 팀에 알림
        sns.publish(
            TopicArn=os.environ['SNS_TOPIC_ARN'],
            Subject=f"[CRITICAL] Detective Investigation - Automated Response Executed",
            Message=json.dumps({
                'Investigation': investigation_id,
                'Severity': severity,
                'Entity': entity_arn,
                'ActionsTaken': [
                    'Access keys disabled' if 'role' in entity_arn else None,
                    'EC2 instance isolated' if 'instance' in entity_arn else None
                ],
                'RelatedFindings': investigation.get('RelatedFindings', []),
                'MitreMapping': investigation.get('MitreMapping', {}),
                'NextSteps': 'Please review and confirm in AWS Console'
            }, indent=2, default=str)
        )
        
        return {
            'statusCode': 200,
            'body': json.dumps('Automated response completed successfully')
        }
    
    return {
        'statusCode': 200,
        'body': json.dumps('Investigation severity below threshold - no action taken')
    }

類似サービス比較表

Detective が勝利するシナリオ

• AWS のみの環境 → セットアップが数分、コスト低廉
• GuardDuty + Detective 統合で完全な自動化
• インシデント調査時間を最小化したい（グラフビジュアル化）
• 複数アカウント / Organization 管理が必要

他サービスを検討すべきシナリオ

• オンプレミス / 混合クラウド環境 → Splunk / QRadar
• DevOps 中心の環境 → Datadog Security（Agent ベース）
• 複雑なカスタムルール設定 → Splunk（拡張性）

ベストプラクティス

DO（すべき）

DON’T（してはいけない）

トラブルシューティング表

2025-2026 最新動向

Detective Investigation GA（2025 年）

リリース内容：

• ML ベース IOC（Indicators of Compromise）の自動検出
• Investigation の自動リスク評価（スコア 0-100）
• MITRE ATT&CK 自動マッピング（初期アクセス・C2・データ流出等）

実装例：

2025-04-20: 「IAM ロール X で不正 API 呼び出し」の GuardDuty Finding 発出
↓ (Detective Investigation 自動開始）
2025-04-20 10:32: Investigation 完了
├─ IOC スコア: 87/100 (高信頼度)
├─ リスク評価: CRITICAL
├─ MITRE マッピング: Initial Access (T1078) → Exfiltration (T1567)
└─ 推奨アクション: すぐに IAM キー無効化

Security Lake 深度統合（2025 年末）

進化：

• CloudTrail・VPC Flow Logs・EKS Audit Logs を OCSF（Open Cybersecurity Schema Framework）で統一
• Detective 内で直接 SQL クエリ可能（Athena 使用）
• クエリ結果を自動相関分析

用途：

• Before: CloudTrail → Athena（JSON）, VPC Logs → Athena（CSV）を別々にクエリ
• After: Security Lake → 統一 OCSF スキーマ → Detective で統一 SQL クエリ
• ↓
• 複数ログソースの自動相関が秒単位で完了

Findings Group 自動生成の高度化（2026 年）

改善：

• MITRE ATT&CK 戦術ごとに自動グループ化
• 攻撃キャンペーン（複数ターゲット、複数時間帯）を自動 cluster
• 誤検知スコア（False Positive Score）の自動算出

例：

Finding Group: "APT28 Campaign"
├─ Target 1: Account A
├─ Target 2: Account B
├─ Target 3: Account C
├─ Duration: 2026-04-15 10:00 ~ 2026-04-20 18:00 (5 日間)
├─ Tactics: Initial Access → Lateral Movement → Exfiltration
├─ False Positive Score: 2% (99% 信頼度が本脅威)
└─ Incident Response Priority: P0 (即座に CEO に報告)

Real-time Threat Correlation（2026 年中盤予定）

機能：

• CloudTrail・VPC Logs・GuardDuty を秒単位で相関分析
• 従来: Finding 発出 → 数分後に Investigation 結果（遅延）
• 新機能: Detection 即座に Correlation（リアルタイム対応可能）

学習リソース・参考文献

AWS 公式ドキュメント

AWS Blog & Re:invent

MITRE ATT&CK フレームワーク

サードパーティ・ベンダーリソース

実装例・導入ロードマップ

Phase 1: 基本セットアップ（Week 1）

# Step 1: GuardDuty 有効化（前提条件）
aws guardduty create-detector \
  --enable \
  --finding-publishing-frequency FIFTEEN_MINUTES \
  --region us-east-1

# Step 2: CloudTrail 有効化・検証
aws cloudtrail create-trail \
  --name detective-trail \
  --s3-bucket-name my-cloudtrail-bucket \
  --region us-east-1

# Step 3: VPC Flow Logs 有効化
aws ec2 create-flow-logs \
  --resource-type VPC \
  --resource-ids vpc-12345678 \
  --traffic-type ALL \
  --log-destination-type cloudwatch-logs \
  --log-group-name /aws/vpc/flowlogs \
  --deliver-logs-permission-iam-role-arn arn:aws:iam::123456789012:role/VPCFlowLogsRole

# Step 4: Detective Graph 作成
RESPONSE=$(aws detective create-graph --region us-east-1)
GRAPH_ARN=$(echo $RESPONSE | jq -r '.GraphArn')
echo "Detective Graph Created: $GRAPH_ARN"

Phase 2: Investigation 自動化（Week 2-3）

# Lambda 関数作成（自動対応）
# → EventBridge でトリガー
# → GuardDuty HIGH/CRITICAL Finding で起動
# → IAM キー無効化・EC2 隔離を自動実行

Phase 3: Organization 統合（Week 3-4）

# Organization 統合
aws detective enable-organization-admin-account \
  --admin-account-id 123456789012 \
  --region us-east-1

# メンバーアカウント登録
aws detective create-members \
  --graph-arn $GRAPH_ARN \
  --account-details \
    AccountId=210987654321,EmailAddress=dev@example.com \
    AccountId=321098765432,EmailAddress=prod@example.com

Phase 4: 運用継続・最適化（Ongoing）

• Weekly: Finding Groups の確認・トリアージ
• Monthly: Investigation 結果の分析・ベースライン見直し
• Quarterly: Dashboard 作成（Detective Findings のトレンド分析）

実装チェックリスト

初期セットアップ

• [ ] GuardDuty 有効化（Management Account + Organization）
• [ ] CloudTrail 有効化（Management Events + Data Events）
• [ ] VPC Flow Logs 有効化（すべての VPC / ENI）
• [ ] Detective Graph 作成（Primary Region）
• [ ] Detective 無料トライアル 30 日を把握

運用準備

• [ ] SNS Topic 作成（Finding アラート用）
• [ ] Lambda Function 開発（自動対応ロジック）
• [ ] EventBridge Rule 設定（GuardDuty → Lambda）
• [ ] IAM Role / Policy 作成（最小権限）
• [ ] CloudFormation テンプレート作成（IaC）

Organization 統合

• [ ] Detective Admin Account を指定（Management Account 経由）
• [ ] メンバーアカウント登録
• [ ] Organizations ポリシー設定（Detective 強制有効化）
• [ ] 複数アカウント Finding 集約確認

運用開始

• [ ] SOC チームへのトレーニング（Investigation ワークフロー）
• [ ] Finding Group 定期確認スケジュール設定
• [ ] Entity Profile Baseline 見直し（3 ヶ月ごと）
• [ ] Incident Response Runbook の更新

継続的改善

• [ ] Finding False Positive 分析（誤検知削減）
• [ ] Entity Profile の Baseline 動的調整
• [ ] Investigation 時間の KPI 追跡
• [ ] Incident Response MTTR（Mean Time To Respond）の測定

コスト・プライシング

課金モデル

Detective は インジェスト GB 数（月額） 課金。

料金例（月額）:

Small Environment（100 GB/月）:
├─ $3 × 100 GB = $300/月

Medium Environment（500 GB/月）:
├─ $3 × 500 GB = $1,500/月

Large Environment（2,000 GB/月）:
├─ $3 × 2,000 GB = $6,000/月

コスト削減戦略

無料トライアル

• 初回 30 日：すべてのインジェスト GB 無料
• 試算機能：Detective Console で月額推定費用を表示
• 警告機能：月額 $100 超過時に Email 通知

まとめ

Amazon Detective は、GuardDuty で検出されたアラートの「その後」を自動調査するフォレンジック分析サービスです。

核となる価値

1. Behavior Graph：CloudTrail・VPC ログから自動構築される知識グラフ。エンティティ間の関係性・時系列を可視化
2. Investigation：ML ベース IOC 検出で「本物の脅威か誤検知か」を自動判定
3. Finding Groups：複数 Findings の自動グループ化で、単一インシデントの全容を可視化
4. 自動対応：EventBridge + Lambda で IAM キー無効化・EC2 隔離を秒単位で実行

推奨される組織

• AWS ネイティブ環境（GuardDuty + Detective 統合で完全自動化）
• 複数アカウント / Organization（管理アカウント一元管理）
• インシデント対応時間の最小化（グラフビジュアル化で数時間 → 数分）
• SOC チームの効率化（自動トリアージで本当の脅威に集中）

導入の First Step

1. GuardDuty を有効化（Detective はこれが前提）
2. CloudTrail・VPC Flow Logs を有効化（ソースデータ）
3. Detective Graph を作成（30 日無料で試行）
4. Finding Groups を 2 週間確認（価値を実感）
5. Organization 統合・自動化に進む（本格運用）

Detective は「Security Operations の自動化」の第一歩。GuardDuty + Detective + EventBridge + Lambda で、検出から対応まで秒単位のセキュリティオペレーションを実現できます。

最終更新：2026-04-26 バージョン：v2.0