セキュリティ本格運用 Security Hub GuardDuty Audit Manager 統合入門

1. なぜセキュリティ本格運用か — AWS本番運用5軸目 + 全12巻からの架橋

1-1. なぜセキュリティ本格運用が必要か — 3つの現実

IAM・EKS・復旧・AI と積み上げてきた AWS本番運用の4軸は、インフラ設計・観測可能性・可用性・自動化の基盤を整えます。しかしその基盤があっても、セキュリティを体系的に運用していなければ本番環境は「構築は一流、防御はゼロ」という状態になります。クラウド上の本番サービスを継続的に安全に運用するために、3つの現実を直視しましょう。

多くの AWS 利用組織でセキュリティ運用が後回しになる理由は「複雑に見える」からです。しかし Security Hub・GuardDuty・Audit Manager はいずれもマネージドサービスであり、適切に設定すれば運用の大半を自動化できます。複雑に見える部分は「設計のパターン」を把握すれば整理できます。

対象読者と前提知識

本記事は AWS本番環境でのセキュリティ運用を初めて設計するエンジニアを主な対象とします。IAMシリーズで学んだ最小権限設計・STS クロスアカウント、EKSシリーズの IRSA 設計、復旧シリーズの EventBridge 自動化、AIシリーズの Bedrock 設定の知識があると理解が深まりますが、各シリーズ未読の場合も §2 以降の実装は独立して追えるよう設計しています。Security Hub・GuardDuty・Audit Manager の3サービスを初めて触る方でも、§2〜§8 を通じてゼロから本番導入できる構成です。

現実1: 脅威の高度化

クラウド環境を標的にした攻撃は年々増加・高度化しています。S3バケットの誤設定を突いた情報漏洩、IAM認証情報の窃取によるリソース乗っ取り、コンテナワークロードへのクリプトマイニング注入など、攻撃の手口は多様化しています。GuardDuty が検出する脅威カテゴリは IAM / S3 / EC2 / EKS / Runtime の5領域にわたり、機械学習ベースの異常検知が人間の目では捕捉できない攻撃の兆候を浮き彫りにします。単体の IDS ツールではカバーできないクラウドネイティブな脅威に対応するには、AWS の各サービスと深く統合した専用の検出レイヤーが必要です。

【クラウド脅威の3分類と GuardDuty 検出範囲】

  外部攻撃内部脅威設定不備
  ──────────  ──────────  ──────────
  ・認証情報窃取・過剰権限IAMロール  ・パブリックS3バケット
  ・API呼び出し異常 ・想定外リージョン利用・暗号化未設定EBS/RDS
  ・EKS Pod侵害・時間外ルートAPI呼出し・MFAなしコンソールアクセス
  ・ポートスキャン  ・VPC外部への大量転送 ・セキュリティグループ全開放
 └──────────────────────────────────────────────────┘
 GuardDuty ML + 脅威インテリジェンスで統合検出

現実2: コンプライアンス要件の高度化

PCI DSS / SOC 2 / ISO 27001 など、エンタープライズ向けセキュリティ規格ではセキュリティ設定の監査証跡が必須です。「設定は正しかった」と口頭で説明するだけでは監査を通過できず、機械可読な証跡を継続的に収集・保持する仕組みが求められます。Audit Manager はこの証跡収集を自動化し、Security Hub は CIS AWS Foundations Benchmark などの業界標準への適合度をスコアとして継続的に可視化します。各 AWS アカウントの設定状態が Rules として評価され、非準拠リソースは Findings として即時通知されます。証跡の収集・整理・レポート出力まで自動化することで、年に一度の監査対応が大幅に効率化されます。

【コンプライアンス要件と AWS サービスの対応関係】

  PCI DSS  ───→  Security Hub PCI DSS 3.2.1 Standards
  SOC 2 ───→  Audit Manager SOC 2 Framework
  CIS───→  Security Hub CIS AWS Foundations Benchmark v1.4
  NIST  ───→  Audit Manager NIST Cybersecurity Framework
  社内基準  ───→  Security Hub Custom Standards (Terraform 管理)
  ↓
  継続的スコアリング + 証跡の自動収集 → 監査対応コスト削減

現実3: 運用の複雑化

マルチアカウント × マルチリージョン環境では手動チェックは限界に達します。AWS Organizations で管理するアカウント数が増えるほど、各アカウントのセキュリティ設定確認・Findings の収集・対応の優先付けを人手で行うことは現実的ではありません。Security Hub の Cross-Account 集約 / Findings フィルタリング / EventBridge 自動対応が「スケールするセキュリティ運用」の核心になります。1つの管理アカウントに全 Findings を集約し、重要度別に自動トリアージする設計が、大規模 AWS 環境での運用効率の鍵です。

これら3つの現実は、Security Hub / GuardDuty / Audit Manager という3つのマネージドサービスに対応しています。脅威の高度化 → GuardDuty、コンプライアンス要件 → Audit Manager、運用の複雑化 → Security Hub という対応関係を念頭に置くと、§2 以降の設計判断が理解しやすくなります。

【マルチアカウント環境でのセキュリティ課題と解決策】

  手動運用 (限界) Security Hub 集約 (スケール)
  ────────── ──────────────────
  Account-A ─┐Account-A ─┐
  Account-B ─┤→ 担当者が個別巡回 Account-B ─┤→ 管理アカウントで一元集約
  Account-C ─┘属人化・見逃し多発 Account-C ─┘ 自動フィルタ・優先度付け
  Account-D 対応遅延 Account-D  EventBridge → Lambda 自動対応

1-2. IAM/EKS/復旧/AI 4シリーズからセキュリティへの昇格

IAM・EKS・復旧・AIシリーズで積み上げた知識は、セキュリティ運用に直結します。各シリーズで習得したサービスと知識が、セキュリティ本格運用にどう活用されるかを整理します。

各シリーズを読んできた方は「学んだ知識が統合される」感覚を持てるはずです。未読の方も各ポイントは独立して理解できますが、リンク先で全体像を確認することをお勧めします。

• IAMシリーズ (Vol1-4) で学んだ最小権限設計 → Security Hub IAM Standards で違反を自動検出します。
  IAM Vol3 の棚卸自動化で整理した権限設定を Security Hub がリアルタイムで継続監視し、IAM Vol4 の STS クロスアカウント設計と Security Hub Cross-Account 集約を組み合わせると Organizations 全体のセキュリティポスチャが一画面で把握できます。

• EKSシリーズ (Vol1-3) で学んだクラスター設計 → GuardDuty EKS Audit Logs でコンテナワークロードへの脅威を検出します。
  EKS Vol3 で構築した ArgoCD GitOps パイプラインへの不正な変更操作も GuardDuty Runtime Monitoring が捕捉し、IRSA で設計した最小権限設定の逸脱を GuardDuty が即時アラートします。

• 復旧シリーズ (Vol1-4) で学んだ障害対応 → EventBridge 自動対応フローで障害発生前に脅威を未然防止します。
  復旧 Vol3 で設計した Lambda による自動化手順の設計思想が、GuardDuty Findings 対応の自動化に直接応用できます。

• AIシリーズ (Vol1) で学んだ Bedrock Agents → Audit Manager で Bedrock 利用のコンプライアンス証跡を収集します。
  AI Vol1 で構築した Bedrock 本番基盤のセキュリティ担保として、Audit Manager Bedrock Framework が証跡収集を自動化します。

【4シリーズ知識からセキュリティ運用への昇格フロー】

  IAM設計  ──→  最小権限 IaC化 ──→  Security Hub で継続監視
  EKS設計  ──→  IRSA + GitOps ──→  GuardDuty EKS Runtime で脅威検出
  復旧設計  ──→  Lambda 自動化手順 ──→  EventBridge 自動対応フロー
  AI設計──→  Bedrock 基盤設計  ──→  Audit Manager でコンプライアンス証跡
 ↓
 セキュリティ本格運用 5軸完結

AWS本番運用 5軸 比較表

5軸のうちセキュリティだけが「他の4軸すべてを守る横断的な軸」です。IAM・EKS・復旧・AIで構築した本番基盤は、セキュリティ運用なしには「鍵のかかっていない金庫」と同じ状態です。本シリーズで AWS本番運用の5軸を完結させましょう。

本シリーズ (Vol1〜予定) の構成は、Security Hub → GuardDuty → Audit Manager の3サービスを一巡学ぶ Vol1 から始まります。Vol1 の到達点は「マルチアカウント環境での脅威検出・コンプライアンス監視・証跡収集をすべて Terraform IaC で稼働させる」ことです。まず全体像を把握したうえで §2 以降の実装に進みましょう。

