GuardDuty Security Hub Findings マルチアカウント Terraform 本番

1. この記事について — セキュリティ本番運用シリーズ Vol1

1-1. セキュリティ本番運用シリーズ起ち上げ

本記事は「AWS 本番運用シリーズ」の第 4 シリーズ起ち上げ巻です。Lambda 3 部作・EKS 3 部作・観測性 3 部作の計 9 巻が完結し、セキュリティ 3 部作を加えて 12 巻体制へ拡張します。

9 巻完結 → 12 巻拡張 のロードマップ

セキュリティ Vol1 は観測性 3 部作と直接連携します。GuardDuty の Findings 発生時に CloudWatch Logs Insights でセキュリティイベントログを相関分析する手順を §6・§7 で解説します。EKS Vol2 (IRSA) で整備した IAM 最小権限設計を Security Hub で継続評価し、Lambda Vol3 の EventBridge 連携パターンを通知パイプライン構築に活用します。

GuardDuty + Security Hub が連携する仕組み

GuardDuty は VPC Flow Logs・DNS Logs・CloudTrail イベントを機械学習で分析し、脅威を Findings として生成します。Security Hub はこの Findings を ASFF (AWS Security Finding Format) で統一し、複数アカウント・複数リージョンの Findings を Delegated Admin へ集約します。本記事ではこの 2 サービスの連携を Terraform で完全実装します。

既存 9 巻との連携ポイント

• 観測性 Vol1 (WP:2252): GuardDuty Findings 発生時に Logs Insights でセキュリティイベントログを相関分析 (§6・§7)
• 観測性 Vol2 (WP:2304): X-Ray トレースと GuardDuty Findings を時系列相関させ、攻撃経路を追跡 (§3)
• EKS Vol2 (WP:2228): IRSA で Security Hub 操作権限を最小化し、EKS ノードの誤検知を Suppression 設計 (§7)
• EKS Vol3 (WP:2241): ArgoCD で Security Hub Terraform 設定を GitOps 管理し、コンフィグ drift を検知 (§6)

1-2. 本記事のゴール

本記事を完了すると、以下の成果物が手元に揃います。

• GuardDuty Terraform 実装: aws_guardduty_detector + aws_guardduty_organization_admin_account で全 Member Account を自動有効化し、8 カテゴリの脅威検知が稼働する
• Security Hub Findings 集約: aws_securityhub_organization_admin_account + aws_securityhub_standards_subscription で CIS v3.0 / AWS Foundational v1.0 のコンプライアンス評価が自動実行される
• マルチアカウント一元管理: Delegated Admin Account に全 Member Account の Findings が集約され、Cross-Region Aggregation で全リージョン横断の可視性が確立される
• EventBridge 通知パイプライン: 重要度 HIGH/CRITICAL の Findings を EventBridge Pattern でフィルタし、SNS → Lambda → Slack への自動通知が稼働する
• Automation Rules + SSM 自動修復: 既知パターンの Findings が自動 Suppression または RESOLVED に更新され、Findings ノイズが削減される
• Findings トリアージ Runbook 5 種: 重大対応 / 誤検知判定 / コスト棚卸 / カスタムルール / Suppression 設計の運用フローが整備される
• セキュリティ Vol2/3 の基盤確立: 本記事で構築した Findings パイプラインを基盤として、IAM Identity Center (Vol2) と AWS Config + Conformance Pack (Vol3) へシームレスに拡張できる

本記事の構成早見表

1-3. 読者像

本記事は以下の読者を想定しています。

• AWS Organizations でマルチアカウント環境を運用中で、GuardDuty / Security Hub の本番運用に課題を感じているインフラ・SRE エンジニア
• GuardDuty / Security Hub を導入済みだが Findings の対処フローが属人化しており、体系的な運用体制を整備したい方
• Terraform IaC 化・EventBridge 通知自動化・Findings 自動修復の実装を 1 冊で完結させたい方
• CIS v3.0 / AWS Foundational Security Best Practices v1.0 のコンプライアンス評価を自動化したい方
• 観測性 3 部作 (CloudWatch Logs Insights / X-Ray + ADOT / Application Signals + SLO) を読了し、セキュリティ検知層を追加したい方
• 既存の AWS セキュリティ対策を IaC 化・自動化したいが、どこから着手すればよいか分からない方

本記事の Terraform スニペットはそのまま本番環境へ適用できる設計です。マルチアカウント環境の Delegated Admin 設定 + Findings 集約 + 自動通知・修復を 1 記事で完結させているため、分散した複数資料を参照せずに実装を完了できます。

GuardDuty / Security Hub 未経験者も §3・§4 の仕組み解説から順に読み進めることで、本番導入に必要な設計判断を自分で行えるようになります。既に一部導入済みの環境では §5〜§7 の Terraform コードを差分適用するだけで通知・自動修復まで拡張できます。

1-4. なぜ今これを書くか

競合記事 10 件を調査した結果、以下の空白地帯を確認しました。

• マルチアカウント Organizations + Delegated Admin を Terraform で一気通貫実装した記事が競合 10 件中 0 件
• EventBridge 通知パイプライン + Automation Rules 自動修復の実装記事が競合 10 件中 0 件
• Findings トリアージの体系的な Runbook (5 種) を提示した記事が競合に存在しない
• 「脅威検知 → 通知 → 修復 → 棚卸」の運用ループを 1 記事で完結させた構成が競合に見当たらない
• 観測性 Vol1 (Logs Insights) との「セキュリティイベント × ログ相関分析」連携を扱った記事が競合 0 件

本記事は Lambda 3 部作・EKS 3 部作・観測性 3 部作の既存 9 巻読者へ、セキュリティ検知層を提供する 12 巻シリーズ起点として設計されています。GuardDuty で検知した脅威を Security Hub で集約し、EventBridge で即時通知・SSM で自動修復するまでの全体像を Terraform IaC で管理します。セキュリティ Vol2 (IAM Identity Center) では本記事の Findings パイプラインを拡張し、Vol3 (AWS Config + Conformance Pack) ではコンプライアンス自動評価まで範囲を広げます。

1-5. 読み進め方ガイド

本記事は通読を基本としますが、目的に応じて以下の読み進め方を推奨します。

§3・§4 は「脅威検知の仕組みと集約方法を理解する」意思決定層で、GuardDuty / Security Hub 導入可否の判断に最適です。§5〜§7 は「Terraform でどう実装するか」の実践層で、コードをそのまま活用できます。

前提シリーズ: 観測性Vol1 CloudWatch Logs Insightsを読む

2. 前提・環境・準備

2-1. 前提環境

本記事では以下の環境が整備済みであることを前提とします。

• AWS Organizations 設定済み: Management Account と Member Account が Organizations で管理されていること
• Delegated Admin Account: GuardDuty / Security Hub の Delegated Admin として指定する AWS アカウントが存在すること (本記事の §5 で Terraform により設定)
• Terraform >= 1.7: terraform version で 1.7 以上であることを確認
• AWS Provider v5.x: aws_guardduty_organization_admin_account / aws_securityhub_organization_admin_account 等を使用するため v5.x 以上が必要
• AWS CLI v2: aws --version で v2.x 以上であることを確認
• IAM 権限: guardduty:* / securityhub:* / organizations:* / events:* / sns:* / lambda:* / ssm:* を Management Account または Delegated Admin Account に付与済み

# 前提環境の確認コマンド
aws --version
terraform version
aws sts get-caller-identity

# Organizations の有効化確認
aws organizations describe-organization \
  --query 'Organization.{Id:Id,MasterAccountId:MasterAccountId}' \
  --output table

# GuardDuty 有効化状態の確認 (ap-northeast-1)
aws guardduty list-detectors --region ap-northeast-1

# Security Hub 有効化状態の確認 (ap-northeast-1)
aws securityhub describe-hub --region ap-northeast-1 2>&1 | head -5

