Config — ルール評価・適合パック・自動修復 | AWS SCS-C03 徹底講義

はじめに：AWS Configの本質

AWS Configはリソース構成の継続的な記録と評価のサービスです。試験ではしばしば CloudTrail と混同されますが、根本的に異なります：

CloudTrail: 誰が何をしたか（API呼び出し）を記録
AWS Config: リソースの状態はどうか（設定値）を評価・追跡

SCS-C03では、単なる記録機能ではなく、ルール設計・組織レベルでの監視・自動修復パイプラインが狙われます。

AWS Config ルール評価フロー

Loading diagram...

AWS Config 自動修復パイプライン

Loading diagram...

AWS Config Rules マネジメントコンソール画面

AWS Config Rules の評価結果

1. 構成レコーダーと基本的な仕組み

1.1 構成レコーダー（Configuration Recorder）の役割

構成レコーダーは AWS Config の最も基本的なコンポーネントです。以下の処理を行います：

リソース変更の検出
- AWS API による変更を常に監視
- サポート対象のリソース種別（EC2, RDS, S3, IAM, VPC等）をキャプチャ
スナップショット取得
- 変更検出時に構成スナップショットを記録
- 指定されたS3バケットに JSON形式で保存
タイムライン管理
- リソースの過去の状態をすべて保持
- 問題発生時に「いつ何が変わったか」を追跡可能

1.2 記録対象リソースの選択（重要な試験出題ポイント）

構成レコーダーの設定オプション：

# パターン1: すべてのサポート対象リソースを記録
recordingGroup:
  allSupported: true

# パターン2: 特定リソースタイプのみ記録（コスト削減）
recordingGroup:
  includeGlobalResources: true  # IAM, CloudFront, Route53等
  resourceTypes:
    - AWS::EC2::Instance
    - AWS::RDS::DBInstance
    - AWS::S3::Bucket

# パターン3: グローバルリソースを除外（複数リージョンで重複回避）
recordingGroup:
  allSupported: true
  includeGlobalResources: false
  # 主アカウント（マスターアカウント）のみで記録

最適実装：

本番環境: allSupported: true + includeGlobalResources: true（本アカウントでのみ）
コスト重視: 特定リソースタイプに絞る
マルチアカウント: グローバルリソースの重複記録を避ける

1.3 変更検出メカニズム

検出方法	特徴	レイテンシ
変更トリガー	EventBridge統合、AWS API呼び出しで即座に検出	数秒以内
定期評価	デフォルト24時間ごと（設定可能）	数分～24時間
CloudTrail統合	API履歴から構成変更を遡及記録	リアルタイム + 履歴

2. Config Rules の詳細設計

2.1 マネージドルール（Managed Rules）

AWS が提供するプリセットルール。~200以上存在し、即座にデプロイ可能です。

代表的なマネージドルール

セキュリティグループ関連

restricted-ssh — ポート22の全開放を検出
restricted-common-ports — 危険なポート(RDP, TELNET等)の開放を検出
vpc-flow-logs-enabled — VPC Flow Logs有効化を強制

暗号化関連

encrypted-volumes — 暗号化されていないEBSボリュームを検出
s3-bucket-server-side-encryption-enabled — S3デフォルト暗号化を強制
rds-encryption-enabled — RDS暗号化有効化を確認

IAM関連

iam-policy-no-statements-with-admin-access — 管理者権限ポリシーを検出
root-account-mfa-enabled — ルートアカウントMFAを確認
iam-user-unused-credentials-check — 未使用のアクセスキーを検出

リソース設定

ec2-instance-managed-by-systems-manager — SSM Agentの登録を確認
required-tags — 必須タグの有無を確認

マネージドルールの制約

制限事項

ソースコード非公開 — カスタマイズ不可
判定ロジックが固定 — 設定パラメータで部分的に調整可能
新しいリソース種別への対応に遅延あり — 最新リソースタイプに即対応不可

2.2 カスタムルール（Custom Rules）

マネージドルールでは対応できない要件に対応します。

パターンA: Lambda ベースのカスタムルール

# Lambda 関数（Python 3.11）
import json
import boto3