1-3. 本記事で達成できること — 5つのゴール

本記事を読了すると、AWS本番環境のセキュリティ運用に関する以下5つのゴールを達成できます。§2〜§8 では各ゴールの設計・実装・Terraform IaC 化を順を追って解説します。

5つのゴールは独立していますが、(a)→(b)→(c) の順に習得すると「検出 → 証跡収集」の流れが自然に身につきます。(d) と (e) は横断的なスキルとして (a)〜(c) の実装と並行して活用できます。

(a) Security Hub の Standards / Findings / Cross-Account 集約を設計できる

CIS / PCI DSS / AWS Foundational Security Best Practices の3標準を有効化し、Organizations 全アカウントへの一括展開と Findings の管理アカウント集約を Terraform で実装できます。スコアの読み方・改善優先度の付け方・Custom Insights の作成まで習得します。スコアが低い原因を Findings のカテゴリ別に分解し、優先度の高い設定修正から着手できるようになります。

Security Hub の全体スコアを 80% 以上に引き上げる実践的な改善ステップも §3 で解説します。スコア改善に直結する Config Rules の設定・修正と、Terraform での自動 remediation の組み合わせが、本番環境での高いセキュリティ水準を維持する鍵となります。

(b) GuardDuty の Detector / Findings 分類 / EventBridge 自動対応を実装できる

GuardDuty の有効化から EKS Audit Logs 保護・S3 Protection・Malware Protection まで全オプションを設定し、Findings を HIGH / MEDIUM / LOW に分類して EventBridge → Lambda による自動隔離・Slack 通知・S3 証跡保存のフローを構築できます。誤検知の Suppression Rules 設計と、脅威レベルに応じた対応フローの分岐も実装します。

GuardDuty Findings の自動対応では「即時通知 → 調査 → 隔離 → 復旧」の4ステップを Lambda で自動化します。EKSシリーズで学んだ IRSA の権限設計と、復旧シリーズで学んだ自動化手順の組み合わせが、ここで結実します。

(c) Audit Manager で Framework / Assessment / Evidence 収集を設定できる

SOC 2 Type 2 または CIS AWS Foundations Benchmark の Framework を選択し、Assessment を作成して Evidence Collector が自動収集する証跡の種類と保持期間を設計できます。レポートエクスポートと監査担当者との共有フロー、証跡の S3 長期保存設定も含めて習得します。

Audit Manager を使うことで、監査前に慌てて証跡を集める「スポット型」から、常時自動収集する「継続型」監査対応へ移行できます。Security Hub の Findings との連携で「設定違反 → 即座に証跡として記録」するフローが実現します。

(d) Cross-Region 集約 / Findings 重複 / コスト爆発等の詰まりポイントを乗り越えられる

本番導入でぶつかりやすい課題を事前に把握できます。Security Hub のマルチリージョン集約で発生する Findings 重複の除外方法、GuardDuty の誤検知をフィルタリングする Suppression Rules の設計、Audit Manager のコスト爆発を防ぐ Assessment スコープ設計について、実測値と対策を示します。月次コストを予測する計算式も §8 で解説します。

(e) Terraform IaC で全設定をコード管理できる

Security Hub / GuardDuty / Audit Manager の全設定を Terraform modules で管理し、Organizations 全アカウントへの一括展開と設定ドリフト検出を実現できます。terraform plan で差分を把握し terraform apply で即時修復できる状態が、セキュリティ運用を「コード化」する到達点です。GitHub Actions による CI/CD パイプラインとの統合例も §7 で紹介します。

IAMシリーズ Vol1 から積み上げてきた「Terraform で本番 AWS を管理する」という一貫したコンセプトが、セキュリティ運用でも完結します。セキュリティ設定を Git で管理することで、設定変更のレビュー・承認フローが確立し、コンプライアンス審査での「変更管理証跡」としても機能します。

2. セキュリティ運用3本柱整理 — 脅威検出 / コンプライアンス / ログ集約 + AWSサービスマップ

AWS 本番環境のセキュリティ運用は「脅威検出 / コンプライアンス / ログ集約」の3本柱で体系化できます。各柱は独立しているのではなく、ログ集約が脅威検出とコンプライアンスの基盤を支えるという関係にあります。この章では3本柱の定義・AWSサービスとの対応関係・Terraform による一括有効化・マルチアカウント統合設計を整理します。

2-1. セキュリティ運用3本柱の定義と役割

【セキュリティ運用3本柱 関係図】

  ┌────────────────────────────────────────────────────┐
  │  柱1: 脅威検出  │
  │  GuardDuty (ML検知) → Security Hub (Findings集約)  │
  │  → EventBridge → Lambda (自動対応)  │
  └────────────────────────────────────────────────────┘
  ┌────────────────────────────────────────────────────┐
  │  柱2: コンプライアンス │
  │  AWS Config (設定変更追跡) → Security Hub Standards │
  │  → Audit Manager (Evidence収集) → 監査レポート生成  │
  └────────────────────────────────────────────────────┘
  ┌────────────────────────────────────────────────────┐
  │  柱3: ログ集約 (基盤層)│
  │  CloudTrail (APIコール) + Config (リソース変更)│
  │  + CloudWatch Logs (アプリ/インフラ) → S3 (長期保管) │
  └────────────────────────────────────────────────────┘

3本柱の中で「ログ集約」が最も先に有効化すべき基盤です。CloudTrail と Config なしでは、脅威検出の証跡もコンプライアンスの証拠も存在しません。新規 AWS アカウントで最初にやるべきことは CloudTrail 全リージョン有効化です。

各柱のコスト感も把握しておきます。

GuardDuty は EKS Protection (Kubernetes 監査ログ解析) と Malware Protection (EBS スキャン) を有効にすると費用が増加します。§4 でコスト最適化の具体的な設定を解説します。

AWS サービスマップ — 各サービスが担う柱と主な機能

IAM Vol1 (最小権限設計) で設計したポリシーは、Security Hub の IAM.x Standards によって継続的に評価されます。「設計の正しさを自動で証明し続ける」仕組みが3本柱の真の価値です。

2-2. Terraform によるセキュリティ基盤一括有効化

3本柱を Terraform で一括有効化します。手動で有効化すると「有効化した/していない」が環境ごとに異なるドリフトが発生するため、IaC 管理が必須です。

# 柱3: CloudTrail — 全リージョン対応証跡
resource "aws_cloudtrail" "main" {
  name  = "production-trail"
  s3_bucket_name = aws_s3_bucket.cloudtrail.id
  is_multi_region_trail= true
  enable_log_file_validation = true
  include_global_service_events = true

  event_selector {
 read_write_type  = "All"
 include_management_events = true
  }
}

# 柱3: AWS Config — 全リソース変更記録
resource "aws_config_configuration_recorder" "main" {
  name  = "production-recorder"
  role_arn = aws_iam_role.config.arn

  recording_group {
 all_supported  = true
 include_global_resource_types = true
  }
}

resource "aws_config_delivery_channel" "main" {
  name  = "production-delivery"
  s3_bucket_name = aws_s3_bucket.config.id
  depends_on  = [aws_config_configuration_recorder.main]
}

resource "aws_config_configuration_recorder_status" "main" {
  name = aws_config_configuration_recorder.main.name
  is_enabled = true
  depends_on = [aws_config_delivery_channel.main]
}

