AWS Configによるリソース設定の監視

January 18, 2026

概要

AWSアカウント内のリソース設定がセキュリティベストプラクティスに準拠しているかを継続的に監視し、準拠していないリソースを検出する必要があります。

例えば、S3バケットのパブリックアクセス設定は誤って公開された場合に重大なセキュリティリスクとなるため継続的な監視が重要です。

AWS Configは、AWSリソースの設定を評価、監査するためのサービスであり、リソースの設定変更を継続的に監視しすることで前述したような状況を防ぐことができます。

AWSが提供しているマネージドルールを使用することで、ベストプラクティスに準拠したルールを簡単に適用できます。

本記事では、AWS Configを使用してS3バケットのパブリックアクセス設定を監視する方法を、実際の設定手順と挙動確認を通じて解説します。

AWS Configが必要な理由

セキュリティコンプライアンスの継続的な監視

AWSリソースの設定は、作成時点では適切に設定されていても、後から変更される可能性があります。

また、複数の開発者がリソースを作成・変更する環境では、設定ミスや意図しない変更が発生する可能性があります。

AWS Configを使用することで、以下のようなメリットがあります。

継続的な監視: リソースの設定変更を自動的に検出し、コンプライアンス状態を評価
マネージドルールの活用: AWSが提供するマネージドルールを使用することで、セキュリティベストプラクティスに準拠したルールを簡単に適用
組織全体での一元管理: AWS Organizationsと連携することで、複数のアカウントにわたる一貫したセキュリティ管理を実現
変更履歴の追跡: リソースの設定変更履歴を保持し、いつ誰が変更したかを追跡可能

AWS Configの基本概念

Configの主要コンポーネント

AWS Configは、以下の主要コンポーネントで構成されています。

Configuration Recorder: AWSリソースの設定を記録するコンポーネント。リソースの設定変更を検出し、設定スナップショットを作成する。
Delivery Channel: 設定スナップショットと設定変更履歴をS3バケットに配信するチャネルする。
Config Rules: リソースの設定を評価するルール。マネージドルールとカスタムルールの2種類がある。
Compliance: ルールに基づいてリソースのコンプライアンス状態を評価し、準拠しているかどうかを判定する。

マネージドルールとカスタムルール

AWS Configでは、以下の2種類のルールを使用できます。

マネージドルール: AWSが提供する事前定義されたルール。セキュリティベストプラクティスに準拠したルールが多数用意されている
カスタムルール: 独自の要件に基づいて作成するルール。AWS Lambda関数を使用して評価ロジックを実装する。

本記事では、S3バケットのパブリックアクセス監視に使用するマネージドルールを使用します。

AWS Configの設定手順

Configのセットアップを行います。

AWS Config 設定

設定項目は以下の通り

記録戦略	全てのリソースを対象にするか、特定のリソースのみを対象にするのかを選択できる。
デフォルト設定	変更が発生するたびに内容を記録するのか、日次で内容を記録するのかを選択できる。
オーバーライド設定	デフォルト設定の上書きを行えます。例えば「全てのリソースを対象にしているが、IAMだけは除外する」というよう調整が行えます。
データガバナンス	AWS Configがほかのサービスを呼び出すときに使用するためのロールです。設定画面から新規作成するか、作成済みのものを指定します。
配信チャネル	AWS Configが取得したリソースの状況を配信するバケットを選択します。

全てのリソースに対して継続的に記録を行うデフォルトの設定と、IAMのイベントをオーバーライド設定で除外しています。

つまり、IAM以外のリソースの変更を継続的に記録するという設定になります。

ここまでの設定では、収集結果をS3バケットに貯めるだけになります。ルールに一致しないリソースがあった場合に通知するケースを想定していますのでSNSでの通知設定をここで入れるのと、次の画面でルールを設定します。

なおSNSの通知はメールに配信されるように設定を行なっています。

事前に作成したS3バケットに配信する場合の設定

事前に作成したAWS ConfigからS3バケットに記録結果を保存する場合、S3のバケットポリシーを設定する必要があります。

AWS Configの画面からS3バケットを作成している場合は、自動必要なポリシーが設定されているのでこの操作は不要です。

https://docs.aws.amazon.com/config/latest/developerguide/s3-bucket-policy.html

{
    "Version": "2012-10-17",
    "Statement": [
        {
            "Sid": "AWSConfigBucketPermissionsCheck",
            "Effect": "Allow",
            "Principal": {
                "Service": "config.amazonaws.com"
            },
            "Action": "s3:GetBucketAcl",
            "Resource": "arn:aws:s3:::<バケット名>",
            "Condition": {
                "StringEquals": {
                    "AWS:SourceAccount": "<送信元のAWSアカウントID>"
                }
            }
        },
        {
            "Sid": "AWSConfigBucketExistenceCheck",
            "Effect": "Allow",
            "Principal": {
                "Service": "config.amazonaws.com"
            },
            "Action": "s3:ListBucket",
            "Resource": "arn:aws:s3:::<バケット名>",
            "Condition": {
                "StringEquals": {
                    "AWS:SourceAccount": "<送信元のAWSアカウントID>"
                }
            }
        },
        {
            "Sid": "AWSConfigBucketDelivery",
            "Effect": "Allow",
            "Principal": {
                "Service": "config.amazonaws.com"
            },
            "Action": "s3:PutObject",
            "Resource": "arn:aws:s3:::<バケット名>/[optional]prefix/AWSLogs/<AWSアカウントID>/Config/*",
            "Condition": {
                "StringEquals": {
                    "s3:x-amz-acl": "bucket-owner-full-control",
                    "AWS:SourceAccount": "<送信元のAWSアカウントID>"
                }
            }
        }
    ]
}

AWS Config ルールの選択

AWSが提供しているベストプラクティスに準拠したマネージドルールからS3のパブリックアクセスに関するルールを選択します。

これにより、対象のリソースがルールに準拠しているか否かの判定をすることができます。

TriggerTypes、サポートされている評価モードについて補足します。

TriggerTypes

AWS Configがリソースをチェックする周期の種類です。

画像ではHYBRIDとなっていますが、これは、「Configuration changes」と「Period」という2種類の周期でチェックするという意味です。

CONFIGURATION CHANGES	設定変更が行われた時にチェックを行います。
PERIOD	日次や時間ごとに定期的なチェックを行います。

サポートされている評価モード

スクショからははみ出ていますが選択した二つはDetectiveになっています。

Detectiveの他にProactiveというものもあり、下記のような意味合いになっています。

DETECTIVE	リソースが作成された後に検知するモードです。
PROACTIVE	リソースが作成される前に検知するモードです。

PROACTIVEは2026年1月時点で、3つのマネージドルールのみが対象となっていました。