AWS Config Conformance Pack Auto Remediation Terraform 本番

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

本記事はセキュリティ本番運用シリーズ第 3 巻（完結巻）として、Lambda 3 部作・EKS 3 部作・観測性 3 部作・セキュリティ Vol1/Vol2 の計 11 巻に続く 12 巻目です。Vol1 で構築した GuardDuty + Security Hub の「検知層」、Vol2 で確立した IAM Identity Center + Permission Sets の「統制層」に続く「準拠層」を本 Vol3 で完成させ、セキュリティ 3 部作 + 12 巻 AWS 本番運用シリーズを完結させます。

Vol1 GuardDuty で侵入を検知し → Vol2 Identity Center で権限を統制し → Vol3 Config で継続的準拠確認と自動修復まで完遂する、3 層防御アーキテクチャが完成します。CIS Benchmark・AWS FSBP・PCI DSS の 3 種 Conformance Pack を同時デプロイし、非準拠検知 → EventBridge → SSM Automation / Lambda Remediation の自動修復ループを Terraform で構築することで、継続的コンプライアンスを実現します。

1-1. 本記事のゴール

本記事を読み終えると、以下の状態を Terraform で構築・運用できるようになります。セキュリティ本番運用シリーズ完結巻として、Lambda 3 部作・EKS 3 部作・観測性 3 部作・セキュリティ Vol1/Vol2 の計 11 巻を前提に、12 巻目の AWS Config 準拠層を確立します。

• AWS Config Recorder + Delivery Channel + Rules の Terraform 本番構築: aws_config_configuration_recorder・aws_config_delivery_channel・aws_config_config_rule リソースで全リソースタイプの設定変更を継続記録する基盤を IaC 化します。Managed Rules (140 種以上) と Custom Lambda Rules 両方を Terraform 管理し、設定変更ドリフトを自動検知します。
• CIS Benchmark / AWS Foundational Security / PCI DSS 3 種 Conformance Pack の同時適用: aws_config_conformance_pack リソースで 3 種類のコンプライアンスフレームワークを同時デプロイし、Rule 重複を排除した効率的なガバナンス体制を Terraform で構築します。各 Pack の適用範囲と必須 Rule をマトリクスで整理します。
• SSM Automation + Lambda Remediation 両対応の Auto Remediation: 非準拠リソース検知後の自動修復を aws_config_remediation_configuration + aws_ssm_document (SSM Automation 方式) と aws_lambda_function (Lambda 方式) の 2 パターンで Terraform 実装します。修復対象リソースタイプに応じた選定基準を QG-3 マトリクスで整理します。
• Organization Conformance Pack + Delegated Admin + Cross-Region Aggregator: aws_config_organization_conformance_pack と Delegated Admin 設定で Management Account から Member Account 全体へ Conformance Pack を一括適用します。aws_config_configuration_aggregator でマルチリージョンの準拠状況を一元ダッシュボード化します。
• Athena 監査クエリ + Recorder コスト最適化: S3 に蓄積された Config スナップショットを Athena でクエリし、非準拠リソースの時系列推移を 5 例のクエリで分析します。Recorder リソースタイプ限定による月額コスト削減手順を §7 で詳述します。
• セキュリティ 3 部作完結 + 12 巻 AWS 本番運用シリーズ完結: Vol1 GuardDuty 検知層 + Vol2 IAM Identity Center 統制層 + 本 Vol3 Config 準拠層の 3 層アーキテクチャを完成させ、Lambda3 + EKS3 + 観測性3 + セキュリティ3 = 12 巻 AWS 本番運用シリーズを完結させます。

本記事の構成早見表

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

• 観測性 Vol1 (WP:2252): CloudWatch Logs Insights で Config 評価ログの時系列分析 (§7)
• 観測性 Vol3 (WP:2315): Application Signals SLO + コンプライアンス Burn Rate ダッシュボード連携 (§7)
• EKS Vol2 (WP:2228): IRSA + Config Custom Lambda Rules で EKS ワークロードの IAM 最小権限を継続監視 (§3/§5)
• EKS Vol3 (WP:2241): ArgoCD で Conformance Pack Terraform を GitOps 管理し設定ドリフトを検知 (§6)
• セキュリティ Vol1 (WP:2331): GuardDuty Findings 連携 → Config 非準拠 → EventBridge Auto Remediation の統合検知フロー (§5)
• セキュリティ Vol2 (WP:2352): IAM Identity Center Permission Sets を Config Conformance Pack で継続準拠確認 (§4/§6)

3 部作を組み合わせると、GuardDuty の Findings を EventBridge で受け取り Identity Center 経由でセキュリティチームへ通知し、Config Auto Remediation で根本原因（設定不備）を自動修正するエンドツーエンドのセキュリティ自動化フローを Terraform で構築できます。各巻が独立した価値を持ちながら、組み合わせることで相乗効果が生まれる設計です。

1-2. 読者像

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

• マルチアカウント環境を運用中のインフラ・SRE エンジニア: AWS Organizations で複数の AWS アカウントを管理しており、各アカウントのセキュリティ準拠状況を Config Rules + Conformance Pack で一元管理したい方。手動での Config Rules 個別適用から Terraform IaC 化と Organization 横断管理への移行を検討している方。
• Auto Remediation による継続的コンプライアンス自動化を推進する方: CIS Benchmark・AWS Foundational Security Best Practices・PCI DSS への準拠確認を手動で実施しており、非準拠検知から自動修復までのループを EventBridge + SSM Automation / Lambda で自動化したい方。
• セキュリティ 3 部作の完成を目指している方: Vol1 (GuardDuty + Security Hub) と Vol2 (IAM Identity Center + ABAC) を読了し、最終ピースとなる Config 準拠層を追加してセキュリティ 3 部作を完結させたい方。
• 12 巻 AWS 本番運用シリーズを通して学んでいる方: Lambda・EKS・観測性の各シリーズを経て、セキュリティシリーズの最終巻として AWS 本番運用の全体像を完成させたい方。
• PCI DSS / CIS ベンチマーク準拠証跡の整備が必要な方: 定期的なコンプライアンス監査に向けて Config スナップショット + Athena 監査クエリで証跡を自動収集したい方。CISO や監査部門への報告資料として活用したい方。

Terraform の基本的な HCL 記述 (resource / variable / output / module) と AWS Organizations の基本概念 (Management Account / Member Account / SCP) を把握していることを前提とします。IAM の基礎知識として aws:ResourceTag / aws:PrincipalTag を理解していると §4 Conformance Pack の Rule 条件設定がよりスムーズに理解できます。

Config や Conformance Pack に初めて触れる方でも §3 の仕組み解説から順に読み進めることで本番導入に必要な判断ができるよう構成しています。Vol2 (IAM Identity Center / WP:2352) の Permission Sets で定義した IAM 権限を、本 Vol3 の Config Conformance Pack で継続的に検証するという 3 部作の連携が §5 Auto Remediation と §6 Organizations 委任管理で活きてきます。

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

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

• AWS Config + Conformance Pack + Auto Remediation の 4 サービスを 1 本で完結実装する日本語 Terraform 記事が競合 10 件中 0 件。DevelopersIO は個別サービス事例が中心、AWS 公式ドキュメントは Terraform 未対応。
• CIS Benchmark・AWS Foundational Security・PCI DSS の 3 種 Conformance Pack を同時デプロイし Rule 重複を排除するパターンを Terraform で示した記事が 0 件。公式 Tutorial は単一 Pack 適用のみ。
• Organization Conformance Pack + Delegated Admin を Terraform で完全実装したハンズオン記事が 0 件 (Stack Overflow 質問レベルに留まる)。
• SSM Automation Documents と Lambda Remediation の両パターンを選定基準マトリクス付きで実装した記事が 0 件。
• Athena 監査クエリ集 + Recorder リソースタイプ限定コスト試算を同一記事で提供する日本語記事が 0 件。Wiz 等 Best Practices は概念解説のみ。
• Cross-Region Aggregator + マルチアカウント準拠ダッシュボードを Terraform で実装した記事が 0 件。AWS Blog は Console 手順のみ。

セキュリティ 3 部作完結巻としての位置付け: Vol1 GuardDuty 検知層 → Vol2 IAM Identity Center 統制層 → Vol3 Config 準拠層という 3 層セキュリティアーキテクチャの最終ピースです。「侵入検知 → 権限統制 → 継続的コンプライアンス確認」のループを 3 巻で体系化した国内唯一のシリーズとなります。Vol1 + Vol2 + Vol3 を組み合わせると、GuardDuty Findings を EventBridge で受け取り IAM Identity Center 経由で通知し Config Auto Remediation で自動修復する統合フローを Terraform で構築できます。

