この記事は公開されてから1年以上経過しています。情報が古い可能性がありますので、ご注意ください。
こんにちは、大前です。
先日 Control Tower のバージョン 2.8 がリリースされましたので、ランディングゾーンの更新を行い、どんな変更があったのか確認してみました。
Landing Zone バージョン 2.8 による更新
バージョン 2.8 における更新内容の概要は以下ドキュメントに記載があります。
上記ドキュメントを要約すると、バージョン 2.8 で以下の変更が適用される様です。
- Control Tower が作成するログアーカイブバケット上のアクセスログバケットに対してアクセスログの設定が追加
- Control Tower が作成するログアーカイブバケット上のアクセスログバケットに対して 10年保持のライフサイクルポリシーを設定
- Config イベントを Audit アカウントに送信するために各アカウントに展開される Lambda 関数にデッドレターキュー設定を追加
- 各アカウント（管理アカウントを除く）の Config で利用されるロールをサービスリンクドロールに変更
- Control Tower が KMS 暗号化設定を入れる際のプロセスを改善
- リージョン拒否ガードレール利用時に route53-application-recovery リソースの利用がブロックされない様に更新
具体的にどういったパラメータが変更されているかは、実際にランディングゾーンを更新して確認してみます。
やってみた
ランディングゾーンの更新
まず、管理アカウントにログインし Control Tower のランディングゾーンを 2.8 にバージョンアップします。私の環境では、2.7 → 2.8 のアップデートでした。
アップデートの具体的な手順については過去の記事を参照ください。
アップデートを実施し、バージョンが 2.8 になっていれば OK です。
2.8 で追加された変更を確認
Control Tower が作成するログアーカイブバケット上のアクセスログバケットに対してアクセスログの設定が追加
ログアーカイブアカウントには Config や CloudTrail ログを集約するための S3 バケットが存在しています。（aws-controltower-logs-<アカウントID>-<リージョン>）
上記バケットには S3 サーバーアクセスログの設定がされており、そのアクセスログの保存先として別途バケットが作成されています。（aws-controltower-s3-access-logs-<アカウントID>-<リージョン>）
バージョン 2.8 にて、上記の アクセスログの保存先バケット に対して S3 サーバーアクセスログの設定が追加されています。
追加された背景としては、Security Hub のカテゴリに S3 アクセスログ設定に関する項目が追加された事に関連しているものと思われます。
考慮事項として、アクセスログの保存先が自分自身となっている事には注意が必要です。ログ量の増加につながる可能性があるため、バージョンアップ前に必ず検証環境で動作確認を行いましょう。
2022/03/23 追記 実際にどのくらいのログが増えるのか調査してみました。
Control Tower が作成するログアーカイブバケット上のアクセスログバケットに対して 10年保持のライフサイクルポリシーを設定
Control Tower が作成するアクセスログ保存先バケット（aws-controltower-s3-access-logs-<アカウントID>-<リージョン>）に対して、10年保持のライフサイクルポリシーが追加されました。
具体的には、現行/非現行オブジェクトがそれぞれ 3650日で期限切れになる様な設定となっています。
ちなみに、Config や CloudTrail のログが保存されるバケット（aws-controltower-logs-<アカウントID>-<リージョン>）の保持期間は 1年です。将来的には、こちらも 10年に更新されたりするのでしょうか。
Config イベントを Audit アカウントに送信するために各アカウントに展開される Lambda 関数にデッドレターキュー設定を追加
Config ルールのイベントを Audit アカウントに集約するため、Control Tower 管理下の各メンバーアカウントには Lambda 関数が展開されています。
バージョン 2.8 にて、この Lambda 関数にデッドレターキューの設定が入る様になりました。下図にある通り、Audit アカウント上の SNS トピック（aws-controltower-AggregateSecurityNotifications）が送信先として指定されています。
これにより、メンバーアカウント側で Lambda 関数の実行に失敗した場合でも、Audit 側でそれを検知することができる様になります。
各アカウント（管理アカウントを除く）の Config で利用されるロールをサービスリンクドロールに変更
従来、Control Tower 管理下の各メンバーアカウントに対して設定される Config の IAM ロールには Control Tower が作成する IAM ロール（aws-controltower-ConfigRecorderRole）が指定されていました。
バージョン 2.8 から、この IAM ロールが Config のサービスリンクドロール（AWSServiceRoleForConfig）に変更されます。
独自に作成される IAM ロールではなく、AWS 側で用意されるサービスリンクドロールを利用できるのは安心ですね。
Control Tower が KMS 暗号化設定を入れる際のプロセスを改善
これについては、Control Tower が展開する StackSets のテンプレートの差分を確認しても、該当しそうなリソース変更は見当たりませんでした。
Control Tower のランディングゾーン設定で KMS 暗号化を有効化にした際の裏側の挙動に変化がありそうですが、リソースのパラメータには影響なさそうですので、気にせずに利用いただけそうです。（パラメータ更新されてるよ！などあれば教えてください。。。！）
リージョン拒否ガードレール利用時に route53-application-recovery リソースの利用がブロックされない様に更新
これは昨年末に追加された、リージョンの利用制限をかけるガードレールに関するアップデートです。
上記ガードレールを有効化すると以下の様な SCP が適用されるのですが、バージョン 2.8 でこの SCP の内容が更新された形になります。
{
"Version": "2012-10-17",
"Statement": [
{
"Sid": "GRREGIONDENY",
"Effect": "Deny",
"NotAction": [
"a4b:*",
"acm:*",
"aws-marketplace-management:*",
（中略）
"waf:*",
"wafv2:*",
"access-analyzer:*"
],
"Resource": "*",
"Condition": {
"StringNotEquals": {
"aws:RequestedRegion": []
},
"ArnNotLike": {
"aws:PrincipalARN": [
"arn:aws:iam::*:role/AWSControlTowerExecution"
]
}
}
}
]
}参考 : データ常駐保護を強化するガードレール - AWS Control Tower
具体的には、上記 SCP の "NotAction" に以下 3つのアクションの記載が追加されています。
- "route53-recovery-control-config:*"
- "route53-recovery-readiness:*"
- "route53-recovery-cluster:*"
上記アクションは、昨年の夏頃にリリースされた Route 53 Application Recovery Controller に関連するアクションの様です。リージョン制限ガードレールを利用すると意図せずブロックされてしまっていた動作を修正した形の様ですね。
おわりに
Control Tower のランディングゾーンバージョン 2.8 を試して、更新内容を確認してみました。バージョン 2.8 は新規ガードレールが追加される様な更新ではありませんでしたが、Security Hub の基礎セキュリティベストプラクティスへ追従するための更新が含まれていたりします。
検証の上、ランディングゾーンのバージョンアップについて要否を検討いただければと思います。
以上、AWS 事業本部の大前でした。
2