2-2. 使用技術スタック

Terraform 主要リソース一覧

2-3. ゴール状態の定義

本記事の完了時点で、以下の状態が AWS マネジメントコンソールおよび terraform state で確認できることをゴールとします。

• GuardDuty: 全 Member Account で有効化済み。8 カテゴリの Threat Detection が稼働し、Test Finding が Delegated Admin の Findings 一覧に集約されている
• Security Hub: 全 Member Account の Findings が Delegated Admin へ Aggregation されている。CIS v3.0 + AWS Foundational Security Best Practices v1.0 が有効化済みで、Standards 評価スコアが確認可能
• 通知パイプライン: 重要度 HIGH / CRITICAL の Findings → EventBridge → SNS → Lambda → Slack の疎通が確認済み。テスト Finding の Slack 通知が到達している
• 自動修復: Automation Rules が 2 件以上定義済み。既知パターンの Findings が自動 Suppression または RESOLVED に更新されている

確認コマンドチートシート

# GuardDuty Findings 確認 (Delegated Admin 側)
aws guardduty list-findings \
  --detector-id $(aws guardduty list-detectors --region ap-northeast-1 \
 --query 'DetectorIds[0]' --output text) \
  --region ap-northeast-1

# Security Hub Findings 確認 (重要度 HIGH)
aws securityhub get-findings \
  --filters '{"SeverityLabel":[{"Value":"HIGH","Comparison":"EQUALS"}]}' \
  --region ap-northeast-1 \
  --query 'Findings[:3].{Title:Title,Severity:Severity.Label}' \
  --output table

# Automation Rules 確認
aws securityhub list-automation-rules --region ap-northeast-1

2-4. コスト概算

本記事の実装によって発生する月額費用の目安を示します。

GuardDuty のコストはログ量に比例するため、VPC Flow Logs / DNS Logs の量が多い環境では $50〜$200/月に達する場合があります。§7 でコスト抑制のための Suppression Rules 設計と Protection Plans の選択的有効化を解説します。

3. GuardDuty の仕組み + Threat Detection 8カテゴリ + Protection Plans 詳説

3-1. GuardDuty の仕組み概要

Amazon GuardDuty は AWS が提供するマネージド型の継続的脅威検知サービスだ。エージェントのインストールが不要で、既存の AWS ログインフラを活用してセキュリティリスクをリアルタイムに検知できる。

GuardDuty は以下の 3 種類のデータソースを継続的に取り込む。

これらのデータをもとに GuardDuty は 機械学習モデル と CrowdStrike / Proofpoint / AWS 内部脅威インテリジェンスリスト を組み合わせてベースラインを構築し、逸脱した動作を Finding として生成する。

Finding は ASFF (Amazon Security Finding Format) に準拠した JSON 形式で出力され、Security Hub へ自動集約される。各 Finding には severity スコア (0–10) が付与され、5 段階に分類される。

GuardDuty は 30 日間無料トライアルを提供しており、本番採用前に検知件数とコストを試算できる。トライアル中も全機能が利用可能で、GuardDuty コンソールの「使用状況」タブで月額コストシミュレーションを確認できる。

sequenceDiagram
 participant VPC as VPC Flow Logs
 participant DNS as DNS Logs
 participant CT as CloudTrail Events
 participant GD as GuardDuty Engine
 participant ML as ML / ThreatIntel
 participant SH as Security Hub
 participant EB as EventBridge

 VPC->>GD: ネットワークフローログ送出
 DNS->>GD: DNS クエリログ送出
 CT->>GD: CloudTrail API イベント送出
 GD->>ML: 機械学習分析 + 脅威インテリジェンス照合
 ML-->>GD: 異常パターン検知
 alt 脅威検知あり
  GD->>SH: Finding 送出 (ASFF 形式)
  GD->>EB: EventBridge イベント発火
  EB->>EB: EventBridge Rule (severity HIGH/CRITICAL) マッチ
 else 脅威なし
  GD->>GD: 継続監視 (ベースライン更新)
 end

3-2. Threat Detection 8カテゴリ 詳説

GuardDuty Findings は 8 つのカテゴリ に分類される。各カテゴリの特性と推奨対応を把握しておくことで、アラート発生時の初動判断が迅速になる。

運用ポイント: HIGH/CRITICAL (severity >= 7.0) はインシデント対応の起動要件とし、§6 で実装する EventBridge → SNS → Slack/PagerDuty フローで即時通知する。LOW Findings は蓄積して週次レビューで傾向分析に使う。CRITICAL の UnauthorizedAccess:IAMUser/InstanceCredentialExfiltration は IMDS v2 強制化 (http_tokens = "required") で根本的に予防できる。

誤検知 (false positive) が多い Finding タイプは Suppression Rule を作成してアーカイブ自動化できる。ただし Suppression Rule は Finding の記録自体を消すわけではなく、Security Hub への転送は継続されるため、監査ログには影響しない。

3-3. Protection Plans 詳説

GuardDuty の基本機能に加えて、4 種類の Protection Plans を有効化することで保護範囲を拡張できる。本番環境では全て有効化が推奨される。

S3 Protection は S3 のデータプレーンイベントを GuardDuty が直接取り込む仕組みで、CloudTrail S3 データイベントの有効化は不要だ。EKS Protection の Runtime Monitoring には GuardDuty Security Agent (DaemonSet) を EKS クラスターにデプロイする追加ステップが必要になる。RDS Protection と Runtime Monitoring は Terraform Provider 5.x での aws_guardduty_detector リソースへの直接組み込みに一部制約があり、aws_guardduty_organization_configuration または AWS コンソールでの有効化を併用する。

Protection Plans のコスト目安として、S3 Protection は S3 オブジェクト 100 万件あたり約 $0.20、EKS Protection は EKS ノード時間で課金される。GuardDuty コンソールの「コスト見積もり」セクションで現在の使用量ベースの試算値を確認できるので、本番有効化前に必ず確認しておくこと。マルチリージョン構成の場合は有効化するリージョンごとに費用が発生するため、ログが集まるリージョン (ap-northeast-1 等) から順に有効化するアプローチが費用対効果に優れる。

3-4. Terraform 実装 — GuardDuty 有効化 + Protection Plans

# GuardDuty Detector 有効化
resource "aws_guardduty_detector" "main" {
  enable = true

  datasources {
 s3_logs {
enable = true  # S3 Protection
 }
 kubernetes {
audit_logs {
  enable = true  # EKS Protection (Audit Log)
}
 }
 malware_protection {
scan_ec2_instance_with_findings {
  ebs_volumes {
 enable = true  # EC2 Malware Protection
  }
}
 }
  }
}

# GuardDuty Filter — HIGH/CRITICAL (severity >= 7) のみ通知対象
resource "aws_guardduty_filter" "high_severity" {
  name  = "high-severity-findings"
  detector_id = aws_guardduty_detector.main.id
  action= "NOOP"
  rank  = 1

  finding_criteria {
 criterion {
field  = "severity"
greater_than_or_equal = "7"
 }
  }
}

3-4b. Terraform 実装 — Organization レベルの Protection Plans 有効化

マルチアカウント構成では、Organizations の Delegated Administrator から Organization 全体に Protection Plans を一括有効化できる。

# Organization 全体への GuardDuty 設定 (管理アカウントで実行)
resource "aws_guardduty_organization_configuration" "main" {
  auto_enable_organization_members = "NEW"
  detector_id  = aws_guardduty_detector.main.id

  datasources {
 s3_logs {
auto_enable = true
 }
 kubernetes {
audit_logs {
  enable = true
}
 }
 malware_protection {
scan_ec2_instance_with_findings {
  ebs_volumes {
 auto_enable = true
  }
}
 }
  }
}

auto_enable_organization_members = "NEW" を設定すると、新規メンバーアカウントへも GuardDuty が自動的に有効化される。既存メンバーへの一括有効化は "ALL" を指定する。

