MENU
AWSを中心としたクラウドインフラ技術サイト
  1. ホーム
  2. AWS
  3. AWS Config

AWS Config

AWS AWS Config AWS認定試験

AWS Config の特徴

AWS Config は、AWS リソースの設定を評価、監査、審査できるサービスです。AWS Config が非準拠を検知する仕組みは、「設定を記録する」→「ルールで評価する」→「結果を COMPLIANT / NON_COMPLIANT にする」 です。記録と評価の2段階で動いています。

AWS リソースの設定が継続的にモニタリングおよび記録され、望まれる設定に対する記録された設定の評価を自動的に実行できます。あるべき状態に準拠しているかどうかを継続的に評価します。

リソース設定を記録する

AWS Config は、対象にした AWS リソースの設定変更を追跡し、Configuration Item（設定項目） として記録します。たとえば EC2、IAM、S3 などで設定変更が起きると、その時点の設定内容が Config に記録されます。さらに、その履歴は指定した S3 バケットにも定期的に配信されます。

Config はまず最初に「今どういう設定か」を知る必要があります。設定を記録していないと、そもそも評価材料がないので、非準拠判定もできません。

Config ルールが記録された設定を評価する

記録された設定に対して Config ルールが評価を行います。ルールには AWS が用意した マネージドルール と、自分で作る カスタムルール があります。評価結果として、対象リソースごとに COMPLIANT、NON_COMPLIANT、場合によっては NOT_APPLICABLE などが付きます。

例えば、以下のような条件をルールで設定し、現在の設定がその条件に合うかを見ます。条件に合わなければ NON_COMPLIANT になります。

  • S3 バケットを暗号化必須にする
  • IAM ポリシーに Action: "*" と Resource: "*" を含めない
  • 特定タグを必須にする

評価が実施されるタイミング

対象リソースの作成・変更・削除など、設定変更が起きたときに評価します。たとえば IAM ポリシーが更新された瞬間に、その変更をきっかけに再評価されます。

また、変更がなくても、24時間ごとなど指定の頻度で定期的に評価します。

非準拠になった場合

評価結果は Config 上でそのリソースに紐づいて保持され、非準拠の評価結果になった場合、NON_COMPLIANT と表示されます。さらに、この結果をもとに 修復アクション をつなげたり、Security Hub など他サービスに連携したりできます。Security Hub の一部コントロールも、裏では AWS Config のルール評価に依存しています。

例えば、SSM Automation で修復処理（例：CloudFormation の再適用など）を実行することができます。

なぜ Security Hub と連携するのか

AWS Config はリソースの準拠・非準拠を評価するサービスです。その一方、Security Hub はセキュリティ関連の検出結果を集約して運用・管理するサービスです。

AWS Config
  ↓
リソースの評価
  ↓
非準拠を検出
  ↓
Security Hub に集約
  ↓
通知・確認・運用対応

Config 単体でもしょっちゅう Config のダッシュボードを見ることで運用はできるかもしれませんが、かなり大変です。Security Hub と連携することで各アカウント・各リージョンで集約して通知や運用管理ができるようになります。

Config と CloudTrail の違い

CloudTrail は「誰が何をしたか」を記録しますが、Config は現在リソース構成がルールに準拠しているかどうかを見ています。状態をみているということですね。

Config と Inspector の違い

Config には Inspector のようなソフトウェア脆弱性の検出機能はありません。

AWS Config を使用すると、AWS リソース間の設定や関連性の変更を確認し、詳細なリソース設定履歴を調べ、社内ガイドラインで指定された設定に対する全体的なコンプライアンスを確認できます（ポリシーやガバナンスを強化できます）。これにより、コンプライアンス監査、セキュリティ分析、変更管理、運用上のトラブルシューティングを実現できます。

例えば、コンプライアンスから外れた設定（インターネットからのアクセスを全部許可など）がされた場合に記録・通知（EventBridgeで）ができます。

■AWS Config の特徴

  • リソース間の関連性を追跡し、変更する前にリソースの依存関係を確認できます。
  • 変更が発生したら、リソース設定の履歴を確認できます。（履歴のヒストリ管理）
  • 過去の任意の時点でリソースがどのように設定されていたかも確認できます。（構成要素のスナップショット）

Config はあるべき状態をルール化できる

Config はあるべき状態をルール化できます。Config の最大の使いどころです。

例えばアクセスキーを90日ごとにローテートしましょう、というルールを作成した場合、90日を超えたらルールに準拠していないということで EventBridge で通知をすることが可能です。

Config で非準拠検知からの修復アクションの方法

