この記事は公開されてから1年以上経過しています。情報が古い可能性がありますので、ご注意ください。
こんにちは、臼田です。
みなさん、AWS Summit参加してますか？(挨拶
今回は2022年5月25 - 26日の2日間開催されているAWS Summit Onlineのセッションレポートをしていきます。セッションのサマリーを理解し、興味があるセッションをチェックすることにご活用ください。また、セッションのアーカイブも公開されますので、詳細はそちらをチェックしてください。
セッション概要
タイトル: セキュアでスケーラブルな AWS アカウント統制プラクティス最新動向(AWS-19)
概要: 「開発や運用の俊敏性を損ねず、複数のAWSアカウントを効率よく統制するにはどうすればよいのか？」と言うご質問をよく伺います。本セッションでは、マルチアカウントにおけるセキュアでスケーラブルな統制の考え方とプラクティスを解説します。そして、AWSのマネージドサービスを活用したマルチアカウント統制の始め方、進め方について理解を深めます。最新動向の一つとして、2021 年 4 月に東京リージョンで利用可能になり、国内のお客様で導入が加速している AWS Control Tower の役割や価値、導入の勘所をお伝えします。
スピーカー: AWS セキュリティソリューションアーキテクト 中島 智広
セッションレベル: Level 200: 初級者向け
レポート
- AWSアカウント統制の最新動向を話す
- 最近はControl TowerやBLEAを提供している
- 前提
- 対象者
- AWSアカウントの統制・管理・運用をしている人
- 開発や運用の俊敏性を実現したい人
- ゴール
- マルチアカウント管理の考え方と効率的な始め方を理解する
- 伝えること
- なぜマルチアカウントアーキテクチャがいいのか
- どうやって統制すればいいのか
- 実際のプラクティス
1. なぜ、AWSアカウントを分割するのか︖
- なぜAWSアカウントを分割するのか？
- 小さな独立したアカウントに分割する
- シンプルになる
- 依存関係が少なくなり組織的・人的障害も少なくなる
- アカウントは増えるので効率よく管理する必要がある
- マルチアカウントアーキテクチャを採用する理由
- 明確な環境分離
- 複雑性の回避
- 権限移譲の単位
- 請求の分離
- 俊敏性を得るために統制メカニズムを備える
- 開発や運用で権限が必要になる
- 俊敏性のために、裁量・権限が移譲されないといけない
- 管理者がリスクを評価してコントロールする仕組みが必要
- 環境分離は統制の基本戦略
- AWSに関わらず基本
- 例えば本番環境と開発環境の分離
- 開発環境に機微情報がなければ開発者にある程度の権限を移譲出来る
- ISO27001やPCI DSSなどでも言及されている統制
2. AWSアカウント統制の考え⽅
- AWSアカウント統制のグランドデザイン
- 統制メカニズムの方向性
- ゲートキーパーではなくガードレールにする
- できるだけ自由に使わせつつ、利用者を守るためのガードレールを作るといい
- 再構築より再利用
- AWS Control Towerからスタートが第一選択肢
- ベストプラクティスに基づいて統制できる
- Landing Zoneを構築してくれるサービス
- AWS Control TowerはAWSアカウント統制の模範であり見本であり習作でもある
- AWS Control Towerを通して運用を体験し理解を深めることができる
- プラクティスを学べる
- 再販されたAWSアカウントにもAWS Control Towerを利用できる
- 詳しくはソリューションプロバイダーやAWSに相談
- AWS Control Towerをカスタマイズする
- AWS Control Towerは単独で統制の要件を満たすものではない
- ベースラインとして使う
- 疎結合にカスタマイズするといい
- カスタマイズ拡張もテンプレート化して再利用
- BLEAを公開している
- AWS-22のセッションでも詳しく解説している
3. 統制のプラクティスとそれを⽀えるAWSマネージドサービス
- セキュリティ管理者が求める統制プラクティス
- 一元管理
- 証跡の保全
- ガードレール
- ガードレールの設計ポイント
- 予防的なものに偏って設計しない
- 管理者が権限をガッツリ絞るのは現実的ではない
- 望ましくない設定にはみ出したときに検知する発見的統制は簡単
- まず発見的統制から始めるのもいい
- AWSアカウントアクセスの一元管理
- 個別のアカウントにIAMユーザーを作成するのはスケールしない
- AWS SSOなどを利用する
- 統制の展開や保守を一元管理
- AWS CloudFormationのStackSetsを使うといい
- 複数のAWSアカウントや複数のリージョンに展開できる
- 後から更新もできる
- 証跡の保全と一元管理
- AWS CloudTrailのログ集約をするといい
- 別のアカウントに退避することで侵害などから守れる
- AWSアカウント単位での強力な予防的統制
- AWS Organizationsでrootユーザーの権限も制限できるSCPを使える
- 構成変更に対する発見的統制
- AWS Configは変更履歴を保全できる
- Config Rulesは逸脱の検知や修復も可能
4. 既存のAWSアカウントに統制を導⼊するには
- 既存ワークロードへの影響を考える
- 既存ワークロードの動作を制限する機能はAWS OrganizationsのSCPのみ
- メカニズムの理解が導入の懸念を払拭する
- AWS Control Tower導入のポイント
- 指定した組織単位に属するAWSアカウントのみが統制対象
- AWSアカウントを例外にすることもできる
- 予防的ガードレールからスタートしない
- 影響を把握することが大変
- 導入しやすいものから積み重ねる
5. まとめ
- マルチアカウントアーキテクチャ推奨の理由などを解説した
- 再構築より再利用を特に意識してほしい
- 固有の統制のみビルディングブロックする
まとめ
AWSマルチアカウント統制についてしっかりまとまっている内容でした。
AWS Control Towerから始めるのは私もめちゃくちゃ推しています！まずどんなことができるのかを体感すると、実際に自身に合う要件を具体化できると思います。
ぜひAWS Summit Onlineに登録してセッションのアーカイブも確認してみてください！スライド資料も配布されていたので要チェックですよ！
3