12 巻 AWS 本番運用シリーズ完結: Lambda 3 巻 + EKS 3 巻 + 観測性 3 巻 + セキュリティ 3 巻 = 12 巻完結。AWS 本番運用の全領域（コンピューティング・コンテナ・可観測性・セキュリティ）を IaC + Terraform で体系化した、国内初の包括的ハンズオンシリーズが完成します。

12 巻 AWS 本番運用シリーズ 完結ロードマップ

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

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

§3・§4 は「Config 基盤と Conformance Pack 設計」を扱う意思決定層で、準拠フレームワーク選定に最適です。§5〜§7 は「Terraform でどう実装するか」の実践層で、コードをそのまま活用できます。セキュリティ Vol1/Vol2 未読の方は §1 の連携ポイントを先に確認することを推奨します。

前提シリーズ: セキュリティVol1 GuardDuty+Security Hub本番運用を読む

2. 前提・環境・準備

2-1. 前提環境

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

• AWS Organizations 設定済み: Management Account と Member Account が Organizations で管理されていること。Delegated Admin 設定 (§6) で Organization Conformance Pack を全 Member Account へ一括適用します。
• AWS Config 有効化済み (Management Account + Member Account): 本記事の §3 で Config Recorder を Terraform 化しますが、既存環境では既に有効化されている場合は terraform import して管理下に置きます。
• Terraform >= 1.7: terraform version で 1.7 以上であることを確認。aws_config_organization_conformance_pack の excluded_accounts 引数は v5.x で対応。
• AWS Provider v5.x: aws_config_configuration_recorder・aws_config_conformance_pack・aws_config_organization_conformance_pack・aws_config_remediation_configuration・aws_config_configuration_aggregator を使用するため v5.x 以上が必要。
• AWS CLI v2: aws --version で v2.x 以上であることを確認。aws configservice コマンドで各セクションの動作確認に使用します。
• IAM 権限: config:* / organizations:* / ssm:* / lambda:* / s3:* / athena:* を Management Account または委任管理アカウントに付与済み。
• IAM Identity Center (推奨): Vol2 (WP:2352) で構築した Permission Sets を使用して AWS アクセスを設定している方はそのまま利用可能。IAM ロール直接設定でも動作します。

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

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

# Config Recorder の現在の状態確認
aws configservice describe-configuration-recorders \
  --query 'ConfigurationRecorders[*].{Name:name,RoleARN:roleARN}' \
  --output table

# Conformance Pack 一覧確認 (既存環境)
aws configservice describe-conformance-packs \
  --query 'ConformancePackDetails[*].{Name:ConformancePackName,Status:ConformancePackState}' \
  --output table

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

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

本記事完了後の状態を以下に定義します。

• Config Recorder: 全リソースタイプを全リージョンで継続記録 (コスト最適化が必要な場合は §7 のリソースタイプ限定設定を適用)
• Delivery Channel: S3 バケット + SNS トピックへ設定スナップショットを自動配信
• Config Rules: Managed Rules 10 本以上 + Custom Lambda Rules 2 本を Terraform 管理
• Conformance Pack: CIS v3 + AWS FSBP + PCI DSS 3.2.1 の 3 種を同時デプロイ済み、準拠スコアが Management Account コンソールで確認可能
• Auto Remediation: 非準拠検知 → EventBridge → SSM Automation (S3 公開バケット修復等) / Lambda Remediation (カスタムロジック) の自動修復ループが稼働中
• Organization: Delegated Admin アカウント設定済み + Organization Conformance Pack で全 Member Account 横断適用済み
• Aggregator: Cross-Region + Cross-Account Aggregator でマルチリージョン準拠状況の一元ダッシュボード表示済み
• Athena: Config スナップショット S3 バケットに対する Glue Crawler 設定済み + 監査クエリ 5 例が実行可能

2-4. コスト概算

本記事で構築する構成の月額コスト目安を示します。環境規模とリソースタイプ設定により大幅に変動するため、§7 で Recorder リソースタイプ限定による削減手順を詳述します。

コスト削減の最重要ポイント: Config Recorder のリソースタイプを ALL から必要最小限 (EC2 / S3 / IAM / Lambda / RDS 等) に絞ることで月額コストを 50〜80% 削減できます。§7 でリソースタイプ限定設定の Terraform 実装と試算を詳述します。

2-5. Terraform ディレクトリ構成

本記事で扱う Terraform コードは以下のディレクトリ構成を推奨します。モジュール化により Conformance Pack・Remediation・Organizations を独立して管理でき、段階的な導入が可能です。

terraform-aws-config/
├── modules/
│├── config-recorder/# §3: Recorder + Delivery Channel
│├── config-rules/# §3: Managed Rules + Custom Lambda Rules
│├── conformance-pack/  # §4: CIS / AWS FSBP / PCI DSS 3 種
│├── auto-remediation/  # §5: SSM Automation + Lambda Remediation
│└── org-config/  # §6: Organization Conformance Pack + Aggregator
├── environments/
│├── management/  # Management Account 設定
│└── member/# Member Account 設定 (Organizations 委任)
└── main.tf # モジュール呼び出し + プロバイダー設定

3. AWS Config 仕組み + Recorder + Delivery Channel + Rules 詳説

sequenceDiagram
  participant Resource as AWSリソース
  participant Recorder as Config Recorder
  participant Rule as Config Rule
  participant EventBridge as EventBridge
  participant Remediation as SSM/Lambda

  Resource->>Recorder: リソース変更検知
  Recorder->>Rule: 設定変更通知
  Rule->>Rule: 準拠評価
  alt compliant
 Rule-->>Resource: COMPLIANT ✅
  else non-compliant
 Rule->>EventBridge: NON_COMPLIANT イベント
 EventBridge->>Remediation: Remediation 実行
  end

3-1. AWS Config の仕組み概要

AWS Config は、AWS リソースの設定変更を継続的に記録・評価するマネージドサービスだ。GuardDuty による「検知層」・IAM Identity Center による「統制層」と組み合わせることで、「検知 → 統制 → 準拠」運用ループが完成する。

AWS Config の主要コンポーネントは以下の 4 要素で構成される。

評価タイミングは 2 種類ある。

• 変更トリガー (Change-triggered): リソース設定変更時に即時評価。S3 バケット設定変更・IAM ポリシー変更など
• 定期トリガー (Periodic): 設定した間隔 (1h / 3h / 6h / 12h / 24h) で定期評価。ルートアカウント MFA など時刻ベースの準拠確認

AWS Config は リソースごとに課金される (2026-05 現在、記録されたリソース設定あたり $0.003/件)。Recorder 設定でリソースタイプを絞ることがコスト最適化の鍵だ (§7 参照)。

3-2. Configuration Recorder + Delivery Channel Terraform 実装

Recorder・Delivery Channel・Recorder Status の 3 リソースを必ずセットでデプロイする。aws_config_configuration_recorder_status を分離したリソースとして定義する点は、初学者が詰まる頻出ミスだ。