def lambda_handler(event, context):
    """
    S3バケットが特定のタグを持つかを評価
    """
    config = boto3.client('config')
    config_item = json.loads(event['configurationItem'])
    
    # リソースタイプチェック
    if config_item['resourceType'] != 'AWS::S3::Bucket':
        return {
            'compliance': 'NOT_APPLICABLE',
            'annotation': 'Not an S3 bucket'
        }
    
    bucket_name = config_item['resourceName']
    s3 = boto3.client('s3')
    
    try:
        # タグ取得
        tags_response = s3.get_bucket_tagging(Bucket=bucket_name)
        tags = {t['Key']: t['Value'] for t in tags_response.get('TagSet', [])}
        
        # 必須タグの確認
        required_tags = {'Environment', 'Owner', 'CostCenter'}
        missing = required_tags - set(tags.keys())
        
        if missing:
            return {
                'compliance': 'NON_COMPLIANT',
                'annotation': f'Missing tags: {", ".join(missing)}'
            }
        else:
            return {
                'compliance': 'COMPLIANT',
                'annotation': 'All required tags present'
            }
    
    except Exception as e:
        return {
            'compliance': 'NON_COMPLIANT',
            'annotation': f'Error evaluating rule: {str(e)}'
        }

Lambda ルールの特徴：

完全なカスタマイズ可能
Python, Java, JavaScript サポート
初回評価 + 変更トリガー時の継続評価

パターンB: AWS Config Guard（DSL ベース）

Guard は YAML 風の DSL で、JSON スキーマを評価します。Lambda よりシンプル：

# guard-lib.guard
# EC2インスタンスの詳細監視が有効であることを確認

rule ec2_detailed_monitoring {
  aws_ec2_instance {
    monitoring {
      enabled == true
    }
  }
}

rule ebs_encryption_enabled {
  aws_ec2_volume {
    encrypted == true
  }
}

# 複数ルールを組み合わせる
rule all_ec2_security_checks {
  check( ec2_detailed_monitoring ) <<
    EC2インスタンスでは詳細監視が必須です
  >>
  
  check( ebs_encryption_enabled ) <<
    すべてのEBSボリュームは暗号化が必須です
  >>
}

Guard の利点：

Lambda より低レイテンシ
バージョン管理・可視性が高い
複雑なビジネスロジックには不向き

2.3 ルール評価の仕組み

1. 変更トリガー（推奨）

AWS API 呼び出し → EventBridge キャプチャ → Config ルール評価（数秒以内） → 結果：COMPLIANT / NON_COMPLIANT

2. 定期評価（デフォルト）

スケジュール（24時間など） → すべての対象リソースを再評価 → 更新検出

試験で狙われるポイント：

変更トリガーは即座だが、定期評価と同時に実行可能
定期評価のみの設定でコスト削減可能（ただし検出遅延あり）
新しいリソース作成時は自動的に評価対象になる

3. 適合パック（Conformance Packs）

適合パックは、複数のルールをグループ化し、業界標準に沿ったコンプライアンス要件を一括適用するものです。

3.1 適合パックの構造

# conformance-pack-template.yaml
AWSTemplateFormatVersion: "2010-09-09"
Description: "CIS AWS Foundations Benchmark 適合パック"

Parameters:
  RequiredTagKey:
    Type: String
    Default: "Environment"
    Description: "必須タグキー"

Resources:
  # ルール1: EC2 詳細監視
  EC2DetailedMonitoringRule:
    Type: AWS::Config::ConfigRule
    Properties:
      ConfigRuleName: ec2-detailed-monitoring
      Description: "EC2インスタンスで詳細監視が有効であることを確認"
      Source:
        Owner: AWS
        SourceIdentifier: EC2_DETAILED_MONITORING_ENABLED
      Scope:
        ComplianceResourceTypes:
          - AWS::EC2::Instance

  # ルール2: 必須タグの確認
  RequiredTagsRule:
    Type: AWS::Config::ConfigRule
    Properties:
      ConfigRuleName: required-tags-rule
      Description: "すべてのタグ付けリソースに必須タグがあることを確認"
      Source:
        Owner: AWS
        SourceIdentifier: REQUIRED_TAGS
      InputParameters:
        tagKeys: !Ref RequiredTagKey

  # ルール3: CloudTrail 有効化
  CloudTrailEnabledRule:
    Type: AWS::Config::ConfigRule
    Properties:
      ConfigRuleName: cloudtrail-enabled
      Source:
        Owner: AWS
        SourceIdentifier: CLOUD_TRAIL_ENABLED
      MaximumExecutionFrequency: Six_Hours  # 定期評価間隔

  # ルール4: CloudWatch ログ設定
  CloudWatchLogsEnabledRule:
    Type: AWS::Config::ConfigRule
    Properties:
      ConfigRuleName: cloudtrail-cloudwatch-logs-enabled
      Source:
        Owner: AWS
        SourceIdentifier: CLOUD_TRAIL_CLOUD_WATCH_LOGS_ENABLED

