【初心者向け】AWS Control Towerでマルチアカウント管理をはじめよう

みなさん、こんばんは。小寺です。
今日はAWS Control Towerについて、お伝えしたいと思います。

Why マルチアカウント管理

本番環境とテスト環境が同じAWSアカウントで運用されている方もいらっしゃるかもしれませんが、AWSではマルチアカウントがベストプラクティスとされています。
なぜ？VPC作るの大変だし、サブネットも同じ環境ではないと・・と思われる方もいらっしゃるかもしれませんね。機能ごとにアカウントを分けることは、マルチアカウント戦略を実行する上でとても重要です。ミスオペレーションを防ぐだけではなく、アカウントごとにアクセスできる人や、アクセス権を最小権限とすることも合わせて考えていきましょう。

マルチアカウント管理を行うためには、Organizationsを使っている方が多いかと思います。Organizationsの管理アカウントについては、このベストプラクティスに従いましょう。特に電話番号認証やメールアドレスにグループアドレスを設定しておくことは、管理されている方が変更される際にとても重要です。

マルチアカウント管理にはControl Tower

AWSアカウント統制する上のベストサービスともいえるAWS Control Towerとは？使いこなしている！という方もいれば、初期設定しただけという方まで幅広いと思いますが、特徴についてお伝えします。

Contol Towerを使えばマルチアカウント環境では、アカウントやポリシーの設計を簡単に行うことができます。
統制を利かせたアカウント環境（LandingZone）が作れることが大きなポイントですよね。あとは、以下の2つが重要なポイントです。
✓セットアップの自動化
✓セキュリティ・ログ統制の維持

ここで、Control Towerでよく使われる用語について整理してみます。

・コントロール（ガードレールと呼ばれることも）

AWS環境全体に継続的なガバナンスを効かせるためのルールです。予防コントロール、検出コントロール、プロアクティブコントロールの3種類があります。
必須、強く推奨、選択的の 3 つのカテゴリが適用されます。

例えば、[Disallow Changes to Bucket Policy for Amazon S3 Buckets] (Amazon S3 バケットのバケットポリシーへの変更を不許可にする) という選択的コントロール (以前の名称は Disallow Policy Changes to Log Archive) により、ログアーカイブ共有アカウント内で IAM ポリシーの変更ができない状態となります。
もし、変更をしようとした場合には、拒否され、CloudTrailに証跡が記録されます。またリソースも AWS Config に記録されるようになっています。

・ランディングゾーン

ランディングゾーンは、Well-Architected によるマルチアカウントの AWS 環境で、セキュリティとコンプライアンスのベストプラクティスに基づいた仕組です。
ランディングゾーンを展開することで、Organizaions配下のAWSアカウントのリソースに対して一元的に管理/監視が可能になります。
AWSのベストプラクティスでは、すべてのアカウントの監査を実施する「監査アカウント（Audit）」、すべてのアカウントのログを集約・管理する「ログアーカイブアカウント（Log Archive）」アカウントが自動的に作成され、組織を管理することが推奨されており、AWS Control Towerではこれに必要なアカウントやログ転送設定などが自動的にセットアップされます。

https://pages.awscloud.com/rs/112-TZM-766/images/20220428_17th_ISV_DiveDeepSeminar_Control_Tower.pdf

監査アカウントでは、ランディングゾーンのすべてのアカウントへの読み書きアクセスを許可するように設計された制限付きのアカウントです。監査アカウントからは、Lambda 関数にのみ付与されるロールを使用して、アカウントをレビューするためにプログラム経由でアクセスが可能です。
監査アカウントでは、他のアカウントに手動でログインすることはできません。
ログアーカイブアカウントでは、ランディングゾーン内のすべてのアカウントからの API アクティビティとリソース設定に関するログのリポジトリとして使用されます。

・ダッシュボード

AWS Control Towerでは、作成した環境を効率的に管理するためのダッシュボードが用意されています。
作成したグループやアカウントの数、ガードレールの数、有効化したガードレールに対して検出された違反の数などがまとめて表示されるようになっています。

・AccountFactory

Account Factory は、事前に承認されたアカウント設定で新規アカウントのプロビジョニングを標準化するのに役立つ、設定可能なアカウントテンプレートです。
以下の順番でテンプレート適用がされます。
1）アカウントベースライン定義
2)AWS Service Catalogによるアカウント払い出し
3)ガードレールの適用

Control Towerのユースケース

アカウント数がまだ少ないから必要ないかも、と思っているかもしれませんが、まだ少ないうちにセットアップしておいた方が後々運用管理が煩雑にならずに済むのがControl Towerの良さでもあります。

・セキュリティの統制
AWS Control Tower の包括的な制御管理は、最小特権の適用、ネットワークアクセスの制限、データ暗号化の適用など、最も一般的な制御目的を果たすために必要な制御の定義、マッピング、管理を簡単にできるようにします。
「監査アカウント」では、リスクのある設定が検出された際に、セキュリティ担当が簡単に対処できるようにアクセス経路が特定できる仕組があります。
さらに、リスクのある設定を自動修復する仕組みに必要な基盤も用意されています。

・ログの一元管理（CloudTrail・Config)
AWS CloudTrail のログや、Amazon Simple Storage Service (Amazon S3) に保存される AWS Config のログを集中管理します。
インシデントの調査などはもちろん、トラブルシューティングやインシデントの全容解明、ステークホルダーへの説明責任を果たすことができます。

・インシデント発生時も調査が簡単（ログアーカイブアカウント）
ログを通常利用するアカウントと分けて、ログアーカイブアカウントで管理することで、インシデント発生時の証跡としても有効になります。
通常のアカウントとは別アカウントにログが保存されるので、アクセス可能な人が限られるログアーカイブアカウントで集中管理できるので、改ざんリスクを低減させることもできます。

Control Towerのベストプラクティス

どのようなサービスかを簡単にまとめてきましたが、ここでOrganizationsの全ての機能をぜひ有効にしてみてください。
Control Towerで担える部分は主には、CloudTrailとConfigの部分です。そのためSecurityHubで可視化を行い、GuardDutyで未知の脅威に備えるということが有効だと考えます。
本番アカウントともちろん同じセキュリティレベルである必要がないかもしれないですが、インシデントが発生してリカバリーするのは、他の環境でも同じようにコストがかかる部分です。
脅威への備えをAWSサービスでOrganizationsから一元管理することがControl Towerを活用するためのベストプラクティスだといえるでしょう。

カスタマイズしてみたいよね CustomizationforControlTower(CfCT)

AWS Control Tower のカスタマイズがしてみたいときは、CustomizationforControlTower(CfCT)を使いましょう。
CfCtにより、AWS Control Tower のランディングゾーンをカスタマイズし、AWS のベストプラクティスに準拠し続けることができます。カスタマイズは、AWS CloudFormation テンプレートとサービスコントロールポリシー (SCP) で実装されます。

この CfCT 機能は AWS Control Tower のライフサイクルイベントと統合されているため、リソースのデプロイはランディングゾーンと同期したままになります。例えば、Account Factory を使用して新しいアカウントを作成すると、アカウントにアタッチされたすべてのリソースが自動的にデプロイされます。カスタムのテンプレートとポリシーを組織内の個々のアカウントと組織単位 (OU) にデプロイできます。
さらに、CfCTを使うことによって、ライフサイクルイベントを使用すると、以前の一連のイベントの完了に基づいてリソースをデプロイすることができます。
ライフサイクルイベントを利用して、リソースをアカウントとOUに自動的にデプロイできます。