resource "aws_iam_role" "config_role" {
  name = "aws-config-role"

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

resource "aws_iam_role_policy_attachment" "config_policy" {
  role = aws_iam_role.config_role.name
  policy_arn = "arn:aws:iam::aws:policy/service-role/AWS_ConfigRole"
}

resource "aws_s3_bucket" "config_bucket" {
  bucket  = "aws-config-delivery-${var.account_id}"
  force_destroy = false
}

# S3 バケットポリシーに AWSConfigBucketPermissionsCheck + AWSConfigBucketDelivery の 2 権限が必要
# (config.amazonaws.com への s3:GetBucketAcl + s3:PutObject を付与)

# 全リソースタイプ記録 (コスト重視の場合は resource_types で絞る)
resource "aws_config_configuration_recorder" "main" {
  name  = "main"
  role_arn = aws_iam_role.config_role.arn

  recording_group {
 all_supported  = true
 include_global_resource_types = true
  }
}

resource "aws_sns_topic" "config_notifications" {
  name = "aws-config-notifications"
}

resource "aws_config_delivery_channel" "main" {
  name  = "main"
  s3_bucket_name = aws_s3_bucket.config_bucket.bucket
  sns_topic_arn  = aws_sns_topic.config_notifications.arn

  snapshot_delivery_properties {
 delivery_frequency = "TwentyFour_Hours"
  }

  depends_on = [aws_config_configuration_recorder.main]
}

# Recorder 有効化は Delivery Channel 作成後に実行
resource "aws_config_configuration_recorder_status" "main" {
  name = aws_config_configuration_recorder.main.name
  is_enabled = true

  depends_on = [aws_config_delivery_channel.main]
}

3-3. Managed Rules 主要 10 選 + Terraform 実装

AWS 提供の Managed Rules は 400 種以上あるが、CIS ベンチマーク・PCI DSS 対応の観点から以下 10 ルールを優先適用する。

resource "aws_config_config_rule" "s3_public_read_prohibited" {
  name = "s3-bucket-public-read-prohibited"

  source {
 owner = "AWS"
 source_identifier = "S3_BUCKET_PUBLIC_READ_PROHIBITED"
  }

  depends_on = [aws_config_configuration_recorder_status.main]
}

resource "aws_config_config_rule" "iam_password_policy" {
  name = "iam-password-policy"

  source {
 owner = "AWS"
 source_identifier = "IAM_PASSWORD_POLICY"
  }

  input_parameters = jsonencode({
 RequireUppercaseCharacters = "true"
 RequireLowercaseCharacters = "true"
 RequireSymbols = "true"
 RequireNumbers = "true"
 MinimumPasswordLength= "14"
 PasswordReusePrevention = "24"
 MaxPasswordAge = "90"
  })

  depends_on = [aws_config_configuration_recorder_status.main]
}

resource "aws_config_config_rule" "guardduty_enabled_centralized" {
  name = "guardduty-enabled-centralized"

  source {
 owner = "AWS"
 source_identifier = "GUARDDUTY_ENABLED_CENTRALIZED"
  }

  depends_on = [aws_config_configuration_recorder_status.main]
}

3-4. Custom Lambda Rules Terraform 実装

Managed Rules でカバーできない独自ガバナンス要件 (特定タグ必須・EC2 インスタンスタイプ制限など) には Custom Lambda Rules を使用する。

resource "aws_lambda_function" "custom_config_rule" {
  function_name = "custom-ec2-tag-check"
  role = aws_iam_role.lambda_config_role.arn
  handler = "index.handler"
  runtime = "python3.12"
  timeout = 60
  filename= "${path.module}/lambda/custom_config_rule.zip"

  environment {
 variables = {
REQUIRED_TAGS = "Environment,Owner,CostCenter"
 }
  }
}

resource "aws_lambda_permission" "config_invoke" {
  statement_id  = "AllowConfigInvoke"
  action  = "lambda:InvokeFunction"
  function_name = aws_lambda_function.custom_config_rule.function_name
  principal  = "config.amazonaws.com"
}

resource "aws_config_config_rule" "custom_ec2_tag_check" {
  name = "custom-ec2-tag-check"

  source {
 owner = "CUSTOM_LAMBDA"
 source_identifier = aws_lambda_function.custom_config_rule.arn

 source_detail {
message_type = "ConfigurationItemChangeNotification"
 }
  }

  scope {
 compliance_resource_types = ["AWS::EC2::Instance"]
  }

  depends_on = [
 aws_config_configuration_recorder_status.main,
 aws_lambda_permission.config_invoke,
  ]
}

Lambda 関数内では invoking_event から設定変更情報を取得し、put_evaluations API で COMPLIANT / NON_COMPLIANT を報告する。評価処理のタイムアウトは 60 秒以内に収める設計が推奨される。

3-5. AWS CLI 確認コマンド

# 全 Config Rules の一覧・準拠状況確認
aws configservice describe-config-rules

# 特定ルールの非準拠リソース一覧
aws configservice get-compliance-details-by-config-rule \
  --config-rule-name s3-bucket-public-read-prohibited \
  --compliance-types NON_COMPLIANT

# 準拠サマリー (COMPLIANT / NON_COMPLIANT 件数)
aws configservice get-compliance-summary-by-config-rule

# Recorder 稼働ステータス確認
aws configservice describe-configuration-recorder-status \
  --configuration-recorder-names main

コンソール確認手順: AWS Config コンソール → 「Rules」で各ルールの準拠状態・リソース一覧を確認する。「Resource inventory」ではリソースの設定スナップショットを時系列で追跡でき、変更の前後差分も視覚的に確認できる。

4. Conformance Pack デプロイ (CIS / AWS Foundational Security / PCI DSS)

4-1. Conformance Pack とは

Conformance Pack は AWS Config Rules と Remediation Actions をひとつのコレクションとしてまとめ、アカウント全体・組織全体に一括デプロイできる AWS Config の管理単位です。単一 Rule を個別設定する従来手法と比較し、Conformance Pack を使うと「セキュリティフレームワーク単位での準拠状態管理」が実現でき、複数の規格への対応状況を Pack 単位でスコアリングできる点が最大の特長です。

Conformance Pack の 3 要素:

AWS 管理テンプレート vs カスタムテンプレート:

AWS が公式に提供する管理テンプレートは s3://aws-config-rules-data/conformance-packs/ に格納されており、CIS Benchmarks・AWS Foundational Security Best Practices・PCI DSS・HIPAA・NIST 800-53 など 60 種以上のフレームワークに対応している。カスタムテンプレートは自社独自のコンプライアンス要件を YAML 形式で記述し、S3 または template_body 直書きで指定する。

Rule 重複排除の仕組み:

複数の Conformance Pack が同一 Config Rule (例: access-keys-rotated) を参照する場合、AWS Config は内部で Rule を単一インスタンスとして扱い、各 Pack が独立してコンプライアンス結果を追跡する。Rule 評価は一度だけ実行されるため、API コール料金の二重課金は発生しない。ただし、Pack ごとに異なる Input Parameter を指定した場合、同一 Rule の最後に適用されたパラメータが優先される点に注意が必要です。複数 Pack で Input Parameter が競合する場合は、後述するように共通 Rule を aws_config_config_rule リソースで直接管理し Pack Template から除外する設計を推奨する。

4-2. CIS AWS Foundations Benchmark Conformance Pack

CIS (Center for Internet Security) が策定する AWS Foundations Benchmark は、AWS アカウントのセキュリティ設定に関する国際標準のベストプラクティス集です。Level 1 は必須対応項目（ほぼ全環境に適用推奨）、Level 2 は高セキュリティ要件環境向けの追加対応項目となる。本番環境では Level 1 を基準に適用し、金融・医療・政府系では Level 2 まで対応することを推奨する。

Terraform 実装: CIS Level 1 Conformance Pack:

resource "aws_config_conformance_pack" "cis_level1" {
  name = "cis-aws-foundations-benchmark-level-1"

  template_body = <<-EOT
 Parameters:
AccessKeysRotatedParamMaxAccessKeyAge:
  Default: '90'
IAMPasswordPolicyParamRequireUppercaseCharacters:
  Default: 'true'
IAMPasswordPolicyParamRequireLowercaseCharacters:
  Default: 'true'
IAMPasswordPolicyParamRequireSymbols:
  Default: 'true'
IAMPasswordPolicyParamRequireNumbers:
  Default: 'true'
IAMPasswordPolicyParamMinimumPasswordLength:
  Default: '14'
IAMPasswordPolicyParamPasswordReusePrevention:
  Default: '24'
IAMPasswordPolicyParamMaxPasswordAge:
  Default: '90'
 Resources:
AccessKeysRotated:
  Type: AWS::Config::ConfigRule
  Properties:
 ConfigRuleName: access-keys-rotated
 Source:
Owner: AWS
SourceIdentifier: ACCESS_KEYS_ROTATED
 InputParameters:
maxAccessKeyAge: !Ref AccessKeysRotatedParamMaxAccessKeyAge
MfaEnabledForIamConsoleAccess:
  Type: AWS::Config::ConfigRule
  Properties:
 ConfigRuleName: mfa-enabled-for-iam-console-access
 Source:
Owner: AWS
SourceIdentifier: MFA_ENABLED_FOR_IAM_CONSOLE_ACCESS
RootAccountMfaEnabled:
  Type: AWS::Config::ConfigRule
  Properties:
 ConfigRuleName: root-account-mfa-enabled
 Source:
Owner: AWS
SourceIdentifier: ROOT_ACCOUNT_MFA_ENABLED
CloudtrailEnabled:
  Type: AWS::Config::ConfigRule
  Properties:
 ConfigRuleName: cloud-trail-enabled
 Source:
Owner: AWS
SourceIdentifier: CLOUD_TRAIL_ENABLED
CloudtrailMultiRegionEnabled:
  Type: AWS::Config::ConfigRule
  Properties:
 ConfigRuleName: multi-region-cloudtrail-enabled
 Source:
Owner: AWS
SourceIdentifier: MULTI_REGION_CLOUD_TRAIL_ENABLED
IamPasswordPolicy:
  Type: AWS::Config::ConfigRule
  Properties:
 ConfigRuleName: iam-password-policy
 Source:
Owner: AWS
SourceIdentifier: IAM_PASSWORD_POLICY
 InputParameters:
RequireUppercaseCharacters: !Ref IAMPasswordPolicyParamRequireUppercaseCharacters
RequireLowercaseCharacters: !Ref IAMPasswordPolicyParamRequireLowercaseCharacters
RequireSymbols: !Ref IAMPasswordPolicyParamRequireSymbols
RequireNumbers: !Ref IAMPasswordPolicyParamRequireNumbers
MinimumPasswordLength: !Ref IAMPasswordPolicyParamMinimumPasswordLength
PasswordReusePrevention: !Ref IAMPasswordPolicyParamPasswordReusePrevention
MaxPasswordAge: !Ref IAMPasswordPolicyParamMaxPasswordAge
VpcDefaultSecurityGroupClosed:
  Type: AWS::Config::ConfigRule
  Properties:
 ConfigRuleName: vpc-default-security-group-closed
 Source:
Owner: AWS
SourceIdentifier: VPC_DEFAULT_SECURITY_GROUP_CLOSED
GuarddutyEnabledCentralized:
  Type: AWS::Config::ConfigRule
  Properties:
 ConfigRuleName: guardduty-enabled-centralized
 Source:
Owner: AWS
SourceIdentifier: GUARDDUTY_ENABLED_CENTRALIZED
  EOT

  depends_on = [
 aws_config_configuration_recorder.main,
 aws_config_delivery_channel.main,
  ]
}

AWS CLI での確認:

aws configservice get-conformance-pack-compliance-details \
  --conformance-pack-name cis-aws-foundations-benchmark-level-1 \
  --filters ComplianceType=NON_COMPLIANT \
  --region ap-northeast-1

AWS マネジメントコンソールでの確認: AWS Config コンソール → 左ペイン「Conformance packs」→ cis-aws-foundations-benchmark-level-1 を選択 → 「Compliance score」でスコアを確認し、「Rules」タブで非準拠 Rule の詳細を確認する。

4-3. AWS Foundational Security Best Practices Conformance Pack

AWS が直接管理する AWS Foundational Security Best Practices (FSBP) は、AWS サービス全体を横断する 230 以上のセキュリティコントロールを集約した Conformance Pack です。CIS Benchmark がアカウント設定に特化するのに対し、FSBP は S3・EC2・RDS・Lambda・ECS・EKS など個々の AWS サービス設定まで評価対象とする点が異なる。

Terraform 実装: AWS Foundational Security Best Practices:

resource "aws_config_conformance_pack" "aws_foundational" {
  name = "aws-foundational-security-best-practices"

  template_s3_uri = "s3://aws-config-rules-data/conformance-packs/aws-foundational-security-best-practices.yaml"

  input_parameter {
 parameter_name  = "AccessKeysRotatedParamMaxAccessKeyAge"
 parameter_value = "90"
  }

  input_parameter {
 parameter_name  = "S3BucketVersioningEnabledParamIsMfaDeleteEnabled"
 parameter_value = "false"
  }

  depends_on = [
 aws_config_configuration_recorder.main,
 aws_config_delivery_channel.main,
  ]
}

FSBP 主要コントロール (代表 20 件):

AWS CLI での確認:

aws configservice describe-conformance-pack-compliance \
  --conformance-pack-names aws-foundational-security-best-practices \
  --query 'ConformancePackComplianceList[*].ConformancePackRuleComplianceList[?ComplianceType==`NON_COMPLIANT`].ConfigRuleName' \
  --output text \
  --region ap-northeast-1

4-4. PCI DSS Conformance Pack

PCI DSS (Payment Card Industry Data Security Standard) は、クレジットカード情報を扱うシステムに適用される国際セキュリティ標準です。AWS の PCI DSS Conformance Pack は PCI DSS 3.2.1 の 12 要件に対応する Config Rules をパッケージ化している。カード情報非保持環境においても、決済サービス連携や EC システムでは PCI DSS 準拠を求められるケースもあるため、金融・EC 系システムへの適用を推奨する。

Terraform 実装: PCI DSS Conformance Pack:

resource "aws_config_conformance_pack" "pci_dss" {
  name = "pci-dss-3-2-1"

  template_s3_uri = "s3://aws-config-rules-data/conformance-packs/pci-dss-3-2-1.yaml"

  input_parameter {
 parameter_name  = "RestrictedCommonPortsParamBlockedPort1"
 parameter_value = "20"
  }

  input_parameter {
 parameter_name  = "RestrictedCommonPortsParamBlockedPort2"
 parameter_value = "21"
  }

  input_parameter {
 parameter_name  = "RestrictedCommonPortsParamBlockedPort3"
 parameter_value = "3389"
  }

  input_parameter {
 parameter_name  = "SSHRestrictedParamIpRanges"
 parameter_value = "0.0.0.0/0"
  }

  depends_on = [
 aws_config_configuration_recorder.main,
 aws_config_delivery_channel.main,
  ]
}

PCI DSS 主要コントロール (代表 10 件):

AWS CLI での確認:

aws configservice get-conformance-pack-compliance-details \
  --conformance-pack-name pci-dss-3-2-1 \
  --filters ComplianceType=NON_COMPLIANT \
  --region ap-northeast-1 \
  --output json | jq '.ConformancePackRuleComplianceList[] | {Rule:.ConfigRuleName, Status:.ComplianceType}'

4-5. 3 種同時適用と Rule 重複排除

3 種 Conformance Pack (CIS / FSBP / PCI DSS) を同一アカウントに同時デプロイする場合、access-keys-rotated など複数 Pack に共通する Rule の Input Parameter 競合に注意が必要です。競合回避の実装パターンとして、共通 Rule を aws_config_config_rule で直接管理し、各 Pack Template からは当該 Rule を除外する方法が最も確実です。

Terraform: 共通 Rule の直接管理 + 3 種 Pack 同時デプロイ:

resource "aws_config_config_rule" "access_keys_rotated_shared" {
  name = "access-keys-rotated"

  source {
 owner = "AWS"
 source_identifier = "ACCESS_KEYS_ROTATED"
  }

  input_parameters = jsonencode({
 maxAccessKeyAge = "90"
  })

  depends_on = [aws_config_configuration_recorder.main]
}

resource "aws_config_config_rule" "root_mfa_shared" {
  name = "root-account-mfa-enabled"

  source {
 owner = "AWS"
 source_identifier = "ROOT_ACCOUNT_MFA_ENABLED"
  }

  depends_on = [aws_config_configuration_recorder.main]
}

resource "aws_config_conformance_pack" "cis_level1" {
  name = "cis-aws-foundations-benchmark-level-1"
  template_body = file("${path.module}/templates/cis-level1-no-duplicates.yaml")

  depends_on = [
 aws_config_configuration_recorder.main,
 aws_config_config_rule.access_keys_rotated_shared,
 aws_config_config_rule.root_mfa_shared,
  ]
}

resource "aws_config_conformance_pack" "aws_foundational" {
  name= "aws-foundational-security-best-practices"
  template_s3_uri = "s3://aws-config-rules-data/conformance-packs/aws-foundational-security-best-practices.yaml"

  depends_on = [
 aws_config_configuration_recorder.main,
 aws_config_config_rule.access_keys_rotated_shared,
  ]
}

resource "aws_config_conformance_pack" "pci_dss" {
  name= "pci-dss-3-2-1"
  template_s3_uri = "s3://aws-config-rules-data/conformance-packs/pci-dss-3-2-1.yaml"

  input_parameter {
 parameter_name  = "RestrictedCommonPortsParamBlockedPort1"
 parameter_value = "20"
  }

  input_parameter {
 parameter_name  = "RestrictedCommonPortsParamBlockedPort2"
 parameter_value = "21"
  }

  depends_on = [
 aws_config_configuration_recorder.main,
 aws_config_config_rule.access_keys_rotated_shared,
 aws_config_config_rule.root_mfa_shared,
  ]
}

3 種 Pack の一括コンプライアンス確認:

aws configservice describe-conformance-packs \
  --region ap-northeast-1

for pack in cis-aws-foundations-benchmark-level-1 aws-foundational-security-best-practices pci-dss-3-2-1; do
  echo "=== ${pack} ==="
  aws configservice describe-conformance-pack-compliance \
 --conformance-pack-names "${pack}" \
 --query 'ConformancePackComplianceList[].ConformancePackRuleComplianceList[?ComplianceType==`NON_COMPLIANT`].ConfigRuleName' \
 --output text \
 --region ap-northeast-1
done

AWS マネジメントコンソールでの 3 種 Pack 確認手順:

1. AWS Config コンソール → 左ペイン「Conformance packs」を選択
2. 一覧に 3 件の Pack が CREATE_COMPLETE 状態で表示されることを確認
3. 各 Pack をクリック → 「Compliance score」でフレームワーク別の準拠スコアを比較
4. 「Rules」タブで「NON_COMPLIANT」フィルタを適用し、修正が必要な Rule を特定
5. Pack 間で同一 Rule が表示される場合は「Rule details」から評価パラメータが意図通りか確認する

3 種 Pack の特性比較マトリクス:

5. Auto Remediation (SSM Automation + Lambda 両対応)

flowchart TD
  A[Config Rule 評価] --> B{準拠状態}
  B -->|COMPLIANT| C[監査ログ記録]
  B -->|NON_COMPLIANT| D[EventBridge イベント発行]
  D --> E{Remediation 種別選択}
  E -->|自動化可能・副作用少| F[SSM Automation Document実行]
  E -->|複雑なロジック必要| G[Lambda Function実行]
  F --> H[リソース修復]
  G --> H
  H --> I[Config Rule 再評価]
  I --> J{修復確認}
  J -->|成功| C
  J -->|失敗| K[SNS アラート + 手動対応]

AWS Config の Auto Remediation は、Config Rule が NON_COMPLIANT と評価したリソースを自動修復する仕組みだ。aws_config_remediation_configuration が Config Rule と修復アクション (SSM Automation または Lambda) を紐付ける核心リソースとなる。

5-1. Auto Remediation の仕組みと選定基準

automatic = true で非準拠検出直後に自動実行、automatic = false で手動承認フローになる。本番環境では false から開始し、動作確認後に true へ昇格するのが安全なアプローチだ。maximum_automatic_attempts = 3 / retry_attempt_seconds = 60 をベースラインに設定し、リトライ上限到達後は SNS 通知で手動介入に引き渡す。

自動修復 vs 手動承認フロー

SSM Automation vs Lambda 選定早見表

5-2. SSM Automation Documents による自動修復 Terraform

AWSConfigRemediation-* プレフィックスの AWS マネージド Document を target_id に指定することで、カスタム実装なしに主要な修復アクションを実行できる。

# S3 パブリックアクセスブロック自動修復
resource "aws_config_remediation_configuration" "s3_block_public_access" {
  config_rule_name  = aws_config_config_rule.s3_public_read_prohibited.name
  target_type = "SSM_DOCUMENT"
  target_id= "AWSConfigRemediation-ConfigureS3BucketPublicAccessBlock"
  automatic= true
  maximum_automatic_attempts = 3
  retry_attempt_seconds= 60

  parameter {
 name= "AutomationAssumeRole"
 static_value = aws_iam_role.config_remediation.arn
  }
  parameter {
 name  = "BucketName"
 resource_value = "RESOURCE_ID"
  }
}

# Remediation 実行 IAM Role (SSM Automation 用)
resource "aws_iam_role" "config_remediation" {
  name = "${var.project}-config-remediation"

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

resource "aws_iam_role_policy" "config_remediation_s3" {
  name= "s3-public-access-remediation"
  role= aws_iam_role.config_remediation.id
  policy = jsonencode({
 Version = "2012-10-17"
 Statement = [{
Effect= "Allow"
Action= ["s3:PutBucketPublicAccessBlock", "s3:GetBucketPublicAccessBlock"]
Resource = "arn:aws:s3:::*"
 }]
  })
}

AWS マネージド SSM Automation Document 主要 10 件

5-3. Custom SSM Automation Document 作成 Terraform

AWS マネージド Document でカバーされない組織固有ルールには aws_ssm_document で Custom Document を作成する。aws:executeAwsApi アクションで任意の AWS API を呼び出せるため、タグポリシー準拠修復など幅広いユースケースに対応できる。

resource "aws_ssm_document" "tag_compliance_remediation" {
  name = "${var.project}-TagComplianceRemediation"
  document_type = "Automation"

  content = jsonencode({
 schemaVersion = "0.3"
 description= "EC2 インスタンスへの必須タグ自動付与"
 assumeRole = "{{ AutomationAssumeRole }}"
 parameters = {
InstanceId  = { type = "String", description = "対象 EC2 インスタンス ID" }
AutomationAssumeRole = { type = "String", description = "Automation 実行 IAM Role ARN" }
Environment = { type = "String", default = "production" }
 }
 mainSteps = [{
name= "AddMissingTags"
action = "aws:executeAwsApi"
inputs = {
  Service= "ec2"
  Api = "CreateTags"
  Resources = ["{{ InstanceId }}"]
  Tags= [
 { Key = "Environment", Value = "{{ Environment }}" },
 { Key = "ManagedBy",Value = "AWS-Config-AutoRemediation" }
  ]
}
 }]
  })
}

resource "aws_config_remediation_configuration" "tag_compliance" {
  config_rule_name  = aws_config_config_rule.required_tags.name
  target_type = "SSM_DOCUMENT"
  target_id= aws_ssm_document.tag_compliance_remediation.name
  automatic= false
  maximum_automatic_attempts = 3
  retry_attempt_seconds= 60

  parameter {
 name= "AutomationAssumeRole"
 static_value = aws_iam_role.config_remediation.arn
  }
  parameter {
 name  = "InstanceId"
 resource_value = "RESOURCE_ID"
  }
}

5-4. Lambda Remediation Terraform

複雑なロジックや複数リソース連携が必要な修復には Lambda を使用する。Config は Lambda を直接呼び出せないため、AWS-InvokeWebhook SSM Document 経由で Lambda Function URL を渡す実装パターンが標準だ。

resource "aws_lambda_function" "config_remediation" {
  function_name = "${var.project}-config-remediation"
  role = aws_iam_role.lambda_remediation.arn
  handler = "index.handler"
  runtime = "python3.12"
  timeout = 300
  filename= "${path.module}/.build/remediation.zip"

  environment {
 variables = {
SNS_TOPIC_ARN = aws_sns_topic.security_alerts.arn
 }
  }
}

resource "aws_lambda_function_url" "remediation" {
  function_name= aws_lambda_function.config_remediation.function_name
  authorization_type = "AWS_IAM"
}

resource "aws_config_remediation_configuration" "lambda_sg_remediation" {
  config_rule_name  = aws_config_config_rule.sg_open_to_world.name
  target_type = "SSM_DOCUMENT"
  target_id= "AWS-InvokeWebhook"
  automatic= false
  maximum_automatic_attempts = 3
  retry_attempt_seconds= 60

  parameter {
 name= "AutomationAssumeRole"
 static_value = aws_iam_role.config_remediation.arn
  }
  parameter {
 name= "HttpMethod"
 static_value = "POST"
  }
  parameter {
 name= "Url"
 static_value = aws_lambda_function_url.remediation.function_url
  }
}

resource "aws_iam_role" "lambda_remediation" {
  name = "${var.project}-lambda-config-remediation"

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

resource "aws_iam_role_policy" "lambda_sg_remediation" {
  name = "sg-open-remediation"
  role = aws_iam_role.lambda_remediation.id
  policy = jsonencode({
 Version = "2012-10-17"
 Statement = [
{
  Effect= "Allow"
  Action= ["ec2:RevokeSecurityGroupIngress", "ec2:DescribeSecurityGroups"]
  Resource = "*"
},
{
  Effect= "Allow"
  Action= ["logs:CreateLogGroup", "logs:CreateLogStream", "logs:PutLogEvents"]
  Resource = "arn:aws:logs:*:*:*"
}
 ]
  })
}

5-5. AWS CLI による Remediation 操作

# 手動修復の実行
aws configservice start-remediation-execution \
  --config-rule-name s3-bucket-public-read-prohibited \
  --resource-keys resourceType=AWS::S3::Bucket,resourceId=my-bucket

# 修復実行ステータスの確認
aws configservice describe-remediation-execution-status \
  --config-rule-name s3-bucket-public-read-prohibited

# Remediation 設定の確認
aws configservice describe-remediation-configurations \
  --config-rule-names s3-bucket-public-read-prohibited

# 修復失敗リソースの一覧取得
aws configservice describe-remediation-execution-status \
  --config-rule-name s3-bucket-public-read-prohibited \
  --query "RemediationExecutionStatuses[?State=='FAILED']"

AWS マネジメントコンソールでの操作手順

1. AWS Config コンソール → Rules → 対象 Rule を選択
2. Actions → Manage remediation をクリック
3. Remediation action で SSM Document または Lambda を選択
4. Automatic remediation のトグルで自動/手動を切り替え
5. Parameters で AutomationAssumeRole と対象リソース ID パラメータを設定
6. Save → 次回の Rule 評価から修復が有効化される
7. 修復結果は Rule 詳細ページの Remediation action タブで確認

6. Organizations 委任管理 + Organization Conformance Pack

6-1. Organizations Config の概念

マルチアカウント環境で AWS Config を一元管理するには、Organizations との統合が不可欠だ。Management Account から別アカウントに権限を委任する Delegated Administrator パターンと、全 Member Account に Conformance Pack を一括適用する Organization Conformance Pack が中核を担う。

Delegated Administrator は、セキュリティ専用アカウント（Security Tooling Account）に config.amazonaws.com と config-multiaccountsetup.amazonaws.com の 2 つのサービスプリンシパルを委任する。Management Account の権限を使わずにセキュリティチームが Config 管理を担える構成になり、最小権限の原則を守りながら運用負荷を分散できる。

Organization Conformance Pack は aws_config_organization_conformance_pack リソースで管理し、全 Member Account に CIS / AWS Foundational / PCI DSS を一括配布する。個別アカウントでの設定ずれを排除し、新規アカウントへの自動適用も実現する。

Cross-Region Aggregator は全リージョン・全アカウントのコンプライアンス状況を単一ビューに集約する。aws_config_configuration_aggregator で all_regions = true を指定することで、マルチリージョン構成でも漏れなく集計できる。

Organizations 連携の前提条件:

• Organizations の All Features が有効化済みであること
• 委任先アカウントの Config サービスロール（AWSConfigRole）が付与済みであること
• Delegated Admin アカウントに config-multiaccountsetup.amazonaws.com の信頼関係が設定済みであること
• S3 バケット（Conformance Pack テンプレート置き場）がクロスアカウントアクセス許可済みであること

6-2. Delegated Admin 設定 Terraform

Management Account で aws_organizations_delegated_administrator を 2 リソース定義する。config.amazonaws.com は Config Rules 管理用、config-multiaccountsetup.amazonaws.com は Organization Conformance Pack のデプロイ用だ。Security Account 側では Delegated Admin 用の IAM ロールを別途用意する。

# ── Delegated Administrator (Management Account で実行) ──────────────
resource "aws_organizations_delegated_administrator" "config" {
  account_id  = var.security_account_id
  service_principal = "config.amazonaws.com"
}

resource "aws_organizations_delegated_administrator" "config_multiaccountsetup" {
  account_id  = var.security_account_id
  service_principal = "config-multiaccountsetup.amazonaws.com"

  depends_on = [aws_organizations_delegated_administrator.config]
}

# ── Delegated Admin IAM ロール (Security Account で実行) ──────────────
resource "aws_iam_role" "org_config_role" {
  name= "OrgConfigDelegatedAdminRole"
  assume_role_policy = data.aws_iam_policy_document.config_assume.json
}

data "aws_iam_policy_document" "config_assume" {
  statement {
 actions = ["sts:AssumeRole"]
 principals {
type  = "Service"
identifiers = ["config.amazonaws.com"]
 }
  }
}

resource "aws_iam_role_policy_attachment" "org_config_admin" {
  role = aws_iam_role.org_config_role.name
  policy_arn = "arn:aws:iam::aws:policy/service-role/AWS_ConfigRole"
}

resource "aws_iam_role_policy_attachment" "org_config_multiaccountsetup" {
  role = aws_iam_role.org_config_role.name
  policy_arn = "arn:aws:iam::aws:policy/AWSConfigMultiAccountSetupPolicy"
}

コンソール確認: AWS Organizations → Services → AWS Config → Delegated administrators でセキュリティアカウント ID が表示されることを確認する。2 つのサービスプリンシパルが別行で登録されていなければ Organization Conformance Pack のデプロイが失敗する。

6-3. Organization Conformance Pack Terraform

Security Account（Delegated Admin）から 3 種の Organization Conformance Pack を一括デプロイする。excluded_accounts に除外アカウントを列挙することで段階的ロールアウトが可能だ。Pack 間でルールが重複する場合も aws_config_organization_conformance_pack は重複排除して適用するため、3 種同時デプロイで Rule 件数が単純加算されない点に注意する。

# ── Organization Conformance Pack: CIS AWS Foundations v1.4 ──────────
resource "aws_config_organization_conformance_pack" "cis_org" {
  name= "org-cis-aws-foundations"
  template_s3_uri = "s3://${var.config_bucket}/conformance-packs/cis-foundations.yaml"
  excluded_accounts = []

  input_parameter {
 parameter_name  = "AccessKeysRotatedParamMaxAccessKeyAge"
 parameter_value = "90"
  }

  input_parameter {
 parameter_name  = "IamPasswordPolicyParamMinimumPasswordLength"
 parameter_value = "14"
  }

  depends_on = [aws_organizations_delegated_administrator.config_multiaccountsetup]
}

# ── Organization Conformance Pack: AWS Foundational Security Best Practices
resource "aws_config_organization_conformance_pack" "aws_foundational_org" {
  name= "org-aws-foundational-security"
  template_s3_uri = "s3://${var.config_bucket}/conformance-packs/aws-foundational-security.yaml"
  excluded_accounts = []

  input_parameter {
 parameter_name  = "S3BucketVersioningEnabled"
 parameter_value = "true"
  }

  input_parameter {
 parameter_name  = "MfaEnabledForIamConsoleAccess"
 parameter_value = "true"
  }

  depends_on = [aws_organizations_delegated_administrator.config_multiaccountsetup]
}

# ── Organization Conformance Pack: PCI DSS v3.2.1 ────────────────────
resource "aws_config_organization_conformance_pack" "pci_dss_org" {
  name= "org-pci-dss-v321"
  template_s3_uri = "s3://${var.config_bucket}/conformance-packs/pci-dss-v321.yaml"
  excluded_accounts = [
 var.sandbox_account_id,# サンドボックスアカウントは PCI DSS 対象外
  ]

  input_parameter {
 parameter_name  = "CloudTrailCloudWatchLogsEnabled"
 parameter_value = "true"
  }

  input_parameter {
 parameter_name  = "LogGroupRetentionPeriodParamMinRetentionTime"
 parameter_value = "365"
  }

  depends_on = [aws_organizations_delegated_administrator.config_multiaccountsetup]
}

Pack のデプロイには Member Account 数に応じて数分〜数十分かかる。get-organization-conformance-pack-statuses で全アカウントが CREATE_SUCCESSFUL になるまで待機し、CREATE_FAILED アカウントが出た場合は IAM ロールの信頼ポリシーを確認する。

6-4. Cross-Region Aggregator Terraform

全リージョン・全アカウントのコンプライアンスデータを集約する Aggregator を定義する。organization_aggregation_source の all_regions = true で漏れなく収集でき、東京リージョン外に存在するリソースの NON_COMPLIANT も一元把握できる。

# ── Config Aggregator IAM ロール ──────────────────────────────────────
resource "aws_iam_role" "config_aggregator_role" {
  name= "ConfigAggregatorRole"
  assume_role_policy = data.aws_iam_policy_document.aggregator_assume.json
}

data "aws_iam_policy_document" "aggregator_assume" {
  statement {
 actions = ["sts:AssumeRole"]
 principals {
type  = "Service"
identifiers = ["config.amazonaws.com"]
 }
  }
}

resource "aws_iam_role_policy_attachment" "aggregator_role_policy" {
  role = aws_iam_role.config_aggregator_role.name
  policy_arn = "arn:aws:iam::aws:policy/service-role/AWSConfigRoleForOrganizations"
}

# ── Configuration Aggregator (全リージョン・全アカウント) ─────────────
resource "aws_config_configuration_aggregator" "org_aggregator" {
  name = "org-config-aggregator"

  organization_aggregation_source {
 all_regions = true
 role_arn = aws_iam_role.config_aggregator_role.arn
  }

  depends_on = [
 aws_organizations_delegated_administrator.config,
 aws_iam_role_policy_attachment.aggregator_role_policy,
  ]
}

Aggregator が有効化されると AWS Config コンソールの Aggregators ページで全アカウント・全リージョンのコンプライアンスサマリーが閲覧できる。コンプライアンス率グラフとアカウント別 NON_COMPLIANT カウントがダッシュボードとして機能する。

6-5. AWS CLI Organizations Config 確認

Delegated Admin 経由で Organization Conformance Pack の適用状態と集約コンプライアンスを確認する。

# Organization Conformance Pack 一覧確認
aws configservice describe-organization-conformance-packs \
  --region ap-northeast-1

# 全 Member Account でのデプロイ状態確認
# status が CREATE_SUCCESSFUL であることを確認
aws configservice get-organization-conformance-pack-statuses \
  --organization-conformance-pack-names org-cis-aws-foundations \
  --region ap-northeast-1

# PCI DSS Pack の詳細ステータス確認
aws configservice get-organization-conformance-pack-statuses \
  --organization-conformance-pack-names org-pci-dss-v321 \
  --region ap-northeast-1

# Aggregator 経由で NON_COMPLIANT リソースを横断検索
aws configservice get-aggregate-compliance-details-by-config-rule \
  --configuration-aggregator-name org-config-aggregator \
  --config-rule-name s3-bucket-public-read-prohibited \
  --compliance-type NON_COMPLIANT \
  --region ap-northeast-1

# アカウント別コンプライアンスサマリー取得
aws configservice get-aggregate-config-rule-compliance-summary \
  --configuration-aggregator-name org-config-aggregator \
  --group-by-key ACCOUNT_ID \
  --region ap-northeast-1

コンソール確認: AWS Config → Aggregators → org-config-aggregator → Accounts and Regions でデータ収集済みアカウント数を確認する。Authorized 状態でないアカウントは Delegated Admin の認可が不足している。

6-6. GitOps 連携 (Argo CD + Terraform)

Conformance Pack の設定変更は Terraform で IaC 管理し、Argo CD で GitOps フローに統合することで「コード変更 → PR → レビュー → Argo CD 自動デプロイ → 全 Member Account 一斉適用」の完全自動化が実現する。

本シリーズ EKS Vol3 ALB + Argo CD GitOps 完全運用編（WP:2241） で構築した Argo CD パイプラインに Conformance Pack Terraform モジュールを追加する構成が推奨だ。Argo CD の ApplicationSet + Cluster Generator を活用することで、複数の Organizations Member Account に対応した GitOps フローを一元管理できる。

# ── Argo CD Application (Conformance Pack Terraform モジュール) ───────
# EKS Vol3 (WP:2241) で構築した Argo CD クラスターに追加
resource "kubernetes_manifest" "conformance_pack_app" {
  manifest = {
 apiVersion = "argoproj.io/v1alpha1"
 kind = "Application"
 metadata = {
name= "conformance-pack-org"
namespace = "argocd"
 }
 spec = {
project = "security"
source = {
  repoURL  = var.gitops_repo_url
  targetRevision = "main"
  path  = "terraform/security/conformance-packs"
}
destination = {
  server = "https://kubernetes.default.svc"
  namespace = "argocd"
}
syncPolicy = {
  automated = {
 prune = true
 selfHeal = true
  }
}
 }
  }
}

Conformance Pack の template_s3_uri が参照する S3 バケットの YAML テンプレートも同一 Git リポジトリで管理し、aws s3 sync ステップを CI/CD パイプラインに組み込む。Rule 追加・パラメータ変更がすべて Pull Request 経由で審査・記録されるため、コンプライアンス基準の変更履歴が Git history として完全に残る。

7. 継続的コンプライアンス監視 + Athena 監査クエリ + コスト最適化

7-1. コンプライアンス監視の全体像

AWS Config の Recorder が記録した構成変更は S3 バケットに JSON Lines 形式で保存される。Athena でクエリを実行することで「どのリソースが・いつ・どのような変更を受けたか」を監査証跡として検索でき、CloudWatch Dashboard と組み合わせることで準拠率のリアルタイム可視化が実現する。

監視アーキテクチャ:

• Config Recorder → S3 (構成変更ログ + 定期スナップショット 24 時間毎)
• S3 → Athena (Glue Data Catalog 経由でスキーマ自動検出 / 手動 DDL でも可)
• Athena クエリ結果 → CloudWatch Dashboard / Amazon QuickSight
• Non-Compliant イベント → EventBridge → SNS アラート → 担当者通知

棚卸し運用サイクル:

7-2. Config ログを Athena で監査する

Config が S3 に配信するログは JSON Lines 形式で AWSLogs/{ACCOUNT_ID}/Config/{REGION}/{YYYY}/{MM}/{DD}/ のパス構造で保存される。Athena テーブルを作成することで SQL でコンプライアンス監査クエリを実行できる。

Athena テーブル作成 (CREATE TABLE DDL):

CREATE EXTERNAL TABLE IF NOT EXISTS aws_config_logs (
  fileversion STRING,
  configSnapshotId STRING,
  configurationItems ARRAY<STRUCT<
 configurationItemVersion: STRING,
 configurationItemCaptureTime: STRING,
 configurationStateId: BIGINT,
 awsAccountId: STRING,
 configurationItemStatus: STRING,
 resourceType: STRING,
 resourceId: STRING,
 resourceName: STRING,
 ARN: STRING,
 awsRegion: STRING,
 availabilityZone: STRING,
 configuration: STRING,
 tags: MAP<STRING, STRING>,
 resourceCreationTime: STRING
  >>
)
ROW FORMAT SERDE 'org.openx.data.jsonserde.JsonSerDe'
WITH SERDEPROPERTIES ('serialization.format' = '1')
LOCATION 's3://YOUR-CONFIG-BUCKET/AWSLogs/ACCOUNT-ID/Config/'
TBLPROPERTIES ('has_encrypted_data' = 'false');

テーブル作成後、MSCK REPAIR TABLE aws_config_logs; でパーティションを追加することで全期間のログを検索対象にできる。大規模環境では AWS Glue Crawler を使ってパーティションを自動更新する運用が推奨される。

Athena クエリ集 5 例:

クエリ 1 — 非準拠リソース一覧 (直近 7 日)

SELECT
  ci.awsAccountId,
  ci.awsRegion,
  ci.resourceType,
  ci.resourceId,
  ci.resourceName,
  ci.configurationItemCaptureTime
FROM aws_config_logs
CROSS JOIN UNNEST(configurationItems) AS t(ci)
WHERE ci.configurationItemStatus = 'OK'
  AND ci.configurationItemCaptureTime >= DATE_FORMAT(
 DATE_ADD('day', -7, NOW()), '%Y-%m-%dT%H:%i:%s'
  )
ORDER BY ci.configurationItemCaptureTime DESC
LIMIT 200;

クエリ 2 — リソース変更履歴 (特定バケット)

SELECT
  ci.configurationItemCaptureTime,
  ci.configurationItemStatus,
  ci.awsRegion,
  ci.resourceId,
  ci.configuration
FROM aws_config_logs
CROSS JOIN UNNEST(configurationItems) AS t(ci)
WHERE ci.resourceType = 'AWS::S3::Bucket'
  AND ci.resourceId = 'your-target-bucket-name'
ORDER BY ci.configurationItemCaptureTime DESC
LIMIT 50;

クエリ 3 — リソースタイプ別件数 (月次棚卸し)

SELECT
  ci.resourceType,
  ci.awsRegion,
  COUNT(*) AS resource_count
FROM aws_config_logs
CROSS JOIN UNNEST(configurationItems) AS t(ci)
WHERE ci.configurationItemCaptureTime >= DATE_FORMAT(
  DATE_ADD('month', -1, NOW()), '%Y-%m-%dT%H:%i:%s'
)
GROUP BY ci.resourceType, ci.awsRegion
ORDER BY resource_count DESC;

クエリ 4 — アカウント横断集計 (Organizations Aggregator 使用時)

SELECT
  ci.awsAccountId,
  ci.awsRegion,
  ci.resourceType,
  COUNT(*) AS resource_count
FROM aws_config_logs
CROSS JOIN UNNEST(configurationItems) AS t(ci)
WHERE ci.configurationItemCaptureTime >= DATE_FORMAT(
  DATE_ADD('day', -30, NOW()), '%Y-%m-%dT%H:%i:%s'
)
GROUP BY ci.awsAccountId, ci.awsRegion, ci.resourceType
ORDER BY ci.awsAccountId, resource_count DESC;

クエリ 5 — タグなしリソース TOP10 (コスト高リソース候補)

SELECT
  ci.resourceType,
  ci.resourceId,
  ci.resourceName,
  ci.awsRegion,
  ci.configurationItemCaptureTime
FROM aws_config_logs
CROSS JOIN UNNEST(configurationItems) AS t(ci)
WHERE cardinality(ci.tags) = 0
  AND ci.resourceType IN (
 'AWS::EC2::Instance',
 'AWS::RDS::DBInstance',
 'AWS::ElasticLoadBalancingV2::LoadBalancer',
 'AWS::EKS::Cluster',
 'AWS::Lambda::Function'
  )
  AND ci.configurationItemCaptureTime >= DATE_FORMAT(
 DATE_ADD('day', -7, NOW()), '%Y-%m-%dT%H:%i:%s'
  )
ORDER BY ci.configurationItemCaptureTime DESC
LIMIT 10;

7-3. CloudWatch Dashboard Terraform

resource "aws_cloudwatch_dashboard" "config_compliance" {
  dashboard_name = "config-compliance-dashboard"

  dashboard_body = jsonencode({
 widgets = [
{
  type= "metric"
  x= 0
  y= 0
  width  = 12
  height = 6
  properties = {
 title= "Config Rule 非準拠リソース数"
 view = "timeSeries"
 region  = var.aws_region
 metrics = [
["AWS/Config", "NonCompliantRuleCount", { stat = "Maximum", period = 300 }]
 ]
 yAxis = { left = { min = 0 } }
  }
},
{
  type= "metric"
  x= 12
  y= 0
  width  = 12
  height = 6
  properties = {
 title= "Conformance Pack 準拠率 (%)"
 view = "timeSeries"
 region  = var.aws_region
 metrics = [
["AWS/Config", "CompliancePercentage", { stat = "Average", period = 3600 }]
 ]
 yAxis = { left = { min = 0, max = 100 } }
  }
},
{
  type= "metric"
  x= 0
  y= 6
  width  = 24
  height = 6
  properties = {
 title= "Auto Remediation 実行 (SSM Automation)"
 view = "timeSeries"
 region  = var.aws_region
 metrics = [
["AWS/SSM", "AutomationSucceeded", { stat = "Sum", period = 3600 }],
["AWS/SSM", "AutomationFailed", { stat = "Sum", period = 3600 }]
 ]
  }
}
 ]
  })
}

resource "aws_cloudwatch_metric_alarm" "non_compliant_resources" {
  alarm_name = "config-non-compliant-resources-high"
  comparison_operator = "GreaterThanThreshold"
  evaluation_periods  = 1
  metric_name= "NonCompliantRuleCount"
  namespace  = "AWS/Config"
  period  = 300
  statistic  = "Maximum"
  threshold  = 10
  alarm_description= "非準拠リソース数が 10 件を超えました"
  alarm_actions = [aws_sns_topic.config_alerts.arn]
}

resource "aws_athena_workgroup" "config_audit" {
  name = "config-audit-workgroup"

  configuration {
 result_configuration {
output_location = "s3://${aws_s3_bucket.config_logs.bucket}/athena-results/"
encryption_configuration {
  encryption_option = "SSE_S3"
}
 }
  }
}

コンソール確認: CloudWatch → Dashboards → config-compliance-dashboard でコンプライアンス率グラフを確認する。NonCompliantRuleCount が 10 件を超えると SNS 経由でアラートが飛ぶ。

7-4. Recorder コスト試算 (1 アカウント / 月額)

AWS Config のコストは「記録された構成項目の件数」と「Conformance Pack 評価件数」で決まる。全リソースタイプを記録すると大規模環境では月数百ドルになるため、Resource Type 絞り込みがコスト最適化の最重要ポイントだ。

コスト試算表 (ap-northeast-1 / 2026 年 5 月時点):

コスト最適化: Recorder Resource Type 絞り込み:

resource "aws_config_configuration_recorder" "cost_optimized" {
  name  = "config-recorder"
  role_arn = aws_iam_role.config_role.arn

  recording_group {
 all_supported  = false  # 全リソース記録 OFF でコスト大幅削減
 include_global_resource_types = false

 resource_types = [
"AWS::IAM::Role",
"AWS::IAM::Policy",
"AWS::IAM::User",
"AWS::S3::Bucket",
"AWS::EC2::Instance",
"AWS::EC2::SecurityGroup",
"AWS::EC2::VPC",
"AWS::RDS::DBInstance",
"AWS::EKS::Cluster",
"AWS::Lambda::Function",
"AWS::CloudTrail::Trail",
 ]
  }
}

AWS CLI コスト・Recorder 状態確認:

# Recorder 記録状態確認
aws configservice describe-configuration-recorder-status

# 記録対象リソースタイプ確認
aws configservice describe-configuration-recorders \
  --query 'ConfigurationRecorders[*].recordingGroup'

# Conformance Pack 評価件数確認
aws configservice get-conformance-pack-compliance-summary \
  --conformance-pack-names cis-aws-foundations-benchmark-level-1 \
 aws-foundational-security-best-practices pci-dss-3-2-1

# 記録リソース件数カウント (リソースタイプ別)
aws configservice get-discovered-resource-counts \
  --resource-type AWS::EC2::Instance

観測性 Vol1 CloudWatch Logs Insights (WP:2252) との連携: Config 評価ログを CloudWatch Logs に転送し、Logs Insights で「特定 Rule の評価タイムライン」を追跡することで準拠状態の変化をリアルタイムに把握できる。

8. まとめ + セキュリティ 3 部作完結 + 12 巻シリーズ完結 + 落とし穴 10 選

本記事では AWS Config + Conformance Pack + Auto Remediation を Terraform で完全実装し、セキュリティ 3 部作の完結巻として「継続的コンプライアンス + 自動修復」運用ループを確立した。最後に本番運用でよくある落とし穴と全体サマリーを整理する。

8-1. 落とし穴 10 選

① Recorder の all_supported=true によるコスト爆発
全リソースタイプを記録すると大規模環境で月数百ドルのコストが発生する。all_supported = false で必要な Resource Type のみを明示指定することが必須だ。

② Delivery Channel の S3 バケットポリシー不備
Config が S3 に書き込めないと CI 配信がサイレント失敗する。config.amazonaws.com に s3:GetBucketAcl と s3:PutObject を付与したバケットポリシーが必要だ。

③ recorder_status リソースの分離定義忘れ
aws_config_configuration_recorder を作成しただけでは記録が始まらない。aws_config_configuration_recorder_status リソースを必ず別途定義し is_enabled = true にすること。

④ Custom Lambda Rule の PutEvaluations 権限不足
カスタムルールの Lambda が config:PutEvaluations 権限を持たないと評価結果を返せず、ルールが INSUFFICIENT_DATA のまま停止する。

⑤ Auto Remediation の無限ループ
Remediation 後も Rule が COMPLIANT と評価されない場合、maximum_automatic_attempts に達するまで修復が繰り返される。Remediation 前に Rule の評価ロジックを必ず検証すること。

⑥ Conformance Pack の Parameter 名ミスマッチ
template_body 内の Parameters セクションと input_parameter ブロックの名前が一致しないと ParameterValueNotFound エラーが発生する。大文字小文字の差異でも失敗する。

⑦ Organization Conformance Pack の excluded_accounts 未設定
excluded_accounts = [] のまま全組織に Pack を適用すると、開発・Sandbox アカウントにも本番相当の Pack が適用される。除外対象は必ず明示指定すること。

⑧ Delegated Admin の 2 サービスプリンシパル設定漏れ
config.amazonaws.com のみ設定して config-multiaccountsetup.amazonaws.com を忘れると Organization Conformance Pack のデプロイが失敗する。2 つセットで登録すること。

⑨ Cross-Region Aggregator の AWSConfigRoleForOrganizations 権限不足
Aggregator IAM ロールに AWSConfigRoleForOrganizations ポリシーがないと他アカウントのデータ収集が失敗し、集計データが部分的になる。

⑩ Athena テーブルのパーティション更新忘れ
Config ログの S3 パスは日付階層構造だが、Athena テーブル作成後にパーティションを追加しないとフルスキャンになりコストが上昇する。MSCK REPAIR TABLE aws_config_logs; を定期実行すること。

8-2. Terraform 早見表

AWS CLI 早見表:

# 全 Config Rule 準拠状況確認
aws configservice get-compliance-summary-by-config-rule

# 特定ルールの非準拠リソース一覧
aws configservice get-compliance-details-by-config-rule \
  --config-rule-name s3-bucket-public-read-prohibited \
  --compliance-types NON_COMPLIANT

# Conformance Pack 準拠サマリー
aws configservice get-conformance-pack-compliance-summary \
  --conformance-pack-names cis-aws-foundations-benchmark-level-1

# Organization Conformance Pack ステータス
aws configservice get-organization-conformance-pack-statuses \
  --organization-conformance-pack-names org-cis-aws-foundations

# Aggregator 経由 NON_COMPLIANT 横断検索
aws configservice get-aggregate-compliance-details-by-config-rule \
  --configuration-aggregator-name org-config-aggregator \
  --config-rule-name s3-bucket-public-read-prohibited \
  --compliance-type NON_COMPLIANT

8-3. 本記事でマスターした実装内容

本記事で Terraform 完全実装した内容と検証コマンドのサマリーを示す。セキュリティ 3 部作 Vol1 (GuardDuty 検知) + Vol2 (IAM 統制) + Vol3 (Config 準拠) が揃うことで AWS セキュリティの「検知 → 統制 → 準拠」3 層防御が完成する。

次の改善サイクルとして、Conformance Pack の評価結果を 観測性 Vol3 Application Signals + SLO (WP:2315) で定義したコンプライアンス SLO と連携させることで、「準拠率の SLO 化 + Burn Rate アラート」へと発展させることができる。

→ Vol1 GuardDuty + Security Hub: セキュリティ 3 部作の起点から読む

8-4. 最後に

本記事は Lambda / EKS / 観測性 / セキュリティの 4 シリーズ × 3 巻で構成された 12 巻 AWS 本番運用シリーズの完結巻だ。

AWS Config + Conformance Pack + Auto Remediation の三位一体実装により「設定変更を即座に検知 → 準拠基準で評価 → 非準拠なら自動修復」という運用ループが自律稼働する。GuardDuty の検知層、IAM Identity Center の統制層、そして本記事の準拠層が揃ったとき、AWS 環境のセキュリティは受動的な防衛から能動的なコンプライアンス保証へと進化する。

12 巻完結。次の課題は「セキュリティ SIEM 統合 (Amazon Security Lake + OpenSearch) と AI/ML 異常検知」だ。