Outputs:
  ConformancePackArn:
    Description: "適合パックの ARN"
    Value: !GetAtt MyConformancePack.ConformancePackArn

3.2 組み込み適合パックテンプレート

AWS は以下のテンプレートを提供しています：

テンプレート	対象基準	用途
CIS AWS Foundations	CIS ベンチマーク	基本的なセキュリティ
PCI DSS 3.2.1	PCI-DSS	決済カード処理
HIPAA Security	HIPAA	医療情報保護
SOC 2	SOC 2 Type II	IT監査
NIST Cybersecurity Framework	NIST CSF	米国標準

適合パックのメリット

1. 業界基準への準拠が簡単

テンプレート適用するだけで複数ルールをデプロイ
コンプライアンス証明に活用可能

2. ルール間の依存性管理

関連ルールが一括評価
相互矛盾のないルールセット

3. バージョン管理

適合パックテンプレートを Git 管理
規制要件の更新時に容易に対応

適合パック評価の流れ

テンプレートをアップロード
AWS Config が CloudFormation スタック作成
ルール群が一括作成・配置
すべてのリソースが包括的に評価
ダッシュボードで準拠率を可視化

4. 組織Config（Organization Config Rules）

4.1 単一アカウント vs 組織ルール

項目	単一アカウント	組織ルール
スコープ	1アカウント、複数リージョン	全アカウント、複数リージョン
設定箇所	各アカウントで個別設定	マスターアカウントで一括設定
継承	なし	配下アカウントに自動適用
ルール数制限	アカウントあたり 150	組織あたり 500
コスト	高（重複記録）	低（集約）

4.2 組織Config の有効化

# AWS CLI: 組織Config の有効化
# 前提: AWS Organizations が有効、マスターアカウントで実行

aws configservice put-organization-config-status \
  --organization-config-enabled \
  --organization-config-status ENABLED

# 委任管理アカウントの指定（オプション）
aws organizations register-delegated-administrator \
  --account-id 123456789012 \
  --service-principal config.amazonaws.com

# 組織ルールの作成
aws configservice put-organization-config-rule \
  --organization-config-rule-name "required-tags-org" \
  --organization-managed-rule-metadata \
    SourceIdentifier=REQUIRED_TAGS,\
    Description="All resources must have required tags",\
    InputParameters='{"tagKeys":"Environment,Owner"}'

4.3 組織適合パック

# 組織レベルで適合パックをデプロイ
aws configservice put-organization-conformance-pack \
  --organization-conformance-pack-name "cis-benchmark-org" \
  --template-s3-uri "s3://my-config-bucket/cis-conformance-pack.yaml" \
  --delivery-s3-bucket "my-config-bucket" \
  --delivery-s3-key-prefix "conformance-packs/" \
  --excluded-accounts "111111111111,222222222222"  # 除外アカウント

重要：

除外アカウントの指定でネストされたアカウント構造に対応
ルール失敗時の通知を SNS で受け取り可能
Organizations ツリー内の OU レベルでの制御も可能

5. アグリゲータ（Aggregator）

5.1 マルチアカウント・マルチリージョン集約

AWS Config の最大の制約は、単一アカウント・単一リージョンの Config データしか見えないことです。複数アカウント・リージョンで一括管理する場合、アグリゲータを使います。

単一アカウント Config 各アカウント・各リージョンの Config Data は独立して存在し、クロスアカウント・クロスリージョンでの統一的な可視化ができません。

アグリゲータで集約 全アカウント + 全リージョンのConfig データを集約し、単一ダッシュボードで可視化できるようになります：

全体の適合率
非準拠リソースの一覧

5.2 アグリゲータの設定パターン

パターン1: 自アカウント内の集約（シンプル）

# 集約リージョン（通常 us-east-1）で実行
aws configservice put-configuration-aggregator \
  --configuration-aggregator-name "single-account-aggregator" \
  --account-aggregation-sources \
    AccountIds=123456789012,\
    AllAwsRegions=true

パターン2: マルチアカウント集約（推奨）

# マスターアカウント（または委任管理アカウント）の us-east-1 で実行

aws configservice put-configuration-aggregator \
  --configuration-aggregator-name "organization-aggregator" \
  --organization-aggregation-sources \
    AllAwsRegions=true,\
    RoleArn=arn:aws:iam::123456789012:role/AWSConfigOrganizationRole,\
    AwsOrganizationRoleArn=arn:aws:iam::org-root:role/service-linked-role