3-5. AWS CLI 確認

# GuardDuty Detector 一覧確認
aws guardduty list-detectors --region ap-northeast-1

# DETECTOR_ID を変数に格納
DETECTOR_ID=$(aws guardduty list-detectors \
  --region ap-northeast-1 \
  --query 'DetectorIds[0]' \
  --output text)

# HIGH/CRITICAL Findings 取得 (severity >= 7.0)
aws guardduty list-findings \
  --detector-id "$DETECTOR_ID" \
  --finding-criteria '{"Criterion":{"severity":{"Gte":7}}}' \
  --region ap-northeast-1

# Finding 詳細取得
aws guardduty get-findings \
  --detector-id "$DETECTOR_ID" \
  --finding-ids "<FINDING_ID>" \
  --region ap-northeast-1

# Protection Plans の有効化状態確認
aws guardduty get-detector \
  --detector-id "$DETECTOR_ID" \
  --region ap-northeast-1 \
  --query 'DataSources'

3-6. コンソール確認手順

1. GuardDuty コンソール → Findings タブ → Severity フィルターで HIGH/CRITICAL に絞り込み、リソース・アクター IP・ポートを確認する
2. Findings の詳細画面 → 右側パネルで MITRE ATT&CK タクティクスと AWS 推奨アクションを確認する
3. Findings を選択 → アクション → アーカイブ でアラート対応済みにマークし、未対応 Findings との混在を防ぐ
4. 保護設定 → 保護プラン → S3 / EKS / RDS / Runtime Monitoring の有効化状態を確認する
5. 設定 → Detectors → リージョン単位の有効化状態・30 日間の推定月額コストを確認する

GuardDuty Findings と分散トレースを組み合わせると、不審な API 呼び出しの前後処理を X-Ray で可視化して侵害経路の特定が容易になる (→ 観測性 Vol2: X-Ray + ADOT 分散トレーシング基盤)。EKS 環境では IRSA で IAM ロールを Pod 単位に割り当て、GuardDuty EKS Protection でその操作ログを監視することで最小権限と可観測性を両立できる (→ EKS Vol2: IRSA)。

次節 §4 では Security Hub が GuardDuty Findings を受け取り、CIS / AWS Foundational Security Best Practices Standards でどのように評価・集約するかを解説する。

4. Security Hub Findings 集約 + ASFF 構造 + Standards (CIS/AWS Foundational) 完全実装

Security Hub は GuardDuty・Inspector・Macie・Config など複数のセキュリティサービスからの Findings を ASFF (AWS Security Finding Format) という統一 JSON フォーマットで集約するマネージドサービスです。マルチアカウント構成でも Organizations 統合により全アカウントの Findings を Delegated Administrator アカウントに集約できる。本章では ASFF の構造・Security Hub 有効化 Terraform 実装・Standards (CIS/AWS Foundational/PCI DSS) の設定・Findings フィルタリングと管理 CLI まで本番運用に必要な実装を一気通貫で網羅する。

4-1. ASFF (AWS Security Finding Format) 詳説

ASFF は Security Hub が採用する Findings の統一 JSON フォーマットであり、GuardDuty・Inspector・Macie・Config・サードパーティツールがすべてこのフォーマットで Findings を Security Hub に送出する。フォーマットを統一することで、発生元が異なる Findings の横断的な集計・フィルタリング・自動ワークフローが一元管理できる。

GuardDuty が検出した UnauthorizedAccess:EC2/SSHBruteForce は ProductArn = guardduty で ASFF に変換され、Severity.Normalized = 80 (HIGH) として Security Hub に送出される。Inspector による CVE 検出も同様に ASFF 変換されて集約されるため、コンソール 1 画面で全サービスの Findings を横断確認できる。Workflow.Status フィールドで NEW / NOTIFIED / RESOLVED / SUPPRESSED のライフサイクルを管理し、対応済み Findings を確実にクローズする運用が本番環境では必須となる。

主要フィールド一覧:

Severity.Normalized の重要度マッピングと対応 SLA:

ASFF JSON サンプル (GuardDuty Findings の例):

{
  "SchemaVersion": "2018-10-08",
  "Id": "arn:aws:securityhub:ap-northeast-1:123456789012:finding/XXXX",
  "ProductArn": "arn:aws:securityhub:ap-northeast-1::product/aws/guardduty",
  "GeneratorId": "arn:aws:guardduty:ap-northeast-1:123456789012:detector/XXXX",
  "AwsAccountId": "123456789012",
  "Types": ["Software and Configuration Checks/AWS Security Best Practices"],
  "Severity": { "Normalized": 80, "Label": "HIGH" },
  "Workflow": { "Status": "NEW" },
  "Resources": [{
 "Type": "AwsEc2Instance",
 "Id": "arn:aws:ec2:ap-northeast-1:123456789012:instance/i-XXXX"
  }]
}

4-2. Security Hub 有効化 Terraform 実装

Security Hub を Terraform で有効化し、CIS AWS Foundations Benchmark v3.0・AWS Foundational Security Best Practices v1.0・PCI DSS v3.2.1 の Standards を有効化する。GuardDuty Findings を Security Hub に統合し、HIGH/CRITICAL の NEW Findings を一覧表示する Insights (カスタムビュー) も設定する。

Standards を有効化する前に aws_securityhub_account で Security Hub 本体を有効化する必要があります。depends_on で順序を保証しないと race condition が発生して terraform apply が失敗するため必須設定です。

# Security Hub アカウント有効化
resource "aws_securityhub_account" "main" {}

# CIS AWS Foundations Benchmark v3.0 有効化
resource "aws_securityhub_standards_subscription" "cis_300" {
  depends_on = [aws_securityhub_account.main]
  standards_arn = "arn:aws:securityhub:ap-northeast-1::standards/cis-aws-foundations-benchmark/v/3.0.0"
}

# AWS Foundational Security Best Practices v1.0 有効化
resource "aws_securityhub_standards_subscription" "aws_foundational" {
  depends_on = [aws_securityhub_account.main]
  standards_arn = "arn:aws:securityhub:ap-northeast-1::standards/aws-foundational-security-best-practices/v/1.0.0"
}

# PCI DSS v3.2.1 有効化 (決済・金融系環境のみ)
resource "aws_securityhub_standards_subscription" "pci_dss" {
  depends_on = [aws_securityhub_account.main]
  standards_arn = "arn:aws:securityhub:ap-northeast-1::standards/pci-dss/v/3.2.1"
}

# GuardDuty の Findings を Security Hub に統合
resource "aws_securityhub_product_subscription" "guardduty" {
  depends_on  = [aws_securityhub_account.main]
  product_arn = "arn:aws:securityhub:ap-northeast-1::product/aws/guardduty"
}

# Security Hub Insights (カスタムビュー) — HIGH/CRITICAL + NEW の Findings を AccountId 単位で集計
resource "aws_securityhub_insight" "critical_findings" {
  name = "critical-and-high-findings"

  filters {
 severity_label {
comparison = "EQUALS"
value= "CRITICAL"
 }
 severity_label {
comparison = "EQUALS"
value= "HIGH"
 }
 workflow_status {
comparison = "EQUALS"
value= "NEW"
 }
  }

  group_by_attribute = "AwsAccountId"
}

4-3. CIS / AWS Foundational / PCI DSS Standards 比較

Security Hub で利用可能な主要 Standards の特性を比較し、有効化の優先順位を定める。Standards ごとにカバレッジ・コントロール数・対象環境が異なるため、組織のリスクプロファイルに合わせて選択する。

Standards の有効化優先順位:

1. AWS Foundational Security Best Practices (最優先) — S3 パブリックアクセス・IAM MFA・暗号化など広範囲のサービスを網羅。
   Security score 算出の主軸となり、有効化直後から最も多くの改善ポイントを発見できる