# 柱1: GuardDuty — 脅威検出有効化
resource "aws_guardduty_detector" "main" {
  enable  = true
  finding_publishing_frequency = "FIFTEEN_MINUTES"

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

# 柱1+2: Security Hub — Findings集約 + Standards有効化
resource "aws_securityhub_account" "main" {}

resource "aws_securityhub_standards_subscription" "aws_best_practices" {
  depends_on = [aws_securityhub_account.main]
  standards_arn = "arn:aws:securityhub:ap-northeast-1::standards/aws-foundational-security-best-practices/v/1.0.0"
}

resource "aws_securityhub_standards_subscription" "cis" {
  depends_on = [aws_securityhub_account.main]
  standards_arn = "arn:aws:securityhub:ap-northeast-1::standards/cis-aws-foundations-benchmark/v/3.0.0"
}

Terraform apply 後、Security Hub コンソールで「セキュリティスコア」が表示されます。初回は 30〜50 点台が一般的です。§3 で Standards の Controls を個別に確認・修正し、スコアを 90 点以上に引き上げる方法を解説します。

2-3. マルチアカウント設計での3本柱統合

IAM Vol2 (マルチアカウント設計) で構成した Organizations 構造の上に、3本柱を組織全体に展開します。

【マルチアカウント 3本柱統合アーキテクチャ】

  Organizations Management Account
  ├── Security Account (専用)
  │  ├── Security Hub (管理者) ← 全メンバー Findings 集約
  │  ├── GuardDuty (管理者) ← 全メンバー Findings 集約
  │  └── CloudTrail (組織証跡) ← 全メンバー API ログ集約
  │
  ├── Log Archive Account (専用)
  │  └── S3 (CloudTrail + Config + CloudWatch Logs)
  │
  ├── Dev Account
  │  ├── Security Hub (メンバー)
  │  └── GuardDuty (メンバー)
  │
  └── Production Account
  ├── Security Hub (メンバー)
  └── GuardDuty (メンバー)

3本柱を有効化した後の優先アクション: §3 (Security Hub 設計) で Standards の Controls を確認し、高重大度の非準拠項目から順に修正します。§4 (GuardDuty 実践) では Findings の分類・優先度付け・自動対応フローを構築します。

3本柱の有効化ステータスをコマンドで確認する方法:

# GuardDuty の有効化確認
aws guardduty list-detectors --query "DetectorIds" --output table

# Security Hub の有効化確認
aws securityhub describe-hub --query "HubArn" --output text

# CloudTrail の証跡一覧確認
aws cloudtrail describe-trails --include-shadow-trails false--query "trailList[*].{Name:Name,Region:HomeRegion,MultiRegion:IsMultiRegionTrail}"--output table

# AWS Config の記録ステータス確認
aws configservice describe-configuration-recorder-status--query "ConfigurationRecordersStatus[*].{Name:name,Recording:recording}"--output table

このコマンド群を定期的に実行するか、AWS Config の cloudtrail-enabled / guardduty-enabled-centralized ルールで自動評価することで、3本柱の有効化漏れを検出できます。

3. Security Hub設計 (山場1) — Standards / Findings / Custom Insights / Cross-Account集約

3-1. Standards と Findings の設計

Security Hub はStandards（コンプライアンス評価）とFindings（検出結果）の2層構造で動作します。Standards を有効化すると Security Hub が自動で AWS リソースをスキャンし、違反を Findings として記録します。

利用可能な Standards

FSBP と CIS を両方有効化することで、互いの死角を補完できます。FSBP は AWS 固有のリスク（S3 パブリックアクセス / CloudTrail 無効化など）を網羅し、CIS はアカウント全体のベースライン強化を担います。

Findings の重大度と対応方針

CRITICAL の Findings は人手を介さず自動修復することが基本方針です（§3-2 で詳述）。HIGH は自動通知で担当者にエスカレーションし、人間が対応内容を判断します。

Terraform で Security Hub 有効化

resource "aws_securityhub_account" "main" {
  enable_default_standards = false
  auto_enable_controls  = true
}

resource "aws_securityhub_standards_subscription" "fsbp" {
  depends_on = [aws_securityhub_account.main]
  standards_arn = "arn:aws:securityhub:ap-northeast-1::standards/aws-foundational-security-best-practices/v/1.0.0"
}

resource "aws_securityhub_standards_subscription" "cis" {
  depends_on = [aws_securityhub_account.main]
  standards_arn = "arn:aws:securityhub:ap-northeast-1::standards/cis-aws-foundations-benchmark/v/1.4.0"
}

enable_default_standards = false を設定してから個別に Standards を有効化することで、不要な Standards を誤って有効にすることを防ぎます。

Findings の抑制設定 (False Positive 対応)

意図的な設定（例: 特定の S3 バケットのパブリックアクセス許可）が Findings として検出される場合は、Suppression Rule で対象を除外します。

resource "aws_securityhub_automation_rule" "suppress_s3_public_access" {
  rule_name  = "suppress-s3-cdn-public-bucket"
  rule_order = 1
  rule_status= "ENABLED"
  description= "CDN配信用バケットのS3パブリックアクセスFindingsを抑制"

  criteria {
 product_name {
comparison = "EQUALS"
value= "Security Hub"
 }
 resource_id {
comparison = "CONTAINS"
value= "my-company-cdn-"
 }
 compliance_status {
comparison = "EQUALS"
value= "FAILED"
 }
  }

  actions {
 type= "FINDING_FIELDS_UPDATE"
 finding_fields_update {
workflow {
  status = "SUPPRESSED"
}
note {
  text = "CDN用バケット - パブリックアクセスは設計上意図的"
  updated_by = "terraform-automation-rule"
}
 }
  }
}

抑制ルールは Automation Rule として管理し、SUPPRESSED にした理由（note.text）を必ず記録します。

3-2. Cross-Account 集約と Custom Insights

Organizations を使った Cross-Account 集約では、セキュリティ専用アカウント（Security Account）を Organizations の委任管理者に指定し、全メンバーアカウントの Findings を一元管理します。

Cross-Account 集約 — Organizations 統合

# 管理アカウント: Security Hub 管理者をセキュリティアカウントに委任
resource "aws_securityhub_organization_admin_account" "delegated" {
  admin_account_id = var.security_account_id
}

# セキュリティアカウント: 全メンバー自動追加 + Standards 自動有効化
resource "aws_securityhub_organization_configuration" "main" {
  auto_enable  = true
  auto_enable_standards = "DEFAULT"
}

auto_enable = true により、Organizations に新規アカウントが追加されると自動的に Security Hub が有効化され、Findings の集約対象になります。手動でメンバーを追加する運用は新規アカウントの漏れが発生するため避けます。

Custom Insight — CRITICAL Findings を Account 別に集計

Custom Insight を使うと、特定の条件に一致する Findings をグループ化して傾向分析できます。以下はアカウント別 CRITICAL Findings 数を集計する例です。

resource "aws_securityhub_insight" "critical_by_account" {
  name = "Critical-Findings-by-Account"

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

  group_by_attribute = "AwsAccountId"
}

このInsight をダッシュボードで定期的に確認することで、特定のアカウントでセキュリティ問題が集中していないかを早期に把握できます。

mermaid01: Security Hub Findings 自動修復シーケンス

sequenceDiagram
 participant SH as Security Hub
 participant EB as EventBridge
 participant L as Lambda (自動修復)
 participant SNS as SNS
 participant Slack as Slack / メール

 SH->>EB: Finding 発生 (CRITICAL / HIGH)
 EB->>L: Rule Match → 自動起動
 L->>L: リソース特定 & 修復実行
 L->>SNS: 修復結果通知
 SNS->>Slack: アラート配信
 L->>SH: Workflow Status: RESOLVED

CRITICAL Finding が発生すると EventBridge Rule が即時 Lambda を起動します。Lambda は Finding に含まれるリソース情報（S3 バケット / IAM ユーザー / セキュリティグループなど）を解析し、ポリシーの無効化・アクセスブロック・パスワードリセットなどの修復を自動実行します。

EventBridge Rule — CRITICAL Findings をトリガー

resource "aws_cloudwatch_event_rule" "securityhub_critical" {
  name  = "securityhub-critical-findings"
  description = "Security Hub CRITICAL findings auto-remediation"

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

resource "aws_cloudwatch_event_target" "securityhub_lambda" {
  rule= aws_cloudwatch_event_rule.securityhub_critical.name
  target_id = "SecurityHubCriticalToLambda"
  arn = aws_lambda_function.security_remediation.arn
}

3-3. IAM Findings 自動修復 Lambda

Security Hub の IAM 関連 Findings（MFA 未設定 / 過剰な管理者権限 / 未使用認証情報など）を自動修復する Lambda の実装例です。

import json
import boto3

iam = boto3.client('iam')
securityhub = boto3.client('securityhub')

def lambda_handler(event, context):
 remediated = 0
 for finding in event['detail']['findings']:
  control_id = finding.get('ProductFields', {}).get('ControlId', '')
  resources  = finding.get('Resources', [])

  # IAM.3: コンソールパスワードありでMFA未設定ユーザーへの対応
  if control_id == 'IAM.3':
for resource in resources:
 username = resource['Id'].split('/')[-1]
 try:
  iam.update_login_profile(
UserName=username,
PasswordResetRequired=True
  )
  remediated += 1
 except iam.exceptions.NoSuchEntityException:
  pass  # コンソールアクセスなし = 対応不要

  # IAM.22: 90日以上未使用のアクセスキー無効化
  elif control_id == 'IAM.22':
for resource in resources:
 parts = resource['Id'].split('/')
 if len(parts) >= 3:
  username, key_id = parts[-2], parts[-1]
  iam.update_access_key(
UserName=username,
AccessKeyId=key_id,
Status='Inactive'
  )
  remediated += 1

  # Workflow を NOTIFIED に更新 (処理中を示す)
  securityhub.batch_update_findings(
FindingIdentifiers=[{
 'Id': finding['Id'],
 'ProductArn': finding['ProductArn']
}],
Workflow={'Status': 'NOTIFIED'}
  )

 return {'statusCode': 200, 'remediated': remediated}

IAM.3 は MFA 未設定のコンソールユーザーに対してパスワードリセットを強制し、次回ログイン時に MFA 設定を促します。IAM.22 は 90 日以上未使用のアクセスキーを自動無効化します。

Lambda の動作確認は以下の AWS CLI コマンドで CRITICAL Findings の一覧を取得してから行います。

# CRITICAL かつ NEW 状態の Findings を取得
aws securityhub get-findings--filters '{
 "SeverityLabel": [{"Value": "CRITICAL","Comparison": "EQUALS"}],
 "WorkflowStatus": [{"Value": "NEW","Comparison": "EQUALS"}]
  }'--region ap-northeast-1--query 'Findings[].{Id:Id,Title:Title,Resource:Resources[0].Id}'--output table

# Lambda を手動テスト (テスト用Finding IDで実行)
aws lambda invoke--function-name security-remediation--payload file://test_finding_event.json--region ap-northeast-1/tmp/lambda_response.json && cat /tmp/lambda_response.json

本番環境に適用する前に開発環境で同一のテスト Finding を使って Lambda の修復ロジックを検証してください。

IAM Vol3 架橋 — 権限棚卸との連携

IAM Vol3 (権限棚卸自動化) で実装した Access Analyzer による権限棚卸と Security Hub の IAM Findings を組み合わせることで、不要な権限を継続的に検出・削除するサイクルが完成します。Access Analyzer の未使用アクセス Findings を Security Hub にインポートし、自動修復パイプラインで処理することで、権限棚卸を完全自動化できます。

IAM Vol1 (最小権限設計) の評価ロジックを IAM Vol2 (マルチアカウント設計) の Organizations 構造に適用した上で Security Hub Cross-Account 集約を行うと、全アカウントの準拠状況を単一の管理コンソールで一元監視できます。

4. GuardDuty実践 (山場2) — Detector / Findings分類 / EventBridge自動対応 / Cost最適化

GuardDuty は CloudTrail・VPC Flow Logs・DNS Logs・EKS Audit Logs を統合分析し、脅威を自動検出するマネージド型セキュリティ監視サービスだ。Detector を有効化するだけで機械学習ベースの異常検知が即時起動し、Findings として結果を提供する。本セクションでは Detector 設計から Findings 分類、EventBridge を使った自動対応パイプライン、EKS Audit Logs 統合、そしてコスト最適化まで実践的に解説する。

4-1. GuardDuty Detector と Findings 分類

GuardDuty の起点は Detector — リージョンごとに有効化するリソースだ。Detector を有効化すると、GuardDuty は CloudTrail の API コール、VPC Flow Logs のネットワーク通信、DNS Logs の名前解決を連続的に分析し始める。加えて、S3 データイベント、EKS Audit Logs、EC2 の Malware Protection (EBS ボリュームスキャン) といった追加 DataSource を有効化することで、検出範囲を大幅に広げられる。

Findings 重大度 (Severity) 分類:

重大度は GuardDuty が自動的に算出する。スコアは Finding タイプ・通信先の脅威インテリジェンス評価・過去の挙動パターンを総合して決定される。HIGH は人手を待たず自動対応するのが原則だ。

主要 Finding タイプ:

Finding タイプは サービス:リソース/攻撃手法 の形式で命名される。タイプを見れば対象サービスと攻撃手法が即座に把握できる設計だ。

Terraform で Detector を有効化する:

resource "aws_guardduty_detector" "main" {
  enable  = true
  finding_publishing_frequency = "FIFTEEN_MINUTES"

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

finding_publishing_frequency は FIFTEEN_MINUTES・ONE_HOUR・SIX_HOURS から選択できる。本番環境では FIFTEEN_MINUTES を推奨する — 検出から対応開始までのラグを最小化するためだ。SIX_HOURS 設定は初動遅延を招き、攻撃者に横展開の時間を与えることになる。

Detector はリージョンごとに個別に有効化する必要がある。Organizations 統合を使えば管理アカウントから全メンバーアカウント・全リージョンへ一括展開できる。マルチリージョン運用では必ずこの Organizations 統合で漏れなく有効化すること。

Finding は 90 日間 GuardDuty コンソールに保持される。長期保管が必要な場合は EventBridge 経由で S3 または Security Hub へエクスポートする設計を検討する。Security Hub との統合を有効化すると、GuardDuty の Findings が自動的に Security Hub に集約され、§3 で構築した Cross-Account 集約ダッシュボードに一元表示できる。

4-2. EventBridge を使った自動対応パイプライン

GuardDuty が HIGH severity の Finding を発行した時点で、人手の確認を待たずに自動対応を起動するパイプラインを構築する。アーキテクチャは GuardDuty → EventBridge Rule → Lambda → (EC2 隔離 + SNS 通知) の 4 段構成だ。

復旧・運用編 Vol3 (障害対応自動化)で構築した EventBridge ベースの自動化フローを、セキュリティ脅威検出領域にそのまま拡張する形だ。障害復旧の自動化で蓄積した EventBridge + Lambda のパターンを流用できるため、実装コストは低く抑えられる。脅威を検出した瞬間に対応フローを起動できる点が最大のメリットだ。

EventBridge Rule — HIGH severity Findings をフィルタリング:

resource "aws_cloudwatch_event_rule" "guardduty_high" {
  name  = "guardduty-high-severity"
  description = "GuardDuty HIGH severity findings auto-response trigger"

  event_pattern = jsonencode({
 source= ["aws.guardduty"]
 detail-type = ["GuardDuty Finding"]
 detail = {
severity = [{ numeric = [">=", 7.0] }]
 }
  })
}

resource "aws_cloudwatch_event_target" "guardduty_lambda" {
  rule= aws_cloudwatch_event_rule.guardduty_high.name
  target_id = "GuardDutyHighToLambda"
  arn = aws_lambda_function.guardduty_response.arn
}

resource "aws_lambda_permission" "allow_eventbridge" {
  statement_id  = "AllowExecutionFromEventBridge"
  action  = "lambda:InvokeFunction"
  function_name = aws_lambda_function.guardduty_response.function_name
  principal  = "events.amazonaws.com"
  source_arn = aws_cloudwatch_event_rule.guardduty_high.arn
}

event_pattern の severity フィールドに numeric フィルターを設定することで、HIGH (7.0 以上) のみを Lambda に転送する。MEDIUM 以下は別ルールで SNS に直送し、担当者へのメール通知に留める設計が実践的だ。EventBridge はリージョンごとに GuardDuty Detector と同じリージョンのイベントを受け取るため、マルチリージョン構成ではリージョンごとにルールを設定する必要がある。

Lambda 自動対応関数 (Python):

import json
import boto3

ec2 = boto3.client('ec2')
sns = boto3.client('sns')
QUARANTINE_SG = 'sg-quarantine-id'
ALERT_TOPIC = 'arn:aws:sns:ap-northeast-1:123456789012:security-alert'

def lambda_handler(event, context):
 detail = event['detail']
 finding_type = detail['type']
 severity = detail['severity']
 resource = detail.get('resource', {})

 if 'EC2' in finding_type and severity >= 7.0:
  instance_id = resource.get('instanceDetails', {}).get('instanceId')
  if instance_id:
# 隔離セキュリティグループへ変更 (外部通信を完全遮断)
ec2.modify_instance_attribute(
 InstanceId=instance_id,
 Groups=[QUARANTINE_SG]
)
sns.publish(
 TopicArn=ALERT_TOPIC,
 Message=(
  f'EC2 {instance_id} を隔離しました\n'
  f'検出タイプ: {finding_type}\n'
  f'重大度: {severity}'
 ),
 Subject='GuardDuty 高危険度検出 — 自動隔離実施'
)

 elif 'S3' in finding_type and 'PublicAccess' in finding_type and severity >= 7.0:
  bucket_name = resource.get('s3BucketDetails', [{}])[0].get('name')
  if bucket_name:
s3control = boto3.client('s3control')
account_id = boto3.client('sts').get_caller_identity()['Account']
s3control.put_public_access_block(
 AccountId=account_id,
 PublicAccessBlockConfiguration={
  'BlockPublicAcls': True,
  'IgnorePublicAcls': True,
  'BlockPublicPolicy': True,
  'RestrictPublicBuckets': True,
 },
 Bucket=bucket_name
)
sns.publish(
 TopicArn=ALERT_TOPIC,
 Message=(
  f'S3 バケット {bucket_name} の公開アクセスを遮断しました\n'
  f'検出タイプ: {finding_type}'
 ),
 Subject='GuardDuty 高危険度検出 — S3 公開アクセス自動遮断'
)

 return {'statusCode': 200, 'body': json.dumps('Response completed')}

この Lambda は Finding タイプに応じて対応ロジックを分岐させる。EC2 関連の HIGH Finding を受信した際は対象インスタンスのセキュリティグループを隔離用 SG に差し替え、S3 公開化 Finding に対しては即時プライベート化を実行する。隔離 SG はインバウンド・アウトバウンドともに全遮断設定にしておくことで、攻撃者の横展開を封じながらフォレンジック調査用にインスタンスを保全できる。

Lambda の IAM 権限設計:

resource "aws_iam_role_policy" "lambda_guardduty_response" {
  name = "lambda-guardduty-response-policy"
  role = aws_iam_role.lambda_guardduty_response.id

  policy = jsonencode({
 Version = "2012-10-17"
 Statement = [
{
  Effect= "Allow"
  Action= ["ec2:ModifyInstanceAttribute", "ec2:DescribeInstances"]
  Resource = "*"
  Condition = {
 StringEquals = {
"ec2:ResourceTag/Environment" = "production"
 }
  }
},
{
  Effect= "Allow"
  Action= ["sns:Publish"]
  Resource = aws_sns_topic.security_alert.arn
},
{
  Effect= "Allow"
  Action= ["s3:PutBucketPublicAccessBlock"]
  Resource = "arn:aws:s3:::*"
},
{
  Effect= "Allow"
  Action= ["sts:GetCallerIdentity"]
  Resource = "*"
}
 ]
  })
}

ec2:ModifyInstanceAttribute に Condition で Environment=production タグを持つインスタンスのみに適用する制約を加えている。開発環境のインスタンスを誤って隔離するリスクを排除できる。Lambda の自動対応は強力な権限を行使するため、最小権限原則の徹底が特に重要だ。

MEDIUM severity の Finding に対しては SNS のみを使った通知ルールを別途設定し、担当者が内容を確認した上で手動対応を実施する。自動対応の範囲を HIGH に限定することで、誤検知による本番環境への影響を最小化できる。

4-3. EKS Audit Logs 統合と Cost最適化

EKS Audit Logs による Kubernetes 脅威検出

GuardDuty の EKS Audit Logs 統合を有効化すると、Kubernetes API サーバーへの不審な操作を GuardDuty が直接分析する。CloudWatch Logs への転送は不要で、GuardDuty が EKS control plane のログを直接取得する仕組みだ。

EKS Vol1 (Cluster設計/IRSA/ALB)で設計した EKS クラスターに GuardDuty EKS Audit Logs を有効化することで、Kubernetes API サーバーへの不審な操作をリアルタイム検出できる。IRSA で適切に権限分離した EKS クラスターでも、kubectl exec による Pod 内への不審な侵入や、特権コンテナの無許可起動は GuardDuty が検出する。

GuardDuty が EKS Audit Logs から検出できる主要な脅威パターン:

これらの Finding に対しても EventBridge Rule を設定し、Kubernetes 固有の対応ロジック (Pod 強制終了・Namespace への NetworkPolicy 追加) を Lambda で自動化することを推奨する。

resource "aws_cloudwatch_event_rule" "guardduty_kubernetes_high" {
  name  = "guardduty-kubernetes-high"
  description = "GuardDuty Kubernetes HIGH severity findings"

  event_pattern = jsonencode({
 source= ["aws.guardduty"]
 detail-type = ["GuardDuty Finding"]
 detail = {
type  = [{ prefix = "Kubernetes:" }]
severity = [{ numeric = [">=", 7.0] }]
 }
  })
}

Cost最適化 3 原則

GuardDuty の料金は分析データ量に比例するため、未チューニングのままでは月次コストが想定を超えることがある。以下の 3 原則でコストを適切に管理する。

原則1 — Suppression Rule による低価値 Finding の除外:

高頻度で発生するが実害のない Finding タイプ (特定の監視ツールが生成する低重大度のネットワーク通信など) は Suppression Rule で除外する。Suppression Rule は Finding タイプ・リソース ARN・タグなどの条件で設定できる。

resource "aws_guardduty_filter" "suppress_monitoring_tools" {
  name  = "suppress-monitoring-tools-low-severity"
  detector_id = aws_guardduty_detector.main.id
  action= "ARCHIVE"
  rank  = 1

  finding_criteria {
 criterion {
field  = "severity"
less_than_or_equal = "3.9"
 }
 criterion {
field  = "resource.instanceDetails.tags.value"
equals = ["monitoring-tool"]
 }
  }
}

Suppression Rule でアーカイブされた Finding は GuardDuty の料金計算対象から除外されない点に注意が必要だ。コスト削減効果が大きいのは不要な DataSource そのものを無効化する次の原則だ。

原則2 — 不要 DataSource の無効化:

S3 バケット全体を分析対象にすると、アクセス頻度の高いバケットほどコストが増大する。機密データを保管していないバケットや、既に別の手段でアクセス制御が完結しているバケットは、GuardDuty の S3 分析対象から除外することを検討する。DataSource の無効化は Terraform の datasources ブロックで enable = false を設定するだけで反映できる。

原則3 — 月次コスト推定の定期確認:

GuardDuty コンソールの「使用状況」ページでは、現在の分析量と月次推定コストをリアルタイムに確認できる。新しい DataSource を有効化する前に必ずこの画面で増加コストを確認してから有効化する。aws guardduty get-usage-statistics CLI コマンドで DataSource 別のコスト内訳を取得し、コスト最大の DataSource を特定した上で Suppression Rule や DataSource 除外の対象を絞り込む運用が効果的だ。

5. Audit Manager実践 — Framework / Assessment / Evidence / Custom Control

5-1. Framework と Assessment の設計

AWS Audit Manager は、コンプライアンス要件への適合状況を継続的に評価し、監査証跡を自動収集するサービスだ。利用するには「Framework (評価基準)」を選び、「Assessment (評価実施)」を作成する。

AWS 提供 Framework 一覧

まず「AWS Core」で AWS 環境全体の基礎的な評価を行い、業種固有の規制対応が必要な場合に PCI DSS / SOC 2 / ISO 27001 を追加する順番が実践的だ。

Assessment 作成の手順

1. AWS Config を有効化する: Audit Manager の Automated evidence は AWS Config ルールに依存するため、Config を先に有効化しておく
2. Audit Manager を有効化する: AWS コンソールの Audit Manager → 設定画面から有効化。S3 バケット (レポート保存先) と KMS キー (暗号化) を指定する
3. Framework を選択する: 既成 Framework (PCI DSS 等) または Custom Framework を指定する
4. Assessment を作成する: 評価対象 AWS アカウント・サービス・担当 IAM ロールを設定して Assessment を開始する
5. Evidence の収集状況を確認する: Assessment ダッシュボードで Control ごとの準拠/非準拠状況を確認し、非準拠項目に対処する

Assessment IAM ロールの設定

Audit Manager が AWS リソースを評価するには専用の IAM ロールが必要だ。

resource "aws_iam_role" "audit_manager" {
  name = "AuditManagerRole"

  assume_role_policy = jsonencode({
 Version = "2012-10-17"
 Statement = [{
Effect = "Allow"
Principal = { Service = "auditmanager.amazonaws.com" }
Action = "sts:AssumeRole"
 }]
  })
}

resource "aws_iam_role_policy_attachment" "audit_manager_admin" {
  role = aws_iam_role.audit_manager.name
  policy_arn = "arn:aws:iam::aws:policy/AWSAuditManagerAdministratorAccess"
}

resource "aws_iam_role_policy" "audit_manager_s3" {
  name = "AuditManagerS3Access"
  role = aws_iam_role.audit_manager.id

  policy = jsonencode({
 Version = "2012-10-17"
 Statement = [{
Effect= "Allow"
Action= ["s3:PutObject", "s3:GetObject", "s3:ListBucket"]
Resource = [
  aws_s3_bucket.audit.arn,
  "${aws_s3_bucket.audit.arn}/*"
]
 }]
  })
}

Terraform による Assessment 作成

resource "aws_auditmanager_framework" "custom" {
  name = "CustomSecurityFramework"

  control_sets {
 name = "IAMControls"
 controls {
id = aws_auditmanager_control.iam_mfa.id
 }
  }

  control_sets {
 name = "S3Controls"
 controls {
id = aws_auditmanager_control.s3_encryption.id
 }
  }
}

resource "aws_auditmanager_assessment" "pci_dss" {
  name= "PCI-DSS-Assessment-2026"
  framework_id = data.aws_auditmanager_framework.pci_dss.id

  assessment_reports_destination {
 destination= "s3://${aws_s3_bucket.audit.bucket}/reports/"
 destination_type = "S3"
  }

  scope {
 aws_accounts {
id = data.aws_caller_identity.current.account_id
 }
 aws_services {
service_name = "S3"
 }
 aws_services {
service_name = "IAM"
 }
  }

  roles {
 role_arn  = aws_iam_role.audit_manager.arn
 role_type = "PROCESS_OWNER"
  }
}

scope.aws_services で評価対象サービスを絞ることが重要だ。全サービスを対象にすると Evidence 収集コストと評価量が急増するため、最初は IAM / S3 / EC2 など重要度の高いサービスに限定して始める。

5-2. Evidence 収集と Custom Control

Evidence の3タイプ

Audit Manager が収集する Evidence は3種類ある。

• Automated evidence: AWS Config ルール評価結果を自動収集。Config ルールの準拠/非準拠が即座に証跡として記録される
• User activity logs: CloudTrail の操作ログ。「誰が何をいつ操作したか」を証跡として記録する
• Manual evidence: 手動でアップロードするファイル・スクリーンショット。AWS 外部のプロセスや物理的な証跡に使う

Custom Control の Terraform 実装

resource "aws_auditmanager_control" "iam_mfa" {
  name = "MFA-Enabled-for-All-IAM-Users"

  control_mapping_sources {
 source_name = "IAM-MFA-Check"
 source_set_up_option = "AWS_Managed"
 source_type = "AWS_Config"
 source_keyword {
keyword_input_type = "SELECT_FROM_LIST"
keyword_value= "IAM_USER_MFA_ENABLED"
 }
  }

  testing_information = "全 IAM ユーザーの MFA 有効化を AWS Config ルールで継続確認する"
  action_plan_title= "MFA が無効な IAM ユーザーに対して即時 MFA を有効化する"
  action_plan_instructions = "1. IAM コンソールで対象ユーザーを確認 2. MFA デバイスを登録 3. 30日以内に再評価を実施"
}

resource "aws_auditmanager_control" "s3_encryption" {
  name = "S3-Server-Side-Encryption-Enabled"

  control_mapping_sources {
 source_name = "S3-Encryption-Check"
 source_set_up_option = "AWS_Managed"
 source_type = "AWS_Config"
 source_keyword {
keyword_input_type = "SELECT_FROM_LIST"
keyword_value= "S3_BUCKET_SERVER_SIDE_ENCRYPTION_ENABLED"
 }
  }

  testing_information = "全 S3 バケットのサーバーサイド暗号化を確認する"
  action_plan_title= "暗号化が未設定の S3 バケットに SSE-S3 または SSE-KMS を設定する"
}

Evidence 収集フロー (Mermaid02)

flowchart LR
 Config[AWS Config
ルール評価] -->|Automated Evidence| AM[Audit Manager
Evidence Repository]
 CT[CloudTrail
操作ログ] -->|User Activity Logs| AM
 Manual[手動エビデンス
スクリーンショット等] -->|Upload| AM
 AM -->|レポート生成| S3[S3 Bucket
Assessment Reports]
 S3 -->|定期送付| Auditor[監査人
レビュー]

Assessment Report の生成と管理

Assessment が完了したら、AWS コンソールから PDF または CSV 形式のレポートを生成できる。レポートは指定 S3 バケットに保存され、監査人に共有する。

# Assessment Report 生成 (AWS CLI)
# aws auditmanager create-assessment-report #--name "PCI-DSS-Q1-2026" #--description "2026年Q1 PCI DSS評価レポート" #--assessment-id <assessment-id>

# S3 バケット (レポート保存先) の設定
resource "aws_s3_bucket" "audit" {
  bucket = "audit-manager-reports-${data.aws_caller_identity.current.account_id}"
}

resource "aws_s3_bucket_versioning" "audit" {
  bucket = aws_s3_bucket.audit.id
  versioning_configuration {
 status = "Enabled"
  }
}

resource "aws_s3_bucket_server_side_encryption_configuration" "audit" {
  bucket = aws_s3_bucket.audit.id
  rule {
 apply_server_side_encryption_by_default {
sse_algorithm  = "aws:kms"
kms_master_key_id = aws_kms_key.audit.arn
 }
  }
}

レポート S3 バケットには厳格なアクセス制御を設定すること。監査レポートは機密情報を含むため、バケットポリシーで監査担当者の IAM ロールのみにアクセスを制限し、パブリックアクセスブロックを有効化する。

AIシリーズ Vol1 との架橋

AIシリーズ Vol1 (Bedrock Agents) で構築した Bedrock エージェントのセキュリティ設定は、Audit Manager の Custom Framework に Control として追加できる。Bedrock Guardrails の設定状況を AWS Config カスタムルールで評価し、Evidence として自動収集することで、AI サービスのコンプライアンス証跡を継続的に管理できる。

Audit Manager 公式ドキュメント

6. 詰まりポイント7選 図解

Security Hub / GuardDuty / Audit Manager 本番運用で頻発する7つの詰まりポイントを解説する。各パターンは「なぜ詰まるか」→「どう解くか」の2段構成で整理する。

6-1. Cross-Region集約でFindings欠損 — 特定リージョンのFindingsが集約されない

なぜ詰まるか

Security HubのCross-Region集約を設定したのに、特定リージョンのFindingsが集約先に現れない。主な原因は2つ。①集約先以外のリージョンでSecurity Hub自体が有効化されていない。②Organizations統合の反映遅延(最大24時間)でメンバーアカウントがまだ紐付いていない。

どう解くか

全メンバーアカウント・全リージョンのSecurity Hub有効化状態を確認し、未有効のリソースをTerraformで一括有効化する。

# メンバーアカウントの有効化状態確認
aws securityhub list-members \
  --only-associated \
  --query 'Members[].{account:AccountId,status:MemberStatus}' \
  --output table

# Terraform: Finding集約設定
resource "aws_securityhub_finding_aggregator" "main" {
  linking_mode= "ALL_REGIONS"
  specified_regions = []
}

6-2. Findings重複 — GuardDutyとSecurity Hubで二重通知が発生する

なぜ詰まるか

GuardDuty→Security Hub統合が有効化されている場合、GuardDutyのFindingsはSecurity Hubにも自動連携される。GuardDuty単体のEventBridgeルールとSecurity Hub Findingsのイベントルールが両方存在すると、同一の障害事象に対してSlack通知が2件届いてしまう。

どう解くか

通知はSecurity Hub経由に一本化し、GuardDuty単体のEventBridgeルールを削除する。Security Hub FindingsのSeverityでCRITICAL/HIGHのみをフィルタリングして通知する。

# 正解: Security Hub Findings のみをトリガーに統一
resource "aws_cloudwatch_event_rule" "securityhub_findings" {
  name = "securityhub-critical-high"

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

GuardDuty単体のEventBridgeルール(source = ["aws.guardduty"])はSeverityフィルタが難しいため削除を推奨。Security Hub経由の方が統一フィルタリングが容易。

6-3. 自動修復の誤動作 — 正常なリソースが隔離される

なぜ詰まるか

自動修復LambdaがFindingの内容を誤判定し、正常なEC2インスタンスを隔離した事例が多い。Lambdaのリソース特定ロジックが不完全で、Findingに関係ないリソースIDを対象にしてしまうパターンが頻発する。

どう解くか

まずLambdaをDry Runモードで運用し、修復対象リソースのリストをSNS通知のみで確認する。2週間ログで誤検知がないことを確認してから実修復を有効化する。

import os, json, boto3

DRY_RUN = os.environ.get("DRY_RUN", "true").lower() == "true"

def lambda_handler(event, context):
 finding = event["detail"]["findings"][0]
 resource_id = finding["Resources"][0]["Id"]
 severity = finding["Severity"]["Label"]

 if DRY_RUN:
  boto3.client("sns").publish(
TopicArn=os.environ["ALERT_TOPIC_ARN"],
Subject=f"[DRY RUN] 自動修復対象: {severity}",
Message=json.dumps({
 "resource": resource_id,
 "finding_id": finding["Id"],
 "action": "would_isolate"
}, ensure_ascii=False)
  )
  return {"status": "dry_run_only"}

 # 実修復 (DRY_RUN=false の場合のみ実行)
 boto3.client("ec2").modify_instance_attribute(
  InstanceId=resource_id.split("/")[-1],
  Groups=["sg-quarantine-id"]
 )
 return {"status": "isolated", "resource": resource_id}

6-4. Audit Manager 未対応リージョン — 大阪リージョンでAssessmentが作成できない

なぜ詰まるか

Audit Managerはap-northeast-3(大阪)など一部リージョンで利用できない(2026年5月時点)。大阪リージョンにも本番ワークロードがある場合、そのリソースのAssessmentが作成できず、コンプライアンス証跡に漏れが生じる。

どう解くか

ap-northeast-1(東京)をAudit Managerの集約リージョンに指定し、Assessmentを一元管理する。大阪リージョンのリソースは東京のAssessmentで対象に追加できる。

# Terraform: 東京リージョンを集約拠点にAudit Manager設定
provider "aws" {
  alias  = "tokyo"
  region = "ap-northeast-1"
}

resource "aws_auditmanager_account_registration" "main" {
  provider = aws.tokyo
}

resource "aws_auditmanager_assessment" "pci" {
  provider = aws.tokyo
  name  = "PCI-DSS-Assessment"

  assessment_reports_destination {
 destination_type = "S3"
 destination= "s3://${aws_s3_bucket.audit_reports.id}"
  }

  roles {
 role_arn  = aws_iam_role.audit_manager.arn
 role_type = "PROCESS_OWNER"
  }

  scope {
 aws_accounts { id = data.aws_caller_identity.current.account_id }
 aws_services { service_name = "IAM" }
 aws_services { service_name = "S3" }
  }
}

6-5. Compliance Standard更新でFindings急増 — バージョンアップ後に数百件増加

なぜ詰まるか

Security HubのStandards(CIS AWS Foundations Benchmark等)バージョンアップ後、突然Findingsが数百件増加する。バージョンアップで新コントロールが追加されるためで、事前にChangelogを確認していないと障害対応と誤認してしまう。

どう解くか

Standardsバージョンアップ前にChangelogを確認し、新コントロールはSuppressedステータスで一時対処する。順次対応計画を立てて実施する。

import boto3

def suppress_new_controls(standard_arn: str, control_ids: list) -> None:
 sh = boto3.client("securityhub")
 for control_id in control_ids:
  sh.update_standards_control(
StandardsControlArn=f"{standard_arn}/1/{control_id}",
ControlStatus="DISABLED",
DisabledReason="CIS v3.0アップグレードで追加。対応期限: 2026-Q3"
  )

# CIS v3.0 バージョンアップで追加された新コントロールを一時抑制
new_controls = ["2.1.4", "3.15", "4.16"]
suppress_new_controls(
 "arn:aws:securityhub:ap-northeast-1:123456789012:subscription/cis-aws-foundations-benchmark/v/3.0.0",
 new_controls
)

6-6. IAM権限不足でTerraform apply失敗 — Service-Linked Role作成権限エラー

なぜ詰まるか

Security Hub / GuardDuty / Audit ManagerのTerraform管理でAccessDeniedが多発する。セキュリティサービスには通常のIAM権限に加え、Service-Linked Roleの自動作成権限が必要。iam:CreateServiceLinkedRoleが不足すると、リソース作成時にロールの作成が失敗して全体がエラーになる。

どう解くか

Terraform実行ロールにiam:CreateServiceLinkedRoleと各サービスの組織管理権限を付与する。

# Terraform実行ロールへの必要権限付与
resource "aws_iam_role_policy" "terraform_security_policy" {
  name = "terraform-security-services-policy"
  role = aws_iam_role.terraform_executor.id

  policy = jsonencode({
 Version = "2012-10-17"
 Statement = [
{
  Sid = "ServiceLinkedRoleCreation"
  Effect = "Allow"
  Action = ["iam:CreateServiceLinkedRole"]
  Resource = [
 "arn:aws:iam::*:role/aws-service-role/securityhub.amazonaws.com/*",
 "arn:aws:iam::*:role/aws-service-role/guardduty.amazonaws.com/*",
 "arn:aws:iam::*:role/aws-service-role/auditmanager.amazonaws.com/*"
  ]
},
{
  Sid = "OrgAdminAccount"
  Effect = "Allow"
  Action = [
 "securityhub:EnableOrganizationAdminAccount",
 "guardduty:EnableOrganizationAdminAccount",
 "auditmanager:RegisterOrganizationAdminAccount"
  ]
  Resource = "*"
}
 ]
  })
}

6-7. GuardDuty / Configコスト爆発 — 月次コストが想定の5倍になる

なぜ詰まるか

高トラフィック環境でのGuardDuty(VPC Flow Logs分析量に比例課金)と、変更頻度の高いリソースが多い環境でのAWS Config(設定変更記録数に比例課金)が組み合わさると、月次コストが見積もりの数倍になるケースがある。

将来的にはAIシリーズ Vol1 で解説したBedrock AgentsをSecurity FindingsのトリアージAIエージェントとして活用することで、GuardDutyの低品質Findingsを自動分類・抑制してコスト最適化につなげる展望がある。

どう解くか

GuardDutyは有効化前に「使用状況」ページで月次推定コストを確認する。AWS Configは不要なリソースタイプを除外して記録コストを削減する。

# GuardDuty の推定月次コストを事前確認
aws guardduty get-usage-statistics \
  --detector-id DETECTOR_ID \
  --usage-statistic-type SUM_BY_DATA_SOURCE \
  --usage-criteria '{"DataSources":["FLOW_LOGS","CLOUD_TRAIL","DNS_LOGS","S3_LOGS"]}' \
  --query 'UsageStatistics.SumByDataSource'

# AWS Config: 必要なリソースタイプのみ記録してコスト削減
resource "aws_config_configuration_recorder" "cost_optimized" {
  name  = "cost-optimized-recorder"
  role_arn = aws_iam_role.config.arn

  recording_group {
 all_supported  = false
 include_global_resource_types = true
 resource_types = [
"AWS::IAM::Role",
"AWS::IAM::Policy",
"AWS::S3::Bucket",
"AWS::EC2::SecurityGroup",
"AWS::Lambda::Function",
 ]
  }
}

7. アンチパターン→正解パターン変換演習 (Terraform + EventBridge yaml + Lambda Python 3形式)

Security Hub / GuardDuty / Audit Managerで本番障害を起こしやすい5パターンを「アンチパターンコード → 問題点 → 正解パターンコード」の3段構成で学ぶ。EKS Vol3 GitOps/ArgoCDで習得したTerraform IaC管理の思想がそのまま活用できる演習構成となっている。

演習1: GuardDuty Detector — データソースが部分有効化のままになっている

【アンチパターン】

resource "aws_guardduty_detector" "bad" {
  enable = true
  # datasources ブロックなし → デフォルト設定のみ (S3 Logsなど無効)
}

【問題点】

datasourcesブロックを省略するとS3バケットへの不審アクセスやKubernetes監査ログのチェックが無効のままとなる。S3への意図しないデータ流出が検出されず、脅威検出に重大な死角が生まれる。

【正解パターン】

resource "aws_guardduty_detector" "good" {
  enable  = true
  finding_publishing_frequency = "FIFTEEN_MINUTES"

  datasources {
 s3_logs {
enable = true  # S3への不審アクセスを検出
 }
 kubernetes {
audit_logs { enable = true }  # EKSクラスタの不審操作を検出
 }
 malware_protection {
scan_ec2_instance_with_findings {
  ebs_volumes { enable = true }  # EC2マルウェアスキャン
}
 }
  }
}

演習2: Security Hub — 全Severity通知でSlackが埋まる

【アンチパターン】

resource "aws_cloudwatch_event_rule" "all_findings" {
  name = "all-securityhub-findings"
  event_pattern = jsonencode({
 source= ["aws.securityhub"]
 detail-type = ["Security Hub Findings - Imported"]
 # Severity フィルタなし → 全件通知
  })
}

【問題点】

Security HubのFindingsはINFORMATIONAL/LOW/MEDIUM/HIGH/CRITICALの5段階。全件を通知すると1日数百件のSlack通知になり、重要なCRITICAL通知が埋もれてしまう。

【正解パターン】

resource "aws_cloudwatch_event_rule" "critical_findings" {
  name  = "securityhub-critical-high-only"
  description = "CRITICAL/HIGH Findingsのみ通知"

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

resource "aws_cloudwatch_event_target" "slack_notify" {
  rule= aws_cloudwatch_event_rule.critical_findings.name
  target_id = "SlackNotify"
  arn = aws_lambda_function.slack_notifier.arn
}

演習3: Audit Manager — Manual Evidenceに日付がなく監査時に有効期限不明

【アンチパターン】

import boto3

def upload_manual_evidence(assessment_id: str, control_id: str, file_path: str) -> None:
 s3 = boto3.client("s3")
 # アンチパターン: ファイル名に日付なし
 s3.upload_file(
  file_path,
  "audit-evidence-bucket",
  f"evidence/{control_id}/screenshot.png"  # 日付なし
 )

【問題点】

証跡ファイルに日付がないと、監査人が「いつ時点の証跡か」を確認できない。複数のスクリーンショットが積み重なると有効期限の判断ができず、監査指摘の原因になる。

【正解パターン】

import boto3
from datetime import date

def upload_manual_evidence(assessment_id: str, control_id: str, file_path: str) -> None:
 s3 = boto3.client("s3")
 audit = boto3.client("auditmanager")

 today = date.today().strftime("%Y%m%d")
 filename = f"evidence/{control_id}/{today}_screenshot.png"  # 日付prefix付与

 s3.upload_file(file_path, "audit-evidence-bucket", filename)

 # Audit Manager にEvidence登録
 audit.batch_import_evidence_to_assessment_control(
  assessmentId=assessment_id,
  controlSetId="access_control",
  controlId=control_id,
  manualEvidence=[{
"s3ResourcePath": f"s3://audit-evidence-bucket/{filename}"
  }]
 )

演習4: Cross-Account Security Hub — 新規アカウント追加のたびに手動設定している

【アンチパターン】

# アンチパターン: メンバーを手動で個別追加
resource "aws_securityhub_member" "account_a" {
  account_id = "111111111111"
  email= "account-a@example.com"
}

resource "aws_securityhub_member" "account_b" {
  account_id = "222222222222"
  email= "account-b@example.com"
}
# 新アカウントのたびにTerraformを手動修正する運用

【問題点】

新規AWSアカウントを発行するたびにTerraformの手動修正が必要で、Security Hub有効化まで数日のラグが生じる。その期間中はセキュリティ可視性がゼロになる。

【正解パターン】

# 正解: Organizations統合でauto_enable=trueにする
resource "aws_securityhub_organization_configuration" "main" {
  auto_enable  = true  # 新規アカウントに自動で有効化
  auto_enable_standards = "NONE"  # Standardsは個別制御
}

# Organizationsレベルでの標準有効化
resource "aws_securityhub_standards_subscription" "cis" {
  standards_arn = "arn:aws:securityhub:ap-northeast-1::standards/cis-aws-foundations-benchmark/v/1.4.0"
}

演習5: GuardDuty Suppression Rule — テスト環境向けルールが本番に適用され続ける

【アンチパターン】

# アンチパターン: 有効期限なし・コメントなしの抑制ルール
resource "aws_guardduty_filter" "suppress_test" {
  detector_id = aws_guardduty_detector.main.id
  name  = "suppress-test-traffic"
  action= "ARCHIVE"
  rank  = 1

  finding_criteria {
 criterion {
field  = "accountId"
equals = ["999999999999"]  # テストアカウントID
 }
  }
}

【問題点】

テスト環境向けに作成した抑制ルールが有効期限なしで本番Detectorに適用され続ける。組織の変化でアカウントIDが変わった場合や、テストアカウントが本番化した場合に気づかないまま脅威が見逃される。

【正解パターン】

# 正解: コメントで有効期限・理由を明記
resource "aws_guardduty_filter" "suppress_pentest" {
  detector_id = aws_guardduty_detector.main.id
  # 命名規則: suppress-{理由}-{期限YYYYMM}
  name  = "suppress-pentest-202606"
  action= "ARCHIVE"
  rank  = 1

  # レビュー期限: 2026-06-30 / 担当: security-team
  # 理由: 四半期ペネトレーションテスト期間中のみ適用

  finding_criteria {
 criterion {
field  = "accountId"
equals = ["999999999999"]
 }
 criterion {
field  = "updatedAt"
greater_than = "2026-06-01T00:00:00Z"
less_than = "2026-06-30T23:59:59Z"
 }
  }
}

四半期ごとに全ルールをレビューし、期限切れのルールを削除する自動化手順をSystems Managerの定期実行で組み込む。

演習解答セクションへ

8. まとめ + Vol2予告 + 落とし穴10選 + 全シリーズクロスリンク + AWS本番運用5軸完結宣言

8-1. 5ゴール達成チェック

本記事で習得した5つのゴールを確認する。

• [ ] (a) セキュリティ3本柱の統合設計: Security Hub / GuardDuty / Audit Managerの役割分担と相互連携を設計できる
• [ ] (b) GuardDuty本番運用: Findings分類 / EventBridge自動対応 / コスト管理の実装が完了している
• [ ] (c) Security Hub Standards管理: CIS/PCI-DSSのCompliance評価・Cross-Account集約・CRITICAL/HIGH通知フィルタが設定されている
• [ ] (d) Audit Manager証跡管理: Framework / Assessment / Evidence収集がTerraform IaCで設定されている
• [ ] (e) アンチパターン回避: 詰まりポイント7選+演習5問で本番でハマりやすい落とし穴を事前回避できる

8-2. 落とし穴10選

本番導入で実際に踏まれやすい落とし穴を整理する。

1. GuardDuty datasourcesブロックを省略する → S3/EKS/マルウェアスキャンが無効のままで脅威検出に死角が生まれる
2. Security Hub全件通知を設定する → 1日数百件のSlack通知でCRITICALが埋もれる。CRITICAL/HIGHのみフィルタが必須
3. Cross-Region集約後のメンバー有効化確認を怠る → 特定リージョンのFindingsが24時間以上欠損することがある
4. 自動修復LambdaをいきなりDry Run=falseで本番投入する → 正常リソースが誤隔離される
5. GuardDuty Suppression Ruleに有効期限を設けない → テスト用ルールが永続的に本番環境に残り脅威を見逃す
6. Audit Manager EvidenceファイルにYYYYMMDD prefixを付けない → 監査時に有効期限が不明で監査指摘の原因になる
7. Standardsバージョンアップ前にChangelogを確認しない → 突然のFindings急増で障害対応と誤認する
8. 新規AWSアカウントをOrganizations統合なしに手動でSecurity Hubに追加する → 追加漏れで可視性のないアカウントが生まれる
9. GuardDutyのコスト見積もりを事前に行わない → 高トラフィック環境でVPC Flow Logs分析費用が月額数万円規模になる
10. Terraform実行ロールにService-Linked Role作成権限を付与しない → iam:CreateServiceLinkedRoleエラーでapplyが失敗する

8-3. 本番リリース前チェックリスト

本番環境にセキュリティ基盤をリリースする前に確認すべき項目を整理する。

GuardDuty設定チェック
– [ ] datasourcesブロックでS3 Logs / Kubernetes audit_logs / Malware Protectionをすべて有効化した
– [ ] finding_publishing_frequencyをFIFTEEN_MINUTESに設定した
– [ ] OrganizationsでDelegated Admin Accountを設定した

Security Hub設定チェック
– [ ] Cross-Region集約を有効化し、全リージョンのFindingsが集約先に届くことを確認した
– [ ] EventBridgeルールのSeverityフィルタをCRITICAL/HIGHのみに設定した
– [ ] GuardDuty単体のEventBridgeルールを削除し、Security Hub経由に一本化した
– [ ] Organizations統合でauto_enable=trueを設定した

Audit Manager設定チェック
– [ ] AssessmentのEvidenceファイルにYYYYMMDD prefixを付ける規約を定めた
– [ ] Assessmentのスコープに対象AWSアカウントとサービスを正確に設定した
– [ ] 証跡保管S3バケットにバージョニングと保持ポリシーを設定した

IAM / コストチェック
– [ ] GuardDutyの有効化前にコスト試算を実施した
– [ ] AWS ConfigはAll_supported=falseで必要なリソースタイプのみ記録している
– [ ] Terraform実行ロールにiam:CreateServiceLinkedRole権限を付与した

Suppression Rule管理
– [ ] 全Suppression Ruleに有効期限コメントと担当者が記載されている
– [ ] 四半期ごとのルールレビューを自動化手順として登録した

8-4. AWS本番運用5軸完結宣言 + Vol2予告

8-4. AWS本番運用 全シリーズ双方向クロスリンク

IAM入門シリーズ (前提知識)

EKS本番運用シリーズ (前提知識)

復旧・運用編シリーズ (前提知識)

AIシリーズ

セキュリティ本格運用シリーズ (本記事)

セキュリティ本格運用シリーズ Vol1 — AWS本番運用5軸の最終章として、Security Hub / GuardDuty / Audit Managerの統合設計を実践解説。IAM4巻+EKS3巻+復旧4巻+AIVol1の全知識が本記事で統合される。