# IAM ロール設定（重要）
cat > trust-policy.json << 'EOF'
{
  "Version": "2012-10-17",
  "Statement": [
    {
      "Effect": "Allow",
      "Principal": {
        "Service": "config.amazonaws.com"
      },
      "Action": "sts:AssumeRole"
    }
  ]
}
EOF

aws iam create-role \
  --role-name AWSConfigOrganizationRole \
  --assume-role-policy-document file://trust-policy.json

aws iam attach-role-policy \
  --role-name AWSConfigOrganizationRole \
  --policy-arn arn:aws:iam::aws:policy/service-role/AWSConfigRoleForOrganizations

5.3 アグリゲータからのクエリ

# 全アカウント・全リージョンの EC2 インスタンス一覧
aws configservice get-aggregate-discovered-resources-count \
  --configuration-aggregator-name "organization-aggregator" \
  --filters '{"ResourceType":"AWS::EC2::Instance"}'

# 特定リージョンでの非準拠リソース一覧
aws configservice get-aggregate-compliance-details-by-config-rule \
  --configuration-aggregator-name "organization-aggregator" \
  --config-rule-name "restricted-ssh" \
  --account-id 123456789012 \
  --aws-region us-east-1 \
  --compliance-type NON_COMPLIANT

6. 自動修復（Remediation）

非準拠リソースを自動的に修復するパイプライン。AWS Systems Manager (SSM) Automation と統合します。

6.1 修復アクションの仕組み

リソース変更 → Config ルール評価 → NON_COMPLIANT 判定 → SNS 通知（オプション） → 自動修復トリガー → SSM Automation ドキュメント実行 → リソース修正 → 再評価

6.2 修復アクション設定例

例1: セキュリティグループの自動修復（非準拠ルール削除）

# Config ルール: 22 番ポートの全開放を検出
aws configservice put-config-rule \
  --config-rule \
    ConfigRuleName=restricted-ssh,\
    Source='Owner=AWS,SourceIdentifier=RESTRICTED_INCOMING_TRAFFIC,\
SourceDetails=[{EventSource=config.amazonaws.com,\
MessageType=ConfigurationItemChangeNotification}]',\
    Scope='ComplianceResourceTypes=["AWS::EC2::SecurityGroup"]',\
    InputParameters='{"REQUIRED_PERMISSION":"tcp:22:22:0.0.0.0/0"}'

# SSM Automation ドキュメント（修復スクリプト）
cat > remediate-sg.json << 'EOF'
{
  "schemaVersion": "0.3",
  "description": "セキュリティグループから SSH ルールを削除",
  "assumeRole": "{{ AutomationAssumeRole }}",
  "parameters": {
    "SecurityGroupId": {
      "type": "String",
      "description": "修復対象のセキュリティグループ ID"
    },
    "AutomationAssumeRole": {
      "type": "String",
      "description": "SSM が使用する IAM ロール"
    }
  },
  "mainSteps": [
    {
      "name": "RevokeSshIngress",
      "action": "aws:executeAwsApi",
      "properties": {
        "Service": "ec2",
        "Api": "RevokeSecurityGroupIngress",
        "GroupId": "{{ SecurityGroupId }}",
        "IpPermissions": [
          {
            "IpProtocol": "tcp",
            "FromPort": 22,
            "ToPort": 22,
            "IpRanges": [{"CidrIp": "0.0.0.0/0"}]
          }
        ]
      }
    }
  ]
}
EOF

# 修復アクション登録
aws configservice put-remediation-configurations \
  --remediation-configurations \
    ConfigRuleName=restricted-ssh,\
    TargetType=SSM_DOCUMENT,\
    TargetIdentifier=AWS-PubliclyExposedSecurityGroupRemediation,\
    TargetVersion=1,\
    Parameters='{"GroupId":{"ResourceValue":{"Value":"RESOURCE_ID"}},\
"AutomationAssumeRole":{"StaticValue":{"Values":["arn:aws:iam::123456789012:role/SSMAutomationRole"]}}}',\
    Automatic=true,\
    MaximumAutomaticAttempts=5,\
    AutomaticRetryAttempts=3

例2: EBS ボリューム暗号化の強制（スナップショットから再作成）

# Config ルール
aws configservice put-config-rule \
  --config-rule \
    ConfigRuleName=encrypted-volumes,\
    Source='Owner=AWS,SourceIdentifier=ENCRYPTED_VOLUMES'

