コンテンツにスキップ
ドキュメント
AWS
Config

Config

AWS Config は AWS リソースの設定を継続的に記録・評価するサービス。リソースの設定変更を Configuration Item（CI）として記録し、マネージドルールやカスタムルールでコンプライアンス要件を満たしているかを判定する。必要に応じて SSM Automation ドキュメントによる自動修復を実行できる。

Security Hub CSPM との関係

Security Hub CSPM のコントロールの多くは、内部的に AWS Config マネージドルールで実装されている。Security Hub のコントロールを有効化すると、対応する Config ルール（例: securityhub-eks-endpoint-no-public-access-<サフィックス>）が自動的に作成される。

検証フローは以下のように Config を経由する。

リソース設定変更
  → Config が CI として記録
  → Config ルールが評価
  → Compliance Status（COMPLIANT / NON_COMPLIANT）
  → Security Hub finding（PASSED / FAILED）

このため、Security Hub finding の状態を変えるには Config ルールの評価結果を変える必要がある。本サイトでは Config 手動トリガー → Config 評価結果確認 → Security Hub 確認の流れで検証を進めている。

本サイトでの扱い

本サイトでは現時点では、Security Hub CSPM のコントロールのうち SCP / 宣言型ポリシー / Control Tower 予防コントロールでは予防できないものを対象に、Config による検知と SSM Automation による自動修復を組み合わせた対応策を 自動修復 セクションで扱う。

Config 単体の網羅的なリファレンス（マネージドルールの全体像、カスタムルールの作成、コンフォーマンスパック、アグリゲータ等）は本サイトのスコープ外。CSPM 検証の過程で観測された Config 挙動の知見のみ Tips としてまとめる。

検証で得られた Tips

Security Hub CSPM の各コントロール検証を通じて得られた、Config の挙動に関する知見をまとめる。

Config のラグの 3 段階

検証中に「設定変更したのに評価結果が変わらない」と感じる事象には、原因の異なる 3 段階のラグがある。症状から該当の節へ辿れるよう対応関係を示す。

症状原因該当節
新規作成したリソースが Config の評価対象に含まれないリソース自体がまだ Config に発見されていない新規リソース作成後の Config 発見ラグ
リソースの設定を変更したが、CI が古いままで評価結果が変わらないリソース変更が CI 更新として認識されないConfiguration changes 型の CI 更新ラグ
CI は最新だが、評価結果が古いまま返るCI 更新は済んでいるが、評価ロジックの反映に時間がかかる設定変更後の評価結果反映ラグ

Config ルールの Trigger type

Config ルールは Trigger type によって評価のトリガーと CI の扱いが異なり、検証手順に影響する。

Trigger type動作例
Periodic 型設定変更の有無に関係なく一定間隔（1 時間〜24 時間）で評価。start-config-rules-evaluation で即時評価でき、CI 更新ラグが少ないEKS.1 検証では約 6〜7 秒で評価反映
Configuration changes 型リソース変更を起点に評価。リソース変更が CI 更新として認識されない場合があるMSK.4 検証で UpdateConnectivity が CI を自動更新しない挙動を観測

検証開始前に対象 Config ルールの Trigger type を以下で確認しておくと、CI 更新ラグに遭遇した際の対処が素早い。

aws configservice describe-config-rules \
  --config-rule-names <Config ルール名> \
  --query 'ConfigRules[0].Source.SourceDetails[0].MessageType'

Configuration changes 型の CI 更新ラグ

Configuration changes 型のルールでは、リソース操作が必ずしも CI 更新を起こさないケースがある。start-config-rules-evaluation を実行しても古い CI を参照して評価結果が変わらない。

回避策はタグ操作（tag-resource / add-tags-to-resource 等、サービスによって API 名が異なる）で CI 再キャプチャを誘発すること（MSK.4 検証で確認）。

設定変更後の評価結果反映ラグ

設定変更直後の Config 手動トリガーでは、変更前の評価結果が返る場合がある（Lambda.1 検証で観測: remove-permission 直後の 1 回目は NON_COMPLIANT のまま、数分待った 2 回目で COMPLIANT に変化）。設定変更が Config 評価に反映されるまでに時間がかかるためで、想定と異なる結果が返った場合は数分待ってから再トリガーする。

