はじめに
最近では当たり前になってきた AWS のマルチアカウント管理ですが、ベストプラクティスに従うと設定・管理が結構大変です。
そこで、これまでの経験を元に マルチアカウント管理のちょうどいい塩梅 を作ってみました。ポイントを絞って書き出してみましたので、これからマルチアカウント管理を考える方の参考になれば幸いです。
なお、本記事では「なんでマルチアカウントがいいの？」といった基本的な事項については触れていません。マルチアカウントの必要性を感じているが、どう設計すれば悩んでいるといった読者を対象としています。
記事を Qiita CLI に移行したことに伴い、体裁を修正しました。ただし、内容の更新まではしていませんので、ご留意ください。
ポイント
- OU の分け方
- マルチアカウントの実装方法
- ユーザー管理
- セキュリティベースライン
- セキュリティ監視
- アカウント間の通信
- マルチアカウントで有用なサービス
1. OU の分け方
基本的にはベストプラクティスに従います。
ただし、少々過剰に思えますので、以下くらいの分け方がちょうど良いんじゃないかと思います。
ポイント
- OU はアカウントの役割、セキュリティ要件によって分ける
- アカウント間は用途ごとに、できるだけ依存関係がないように分ける
最低限これでいいと思っている分け方
- Security OU: セキュリティに関するアカウントが所属。 ex.: Control Tower で作られる Audit, Log Archive など
- Infrastructure OU: 複数サービスで共通するアカウントが所属。 ex.: Transit Gateway, Route 53 などを管理
-
Workloads OU: サービスアカウントが所属。
- Production OU: 本番環境のサービスが所属。
- SDLC OU: 本番環境以外のサービスが所属 (Staging とか Development と分ける案もアリ)
- Deployment OU: CI/CD などの仕組みを提供するアカウントが所属。
- Sandbox OU: 開発者個人の開発環境 (Playground) が所属する OU。
2. マルチアカウントの実装方法
Control Tower を使いましょう。Control Tower を使えば以下をやってくれます。
- マルチアカウント含めた Organizations 設定が簡単に行える。 -> ランディングゾーン
- アカウント全体の統制ルールの設定が自動で適用される。 -> コントロール (旧ガードレール)
- 新しくアカウントを作成するための簡単なインターフェースがある。 -> Account Factory
- アカウントを跨いだユーザー管理が自動で設定される。 -> IAM Identity Center
3. ユーザー管理
AWS のユーザー管理といえば IAM ですが、マルチアカウントでは IAM をやめて、IAM Identity Center を使いましょう。マルチアカウントでの権限設定ができるとともに、AWS 以外のサービスに SSO (SAML) できたりします。
Account Factory を使うと、新しい AWS アカウントとユーザーがセットで作成できるので、 playground アカウントと共に作成することをお勧めします。
4. セキュリティベースライン
マルチアカウントに限らず、セキュリティベースライン設定は BLEA (Baseline Environment on AWS) がお勧めです。
5. セキュリティ監視
Control Tower と BLEA の設定が済んでいれば、 Audit アカウントの Security Hub で全アカウントのセキュリティ状態が確認できると思います。BLEA の設定により通知もできますが、デフォルトだと見切れないほど大量に届くため、必要最低限にするための実装・設定が必要です。
- 真に必要な監視ルールだけ有効にして、不要なもの・許容できるルールは無効化する。
- 通知するもののフィルタリングを設定する。
不要なルールの例
例えば、コントロールでルートユーザーの操作を禁止した場合、ルートユーザーの MFA を強制させるルールは無効化します。
フィルタリングの設定例
例えば、Security Hub の検出結果を Slack に通知する場合、以下のような構成を独自に作ります。
EventBridge では以下イベントパターンを設定したルールを作成して、重要度の高いルール違反のみを通知するようフィルタリングを行います。
{
"detail": {
"findings": {
"Severity": {
"Label": ["CRITICAL", "HIGH"]
},
"Workflow": {
"Status": ["NEW"]
}
}
},
"detail-type": ["Security Hub Findings - Imported"],
"source": ["aws.securityhub"]
}
6. アカウント間の通信
特別な理由がない限りは Transit Gateway を使います。Infrastructure OU に作るであろう 共有サービスアカウント に Transit Gateway を配置して、相互接続が必要なアカウントと接続します。
ちょっと応用的な設定 - インターネットとの接続点を一本化する
共有サービスアカウントを全アカウントのインターネットとの接続口として通信制御を行うことができます。その場合、共有サービスアカウントに Network Firewall を併設することで、制御設定を行うことができます。具体的な設定は以下をご参照ください。
ただし、本構成はメリットもあればデメリットもあります。
メリット
- アカウント毎に NAT Gateway や VPC エンドポイントを配置しなくて良くコスト削減できる。
- 全体の通信制御を 1 箇所で行うことができ、セキュリティ統制がしやすい。
デメリット
- ルートテーブルの設定が複雑となる。
- 設定をミスると全体に影響が及ぶため設定変更が怖い。
マルチアカウントで有用なサービス
マルチアカウント管理において、併用して良かったサービスをご紹介します。
IP Address Manager (IPAM)
AWS で使う IP アドレスを管理できるサービス。Transit Gateway で複数のアカウント (VPC) を接続する場合、プライベート IP が重複すると困るため利用すると有用。Resource Access Manager (RAM) を使って組織全体で共有して利用する。
Reachability Analyzer
指定したネットワークインターフェース同士で通信可能かどうかを分析してくれるサービス。マルチアカウントを接続した場合に、ネットワークが複雑になりがちなので、ルートテーブルやセキュリティグループの設定ミスを発見するのにとても重宝する。信頼されたアクセスを有効にすることで組織内のアカウント全体で分析ができるようになる。ただし、Network Firewall を介した分析はできないので注意。
さいごに
ポイントを絞って書きはしましたが、プロジェクト・組織によって要件は変わってきます。必要最低限の要件を見極めてちょうどいい塩梅のマルチアカウント管理を実現してもらえばと思います。
参考
文章中の参考サイト以外にも以下サイトを参考にさせていただきました。ありがとうございました。