# SSM Automation ドキュメント（暗号化ボリューム再作成）
cat > remediate-ebs-encryption.json << 'EOF'
{
  "schemaVersion": "0.3",
  "description": "非暗号化 EBS ボリュームを暗号化して再作成",
  "assumeRole": "{{ AutomationAssumeRole }}",
  "parameters": {
    "VolumeId": {
      "type": "String"
    },
    "AutomationAssumeRole": {
      "type": "String"
    }
  },
  "mainSteps": [
    {
      "name": "CreateSnapshot",
      "action": "aws:executeAwsApi",
      "properties": {
        "Service": "ec2",
        "Api": "CreateSnapshot",
        "VolumeId": "{{ VolumeId }}"
      },
      "outputs": [{
        "Name": "SnapshotId",
        "Selector": "$.SnapshotId",
        "Type": "String"
      }]
    },
    {
      "name": "WaitForSnapshot",
      "action": "aws:waitForAwsResourceProperty",
      "properties": {
        "Service": "ec2",
        "Api": "DescribeSnapshots",
        "SnapshotIds": ["{{ CreateSnapshot.SnapshotId }}"],
        "PropertySelector": "$.Snapshots[0].State",
        "DesiredValues": ["completed"]
      }
    },
    {
      "name": "CreateEncryptedVolume",
      "action": "aws:executeAwsApi",
      "properties": {
        "Service": "ec2",
        "Api": "CreateVolume",
        "SnapshotId": "{{ CreateSnapshot.SnapshotId }}",
        "AvailabilityZone": "us-east-1a",
        "Encrypted": true
      }
    }
  ]
}
EOF

# 修復アクション登録（手動確認ステップ付き）
aws configservice put-remediation-configurations \
  --remediation-configurations \
    ConfigRuleName=encrypted-volumes,\
    TargetType=SSM_DOCUMENT,\
    TargetIdentifier=remediate-ebs-encryption,\
    Automatic=false,\
    MaximumAutomaticAttempts=3,\
    AutomaticRetryAttempts=5

6.3 修復アクション設計のベストプラクティス

段階1: 検証・テスト段階

Automatic = false（手動トリガー）
修復実行前にレビュー
テストアカウントで試行

段階2: 段階的導入

非本番環境で Automatic = true
CloudWatch ログで監視
SNS 通知で追跡

段階3: 本番展開

MaximumAutomaticAttempts = 3（最大試行回数）
AutomaticRetryAttempts = 5（リトライ時間：分）
修復失敗時は SNS で通知
修復結果を定期レポート

重要な注意

破壊的修復（削除など）は Automatic=false 必須
修復対象リソースが複数の場合、段階的な処理を検討
修復実行ロールに最小権限付与（過剰権限は禁止）

7. AWS Config Query（高度なクエリ機能）

7.1 SQL 構文での構成検索

AWS Config Query は、すべてのリソース構成データに対して SQL クエリを実行できます。

-- 例1: 非暗号化の RDS インスタンスを検索
SELECT
  resourceId,
  resourceType,
  configuration.storageEncrypted,
  configuration.engine,
  accountId,
  awsRegion
FROM
  aws_rds_dbinstance
WHERE
  configuration.storageEncrypted = false
  AND configuration.engine = 'mysql'
ORDER BY
  accountId, awsRegion;

-- 例2: 特定タグがないすべてのリソース
SELECT
  resourceId,
  resourceType,
  tags
FROM
  aws_generic_resource
WHERE
  tags.Environment IS NULL
  AND resourceType IN ('AWS::EC2::Instance', 'AWS::S3::Bucket')
ORDER BY
  resourceType;

-- 例3: セキュリティグループで複数のインバウンドルール持つものを特定
SELECT
  resourceId,
  configuration.groupId,
  configuration.ingressRules
FROM
  aws_ec2_securitygroup
WHERE
  length(configuration.ingressRules) > 5
  AND accountId = '123456789012'
  AND awsRegion = 'us-east-1';

-- 例4: リレーショナルクエリ（EC2 + セキュリティグループ）
SELECT
  i.resourceId AS instance_id,
  i.configuration.instanceType,
  sg.configuration.groupName,
  sg.configuration.ingressRules
FROM
  aws_ec2_instance i,
  aws_ec2_securitygroup sg
WHERE
  i.relationships.securityGroupId = sg.resourceId
  AND sg.configuration.ingressRules[0].cidrIp = '0.0.0.0/0';

