Amazon GuardDuty 本番運用ガイド（脅威検知／Extended Threat Detection・攻撃シーケンス／EventBridge自動対応(SOAR)／マルチアカウント統制／Runtime Monitoring／EKS Protection／S3マルウェア対策／RDS・Lambda Protection／Detective調査／Security Lake集約／誤検知チューニング／コスト最適化／技術選定）

GuardDuty が Critical を上げた——では『何が起きて、どこまで侵されたのか』に答えられますか。Amazon Detective は CloudTrail・VPC Flow Logs・GuardDuty finding・EKS 監査ログから最大1年分の行動グラフを構築し、根本原因と影響範囲（ブラストラディウス）を可視化します。finding からのピボット、finding groups、IOC を使う Detective Investigation、StartInvestigation の CLI／EventBridge 自動起動、組織の委任管理者整合まで、detect→investigate→respond の調査レイヤーを公式ドキュメント（2026年6月）に基づき実コードで設計します。

Amazon GuardDutyの料金をコンポーネント単位で分解し、支配的ドライバー(Runtime MonitoringのvCPU時間・CloudTrail管理イベント・VPC Flow Logs)を特定。get-usage-statisticsでの使用量可視化、トライアルからの請求予測、保護プラン取捨選択、抑制ルールはコストを下げない誤解の解消までをbash/Terraformで解説。価格はリージョン/改定で変動、要確認。

GuardDuty EKS Protection の本番設計ガイド。EKS 監査ログでコントロールプレーンの脅威——system:anonymous への RBAC 付与、cluster-admin の改変、kube-system での exec、特権コンテナ起動——を検知する仕組みを解説。GuardDuty は独立ストリームで監査ログを取り込むため EKS コントロールプレーンログ(CloudWatch)の有効化は不要。finding 型をThreatPurpose別・MITRE ATT&CK対応で整理し、ThreatPurpose別の対応、Terraform(EKS_AUDIT_LOGS)有効化、RBAC ハードニング、SOAR 連携までをコードで示します。Runtime Monitoring(データプレーン)との違いも明確化。

GuardDuty の finding を EventBridge→Step Functions で自動インシデント対応（SOAR）に変える本番設計ガイド。重大度の数値マッチ・通知は広く封じ込めは許可リストで狭く・破壊は人間承認、EC2/IAM/S3/EKS プレイブックと冪等性・DLQ・最小権限を実コードで解説します。

GuardDuty Extended Threat Detection（ETD）と攻撃シーケンス（AttackSequence）findingの徹底解説。弱いシグナルの相関モデル、24時間ローリングウィンドウ、IAM/S3/EKS/ECS/EC2の5つの攻撃シーケンス型、なぜ全て Critical(9.0〜10.0)なのか、保護プランで広がる相関範囲、サンプル生成での検証、Suppression Ruleがアーカイブ済みを無視する罠まで——credential侵害→権限昇格→S3持ち出しの実例で線として読み解きます。

GuardDuty Malware Protection for S3 でアップロードされた S3 オブジェクトを自動マルウェアスキャンする本番設計ガイド。混同されがちな『S3 Protection（CloudTrail データイベント監視）』との違い、GuardDuty 本体なしで使う単独運用モード（detector ID なし＝finding を生成しない）、スキャン結果タグ（GuardDutyMalwareScanStatus）と EventBridge イベント、そして NO_THREATS_FOUND だけを清浄バケットへ昇格しタグベースアクセス制御（TBAC）で読み取りを封じる安全なアップロードパイプラインを、Terraform / Python / バケットポリシーの実コードで解説します。

GuardDutyをAWS Organizationsで全社統制する実装ガイド。なぜ管理アカウントで運用せず委任管理者（専用セキュリティアカウント）に集約するのか、招待方式からの移行、auto_enable_organization_membersをALLにする理由、保護プランの組織自動有効化、グローバルサービスイベントを取りこぼさない全リージョン戦略、provider alias/for_eachによるTerraformマルチリージョン実装、そしてアカウント間の最小権限境界までをコードで解説します。

Amazon GuardDuty の RDS Protection と Lambda Protection を本番設計する実装ガイド。Aurora/RDS のログイン異常(成功・失敗・ブルートフォース・悪性IP・Tor)を直接監視し、Lambda の全関数(非VPC含む)のネットワーク活動から暗号資産マイニング・C&C 通信を検知する——どちらもエージェントレス・インフラ変更ゼロ・コード変更不要。対応エンジン、finding 型、最大2週間の学習期間、料金と30日無料トライアル、Terraform 有効化、EventBridge 自動対応までを公式準拠で解説します。

GuardDuty Runtime Monitoring の本番運用ガイド。eBPFエージェントがOSレベルのプロセス・ファイル・ネットワークを内側から観測する仕組み、EKS/ECS-Fargate/EC2の3配布面と自動・手動管理、カバレッジ(Healthy/Unhealthy)確認、VPC Flow Logs二重課金免除、vCPU課金の規律をTerraform/bashで解説します。

GuardDuty の finding は『いま』には強いが、コンプライアンスの長期保管・finding × CloudTrail × VPC Flow の横断クエリ・SIEM 供給には向きません。Amazon Security Lake は自分の S3 上に OCSF + Apache Parquet の管理データレイクを作り、数年スパンで保管・SQL 分析・SIEM 連携を可能にします。決定的な正確さの勘所——Security Lake に GuardDuty の直接ソースは無く、findingは『AWS Security Hub CSPM findings（SH_FINDINGS）』経由で OCSF 化される——を軸に、ネイティブソース・ロールアップリージョン・2種類のサブスクライバ（クエリ/データアクセス）・Athena の実 SQL・Terraform 実装まで、公式ドキュメント（2026年6月）に基づき通します。

Amazon GuardDuty のノイズ・誤検知を本番品質で抑えるチューニング実装ガイド。Suppression Rule（既知ノイズの自動アーカイブ）・信頼 IP/エンティティリスト（既知の正規ソースから finding を出さない）・脅威リスト（既知の悪性ソースから finding を出す）の3つの道具を、症状→正しい道具のマッピングで使い分けます。抑制された finding は Security Hub/S3/Detective/EventBridge に届かず、Extended Threat Detection の相関材料にもならない——広すぎる抑制が Critical な攻撃シーケンスを丸ごと不可視化する罠と、reactive・スコープ最小・IaC 中心の運用ルールを、Terraform/CLI の実コードで解説します。

GuardDuty(検知)・Security Hub(集約と標準チェック)・Detective(調査)・Inspector(脆弱性)・Macie(データ分類)は競合ではなく多層防御の補完レイヤーです。各サービスの役割・扱うデータ・ライフサイクル上の位置を公式ドキュメント(2026年6月)に基づき整理し、混同しやすい違い、技術選定フレーム、EventBridge/Security Hub での連携設計まで解説します。