概要
AWS認定のDOP-C02を受験するうえで、AWS Configをほとんど触ったことが無かったので概要を把握するために試しに触った際の記録。
S3バケットのパブリックアクセスを自動検知するルールがあるらしいので、そりゃ便利だということで試してみる。（TerraformのStateファイルのバックエンドの保管等にも使用するので、意図せずパブリックアクセスが有効になったりすると困るので…）
手順
- 検証用のS3バケットを作成する
- AWS Configを設定する
- 自動修復アクションを追加する
- パブリックアクセスを有効にして挙動を確認する
検証用のS3バケットを作成する
terraformで作成。モジュールはこちらを使用しています。
terraform {
backend "local" {}
required_version = ">=1.3.7"
required_providers {
aws = {
version = "5.53.0"
}
}
}
provider "aws" {
region = "ap-northeast-1"
}
module "general_s3_bucket" {
source = "git::https://github.com/terraform-aws-modules/terraform-aws-s3-bucket.git?ref=v4.1.2"
bucket = "<S3-BUCKET-NAME>"
}
terraform applyで作成し、パブリックアクセスが無効のバケットが出来上がったことを確認する。
AWS Configの設定
こちらのs3-bucket-level-public-access-prohibitedのAWS管理ルールを使います。
すべてデフォルト値で設定をします。
まずはこの状態で、どのように検出されるかを確認します。
今回作成したS3バケットはパブリックアクセス無効なので、コンプライアンスは「準拠」になっています。
動作検証
では、このバケットのパブリックアクセスが有効になった際は、きちんと検出されるかを確認します。
terraformに一部パラメータを追加して、パブリックアクセスを有効にします。
module "general_s3_bucket" {
source = "git::https://github.com/terraform-aws-modules/terraform-aws-s3-bucket.git?ref=v4.1.2"
bucket = "<S3-BUCKET-NAME>"
attach_public_policy = false # add
}
変更を加えます。
Terraform will perform the following actions:
# module.general_s3_bucket.aws_s3_bucket_public_access_block.this[0] will be destroyed
# (because index [0] is out of range for count)
- resource "aws_s3_bucket_public_access_block" "this" {
- block_public_acls = true -> null
- block_public_policy = true -> null
- bucket = "<S3-BUCKET-NAME>" -> null
- id = "<S3-BUCKET-NAME>" -> null
- ignore_public_acls = true -> null
- restrict_public_buckets = true -> null
}
Plan: 0 to add, 0 to change, 1 to destroy.
S3バケットのパブリックアクセスが有効になったので、Configが検出するのを待ちます。
数分後に、このバケットのコンプライアンスステータスが「非準拠」になっていました。想定通り、S3バケットのパブリックアクセスの設定変更を検知できているようです。
自動修復アクションを設定する
今回作成したルールに対して、自動修復アクションを追加します。
「アクション」->「修復の管理」をクリックします。
「修復方法を選択」で「自動修復」を選択します。再試行も必要であれば設定しておきます。
お目当てのアクションを実行してくれそうな修復アクションを発見したので、こちらを設定します。
そのまま設定を保存しようとしたらエラーが出ました。
どうやらSystems ManagerがS3バケットを操作するために、IAMロールを設定しておく必要があるみたいですね。今回は前工程でTerraformの実行用に使用していたIAMロールにssmに対する信頼関係ポリシーを追加して流用しました。
設定後のパラメータ一覧はこうなりました。自動修復するS3バケットの名前（リソースID）は、非準拠になったリソースのパラメータを渡します。
パブリックアクセスを有効にして挙動を確認する
再度Terraformを使ってパブリックアクセスが無効のS3バケットを作成します。
module "general_s3_bucket" {
source = "git::https://github.com/terraform-aws-modules/terraform-aws-s3-bucket.git?ref=v4.1.2"
bucket = "<S3-BUCKET-NAME>"
attach_public_policy = true
}
AWS Config上でも「準拠」になっていることを確認しました。
マネジメントコンソールからこのS3バケットの「ブロックパブリックアクセス」を意図的に「オフ」にします。
この状態でしばらく待機します。
自動修復アクションが開始された模様。
正常に実行されたようです。
マネジメントコンソール上でも「ブロックパブリックアクセス」がオンへ修復されていることを確認しました。
また、リソースのタイムライン上でも「ブロックパブリックアクセス」の設定が削除された2分後にSystems Managerによって修復されている履歴を確認することができました。
Terraformでplanコマンドを実行しても、差分なし（＝ブロックパブリックアクセスが有効）であることを確認できました。
No changes. Your infrastructure matches the configuration.
Terraform has compared your real infrastructure against your configuration and found no
differences, so no changes are needed.
感想
上手に使えば意図しない変更や悪意のある変更にも耐久性のあるAWS環境を実現できる便利なサービスだと再度認識しました。こういう発見があるのも認定試験のメリットですね。