7.2 集計クエリ

-- 例1: リソースタイプ別の集計
SELECT
  resourceType,
  count(*) AS total_count
FROM
  aws_generic_resource
GROUP BY
  resourceType
ORDER BY
  total_count DESC;

-- 例2: 非準拠ルール別の問題カウント
SELECT
  configRuleName,
  complianceType,
  count(*) AS count
FROM
  aws_config_rules
WHERE
  complianceType = 'NON_COMPLIANT'
GROUP BY
  configRuleName, complianceType
ORDER BY
  count DESC;

-- 例3: アカウント・リージョン別の準拠状況
SELECT
  accountId,
  awsRegion,
  count(*) AS total_resources,
  sum(CASE WHEN complianceType = 'COMPLIANT' THEN 1 ELSE 0 END) AS compliant_count
FROM
  aws_generic_resource
GROUP BY
  accountId, awsRegion
ORDER BY
  accountId, awsRegion;

7.3 試験で狙われるポイント

1. アグリゲータ必須

単一アカウントでは自アカウント+現在のリージョンのみ
マルチアカウント/リージョン検索にはアグリゲータが必要

2. JOIN の制限

aws_generic_resource テーブルでリレーショナル検索可能
ただしパフォーマンスは構成アイテム数に依存

3. 実行ロール

“config:GetResourceConfig” 権限が必須
“config:ListAggregateDiscoveredResources” でアグリゲータ経由

8. できないこと・制約

8.1 リアルタイム性の制約

一般的な誤解 「Config ルールはリアルタイムに評価される」

現実

変更トリガー: 数秒～数分（EventBridge 経由なので即座だが完全保証なし）
定期評価: 最大 24 時間
履歴記録: API 呼び出しから Config 反映まで若干の遅延

重要秒単位の応答が必要な場合は EventBridge 直結が必須。Config ルールは「監視・継続的評価」向き、リアルタイム検知向きではありません。

8.2 ルール数・リソース数の制限

制限項目	上限値	超過時の対応
単一アカウントの Config ルール数	150	AWS サポートに増加申請
組織ルール数	500	複数の適合パックに分割
Config ルール当たりの評価時間	15 分	複雑なカスタムルールは改善必須
構成レコーダー（アカウント当たり）	1 個	不可変（複数リージョンをカバー）

8.3 コスト関連の制約

Config の課金体系（2026年4月時点）:

1) 構成アイテムの記録: $0.003/アイテム/月
   - サポート対象リソース（EC2, RDS, S3等）をすべて記録時の見積例
   - 小規模環境（100リソース）: ~$0.30/月
   - 大規模環境（10000リソース）: ~$30/月

2) Config ルールの評価: $0.001/ルール評価/月
   - 150 ルール × 24 評価/日（毎時） = ~$108/月

3) アグリゲータ: $0.5/集約/月
   - マルチアカウント集約が必須な場合は必須コスト

最適化戦略:
  ├─ すべてのリソース記録よりも「必須リソースのみ」
  ├─ 定期評価は 12 時間間隔に（24 時間の 2 倍評価回数削減）
  └─ ルール数は 100～150 程度に厳選（業界基準テンプレ活用）

非本番環境：
  ├─ 構成レコーダー OFF で記録コスト削減
  ├─ ルール評価は定期ジョブで限定
  └─ アグリゲータ未使用

8.4 データ保持期間の制限

Config 履歴保持期間：設定可能（デフォルト: 無制限、ただしコスト増）

推奨設定

本番環境: 無制限（コンプライアンス要件）
非本番環境: 90 日～180 日（コスト + セキュリティ・バランス）

S3 ライフサイクル設定

Glacier 移行: 1 年後
削除: 7 年後（監査証跡要件に応じて）

8.5 サービスの依存性

1. IAM ロール

リソース読み取り権限が必須
不足時は「リソース検出失敗」エラー

2. CloudTrail（オプションだが推奨）

履歴トレース機能を有効化
「誰が変更したか」を追跡（Config のみでは不可）

3. S3 バケット（設定スナップショット保存先）

バージョニング必須（推奨）
過度なアクセス制限で Config の書き込み失敗

4. SNS トピック（通知用）

非準拠通知のデリバリ先
トピックポリシーで config.amazonaws.com 許可必須

5. Systems Manager（修復時）

Automation ドキュメント実行用
IAM ロール信頼ポリシーに SSM サービスを追加

9. 連携パターン

9.1 Config + Security Hub

Security Hub の統合