2. CIS AWS Foundations Benchmark — CloudTrail 有効化・IAM パスワードポリシー・VPC フローログなどアカウント基盤設定の 58 コントロールに特化。
   CIS 単独でも IAM/ログ設定の網羅的チェックとして有用
3. PCI DSS — カード決済・金融系環境の場合のみ追加有効化。
   非該当環境での有効化はノイズ増加につながるため対象環境を絞って有効化する

コントロール抑制 (Suppressed Controls) の活用:

組織ポリシー上対応不要なコントロールは SUPPRESSED に設定することで、Security score のノイズを除去できる。抑制設定は以下の CLI で実行する。

# 特定コントロールを DISABLED (抑制) に設定 (例: 開発環境の MFA 未設定コントロール)
aws securityhub update-standards-control \
  --standards-control-arn "arn:aws:securityhub:ap-northeast-1:123456789012:control/cis-aws-foundations-benchmark/v/3.0.0/1.1" \
  --control-status "DISABLED" \
  --disabled-reason "開発環境: MFA 未設定はセキュリティポリシーで許容" \
  --region ap-northeast-1

4-4. Findings 管理 Terraform + CLI

Findings のワークフロー管理は batch-update-findings CLI と §7 で実装する Automation Rules で行う。ここでは手動管理 CLI コマンドと Findings 取得の基本操作を示す。

# Automation Rules は §7 で完全実装
# ここでは Insights によるカスタム集計のみ設定
# aws_securityhub_automation_rule リソースの詳細は §7 を参照

# Security Hub Findings 取得 (HIGH/CRITICAL + NEW ステータスのみ)
aws securityhub get-findings \
  --filters '{"SeverityLabel":[{"Value":"HIGH","Comparison":"EQUALS"},{"Value":"CRITICAL","Comparison":"EQUALS"}],"WorkflowStatus":[{"Value":"NEW","Comparison":"EQUALS"}]}' \
  --region ap-northeast-1

# Findings の一括ステータス更新 (NEW → NOTIFIED)
aws securityhub batch-update-findings \
  --finding-identifiers '[{"Id":"FINDING_ARN","ProductArn":"PRODUCT_ARN"}]' \
  --workflow '{"Status":"NOTIFIED"}' \
  --region ap-northeast-1

# Standards の未達成コントロール一覧確認
aws securityhub get-findings \
  --filters '{"ComplianceStatus":[{"Value":"FAILED","Comparison":"EQUALS"}],"WorkflowStatus":[{"Value":"NEW","Comparison":"EQUALS"}]}' \
  --query 'Findings[].{Title:Title,Severity:Severity.Label,ProductArn:ProductArn}' \
  --region ap-northeast-1

# Automation Rules 一覧確認
aws securityhub list-automation-rules --region ap-northeast-1

# Insights 結果確認 (HIGH/CRITICAL Findings を AccountId 単位で集計)
aws securityhub get-insight-results \
  --insight-arn "arn:aws:securityhub:ap-northeast-1:123456789012:insight/custom/XXXX" \
  --region ap-northeast-1

# アクティブな CRITICAL Findings 件数確認
aws securityhub get-findings \
  --filters '{"RecordState":[{"Value":"ACTIVE","Comparison":"EQUALS"}],"SeverityLabel":[{"Value":"CRITICAL","Comparison":"EQUALS"}]}' \
  --query 'length(Findings)' \
  --region ap-northeast-1

4-5. コンソール確認手順

Security Hub コンソールでの主要な確認ポイントを示す。Standards の達成状況・要対応 Findings の特定・統合サービスの確認まで一連の確認フローとして実施する。

1. Summary タブ → Security score (Standards 達成率) を確認。CIS v3.0 + AWS Foundational で 80% 以上を目標とする。スコア低下は Standards 未達成コントロール増加を示す
2. Findings タブ → フィルタ条件: Severity = HIGH/CRITICAL かつ Workflow = NEW で要対応 Findings を抽出。10 件以上の場合は即時トリアージを開始する
3. Standards タブ → CIS v3.0 / AWS Foundational それぞれを選択し、未達成コントロール一覧を確認。コントロール単位で Disable/Suppress が設定可能
4. Insights タブ → カスタムビューで AccountId 単位の Findings 集計を確認。マルチアカウント構成では Organizations 全体の集計が可能 (§5 参照)
5. Integrations タブ → GuardDuty・Inspector・Macie の統合ステータスを確認。Enabled 表示であれば Findings が正常に集約されている
6. Settings → Exports タブ → Findings を S3 バケットにエクスポートして長期アーカイブ保存が可能。SIEM 連携時はここからエクスポート設定を有効化する

4-6. クロスリンク

• CloudWatch Logs Insights + メトリクスフィルタ 本番運用 (観測性 Vol1) — CloudTrail Logs × Security Hub Findings 相関分析
• EKS IRSA 本番運用 (EKS Vol2) — IRSA 経由 Security Hub 操作権限設定パターン

5. マルチアカウント運用 — Organizations + Delegated Admin + Cross-Region Aggregation Terraform 完全実装

5-1. マルチアカウント構成の概要

AWS Organizations を利用したマルチアカウント構成では、セキュリティ管理を3種類のアカウントロールに分割する。

• Management Account: Organizations のルートアカウント。GuardDuty / Security Hub の Delegated Admin を指名する権限を持ち、指名操作はこのアカウントの IAM 権限で実行する。
• Delegated Admin Account: GuardDuty / Security Hub の集約管理専用アカウント。Management Account とは完全に分離し、セキュリティチームが管理するセキュリティ専用アカウントとして構成することが強く推奨される。Member Accounts の Findings を一元的に集約・管理する中核アカウントとなる。
• Member Accounts: GuardDuty / Security Hub が Auto-Enable 設定により自動有効化される。新規アカウントが Organizations に追加された場合も自動的に対象となる。手動で各アカウントに設定する運用は廃止し、Delegated Admin による一元管理に統一する。
• Cross-Region Aggregation: aws_securityhub_finding_aggregator により、複数リージョンの Findings を1つの aggregating_region に集約する。リージョン横断の一元的な Findings 管理が実現し、セキュリティ運用チームがコンソールを複数リージョンで切り替える手間を排除できる。

この構成により、Security Hub Findings / GuardDuty Findings がアカウント・リージョンをまたいで Delegated Admin Account の1か所に集約され、EventBridge ルールや自動修復 Lambda の適用対象が統一される。

セキュリティ専用アカウントは本番/開発/ステージングといったワークロードアカウントとは独立して管理し、最小権限の IAM ポリシーで運用することが AWS Well-Architected Security Pillar の推奨構成となる。

5-2. マルチアカウント運用フロー — fig04

flowchart TD
 A[Management Account\nOrganizations Root] --> B{Delegated Admin\n指名済みか?}
 B -- No --> C[aws_guardduty_organization_admin_account\naws_securityhub_organization_admin_account\nで指名]
 B -- Yes --> D[Delegated Admin Account\nセキュリティ専用]
 C --> D
 D --> E{Auto-Enable 設定}
 E --> F[GuardDuty: auto_enable_organization_members = ALL\nすべての既存+新規 Member に自動有効化]
 E --> G[Security Hub: auto_enable = true\nすべての既存+新規 Member に自動有効化]
 F & G --> H[Member Account 自動有効化]
 H --> I{Cross-Region Aggregation}
 I --> J[aws_securityhub_finding_aggregator\nで全リージョン集約]
 J --> K[Delegated Admin の\naggregating_region で一元管理]

5-3. GuardDuty Organizations 設定 — Terraform 完全実装

GuardDuty のマルチアカウント設定は、Management Account での Delegated Admin 指名と、Delegated Admin Account での Organization 設定の2段階で構成する。Terraform では alias provider を使用して両アカウントの設定を同一コードベースで管理する。

# GuardDuty Delegated Admin 指名 (Management Account で実行)
resource "aws_guardduty_organization_admin_account" "delegated" {
  provider= aws.management_account
  admin_account_id = var.security_account_id
}

