Configルール・修復を使ってS3アクセスログの設定有無の検知・対応を行う

川原征大

2020.06.16

この記事は公開されてから1年以上経過しています。情報が古い可能性がありますので、ご注意ください。

AWS Config は AWSリソースの構成を記録、管理するためのサービスです。 EC2インスタンスやセキュリティグループなど、AWSリソースが「いつ、どのような変更がされたか」の履歴を記録してくれます。

また、 AWS Config ルールを利用して AWSリソースの構成の評価ができます。 AWSリソースのあるべき構成を条件としています。条件に違反しているリソースが検出されると「非準拠」フラグが付けられます。

さらに、この「非準拠」リソースを修復することもできます。 "AWS Systems Manager オートメーション(SSM オートメーション)" という自動化を行うためのワークフローと連携して、「非準拠」リソースが見つかれば SSMオートメーションを使ってあるべき構成へ自動修復する、便利な自動化が実現できます。

本記事では S3アクセスログの設定有無を検知/修復 を行うための Configルール/修復を構築してみます。

以下 Configルール、修復アクションを利用します。

やってみる(IAMロールの作成)
やってみる(Configルール・修復アクションの作成)
1. ルール部分
2. 修復アクション部分
確認
1. 修復してみる
CloudFormationテンプレート
注意など
1. 修復のパラメータ "TargetPrefix" 設定をおすすめします
2. アクセスログのループに注意
おわりに
参考

やってみる(IAMロールの作成)

修復を行うための IAMロールを事前に作成します。

以前書いた Config ルール・自動修復を使ってS3全バケットのデフォルト暗号化を自動的に有効化する #やってみる(IAMロールの作成) と同じような手順で以下のようなポリシーを付与した IAMロール(SSM Automation Service Role)を作成します

{
    "Version": "2012-10-17",
    "Statement": {
        "Action": "s3:PutBucketLogging",
        "Resource": "*",
        "Effect": "Allow"
    }
}

やってみる(Configルール・修復アクションの作成)

Configの [ルール] > [ルールを追加] から AWS管理のルール s3-bucket-loging-enabled を選択します。

ルール部分

ルール名や説明、トリガー(変更範囲:リソース, 対象:S3バケット)は特に変更する必要ありません。「ルールのパラメータ」部分はアカウント内でアクセスログ用バケット(optional: プレフィクス)が一意に決まっている場合、設定しましょう。

修復アクション部分

修復アクションに AWS-ConfigureS3BucketLogging を選択します。これは AWS管理の Systems Manager オートメーション(自動化)ドキュメントです。

自動修復を [いいえ] とすること推奨します。 (サーバーアクセスログ用のバケットも「非準拠」扱いになった場合、自動修復によってログのループが発生する可能性があるため)

パラメータ周りは以下のように設定します。

リソースID パラメータ :: BucketName
AutomationAssumeRole :: 先程作成したIAMロールの ARN
GrantedPermission :: ログのアクセス許可( FULL_CONTROL )
GranteeId :: ログにアクセスできるアカウントの正規ユーザーID※
GranteeType :: 正規ユーザー( CanonicalUser )
TargetBucket :: サーバーアクセスログ用のバケット名
(option) TargetPrefix :: ログ格納先プレフィクス

※ 正規ユーザーIDについて

正規ユーザーIDは AWSアカウントID(12桁の数字)と同じように、AWSアカウント1つに割り当てられる長い文字列です。この正規ユーザーIDを検索するには aws s3api list-buckets を実行することで分かります。

$ aws s3api list-buckets
    ︙
    "Owner": {
        "DisplayName": "xxxxx",
        "ID": "b48xxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxx" <----- 正規ユーザーID
    }
}

他マネジメントコンソールなど他手段で確認する方法は以下参照ください。

問題なければ [保存] しましょう。

確認

作成したConfigルールの画面を見てみます。非準拠となっている(アクセスログが設定されていない)S3バケット一覧が表示されます。

修復してみる

1つのバケットにチェックを入れて [修復] してみます。

▼ アクションが正常に実行されました

▼ [再評価] を実施して、「準拠」リソース(S3アクセスログが設定されているリソース)となっていることを確認できました

CloudFormationテンプレート

今回の作業の CFnテンプレート版です。以下リソース作成します。

IAMロール :: ロール名 ssm-automation-role-for-s3-logging
Configルール :: ルール名 s3-bucket-logging-enabled
Config 修復設定 :: 実行ドキュメント AWS-ConfigureS3BucketLogging

パラメータにアクセスログ格納先のバケット名、正規ユーザーIDを指定します。バケットにプレフィクスを指定したい場合、ルールのパラメータを指定した場合は適宜テンプレート修正してください。

注意など

修復のパラメータ "TargetPrefix" 設定をおすすめします

TargetPrefix

型: 文字列

デフォルト: /

説明: (オプション) ログファイルを格納するキーのプレフィックスを指定します。

引用: AWS-ConfigureS3BucketLogging

何も指定しない場合、 "/" となります。これは以下のように名前のないフォルダ内にオブジェクトが作成されるようになります(2020/06/16時点)。気持ちが悪いので、何かしらプレフィクスを指定することをおすすめします。

アクセスログのループに注意

(サーバーアクセスログ用のバケットも「非準拠」扱いになった場合、修復によってログのループが発生する可能性があるため)

前述していましたが、自動修復を検討する場合は特にこちら注意が必要です。

自動修復を設定する前に aws configservice put-remediation-exceptions を実施して、自動修復の対象外とする必要があります。

おわりに

Configルール・修復を使った S3バケットアクセスログ設定を試してみました。以下メリット・デメリットを感じました。

メリット
- ノーコードでS3アクセスログの有無を検知可能
- 修復アクションと関連付けることで、修復プロセスを簡素化
- 自動修復も可能
デメリット
- 「アクセスログを設定しない アクセスログ用バケット 」も非準拠となってしまう
- 自動修復を設定するときは、例外登録を行う必要あり
- バケット単位で TargetBucket , TargetPrefix は指定できない