AWS Config → Security Hub に同期 → Security Hub ダッシュボード表示

Security Hub ダッシュボード

Config ルール評価結果を「検出事項」として表示
セキュリティスコア算出に反映
他セキュリティサービス（GuardDuty等）と統合表示

セキュリティチーム統一運用

Security Hub が「セキュリティ全体の窓」
Config ルール結果もここで可視化

設定例：

# Security Hub で Config 統合を有効化
aws securityhub enable-security-hub \
  --tags '{"Environment":"Production"}'

# Config ルール結果を Security Hub に送信（自動）
aws configservice put-config-rule \
  --config-rule \
    ConfigRuleName=my-rule,\
    Source='Owner=AWS,...'

9.2 Config + CloudTrail

役割分担

CloudTrail: 「誰が」「いつ」「何を」（API レベル）
Config: 「その結果、リソースはどうなったか」（構成レベル）

組み合わせ活用

CloudTrail: IAM ユーザーが SecurityGroup を修正した API ログ
Config: その修正によって SecurityGroup の構成が変わった記録
連動: 修正の因果関係を追跡可能

例：EC2 セキュリティグループ変更の完全追跡

# 1. CloudTrail で API 呼び出しを検出
aws cloudtrail lookup-events \
  --lookup-attributes AttributeKey=ResourceType,AttributeValue=AWS::EC2::SecurityGroup \
  --max-results 10

# 2. Config でその時点の構成を確認
aws configservice get-config-item-history \
  --configuration-item-identifier \
    ConfigurationItemId=sg-12345,\
    ResourceType=AWS::EC2::SecurityGroup \
  --chronological-order REVERSE \
  --max-results 5

# 3. リレーション: 「この API 呼び出しによってこの構成変化が生じた」を確認

9.3 Config + Systems Manager

自動修復パイプライン

Config ルール（評価） → NON_COMPLIANT 検出 → 修復アクション → Systems Manager Automation ドキュメント実行 → リソース修正 → Config ルール再実行 → COMPLIANT 確認

9.4 Config + Organizations

階層的なガバナンス

組織レベル（マスターアカウント）で組織 Config ルール設定と組織適合パックをデプロイ → 配下アカウントに自動継承（ルール自動適用、準拠状況を親に報告）

メリット

統一されたセキュリティポリシー
設定漏れがない（自動適用）
除外アカウント設定で柔軟性確保

9.5 Config + EventBridge

イベント駆動のアクション

Config ルール評価結果 → EventBridge イベント生成 → NON_COMPLIANT ルール検出 → 複数ターゲットへ並行実行

並行実行ターゲット

Lambda: カスタム修復ロジック
SNS: メール/Slack 通知
SQS: 修復ジョブキュー
Systems Manager: 自動修復実行

統一的なアクション管理が可能になります。

10. ベストプラクティス

10.1 全リソース記録の推奨

構成レコーダー設定:

production:
  allSupported: true
  includeGlobalResources: true  # IAM, CloudFront 等
  recordingGroup:
    resourceTypes:
      - AWS::EC2::*               # EC2 全リソース
      - AWS::RDS::*               # RDS 全リソース
      - AWS::S3::*                # S3 全リソース
      - AWS::IAM::*               # IAM 全リソース
      - AWS::CloudTrail::*        # CloudTrail 監視

理由:
  1. 予期しない変更の追跡が容易
  2. コンプライアンス監査で必須
  3. インシデント調査時に情報不足が起こらない
  4. AWS の新リソース種別対応も自動追加

コスト:
  - 大規模環境（10000リソース以上）でも月数百円程度
  - 節約の価値がない

10.2 組織ルール活用による統一化

戦略

本社（マスターアカウント）:

CIS Benchmark 適合パック配置
すべてのセキュリティルール統一
除外アカウント明示（開発環境など）

支社・子会社アカウント:

親ルールを自動継承
ローカルルールのみ追加可能
準拠状況を親に自動報告

利点

セキュリティポリシーの統一と実装
アカウント追加時も自動的に適用
コンプライアンス効率化

10.3 自動修復の段階的導入

フェーズ1: 検証（テスト環境、本番の小規模機能）

Automatic = false
手動トリガー
修復結果を記録・確認
副作用チェック（最低 1 週間）

フェーズ2: 部分的導入（非本番環境）

Automatic = true
MaximumAutomaticAttempts = 3
SNS 通知で監視
修復失敗率が 5% 未満を確認

フェーズ3: 本番展開（本番環境）