# GuardDuty Organization 設定 (Delegated Admin Account で実行)
resource "aws_guardduty_organization_configuration" "main" {
  provider = aws.security_account
  auto_enable_organization_members = "ALL"
  detector_id = aws_guardduty_detector.main.id

  depends_on = [aws_guardduty_organization_admin_account.delegated]

  datasources {
 s3_logs {
auto_enable = true
 }
 kubernetes {
audit_logs {
  enable = true
}
 }
 malware_protection {
scan_ec2_instance_with_findings {
  ebs_volumes {
 auto_enable = true
  }
}
 }
  }
}

auto_enable_organization_members = "ALL" を指定することで、既存の Member Account すべてと、将来 Organizations に追加される新規アカウントに対して GuardDuty が自動有効化される。NEW を指定すると新規アカウントのみが対象になるため、既存アカウントへの適用漏れが発生する点に注意する。

datasources セクションでは S3・Kubernetes・MalwareProtection の各データソースを Auto-Enable 設定している。EKS Audit Logs や Malware Protection は追加料金が発生するため、コスト影響を事前に試算した上で auto_enable / enable の値を組織ポリシーに合わせて調整する。

5-4. Security Hub Organizations 設定 — Terraform 完全実装

Security Hub の Delegated Admin 指名と Organization 設定、さらに Cross-Region Aggregation を一括で Terraform 管理する。

# Security Hub Delegated Admin 指名 (Management Account で実行)
resource "aws_securityhub_organization_admin_account" "delegated" {
  provider= aws.management_account
  admin_account_id = var.security_account_id
}

# Security Hub Organization 設定 (Delegated Admin Account で実行)
resource "aws_securityhub_organization_configuration" "main" {
  provider  = aws.security_account
  depends_on= [aws_securityhub_organization_admin_account.delegated]
  auto_enable  = true
  auto_enable_standards = "NONE"
}

# Cross-Region Aggregation (全リージョンの Findings を ap-northeast-1 に集約)
resource "aws_securityhub_finding_aggregator" "main" {
  provider  = aws.security_account
  linking_mode = "ALL_REGIONS"

  depends_on = [aws_securityhub_organization_configuration.main]
}

auto_enable_standards = "NONE" を推奨する理由は、各 Member Account で有効化すべき Standards (AWS Foundational Security Best Practices / CIS AWS Foundations Benchmark) はアカウントの用途により異なるケースがあるためです。Standards の適用方針を組織内で決定したうえ、NONE / DEFAULT を選択します。

aws_securityhub_finding_aggregator の linking_mode は以下の3通りから選択する:

• ALL_REGIONS: 全リージョンを集約対象とする（推奨）
• SPECIFIED_REGIONS: specified_regions で列挙したリージョンのみを集約対象とする
• ALL_REGIONS_EXCEPT_SPECIFIED: specified_regions で列挙したリージョンを除く全リージョンを集約対象とする

本番環境では ALL_REGIONS を推奨する。新規リージョンが AWS から追加された際も自動で集約対象となり、設定漏れを防止できる。

Terraform の alias provider と変数設定例:

provider "aws" {
  alias= "management_account"
  profile = "management-account"
  region  = "ap-northeast-1"
}

provider "aws" {
  alias= "security_account"
  profile = "security-account"
  region  = "ap-northeast-1"
}

variable "security_account_id" {
  description = "セキュリティ専用アカウント (Delegated Admin) のAWSアカウントID"
  type  = string
}

var.security_account_id には セキュリティ専用アカウントのAWSアカウントIDを渡す。terraform.tfvars または CI/CD パイプラインの環境変数 TF_VAR_security_account_id で設定することを推奨する。アカウントIDをコードに直書きすると、アカウント再編成時の変更箇所が増えるため、必ず変数化して管理する。

5-5. Member Account 追加・確認 — AWS CLI

Delegated Admin 指名と Organization 設定が完了した後、以下の CLI コマンドで設定状態を確認する。

# GuardDuty Organization Admin 確認
aws guardduty list-organization-admin-accounts --region ap-northeast-1

# GuardDuty Members 一覧確認 (Delegated Admin Account で実行)
DETECTOR_ID=$(aws guardduty list-detectors --region ap-northeast-1 --query 'DetectorIds[0]' --output text)
aws guardduty list-members \
  --detector-id "$DETECTOR_ID" \
  --region ap-northeast-1

# Security Hub Members 一覧確認
aws securityhub list-members --region ap-northeast-1

# Cross-Region Aggregation 確認
aws securityhub list-finding-aggregators --region ap-northeast-1

list-members で RelationshipStatus: Enabled / MemberStatus: Enabled が全 Member Account で表示されていれば、Auto-Enable による自動有効化が正常に動作している。RelationshipStatus: Created は招待送信済みで未承諾の状態を示す。Organizations を利用した自動有効化では承諾フローが不要なため、Created が残り続ける場合は Delegated Admin の Organizations 設定を確認する。

list-finding-aggregators のレスポンスに FindingAggregatorArn と LinkingMode: ALL_REGIONS が含まれていることを確認する。RegionLinkingMode が空の場合は Cross-Region Aggregation が未設定であるため、aws_securityhub_finding_aggregator リソースの depends_on と apply 順序を確認する。

5-6. コンソールによる確認手順

Terraform 適用後、AWS Management Console で以下の手順により設定を視覚的に確認する。

• Security Hub コンソール → Settings → Accounts: Member アカウントの一覧と有効化ステータスを確認する。Status: Enabled が全 Member Account に表示されていること。Status: Enabling は処理中を示すため、数分待機して再確認する。
• Security Hub コンソール → Settings → Regions: Cross-Region Aggregation のステータスと Linked / Aggregation リージョンの一覧を確認する。aggregating_region に ap-northeast-1 が設定されていること。
• GuardDuty コンソール → Settings → Accounts: Organization members の自動有効化ステータスを確認する。Member type: ORGANIZATION で全 Member が表示され、Relationship status: Enabled であること。
• Security Hub コンソール → Findings: Account ID フィルタで Member Accounts の Findings が Delegated Admin Account に集約されていることを確認する。AccountId 列に複数アカウントのIDが表示されること。
• Organizations コンソール → Services → AWS GuardDuty: Delegated administrator 欄に セキュリティ専用アカウント ID が表示されていること。
• Organizations コンソール → Services → AWS Security Hub: Delegated administrator 欄に セキュリティ専用アカウント ID が表示されていること。

5-7. 落とし穴と対策

1. Delegated Admin 指名順序の誤り

GuardDuty の Delegated Admin を先に指名し、その後 Security Hub の Delegated Admin を指名する順序を守る必要がある。逆順で適用すると API エラーになるケースもある。Terraform の depends_on を活用して依存関係を明示的に管理する。

2. auto_enable_organization_members の選択ミス

NEW を指定すると既存 Member Account への GuardDuty 有効化が行われない。初回適用時に既存アカウントへの設定漏れが発生するため、新規・既存を問わず全 Member に適用する ALL を推奨する。

3. auto_enable_standards の誤設定

DEFAULT を指定すると、Member Account に AWS Foundational Security Best Practices Standard が自動適用される。Standards ごとに課金が発生するため、意図せずコスト増加につながる可能性もある。Standards の適用方針を組織内で決定したうえ、NONE / DEFAULT を選択する。

4. IAM 権限不足による Delegated Admin 指名失敗

Management Account で aws_guardduty_organization_admin_account / aws_securityhub_organization_admin_account を作成するには organizations:EnableAWSServiceAccess・organizations:RegisterDelegatedAdministrator の権限が必要です。Terraform 実行ロールのポリシーへ事前付与しておきましょう。

5. Terraform Provider の alias 設定漏れ