例えば、AWS CloudTrail が無効化された場合に、自動的に CloudTrail を再有効化する仕組みを Config を利用して設定するとします。 

その場合、対象のリソース（CloudTrail の設定）を実際に操作するのは AWS Config 自身ではありません。

AWS Config は次の役割を担当します。

  1. Config ルールで違反を検知する
  2. Systems Manager Automation のランブックを起動する
  3. Systems Manager が専用 IAM ロールを引き受ける
  4. その IAM ロールの権限で CloudTrail API を実行する

つまり、実際の流れは次のようになります。

AWS Config
   ↓ 非準拠を検知
AWSServiceRoleForConfigRemediation
   ↓ ssm:StartAutomationExecution
Systems Manager Automation
   ↓ sts:AssumeRole
AutomationAssumeRole
   ↓ cloudtrail:CreateTrail / StartLogging
CloudTrail
   ↓
S3バケットへログ出力

AWS Config の修復処理は、Systems Manager Automation ドキュメントを利用して実行されます。

1. AWS Config ルールが非準拠を検知する

例えば、AWS Config のマネージドルールとして次を使用します。

cloudtrail-enabled

このルールは、アカウント内で CloudTrail の証跡が有効かを定期的に評価し、証跡が有効でなければ NON_COMPLIANT と判定します。

ここで重要なのは、Config ルールは基本的に検査するだけということです。

CloudTrailは有効か？
    ├─ 有効   → COMPLIANT
    └─ 無効   → NON_COMPLIANT

ルールそのものが StartLogging を実行するわけではありません。

2. 修復設定に SSM Automation ランブックを関連付ける

Config ルールには、次のような修復設定を関連付けます。

Configルール
  cloudtrail-enabled

修復アクション
  AWS-EnableCloudTrail

自動修復
  有効

パラメータ
  AutomationAssumeRole
  TrailName
  S3BucketName

AWS-EnableCloudTrail は、Config ルールではなく、Systems Manager Automation のランブックです。

このランブックは CloudTrail 証跡を作成し、指定されたS3バケットへのログ出力を設定します。S3バケット自体と、CloudTrail が書き込めるバケットポリシーは事前に必要です。

3. AWS Config はどの権限で SSM を起動するのか

自動修復時には、AWS Config のサービスリンクロールが使用されます。

AWSServiceRoleForConfigRemediation

remediation とは「修復する」の意味です。

このロールには、AWS管理ポリシーの次のポリシーが関連付けられています。

AWSConfigRemediationServiceRolePolicy

主な権限は次のとおりです。

{
  "Action": [
    "ssm:GetDocument",
    "ssm:DescribeDocument",
    "ssm:StartAutomationExecution"
  ],
  "Resource": "*",
  "Effect": "Allow"
}

さらに、Systems Manager へ実行ロールを渡すために、次の権限があります。

{
  "Action": "iam:PassRole",
  "Resource": "*",
  "Effect": "Allow",
  "Condition": {
    "StringEquals": {
      "iam:PassedToService": "ssm.amazonaws.com"
    }
  }
}

したがって、このサービスリンクロールが行うのは主に次の2点です。

1. SSM Automation を開始する
2. SSM に AutomationAssumeRole を渡す

このロールが直接 cloudtrail:StartLogging するわけではありません。

4. Systems Manager が AutomationAssumeRole を引き受ける

Configの修復設定では、通常、次のようなIAMロールARNを指定します。

AutomationAssumeRole
  arn:aws:iam::123456789012:role/ConfigCloudTrailRemediationRole

このロールの信頼ポリシーでは、Systems Managerがロールを引き受けられるようにします。

{
  "Version": "2012-10-17",
  "Statement": [
    {
      "Effect": "Allow",
      "Principal": {
        "Service": "ssm.amazonaws.com"
      },
      "Action": "sts:AssumeRole"
    }
  ]
}

つまり、信頼する相手は次ではありません。

config.amazonaws.com

次が正解です。

ssm.amazonaws.com

なぜなら、CloudTrail API を実行する主体は Systems Manager Automation だからです。Systems Manager の Automation 用サービスロールは、ssm.amazonaws.com を信頼するよう設定します。

5. AutomationAssumeRoleにCloudTrail操作権限を付ける

このロールには、ランブックが必要とする CloudTrail 操作権限を付与します。

概念的には次のような権限です。

{
  "Version": "2012-10-17",
  "Statement": [
    {
      "Effect": "Allow",
      "Action": [
        "cloudtrail:CreateTrail",
        "cloudtrail:StartLogging",
        "cloudtrail:GetTrail",
        "cloudtrail:GetTrailStatus"
      ],
      "Resource": "*"
    }
  ]
}