新規リソース作成後の Config 発見ラグ

新規リソース作成後、Config が発見・記録するまでに時間がかかる場合がある。SNS.4 検証では、新規 SNS トピック作成から Config に認識されるまで約 10 分のラグがあった。リソース作成直後に Config ルールをトリガーしても評価対象に含まれず、get-compliance-details-by-config-rule が空を返すケースがある。

Config と Security Hub での ResourceId 形式の違い

Config ルールが返す ResourceId と、Security Hub finding の ResourceId は形式が異なる場合がある。アカウントレベルのコントロール（SSM.7 / EMR.2 等）で顕著。

Config（AWS::::Account リソース）Security Hub finding
形式アカウント ID そのまま（例: <アカウント ID>）AWS::::Account:<アカウント ID>
取得 APIget-compliance-details-by-config-rulesecurityhub get-findings

両者でフィルタを書く際は形式の違いに注意。

CloudFormation と Config / Security Hub のリソースタイプ名の違い

リソースタイプ名が CloudFormation と Config / Security Hub で一致しない場合がある（Opensearch.2 検証で確認）。

リソースCloudFormationConfig / Security Hub
OpenSearch ドメインAWS::OpenSearchService::DomainAWS::OpenSearch::Domain

検証開始前に以下で実測値を取得しておくと、後から手順書全体を書き換える事故を防げる。

aws configservice get-compliance-details-by-config-rule \
  --config-rule-name <Config ルール名> \
  --query 'EvaluationResults[0].EvaluationResultIdentifier.EvaluationResultQualifier.{ResourceType:ResourceType,ResourceId:ResourceId}'

時刻に基づく再評価の確認

設定変更後に「再評価されたが結果は変わらない」ことを示すには、ResultRecordedTime が設定変更時刻より後であることを確認する。

  • 状態が変わる場合（COMPLIANT ↔ NON_COMPLIANT）: Security Hub finding の UpdatedAt も通常更新される
  • 状態が変わらない場合: Security Hub の UpdatedAt が更新されないケースがある（VPC BPA 検証で観測）。その場合は Config の ResultRecordedTime が再評価の証拠となる

反映時間の目安（実測）

複数の検証で観測された反映時間。Trigger type による違いに注意。安全マージンを取って手順書では sleep を入れているが、実際にはより短く完了するケースが多い。

#状況対象かかる時間
1リソースを新規作成してから、Config が CI として発見・記録するまでTrigger type に依存しない通常数秒〜数分。SNS トピックは約 10 分の事例あり
2既存リソースの設定を変更してから、Config が CI を更新するまで（変更を認識する処理）Trigger type に依存しない通常数秒〜数分。MSK の UpdateConnectivity のように Config が変更を自動認識せず、タグ操作で誘発が必要なケースもある
3aws configservice start-config-rules-evaluation で手動トリガーしてから、Config の評価結果が更新されるまでPeriodic 型 / Configuration changes 型（CI が最新の場合）約 3〜10 秒
4Config の評価結果が更新されてから、Security Hub finding に反映されるまでTrigger type に依存しない約 10〜15 秒（さらに 2〜3 分かかる場合あり）

特殊ケース: 宣言型ポリシー経由の Configuration changes 型ルール

宣言型ポリシーで設定値を変更してから、Configuration changes 型ルールの評価が更新されるまでは 数時間〜1 日 かかる。手動トリガーは効かないため待機が必要。詳細は次節「Trigger type と宣言型ポリシーの相性」を参照。

Trigger type と宣言型ポリシーの相性

宣言型ポリシーによる設定変更は、Configuration changes 型の Config ルールでは設定変更として認識されないケースがある。Periodic 型は手動トリガーで即座に確認できるが、Configuration changes 型は Security Hub の定期スキャンによる反映を待つ必要がある（数時間〜1 日）。

EBS Snapshot BPA（EC2.182、Configuration changes 型）の検証では、リージョンによって反映タイミングが大きく異なることも観測されている（ap-northeast-1: 約 17.5 時間、ap-southeast-1: 約 23 時間）。