複数アカウントを管理する場合、各リソースに対して適切な provider = aws.{alias} を指定しないと、意図しないアカウントにリソースが作成される。Management Account 操作用と Delegated Admin Account 操作用の provider alias を明確に分離し、各リソースへの割り当てを徹底する。

6. Cross-Region Aggregation の削除時の依存関係エラー

aws_securityhub_finding_aggregator を削除する前に aws_securityhub_organization_configuration を削除しようとすると、依存関係エラーが発生する。Terraform destroy 時は aws_securityhub_finding_aggregator → aws_securityhub_organization_configuration → aws_securityhub_organization_admin_account の順に削除する必要がある。terraform destroy -target で順序を制御する。

5-8. 関連記事

• EKS IRSA 本番運用 (Vol2): IRSA 経由での Security Hub / GuardDuty 操作権限付与 (Organization member アカウントへの適用例)
• EKS ALB + Argo CD 本番運用 (Vol3): Argo CD を用いた Security Hub Terraform の GitOps 管理

6. EventBridge → SNS → Lambda (Slack Webhook) 自動通知パイプライン Terraform 完全実装

6-1. 通知パイプラインの概要

Security Hub が検出した Findings を即時に Slack へ通知するパイプラインは、EventBridge → SNS → Lambda の 3 段構成で実現する。EventBridge Rule が Security Hub の Security Hub Findings - Imported イベントを受け取り、重要度フィルタ（CRITICAL / HIGH）かつ WorkflowStatus = NEW・RecordState = ACTIVE に一致する Findings のみを SNS Topic に転送する。SNS は Lambda 関数をサブスクリプション経由で呼び出し、Lambda が Slack Webhook API へ整形済みメッセージを POST する仕組みだ。

このアーキテクチャの利点は 3 点ある。第一に重要度フィルタにより CRITICAL / HIGH Findings だけを通知し、LOW / MEDIUM のノイズを完全に排除できる。第二に Lambda 内でメッセージのカスタマイズ・重複排除・通知先の条件分岐（例: 重要度別チャンネル振り分け）を柔軟に実装できる。第三に Terraform による IaC 管理で通知ルールのバージョン管理・PR レビュー・ロールバックが容易になる。

Slack メッセージには AccountId・Region・FindingType・Severity・Title の 5 項目を含め、担当チームが即座にトリアージを開始できる情報密度を確保する。EventBridge → SNS の組み合わせにより、Lambda への直接呼び出しと比較して SNS のリトライ機能・デッドレターキュー（DLQ）活用による耐障害性も高まる。

6-2. EventBridge Rule Terraform 実装

EventBridge Rule には 3 つのフィルタ条件を設定する。source で aws.securityhub イベントのみに絞り込み、detail-type で Security Hub Findings - Imported に限定し、detail.findings.Severity.Label で HIGH と CRITICAL のみを通過させる。加えて Workflow.Status = NEW と RecordState = ACTIVE を組み合わせることで、抑制済み・クローズ済みの Findings による再通知ノイズを防ぐ。aws_sns_topic_policy で EventBridge サービスプリンシパルに SNS:Publish 権限を付与することを忘れずに設定する。

# EventBridge Rule: Security Hub HIGH/CRITICAL Findings を捕捉
resource "aws_cloudwatch_event_rule" "securityhub_findings" {
  name  = "security-hub-high-critical-findings"
  description = "Security Hub の HIGH/CRITICAL Findings を SNS に転送"

  event_pattern = jsonencode({
 source= ["aws.securityhub"]
 "detail-type" = ["Security Hub Findings - Imported"]
 detail = {
findings = {
  Severity = {
 Label = ["HIGH", "CRITICAL"]
  }
  Workflow = {
 Status = ["NEW"]
  }
  RecordState = ["ACTIVE"]
}
 }
  })
}

# EventBridge → SNS Target
resource "aws_cloudwatch_event_target" "sns_target" {
  rule= aws_cloudwatch_event_rule.securityhub_findings.name
  target_id = "security-hub-findings-sns"
  arn = aws_sns_topic.securityhub_alerts.arn
}

# EventBridge から SNS への送信権限
resource "aws_sns_topic_policy" "eventbridge_policy" {
  arn = aws_sns_topic.securityhub_alerts.arn
  policy = jsonencode({
 Version = "2012-10-17"
 Statement = [{
Effect = "Allow"
Principal = { Service = "events.amazonaws.com" }
Action = "SNS:Publish"
Resource  = aws_sns_topic.securityhub_alerts.arn
 }]
  })
}

6-3. SNS Topic + Lambda Terraform 実装

SNS Topic は kms_master_key_id = "alias/aws/sns" で AWS マネージドキーによる暗号化を有効化する。Lambda サブスクリプション (aws_sns_topic_subscription) と実行権限 (aws_lambda_permission) は必ずセットで設定し、SNS から Lambda への呼び出しを許可する。Lambda IAM Role には AWSLambdaBasicExecutionRole を付与し CloudWatch Logs への書き込みを確保する。SLACK_WEBHOOK_URL は環境変数経由で注入し、コード内ハードコードは禁止する（本番では SSM Parameter Store / Secrets Manager 経由を推奨）。

# SNS Topic
resource "aws_sns_topic" "securityhub_alerts" {
  name  = "security-hub-alerts"
  kms_master_key_id = "alias/aws/sns"
}

# SNS → Lambda サブスクリプション
resource "aws_sns_topic_subscription" "lambda_subscription" {
  topic_arn = aws_sns_topic.securityhub_alerts.arn
  protocol  = "lambda"
  endpoint  = aws_lambda_function.slack_notifier.arn
}

# Lambda 関数 (Slack Webhook 通知)
resource "aws_lambda_function" "slack_notifier" {
  function_name = "security-hub-slack-notifier"
  runtime = "python3.12"
  handler = "handler.lambda_handler"
  filename= data.archive_file.slack_notifier.output_path
  role = aws_iam_role.lambda_slack_role.arn
  timeout = 30

  environment {
 variables = {
SLACK_WEBHOOK_URL = var.slack_webhook_url
SLACK_CHANNEL  = "#aws-security-alerts"
 }
  }
}

# Lambda: SNS からの実行権限
resource "aws_lambda_permission" "sns_invoke" {
  statement_id  = "AllowSNSInvoke"
  action  = "lambda:InvokeFunction"
  function_name = aws_lambda_function.slack_notifier.function_name
  principal  = "sns.amazonaws.com"
  source_arn = aws_sns_topic.securityhub_alerts.arn
}

# Lambda IAM Role
resource "aws_iam_role" "lambda_slack_role" {
  name = "security-hub-slack-notifier-role"
  assume_role_policy = jsonencode({
 Version = "2012-10-17"
 Statement = [{
Effect = "Allow"
Principal = { Service = "lambda.amazonaws.com" }
Action = "sts:AssumeRole"
 }]
  })
}

resource "aws_iam_role_policy_attachment" "lambda_basic" {
  role = aws_iam_role.lambda_slack_role.name
  policy_arn = "arn:aws:iam::aws:policy/service-role/AWSLambdaBasicExecutionRole"
}

6-4. Lambda Python コード (Slack Webhook 通知)

Lambda 関数は SNS Records をループし、各 Finding の Severity・AccountId・Region・Title・FindingType を抽出して Slack メッセージを組み立てる。標準ライブラリ urllib.request のみを使用するため、外部ライブラリのパッケージングが不要だ。本番環境では SLACK_WEBHOOK_URL を SSM Parameter Store から動的取得し、Lambda 環境変数への直接埋め込みを避けることを推奨する。

import json
import os
import urllib.request
import urllib.error

SLACK_WEBHOOK_URL = os.environ["SLACK_WEBHOOK_URL"]

def lambda_handler(event, context):
 for record in event["Records"]:
  message = json.loads(record["Sns"]["Message"])
  findings = message.get("detail", {}).get("findings", [])
  for finding in findings:
