GuardDuty 通知設計書
1. 目的・スコープ
目的
GuardDutyの組織統合に伴い、findingsの検知・通知基盤を整理し、 fd-security-tooling（Delegated Admin）への集約通知体制を構築する。
スコープ
- GuardDutyのfindingsの通知設計
- 通知の重複排除方針
- 通知先Slackチャンネルの整理
- 既存個別通知の移行方針
スコープ外
- 通知メッセージのフォーマット設計（別途検討）
- オンコール連携（PagerDuty等、全体で検討する必要があるため今後の検討課題）
- 対応フロー定義（運用設計書の範囲）
- Inspector、Config等の他サービスの通知設計（各導入時に追記）
- セキュリティ通知の全体設計（Security Hub導入時にあらためて検討）
前提
- GuardDuty組織統合設計書に従い、fd-security-toolingがDelegated Adminとなる
- Datadogインテグレーションの基盤が利用可能
2. 現状と課題
現状
GuardDuty通知（既存 — 各アカウント個別）:
構成: EventBridge（severity >= 7）→ SNS → Amazon Q Developer（旧AWS Chatbot）→ Slack
※ 以降「Amazon Q Developer」と表記
対象リージョン: 東京 + オレゴン（一部東京のみ）
アカウント別状況:
・production: GuardDuty + Access Analyzer + Macie（東京+オレゴン）
・staging: GuardDuty + Access Analyzer + Macie（東京）
・infra-dev: GuardDuty + Access Analyzer + Macie（東京+オレゴン+大阪）+ Route53ヘルスチェック
・amazon-connect: GuardDutyのみ（東京）
・develop: Access Analyzer + Macieのみ（GuardDutyのSNSサブスクリプション空 → 通知されていない）
・integration: GuardDutyのみ（東京）課題
| # | 課題 | 影響 |
|---|---|---|
| 1 | 各アカウントに個別通知が分散 | 管理が煩雑、設定のばらつき |
| 2 | developのGuardDuty通知が壊れている | findingsが通知されていない |
| 3 | 新規アカウントは個別に通知設定が必要 | 設定漏れのリスク |
| 4 | ctop系・cc-poc等は通知設定がない | GuardDuty未導入（組織統合で解消予定） |
| 5 | マルチリージョン有効化後の未対応リージョン | 一部リージョンのfindingsが通知されない |
| 6 | 通知先Slackチャンネルにノイズが多い | 重要な通知が埋もれる |
3. 通知アーキテクチャ
全体構成
通知経路の使い分け
通知経路にEventBridge → SNS → Amazon Q Developer → Slackを採用した理由:
・リアルタイム性: EventBridgeはイベント発生から秒単位で検知・通知可能
HIGH/CRITICALのfindings（マイニング、C&C通信、マルウェア等）は
数分の遅延が被害拡大に直結するため、即時通知が必要
（Datadog連携もEventBridge経由だが、Slack通知とは用途を分けて運用する）
・Delegated Admin集約: fd-security-toolingのEventBridgeに全アカウントのfindingsが自動集約
・既存実績: 各アカウントで同じ構成（EventBridge → SNS → Amazon Q Developer）が稼働済み
・コスト:
EventBridge: AWSサービスイベントのルールマッチングは無料
SNS: 最初の1,000件/月の通知は無料。超過しても$0.50/100万件
Amazon Q Developer: 無料（Slackとの連携サービス）
GuardDutyのfindings量ではコストはほぼ発生しない
通知（EventBridge ルール① — Slack通知）:
・対象: severity >= 7（HIGH/CRITICAL）
・経路: EventBridge → SNS → Amazon Q Developer → Slack（#squad-sre-noti-security）
・遅延: 秒単位
・リージョン: SCP許可リージョン（東京、バージニア、オレゴン、大阪）
調査用収集（EventBridge ルール② — Datadog）:
・対象: 全severity（HIGH/CRITICAL/MEDIUM/LOW）
・経路: EventBridge → Datadog Forwarder Lambda → Datadog Log Management
・遅延: 秒単位（Lambda即時実行）
・リージョン: SCP許可リージョン（東京、バージニア、オレゴン、大阪）
検知例（HIGH/CRITICAL — Slack即時通知 + Datadog収集）:
・CryptoCurrency:EC2/BitcoinTool.B — EC2が暗号通貨マイニングに使われている
・Backdoor:EC2/C&CActivity.B — EC2がC&Cサーバーと通信している
・Trojan:EC2/DNSDataExfiltration — DNS経由のデータ窃取
・Execution:Runtime/MaliciousFileExecuted — マルウェアの実行検知
・PrivilegeEscalation:Runtime/RuncContainerEscape — コンテナからのエスケープ
・Execution:Runtime/ReverseShell — リバースシェルの実行
・PrivilegeEscalation:Runtime/ElevationToRoot — root権限への昇格
・Policy:IAMUser/RootCredentialUsage — ルートユーザーのAPI呼び出し
検知例（MEDIUM — Datadog収集のみ、Slack通知なし）:
・UnauthorizedAccess:EC2/SSHBruteForce — SSHブルートフォース試行（攻撃対象の場合）
・Recon:EC2/Portscan — ポートスキャンの検知
・UnauthorizedAccess:IAMUser/InstanceCredentialExfiltration — EC2クレデンシャルの外部利用
・Impact:EC2/SuspiciousDomainRequest.Reputation — 不審なドメインへのリクエスト
検知例（LOW — Datadog収集のみ、Slack通知なし）:
・UnauthorizedAccess:EC2/SSHBruteForce — SSHブルートフォース試行（攻撃元が外部の場合）
・Recon:EC2/PortProbeUnprotectedPort — 保護されていないポートへのプローブ
調査・モニタリング（Datadog）:
・EventBridge → Datadog Forwarder Lambda経由でfindingsをDatadog Log Managementに取り込む
（通知目的ではない）
・用途: 調査連携（Bits AI、MCP）、APM/ログとの相関分析、傾向把握
・収集方式: EventBridge → Datadog Forwarder Lambda → Datadog Log Management
（Slack通知と同じEventBridgeを利用するが、別ルールで全severityを対象とする）
Firehose方式を採用しない理由:
・バッチ配信による欠損・重複問題:
Firehoseは短時間に発生した複数のfindingsを1つのバッチ（records配列）にまとめて配信する
Datadog側ではPipelineで records.0.data のように特定インデックスしか指定できないため、
2件目以降（records.1.data 等）はパースされず欠損する
さらに、同一バッチがレコード数分のログとして重複保存される問題も確認された
・base64エンコード問題:
Firehose HTTP Endpoint宛先ではレコードが自動的にbase64エンコードされるため、
Datadog Logs Pipelineでのデコード設定が必要になる
AP1サイトではbase64デコード用のDecoder Processorが利用できない可能性がある
Forwarder Lambdaのメリット:
・各findingが個別のログイベントとして送信される（バッチ問題なし）
・base64デコード不要（Lambdaが直接JSON処理）
・GuardDutyの属性が自動パースされる（Logs Pipeline設定不要）
・source, service, host, message, タグが自動設定される
リージョンについて:
・EventBridgeはリージョンごとのサービスのため、各リージョンにルール構築が必要
全サポートリージョン（20以上）に作るのは管理コストが高いため、
SCP許可リージョン（4リージョン）に限定する
・Datadog Forwarder Lambdaもリージョナルサービスのため、
各リージョンにデプロイが必要（4リージョン分）
・結果として:
SCP許可4リージョン → EventBridge（Slack通知 + Datadog収集）の両方でカバー
その他リージョン → カバーなし
（その他リージョンはSCPでリソース作成がブロックされているためリスク低い）4. Slackチャンネル設計
チャンネル構成
| チャンネル | 用途 | 通知元 |
|---|---|---|
| #squad-sre-noti-security | HIGH/CRITICALのGuardDuty findings通知（全環境） | EventBridge（severity >= 7）→ Amazon Q Developer |
・全環境（本番・非本番）を1チャンネルに集約
・severity >= 7（HIGH/CRITICAL）のみ通知
・MEDIUM/LOWはDatadogに全件収集されているため、Slack通知は不要
・通知メッセージのフォーマットカスタマイズ（EventBridge Input Transformer等）は今後のタスクとする5. fd-security-tooling集約通知の構築
EventBridge設定（fd-security-tooling内、各リージョンに作成）
対象リージョン（SCP許可リージョン）:
・ap-northeast-1（東京）
・us-east-1（バージニア）
・us-west-2（オレゴン）
・ap-northeast-3（大阪）
各リージョンに以下を作成:
・EventBridgeルール①: severity >= 7 → SNS（Slack通知用）
・EventBridgeルール②: 全severity → Datadog Forwarder Lambda（調査用）
・SNSトピック: GuardDuty findings通知用
・Datadog Forwarder Lambda: findingsをDatadog Log Managementに転送
※ fd-security-toolingには既存のForwarderがないため新規デプロイが必要
※ 既存モジュール（template_modules/common/platform/datadog_lambda_forwarder）を使用
EventBridgeイベントパターン:
ルール①（Slack通知用 — severity >= 7）:
{
"source": ["aws.guardduty"],
"detail-type": ["GuardDuty Finding"],
"detail": {
"severity": [{ "numeric": [">=", 7] }]
}
}
ルール②（Datadog収集用 — 全severity）:
{
"source": ["aws.guardduty"],
"detail-type": ["GuardDuty Finding"]
}
Amazon Q Developer:
・1つのAmazon Q Developer設定で4リージョン分のSNSトピックを紐付け
・通知先: #squad-sre-noti-security
Delegated Adminの仕組み:
・組織統合後、fd-security-toolingのEventBridgeに
全メンバーアカウントのfindingsが自動的に流れる
・AssumeRole不要、fd-security-tooling内で完結
・新規アカウント追加時も通知設定の追加が不要Terraform管理
fd-security-tooling（Terraform）:
Slack通知用:
・aws_cloudwatch_event_rule — EventBridgeルール①（severity >= 7、4リージョン分）
・aws_cloudwatch_event_target — SNSターゲット
・aws_sns_topic — 通知用トピック（4リージョン分）
・aws_sns_topic_policy — Amazon Q Developer用ポリシー
・template_modules/options/chatbot モジュール — Amazon Q Developer（旧Chatbot）設定
※ CloudFormation Stack方式（既存の各アカウントと同じ実績ある方式）
Datadog連携用:
・aws_cloudwatch_event_rule — EventBridgeルール②（全severity、4リージョン分）
・aws_cloudwatch_event_target — Datadog Forwarder Lambdaターゲット
・aws_lambda_permission — EventBridgeからLambda呼び出し権限
・aws_sqs_queue — DLQ（配信失敗時のデッドレターキュー、4リージョン分）
・Datadog Monitor — DLQメッセージ数のアラート（SQS ApproximateNumberOfMessagesVisible > 0）
・template_modules/common/platform/datadog_lambda_forwarder — Forwarder Lambda（4リージョン分）
※ CloudFormation Stackでデプロイ（Datadog公式テンプレート）
※ Datadog APIキーはSecrets Managerに格納（リージョンごとに作成）
マルチリージョン対応:
・security-toolingのprovider.tfにリージョン別aliasを追加
- aws.us_east_1（バージニア）
- aws.us_west_2（オレゴン）
- aws.ap_northeast_3（大阪）
- デフォルトprovider（東京）
・EventBridge/SNSは各リージョンのproviderで作成
・Amazon Q Developer設定は1つで4リージョンのSNSを紐付け
コードの配置:
fastdoctor-template/common/security-tooling/guardduty-notification.tf
fastdoctor-template/common/security-tooling/provider.tf（マルチリージョンalias追加）6. Datadog GuardDutyインテグレーション
Datadogは通知目的ではなく、以下の調査・分析用途で導入する。
具体的なユースケース:
1. Bits AIとの連携
・自然言語でfindingsを検索・分析
・例: 「過去7日間のHIGH severityのfindingsを要約して」
2. MCP連携
・Claude CodeからDatadog経由でfindingsを直接参照
・コード修正と脅威分析を同時に実行
3. APM/ログとの相関分析
・findingsとアプリケーションログを時系列で照合
・例: EC2のマルウェア検知とアプリケーションエラーログの相関
4. 傾向分析
・finding種別の推移をグラフ化
・アカウント・リージョン別の統計
EventBridge通知との使い分け:
・即時通知 → EventBridge → SNS → Amazon Q Developer → Slack（秒単位）
・調査・分析 → EventBridge → Datadog Forwarder Lambda → Datadog Log Management（秒単位）
収集方式:
・EventBridge → Datadog Forwarder Lambda方式でfindingsをログとして取り込む
・Forwarder LambdaはDatadog公式が提供するCloudFormationテンプレートでデプロイ
（各アカウントで既に稼働中の既存モジュールと同じ方式）
・Delegated Admin（fd-security-tooling）のEventBridgeには
全メンバーアカウントのfindingsが自動集約されるため、
fd-security-toolingにForwarderを配置するだけで全組織のfindingsを収集可能
構成:
・fd-security-toolingの各リージョンに以下を作成:
- EventBridgeルール: source=aws.guardduty（全severity）
※ Slack通知用ルール（severity >= 7）とは別のルール
- EventBridgeターゲット: Datadog Forwarder Lambda
- aws_lambda_permission: EventBridgeからの呼び出し許可
・Datadog Forwarder Lambda:
- CloudFormation Stackでデプロイ（Datadog公式テンプレート）
- Datadog APIキーはSecrets Managerに格納
- Datadogアカウント: FD - 本番のAPIキーを使用
・Datadog Forwarder Lambda のバージョン管理:
- テンプレートURL（latest.yaml）でデプロイ。作成時のバージョンで固定
- Datadog公式GitHubリリースノートでバージョン管理
- 通常の運用ではバージョンアップ不要
- Datadog公式GitHubリリースノートを定期確認し、セキュリティパッチや重要な変更がある場合に更新
fd-security-toolingへの構築が必要:
- Datadog Forwarder Lambda（4リージョン分、CloudFormation Stack）
- Secrets Manager（Datadog APIキー、4リージョン分）
- EventBridgeルール + ターゲット + Lambda権限（4リージョン分）
※ Datadog AWSインテグレーション（datadog-integration-role, datadog_integration_aws）は不要
- Security Hub導入時にもEventBridgeルールを追加するだけでForwarder経由の収集を拡張可能
- 各アカウント個別に構築する方式と比較して、fd-security-tooling1箇所で完結する
エラーハンドリング:
- EventBridge → Lambda失敗時はデフォルトで最大185回リトライ（24時間）
- リトライ全失敗時のfinding欠損を防ぐため、DLQ（SQS）を設定する
- DLQにメッセージが入った場合はDatadog Monitorで通知する
（SQSメトリクス ApproximateNumberOfMessagesVisible > 0 で検知）
- DLQに入ったイベントは手動で再処理、またはfd-log-archive S3エクスポートから復旧可能
※ 既存の各アカウント個別通知ではDLQ未設定だが、
集約通知では全アカウントのfindingsが集中するためDLQを設定する
注意事項:
- Forwarder Lambdaの同時実行数: Datadogは最低10の予約同時実行数を推奨
- Forwarder Lambdaはリージョナルサービスのため、各リージョンに個別デプロイが必要7. Findingsの更新通知
GuardDutyのfindingsは解決（アーカイブ）されない限り、
設定した頻度でEventBridgeにイベントが再送される。
通知頻度の設定:
・FIFTEEN_MINUTES（15分ごと）
・ONE_HOUR（1時間ごと）← 既存設定
・SIX_HOURS（6時間ごと）← デフォルト
※ 初回検知は常にリアルタイム。上記は同一findingの更新通知の頻度
※ 既存設定のONE_HOURを引き継ぐ。必要に応じてFIFTEEN_MINUTESに短縮可能
対策:
・findingを確認したらアーカイブして再通知を止める（手動）
・サプレッションルールで既知のfindingsを自動アーカイブ（Delegated Adminから設定）
例: 特定IPアドレスからのfinding、既知の誤検知パターン
・初期は手動アーカイブで運用し、繰り返し発生するものを
サプレッションルールで自動化する8. 既存個別通知の移行方針
移行手順:
1. fd-security-toolingに集約通知を構築（EventBridge + Amazon Q Developer）
2. Datadogインテグレーションを導入（調査・モニタリング用）
3. 動作確認: 全アカウントのfindingsが集約通知されることを確認
4. 並行稼働期間（1〜2週間）: 既存個別通知と集約通知の両方で運用
5. 集約通知に問題がなければ、既存の各アカウント個別通知を削除
→ EventBridgeルール、SNSトピック、Amazon Q Developer設定を各アカウントから削除
→ Terraform管理の場合はコード削除→apply
注意:
・developのGuardDuty通知は壊れているため修正不要（集約通知でカバー）
・既存通知の削除前に、集約通知で全アカウント分のfindingsが来ていることを必ず確認
移行リスクと対策:
・集約通知の設定ミス → 全アカウントの通知停止
対策: 並行稼働期間（1〜2週間）で既存通知と比較検証
・リージョン漏れ → 一部リージョンのfindingsが通知されない
対策: 4リージョン全てで動作確認を実施
・Slackチャンネル誤設定 → 通知が届かない
対策: テストfindingsで#squad-sre-noti-securityに届くか確認
ロールバック手順:
集約通知に問題が発覚した場合:
1. 既存個別通知を維持（並行稼働中は削除しない）
2. fd-security-toolingの集約通知を修正
3. 動作確認後、再度移行を実施
動作確認チェックリスト:
□ 4リージョン全てのEventBridgeルールが作成されている
□ SNSトピックが4リージョン全てに存在する
□ Amazon Q Developerに4つのSNSトピックが登録されている
□ Slack #squad-sre-noti-securityに通知が届く
□ テストfindingsで各リージョンから1件ずつ確認
□ 全アカウント（production, staging, develop, infra-dev等）のfindingsが届く
□ Datadogにfindingsが個別のログとして収集されている
□ Datadogでseverity, accountId, region等の属性で検索・フィルタできる9. 適用手順
Step 1: fd-security-toolingにDatadog Forwarder Lambdaをデプロイ
→ Datadog APIキーをSecrets Managerに格納（4リージョン分）
→ Forwarder LambdaをCloudFormation Stackでデプロイ（4リージョン分）
→ Terraform apply
Step 2: fd-security-toolingにEventBridge集約通知を構築
→ Terraform apply（4リージョン分のEventBridge + SNS + Amazon Q Developer）
→ Slack通知用: EventBridge（severity >= 7）→ SNS → Amazon Q Developer
→ Datadog用: EventBridge（全severity）→ Datadog Forwarder Lambda
Step 3: 動作確認
→ サンプルfindingsを生成して集約通知が来ることを確認
→ Datadogでもfindingsが個別のログとして収集されていることを確認
→ severity, accountId, region等の属性で検索・フィルタできることを確認
Step 4: 並行稼働（1〜2週間）
→ 既存個別通知と集約通知の両方で運用
Step 5: 既存個別通知の削除
→ 各アカウントのEventBridge/SNS/Amazon Q Developer設定を削除10. 今後のタスク
| 優先度 | タスク | 概要 | 時期 |
|---|---|---|---|
| 高 | 通知メッセージのフォーマット設計 | アカウント名、リソース、対応手順リンク等を見やすく整形 | 集約通知構築後1ヶ月以内 |
| 高 | サプレッションルール | 運用しながら誤検知パターンを特定し自動アーカイブ設定 | 並行稼働期間中に開始 |
| 中 | 対応フロー定義 | 通知受信後の対応手順、エスカレーション先の定義 | 集約通知構築後2ヶ月以内 |
| 中 | オンコール連携 | severity CRITICAL時のPagerDuty等によるオンコール呼び出し | 全体で検討 |
| 低 | セキュリティ通知の全体設計 | Security Hub導入時にGuardDuty/Inspector/Config等の通知基盤をあらためて統合設計 | Security Hub導入時 |