非破壊的修復（ルール削除、タグ追加など）のみ
破壊的修復（リソース削除など）は Automatic = false 維持
修復前に CloudFormation、Terraform との干渉チェック
定期的にドキュメント更新

10.4 ルール選定のポイント

必須ルール（すべての環境に推奨）

required-tags — リソース可視化・コスト管理
restricted-ssh — セキュリティ
ec2-instance-managed-by-systems-manager — 運用効率
iam-policy-no-statements-with-admin-access — 権限最小化
s3-bucket-public-read-prohibited — データ漏洩防止

監査・コンプライアンスルール

cloudtrail-enabled — 監査
config-enabled — 構成管理
multi-region-cloudtrail-enabled — 全リージョン監視
kms-cmk-backing-key-rotation-enabled — 暗号化キー管理

環境別の追加ルール

本番環境:

db-backup-enabled — バックアップ
ec2-volume-inuse-check — 不要なボリューム削除

非本番環境:

ec2-instance-type-check — コスト削減
ebs-volumes-not-attached-to-instance — 不要リソース削除

10.5 クエリとダッシュボード

メインダッシュボード

全体準拠率（%）
リージョン別・アカウント別の準拠率
ルール別の非準拠リソース数
過去 7 日間のトレンド

詳細ドリルダウン

リソースタイプ別の準拠状況
特定ルールの非準拠リソース一覧
修復アクションの成功率
リソースの過去 30 日間の変更履歴

Webhook / Slack 連携

新規非準拠リソース検出時に通知
修復アクション失敗時に通知
週次のコンプライアンスレポート配信

試験で狙われるポイント

頻出問題パターン

パターン1：「どのサービスを組み合わせるか」

問題例：「セキュリティグループから 22 番ポートの全開放を自動的に削除したい。どのサービス・設定を使うか」

答え：

Config ルール（restricted-ssh）で検出
SSM Automation ドキュメント作成（修復スクリプト）
修復アクション設定（Automatic = true）で自動実行

重要：

単独の Config では修復できない（評価のみ）
Systems Manager 統合が必須

パターン2：「マルチアカウント・マルチリージョンで何が可能か」

よくある誤解：「Config ルール自体がマルチアカウント対応」

現実：

単一 Config ルールは 1 アカウント用
組織ルール（Organization Config Rules）で複数アカウント対応
マルチリージョン検索にはアグリゲータが必須

設問の読み方：「全アカウント・全リージョンのセキュリティグループを検索」 → アグリゲータ + SQL クエリ + 適合パック

パターン3：「リアルタイム vs 継続的評価」

シナリオ：「MySQL ポート 3306 を開放したセキュリティグループの作成を即座に検出して警告したい」

最適解：EventBridge ルール（リアルタイム検知） + Config ルール（継続的評価）

注意：

Config のみでは不十分（定期評価の遅延リスク）
EventBridge のみでは追跡困難（状態管理が必要）

パターン4：「コスト最適化」

シナリオ：「多数のアカウント・リージョンで Config 運用するが、コストを最小化したい」

対策：

特定リソースタイプのみ記録（すべてではなく）
定期評価間隔を 24 時間に（変更トリガーは併用）
非本番環境では構成レコーダー OFF
アグリゲータは本当に必要なときだけ
ルール数を 50～100 に厳選（適合パック活用）

注意：「コスト削減」と「コンプライアンス」のバランスが問われる → 非本番環境の割り切りが重要

パターン5：「適合パック vs カスタムルール」

適合パック活用時:

CIS Benchmark / PCI-DSS / HIPAA 対応が必要
業界標準に沿いたい
複数ルールを一括管理したい
CloudFormation テンプレート管理で保守性向上

カスタムルール必須:

ビジネスロジック特有のルール（非標準）
既存システムとの統合が必要
高度なデータ検証
Lambda / Guard で実装

試験での問い方：「いかなる状況でカスタムルールが必要か」と聞かれたら → 「マネージドルールでカバーされない要件」を答える

まとめ：AWS Config の立場

AWS Config は セキュリティ・コンプライアンスの基盤です。

CloudTrail は「何が起きたか」の記録
Config は「結果どうなったか」の記録

両者が揃って初めて完全な監視が成立します。

SCS-C03 では、Config の技術的な深さ（ルール設計・修復パイプライン・マルチアカウント運用）が試験ポイントになります。単なる「オンにする」ではなく、本番環境での運用形態まで意識して学習してください。

Config — ルール評価・適合パック・自動修復