severity = finding.get("Severity", {}).get("Label", "UNKNOWN")
account_id = finding.get("AwsAccountId", "N/A")
region = finding.get("Region", "N/A")
title = finding.get("Title", "N/A")
finding_type = finding.get("Types", ["N/A"])[0]
slack_message = {
 "text": f":rotating_light: *Security Hub {severity} Finding*\n"
f"*Account:* {account_id} | *Region:* {region}\n"
f"*Type:* {finding_type}\n"
f"*Title:* {title}"
}
req = urllib.request.Request(
 SLACK_WEBHOOK_URL,
 data=json.dumps(slack_message).encode("utf-8"),
 headers={"Content-Type": "application/json"},
 method="POST"
)
urllib.request.urlopen(req)

6-5. AWS CLI 確認

Terraform apply 後は以下の CLI コマンドで各リソースの存在・設定を確認する。

# EventBridge Rule 確認
aws events list-rules \
  --name-prefix "security-hub" \
  --region ap-northeast-1

# EventBridge Rule のターゲット確認
aws events list-targets-by-rule \
  --rule "security-hub-high-critical-findings" \
  --region ap-northeast-1

# SNS Topic 確認
aws sns list-topics --region ap-northeast-1

# SNS サブスクリプション確認 (Lambda ARN が登録されているか)
aws sns list-subscriptions-by-topic \
  --topic-arn $(aws sns list-topics --region ap-northeast-1 \
 --query 'Topics[?contains(TopicArn,`security-hub-alerts`)].TopicArn' \
 --output text) \
  --region ap-northeast-1

# Lambda ログ確認 (通知テスト後)
aws logs tail /aws/lambda/security-hub-slack-notifier --follow --region ap-northeast-1

6-6. コンソール確認手順

1. EventBridge コンソール → Rules → security-hub-high-critical-findings → イベントパターン確認
2. EventBridge → Rules → Targets → SNS Topic ARN 確認
3. SNS コンソール → Topics → security-hub-alerts → Subscriptions → Lambda ARN 確認
4. Lambda コンソール → security-hub-slack-notifier → テスト（サンプル Security Hub イベント送信）
5. CloudWatch → Log Groups → /aws/lambda/security-hub-slack-notifier → ログ確認

6-7. 関連記事

• CloudWatch Logs Insights + Metrics Filter 本番運用 — セキュリティイベントと CloudWatch Logs の相関分析
• EKS + ALB + Argo CD 本番運用 — Argo CD で EventBridge / Lambda Terraform を GitOps 管理

7. Findings トリアージ + 自動修復連携 + コスト最適化

7-1. Findings トリアージの5段階フロー

Security Hub に集約された Findings は優先度に応じて5段階でトリアージする。

トリアージの判断基準:

セキュリティ運用の核心は「アラートに溺れない」こと。CRITICAL/HIGH のみ即時対応し、MEDIUM 以下は Suppression Rules と Automation Rules で自動処理することでノイズを制御する。

7-2. Security Hub Automation Rules Terraform 実装

Automation Rules は Security Hub の Findings に対してルールベースで自動アクションを実行する。Workflow Status の変更・Suppression・Notes 追加が可能。

# Automation Rule 1: 既知の pentest ツール由来 Finding を自動 Suppress
resource "aws_securityhub_automation_rule" "suppress_pentest" {
  rule_name  = "suppress-known-pentest-findings"
  rule_order = 1
  rule_status= "ENABLED"
  description= "PenTest カテゴリ Finding を自動 Suppressed に設定"
  is_terminal= false

  criteria {
 type {
comparison = "PREFIX"
value= "PenTest"
 }
 workflow_status {
comparison = "EQUALS"
value= "NEW"
 }
 record_state {
comparison = "EQUALS"
value= "ACTIVE"
 }
  }

  actions {
 type = "FINDING_FIELDS_UPDATE"
 finding_fields_update {
workflow {
  status = "SUPPRESSED"
}
note {
  text = "既知の pentest ツールによる Finding のため自動 Suppress"
  updated_by = "SecurityHub-AutomationRule"
}
 }
  }
}

# Automation Rule 2: CRITICAL Finding を NOTIFIED に自動更新 (Slack 通知と連動)
resource "aws_securityhub_automation_rule" "notify_critical" {
  rule_name = "notify-critical-findings"
  rule_order= 2
  rule_status  = "ENABLED"
  description  = "CRITICAL Finding を自動 NOTIFIED に更新"
  is_terminal  = false

  criteria {
 severity_label {
comparison = "EQUALS"
value= "CRITICAL"
 }
 workflow_status {
comparison = "EQUALS"
value= "NEW"
 }
  }

  actions {
 type = "FINDING_FIELDS_UPDATE"
 finding_fields_update {
workflow {
  status = "NOTIFIED"
}
 }
  }
}

# Automation Rule 3: 開発環境アカウントの MEDIUM 以下を自動 Suppressed
resource "aws_securityhub_automation_rule" "suppress_dev_medium" {
  rule_name = "suppress-dev-account-medium-findings"
  rule_order= 10
  rule_status  = "ENABLED"
  description  = "開発アカウントの MEDIUM/LOW Finding を自動 Suppress"
  is_terminal  = false

  criteria {
 aws_account_id {
comparison = "EQUALS"
value= var.dev_account_id
 }
 severity_label {
comparison = "EQUALS"
value= "MEDIUM"
 }
  }

  actions {
 type = "FINDING_FIELDS_UPDATE"
 finding_fields_update {
workflow {
  status = "SUPPRESSED"
}
 }
  }
}

Automation Rules の CLI 確認:

# Automation Rules 一覧確認
aws securityhub list-automation-rules --region ap-northeast-1

# Automation Rule の詳細確認
aws securityhub batch-get-automation-rules \
  --automation-rules-arns "arn:aws:securityhub:ap-northeast-1:123456789012:automation-rule/RULE_ID" \
  --region ap-northeast-1

7-3. SSM Automation 自動修復連携

Security Hub → EventBridge → SSM Automation のフローで Findings に対する自動修復を実装する。

# SSM Document: S3 バケットのパブリックアクセス自動ブロック
resource "aws_ssm_document" "remediate_s3_public_access" {
  name = "Remediate-S3-PublicAccess"
  document_type = "Automation"
  content = jsonencode({
 schemaVersion = "0.3"
 description= "S3 バケットのパブリックアクセスブロック設定を自動修復"
 parameters = {
BucketName = {
  type  = "String"
  description = "修復対象の S3 バケット名"
}
AutomationAssumeRole = {
  type  = "String"
  description = "Automation 実行ロール ARN"
}
 }
 mainSteps = [{
name= "BlockPublicAccess"
action = "aws:executeAwsApi"
inputs = {
  Service = "s3"
  Api  = "put_public_access_block"
  Bucket  = "{{BucketName}}"
  PublicAccessBlockConfiguration = {
 BlockPublicAcls = true
 IgnorePublicAcls= true
 BlockPublicPolicy  = true
 RestrictPublicBuckets = true
  }
}
 }]
  })
}

# EventBridge Rule: S3 Public Access 関連 Finding を捕捉
resource "aws_cloudwatch_event_rule" "s3_remediation" {
  name  = "security-hub-s3-public-access-remediation"
  description = "S3 パブリックアクセス Finding を SSM で自動修復"

  event_pattern = jsonencode({
 source= ["aws.securityhub"]
 "detail-type" = ["Security Hub Findings - Imported"]
 detail = {
findings = {
  Types = [{ prefix = "Software and Configuration Checks/AWS Security Best Practices/S3" }]
  Severity = { Label = ["CRITICAL", "HIGH"] }
}
 }
  })
}

