🛡️

予防コントロール AWS-GR_AUDIT_BUCKET_ENCRYPTION_ENABLED でハマった話

に公開

AWSのマルチアカウント環境をベストプラクティスに沿って統制する AWS Control Tower を導入し、セキュリティを強化しようとした際、思わぬところで開発作業がブロックされてしまったお話です。

はじめに

AWS Control Tower(AWSが定義する「ベストプラクティスに基づいたマルチアカウント環境」を、自動的かつ迅速に構築・管理するサービス) には、あらかじめ定義された「コントロール」が多数用意されています。その中に AWS-GR_AUDIT_BUCKET_ENCRYPTION_ENABLED(Amazon S3 バケット暗号化の変更を禁止する) という予防コントロールがあります。

「S3バケットは常に暗号化されていてほしいし、SSE-S3をデフォルトにしてほしい」という素朴なモチベーションでこれを有効化したのですが、これが思わぬ挙動を引き起こしました。

発生した事象

AWS SAMを利用したデプロイ時に、以下の事象が発生しました。

1. sam deploy の失敗

sam deploy を実行し、アーティファクト保存用のS3バケットが自動生成されるプロセスでエラーが発生しました。

2. マネジメントコンソールでの挙動

コンソールから手動でバケットを作成しようとすると、同様の権限エラーが表示されます。ただし、コンソールの場合は内部的に複数のリクエストを投げているためか、エラーは出るもののバケット自体は作成されるという動きでした。

3. AWS CLI での挙動

一方で、以下のコマンドは成功します。

aws s3 mb s3://my-test-bucket-from-cli
make_bucket: my-test-bucket-from-cli

オプションを一切つけない単純なバケット作成であれば、エラーは出ませんでした。

原因:コントロールの正体は「SCP」

このコントロールのアーティファクトを確認したところ、実態は以下の通りでした。

  • 仕組み: SCP(サービスコントロールポリシー)
  • アクション: s3:PutEncryptionConfigurationDeny する
AWS-GR_AUDIT_BUCKET_ENCRYPTION_ENABLEDのアーティファクト(SCP定義)
{
    "Version": "2012-10-17",		 	 	 
    "Statement": [
        {
            "Sid": "GRAUDITBUCKETENCRYPTIONENABLED",
            "Effect": "Deny",
            "Action": "s3:PutEncryptionConfiguration",
            "Resource": "*",
            "Condition": {
                "ArnNotLike": {
                    "aws:PrincipalARN": [
                        {{ExemptedPrincipalArns}}
                        "arn:*:iam::*:role/AWSControlTowerExecution"
                    ]
                }
            }
        }
    ]
}

つまり、「暗号化設定を作成・変更しようとする操作そのもの」を一律で禁止していたのです。

  • AWS CLI (mb): 暗号化設定を明示せずに「空の箱だけ作る」ため、ポリシーに抵触しない(作成後にデフォルトのSSE-S3が適用される)。
  • SAM / コンソール: バケット作成プロセスの中で「暗号化設定を明示的にセット(Put)」しようとします。たとえそれがデフォルト設定と同じ内容であっても、PutEncryptionConfiguration アクションが発生するため、Denyに引っかかる。

関連資料)Amazon S3 API オペレーションに必要なアクセス許可

考察:このコントロールの本来の用途

調査の結果、このコントロールの目的は「S3に暗号化を強制すること」ではなく、「管理者によってあらかじめ用意された暗号化設定を、後から変更させないこと」 にあると解釈するのが正しそうです。

実は現在、Amazon S3はデフォルトですべてのバケットがSSE-S3で暗号化される仕様になっています。

  • やりたかったこと: すべてのバケットを暗号化したい(=実は何もしなくてもデフォルトでそうなっている)。
  • 起きたこと: デプロイツールが良かれと思って「暗号化設定」を明示的にリクエストに含めたため、SCPの「設定操作禁止」に触れてしまった。

学び

今回の件で得た教訓はシンプルです。

「コントロールの名前だけで判断せず、必ずそのアーティファクトを確認してから導入する」

Control Towerのコントロールは便利ですが、今回のように「明示的に設定を指定する」という一般的なデプロイフローを阻害する場合があります。有効化する前に、どのAPIアクションを縛るものなのかを精査することの重要性を痛感しました。

結びに

「とりあえず強めておこう」で有効化したガードレールが、開発現場の足を止めてしまうのは本末転倒です。Control Towerを運用する際は、コントロールのドキュメントにある「アーティファクト」のセクションを熟読することをおすすめします。

レスキューナウテックブログ

Discussion