実際に必要な権限は、使用するAutomationランブックのバージョンと内部ステップに合わせて調整します。

例えば CloudTrail 証跡を作成する代表的な Config 修復用ランブックでは、次のような処理が実行されます。

cloudtrail:CreateTrail
cloudtrail:StartLogging
cloudtrail:GetTrail

ランブック内部では、aws:executeAwsApi などの Automation アクションを使って AWS API が呼び出されます。

6. 実際のAPI実行主体

ここまでの役割を整理すると、次のようになります。

処理実行主体使用する権限
CloudTrailの状態を記録・評価AWS ConfigAWSServiceRoleForConfig
SSM Automationの起動AWS Config修復機能AWSServiceRoleForConfigRemediation
実行ロールをSSMに渡すAWS Config修復機能iam:PassRole
実行ロールを引き受けるSystems Managersts:AssumeRole
CloudTrailを作成・開始Systems Manager AutomationAutomationAssumeRole のCloudTrail権限
S3へログを書き込むCloudTrailサービスS3バケットポリシー

通常のAWS Configサービスリンクロールである AwsServiceRoleForConfig は、AWSリソースの設定情報を読み取って記録するためのロールです。修復時のCloudTrail変更権限とは別物です。

AWS Config アグリゲーター

AWS Config アグリゲーター は、複数アカウント・複数リージョン、または Organizations 全体からの AWS Config データを 1か所に集約して見る（一元管理する）ための仕組み（機能）です。アグリゲータは AWS Config 設定およびコンプライアンスデータを収集する AWS Config リソースタイプです。

ちなみにアグリゲーター（Aggregator）とは、集める人・事業者、といった意味を持つ言葉です。複数（バラバラ）のものを集めて統合し、新たな価値や大きな力に変える「集める人・事業者」というニュアンスが強いです。

リソースタイプ（Resource Type）とは？

リソースタイプとサービスは異なります。サービスの中にある「リソースの種類」がリソースタイプと言えます。以下のイメージです。

  • Amazon EC2　…　サービス
  • EC2 インスタンス　…　リソース
  • AWS:::EC2::Instance　…　リソースタイプ（AWS::サービス名::種類名 の形式）

Cofig アグリゲーターが集約できるもの

リソース設定情報と、コンプライアンス情報を集約できます。

リソース設定情報は各リソースが今どう設定されているか。コンプライアンス情報は Config ルールに対して COMPLIANT / NON_COMPLIANT か、という評価結果です。そのため、Config アグリゲーターは「複数環境の Config をまとめて見るためのビュー」と考えると分かりやすいです。

AWS Config 運用

AWS Config マネージドルール（managed rule）

AWS Config マネージドルールは、定義済みのカスタマイズ可能なルールであり、AWS リソースが一般的なベストプラクティスに準拠しているかどうかを評価するために AWS Config で使用します。たとえば「EBS が暗号化されているか」「必要なタグが付いているか」などを、自分で設計してルールを書く必要がなくすぐに評価できます。

Config Rules Compliance Change イベント

AWS Configの Config Rules Compliance Change イベントは、リソースの準拠状態が「準拠」から「非準拠」へ（またはその逆）変化した際に発生します。AWS Config は EventBridge に複数種類のイベントを送りますが、その1つが Config Rules Compliance Change です。

Config と Organizations との関係について

AWS Config と AWS Organizations の関係は、ざっくり言うと以下のような感じです。注意点としては Organizations に入っているだけで AWS Config が全部自動設定されるわけではありません。

AWS Organizations
= 複数 AWS アカウントを組織として管理する土台

AWS Config
= 各アカウント・各リージョンのリソース設定を記録・評価するサービス

AWS Config × Organizations
= 組織全体の Config データを集約したり、Config ルールを組織全体に配布したりできる

Config と Organizations の全体像

Organizations と Config の関係性は以下のようになります。

AWS Organizations
├─ 管理アカウント
│
├─ 委任管理アカウント
│   └─ AWS Configを中央管理するアカウント
│
├─ メンバーアカウントA
│   └─ AWS Config Recorder
│      └─ Config Rule
│
├─ メンバーアカウントB
│   └─ AWS Config Recorder
│      └─ Config Rule
│
└─ メンバーアカウントC
    └─ AWS Config Recorder
       └─ Config Rule

【Black Belt】AWS Config

AWS AWS Config AWS認定試験
AWS AWS Config AWS認定試験

関連記事