# EventBridge → SSM Automation ターゲット
resource "aws_cloudwatch_event_target" "ssm_remediation" {
  rule= aws_cloudwatch_event_rule.s3_remediation.name
  target_id = "ssm-s3-remediation"
  arn = "arn:aws:ssm:ap-northeast-1:${data.aws_caller_identity.current.account_id}:automation-definition/Remediate-S3-PublicAccess"
  role_arn  = aws_iam_role.eventbridge_ssm_role.arn

  input_transformer {
 input_paths = {
bucket_name = "$.detail.findings[0].Resources[0].Id"
 }
 input_template = "{\"BucketName\":[\"<bucket_name>\"],\"AutomationAssumeRole\":[\"${aws_iam_role.ssm_automation_role.arn}\"]}"
  }
}

7-4. Findings トリアージ Runbook 5種

実運用で活用する Runbook 5種を一覧で提示する。各 Runbook は「発生 → 判断 → 対応 → 事後」の4ステップで構成。

RB-1 重大脅威対応のコマンド例:

# IAM アクセスキーを即時無効化
FINDING_ACCESS_KEY=$(aws securityhub get-findings \
  --filters '{"SeverityLabel":[{"Value":"CRITICAL","Comparison":"EQUALS"}]}' \
  --query 'Findings[0].Resources[0].Details.AwsIamAccessKey.AccessKeyId' \
  --output text --region ap-northeast-1)

aws iam update-access-key \
  --access-key-id "$FINDING_ACCESS_KEY" \
  --status Inactive

# EC2 インスタンスをセキュリティグループで隔離
aws ec2 modify-instance-attribute \
  --instance-id i-XXXXXXXX \
  --groups sg-QUARANTINE_SG_ID \
  --region ap-northeast-1

# Security Hub Finding を RESOLVED に更新
aws securityhub batch-update-findings \
  --finding-identifiers '[{"Id":"FINDING_ARN","ProductArn":"PRODUCT_ARN"}]' \
  --workflow '{"Status":"RESOLVED"}' \
  --note '{"Text":"RB-1実施: IAMキー無効化+EC2隔離完了","UpdatedBy":"security-team"}' \
  --region ap-northeast-1

7-5. コスト最適化

GuardDuty と Security Hub のコストは Findings 量と分析データ量に比例する。以下の最適化で月額コストを大幅削減できる。

GuardDuty コスト構造と最適化:

コスト試算 (1アカウント / 月額目安):
– 小規模環境 (Flow Logs 10GB/月): $15-30
– 中規模環境 (Flow Logs 100GB/月): $80-150
– マルチアカウント (10 Member × 中規模): $800-1500

Suppression Rules によるノイズ削減:

# GuardDuty Filter で既知の安全な CIDR を除外
resource "aws_guardduty_filter" "suppress_trusted_cidr" {
  name  = "suppress-trusted-monitoring-cidr"
  detector_id = aws_guardduty_detector.main.id
  action= "ARCHIVE"  # Finding を自動アーカイブ
  rank  = 1

  finding_criteria {
 criterion {
field  = "service.action.networkConnectionAction.remoteIpDetails.ipAddressV4"
equals = ["10.0.0.0/8", "172.16.0.0/12"]  # 社内 CIDR
 }
  }
}

Security Hub のコストは Standards の有効化コントロール数に比例する。PCI DSS はカード会員データ非対象環境では無効化を推奨。月次でコスト棚卸 (RB-3) を実施し、不要な Protection Plan と Standards を定期的に見直すことで最適化を維持する。

7-6. クロスリンク

• 観測性 Vol1 (CloudWatch Logs Insights): https://www.watchittrend.com/cloudwatch-logs-insights-metrics-filter-production/ — セキュリティイベント × CloudWatch Logs 相関分析 (GuardDuty Finding の関連ログを Logs Insights で深堀り)
• 観測性 Vol2 (X-Ray + ADOT): https://www.watchittrend.com/xray-adot-distributed-tracing-production/ — 分散トレース × GuardDuty Findings 相関 (不審な API 呼び出しをトレースで追跡)

8. まとめ + セキュリティ 3 部作予告 + 落とし穴 10 選

8-1. まとめ: 今回構築したセキュリティ運用ループ

本記事で GuardDuty + Security Hub を中心とした「脅威検知 → 通知 → 修復 → 棚卸」の運用ループを Terraform IaC として完成させた。

本記事で確立した差別化ポイント (競合10件中0件):
– マルチアカウント Organizations + Delegated Admin Terraform 完全実装
– EventBridge → SNS → Lambda Slack Webhook パイプライン Terraform
– Security Hub Automation Rules + SSM Automation 自動修復ハンズオン
– Findings トリアージ Runbook 5種の体系化

観測性 3 部作 (CloudWatch Logs Insights / X-Ray + ADOT / Application Signals + SLO) との連携で、「ログ × トレース × SLO × セキュリティ」を一元把握する AWS 本番運用の基盤が整った。

8-2. セキュリティ 3 部作ロードマップ + 12 巻 AWS 本番運用シリーズ

8-3. セキュリティ × 観測性 連携まとめ — ログ・トレース・SLO との統合活用

セキュリティ本番運用シリーズの最大の差別化は、観測性 3 部作 との深い連携にある。GuardDuty / Security Hub 単体ではなく、CloudWatch Logs Insights / X-Ray / Application Signals との連携で「セキュリティイベントを可観測性の文脈で追跡」できる点が実運用の核心だ。

実装推奨パターン: GuardDuty Finding → CloudWatch Logs 相関分析

# GuardDuty HIGH/CRITICAL Finding の発生時刻を取得
FINDING_TIME=$(aws securityhub get-findings \
  --filters '{"SeverityLabel":[{"Value":"CRITICAL","Comparison":"EQUALS"}]}' \
  --query 'Findings[0].CreatedAt' --output text --region ap-northeast-1)

# 前後30分の CloudTrail ログを Logs Insights で検索
aws logs start-query \
  --log-group-name "aws-cloudtrail-logs" \
  --start-time $(date -d "${FINDING_TIME} -30 minutes" +%s) \
  --end-time $(date -d "${FINDING_TIME} +30 minutes" +%s) \
  --query-string 'fields @timestamp, userIdentity.arn, eventName, sourceIPAddress
 | filter sourceIPAddress like /suspicious-ip/
 | sort @timestamp desc | limit 50' \
  --region ap-northeast-1

8-4. 落とし穴 10 選 — 実運用で踏みがちな罠

GuardDuty と Security Hub の本番運用で実際に踏まれやすい落とし穴を10件まとめる。

8-4. まとめチートシート

# GuardDuty: 全リージョンの有効化確認
for region in $(aws ec2 describe-regions --query 'Regions[].RegionName' --output text); do
  echo "Region: $region"
  aws guardduty list-detectors --region "$region" 2>/dev/null
done

# Security Hub: 要対応 Finding 数の確認
aws securityhub get-findings \
  --filters '{"SeverityLabel":[{"Value":"HIGH","Comparison":"EQUALS"},{"Value":"CRITICAL","Comparison":"EQUALS"}],"WorkflowStatus":[{"Value":"NEW","Comparison":"EQUALS"}]}' \
  --query 'length(Findings)' \
  --output text --region ap-northeast-1

# Security Hub: Security Score (Standards 達成率) 確認
aws securityhub get-insights \
  --insight-arns "arn:aws:securityhub:::insight/securityhub/default/1" \
  --region ap-northeast-1

# GuardDuty: Sample Findings 生成 (テスト用)
DETECTOR_ID=$(aws guardduty list-detectors --region ap-northeast-1 --query 'DetectorIds[0]' --output text)
aws guardduty create-sample-findings \
  --detector-id "$DETECTOR_ID" \
  --finding-types "UnauthorizedAccess:IAMUser/ConsoleLoginSuccess.B" \
  --region ap-northeast-1

次を読む: セキュリティ Vol2 IAM Identity Center + Permission Sets + ABAC 完全活用編

シリーズ完結: セキュリティ Vol3 AWS Config + Conformance Pack + Auto Remediation を読む