こんにちは、最近はAWS Control Towerばかり触っている上野です。
Control Towerの検証を進める中で色々と中身が見えてきたこともあり、個人的に嬉しいポイントと注意ポイントをまとめてみます。 導入検討をされている方、参考となれば幸いです。
Control Towerとは？
詳細は以前書いた記事でまとめています。
東京上陸！AWS Control Towerを触ってマルチアカウント管理のベストプラクティスを理解する ～セットアップ編～ - NRIネットコム Design and Tech Blog
【Part2】東京上陸！AWS Control Towerを触ってマルチアカウント管理のベストプラクティスを理解する ～運用編～ - NRIネットコム Design and Tech Blog
AWSのベストプラクティスに基づいたセキュアな状態の新規アカウントのセットアップと、セットアップ後も安全に使用できるようガードレールを簡単に設定できるサービスになります。 ONにすると最低限のマルチアカウント構成をセットアップしてくれます。構成は以下のような形です。
提供する機能はざっくりと以下のとおりです。
- ログアーカイブ、監査アカウント、OU基本構成のセットアップ
- SCPによる予防ガードレールの設定
- Configルールによる発見ガードレールの設定
- Configの自動有効およびログの一元管理
- CloudTrail証跡の自動設定およびログの一元管理
- AWS SSOのセットアップ
- 管理者への通知機能（Configルール非準拠をSNSで通知）
※細かな詳細を言うと、セットアップにCloudFormationが使われていたり、通知用にEventBridgeやLambdaが使用されていたりします。
Control Towerの嬉しいポイント
自動でセットアップしてくれるという嬉しさはまずあるのですが、もう少し具体的なところを見ていきます。
嬉しいポイント①ガードレールの簡単な設定
Control Towerのメインとも言える機能です。画面から簡単に設定できるというところがありがたいです。
たとえば「SSHがフルオープンのセキュリティグループが作成されたら検知したい」という要件が複数のアカウントで出てきた場合、ガードレール画面からワンクリックで設定できます。
これを自前で作ろうとすると、けっこう面倒です。 予防ガードレールを自分でSCPを書いて作る場合、意図せず通常の操作もできなくなる可能性があるため、慎重に設定、確認する必要があります。
作成後の検知状況もControl Towerで簡単に見れるのもグッドですね。 Control Towerではほかにも多くのガードレールが用意されています。
ガードレールリファレンス - AWS Control Tower
嬉しいポイント②CloudTrail証跡、Configの自動設定
新規も含む全アカウントに対し、Config、CloudTrail証跡が自動有効され、かつ一ヵ所へログが集約されますが、これらをControl Towerが自動でやってくれます。
これらを自分でやろうとすると、けっこうやることが多くて大変です。
- （Organizationsを使う場合）組織関連の設定→「信頼されたアクセス」有効化、アカウントの委任
- ログ管理アカウント、バケットの作成、バケットポリシーの設定
- 新規アカウント追加時の自動設定
Control Towerではポチポチ何回かクリックするだけでこれができます！
嬉しいポイント③既存アカウントがいても大丈夫
既にOrganizations配下に複数AWSアカウントが存在する場合、Control Towerの有効を躊躇する場合があるかもしれせんが、 既存アカウントがいきなりControl Towerのコントロール配下（必須ガードレール有効）になるわけではありません。
既存アカウントは以下のように未登録状態で表示されます。
Control TowerをONにするのは既存アカウントがいても大丈夫ということですね。 ただし、ONにしたあと、Control Towerに登録する場合は、ガードレールが効いたり、ConfigやCloudTrail証跡が自動ONになるので、事前に影響確認をしたほうが良いでしょう。
既存アカウントも段階的にControl Towerに入れていける。というのが嬉しいポイントです。
その他嬉しいポイント
ほかにも、AWS SSOの設定、通知機能の自動設定などいくつかあるのですが、特に嬉しいポイントを3つ書きました。
Control Towerの注意ポイント
現時点での注意ポイントです。今後のアップデートにより改善される可能性もありますので、期待しましょう。
注意ポイント①大阪リージョン未対応
これはそのうちやってくると思います（期待）。現時点では未対応なので、Config等の設定は手動で行う必要があります。ガードレールの設定もできません。
積極的に大阪リージョンを使う予定の方は、Control Towerの使用は対応するまで待ったほうが良いかと思います。
注意ポイント②CloudTrailのログ保存期間は1年間
CloudTrailはログアーカイブアカウントのS3バケット、各アカウントのCloud Watch Logsに証跡が設定されるのですが、S3バケット→1年間、Cloud Watch Logs→2週間という設定になっています。
1年間と書きましたが、正確には1年間で削除マーカー付与、付与後に1年間で完全削除となります。（実質2年間） 「ログを3年間保存」のような要件があった場合、Control Towerではこれを満たせません。
SCPやバケット、または展開しているCloud Formationテンプレートを書き替えて一時的な変更は可能ですが、 個人的にはおススメしません。
というのも、Control Towerでは設定状況を監視しており、変更内容によっては強制的な修正が求められます。 たとえばControl TowerのSCPを手動で修正すると、以下のように怒られます・・
Landing Zoneのバージョンアップなどで自動的に設定が戻る可能性もあります。
ここはControl Towerからログの保存期間を変更できるようになるよう、アップデートを待ったほうが良いと考えています。
現状の回避策としては、証跡を2重で作って手動作成した証跡は保存期間を変更するというやり方がありますね。 InsightsやデータイベントをONにしたい場合もこのやり方になると思います。
注意ポイント③GuardDutyやSecurity Hubは手動対応が必要
Control Towerでは、SSO、SCP、Config、CloudTrailの設定が自動で行われます。逆に言うとそれ以外のサービスは特に設定されません。 GuardDutyやSecurity Hub、個人的にはアカウント作ったらONにしておきましょうというサービスなのですが、 これらのサービスはControl Tower外で設定する必要があります。
組織機能を使用して自動有効にしたり、CloudFormation StackSetsを使用してOUごとに自動有効にしていく形が良いと思います。
まとめ
簡単ではありますがいくつかポイントをまとめてみました。 特に注意ポイントの①と②が気になる場合は、Control Towerのアップデートを期待して待っても良いかと思います。
それではまた！
