はじめに
企業におけるAWS利用では、請求/権限分離、セキュリティ境界の確保、クォータ管理の観点からマルチアカウント構成が標準となる。
しかし、各アカウントの自律性とセキュリティの一元管理を両立させる構成を1から作り上げるのは手間が掛かる。
本記事では、AWS Organizations、Control Tower、IAM Identity Centerを組み合わせ、ガードレールによる「統制」と開発チームの「スピード」を両立させる、エンタープライズ向けの実務的な基盤設計について解説する。
1. AWS Organizationsを利用したマルチアカウント構成の例
Organizationsとその拡張機能であるControl Tower、認証認可を管理するIAM Identity Centerをデプロイする。(便宜上管理アカウントと呼ぶ)
Control Towerを利用すると監査アカウントとログアーカイブアカウントが払い出され、ConfigデータとCloudTrailログがログアーカイブアカウントのS3に保管されるようになる。監査アカウントをSecurity Hub CSPM、GuardDutyの委任管理者として指定する。
管理・監査・ログアーカイブと統制をかけるサービス群だけ取ってもマルチアカウント構成であるが、アカウント単位で役割を分離することで、権限管理を分かりやすく、また万一認証情報が侵害されたときの影響範囲を最小化することができる。
各アカウントの位置づけ
- 管理アカウント：Organizationsのルートとして請求管理、アカウント作成/閉鎖、OU管理を担う。日常的な作業は実施しない
- 監査アカウント：Security Hub CSPMやGuardDutyの委任管理者として、全アカウントの脅威検知やセキュリティ態勢を一元監視する
- ログアーカイブアカウント:監査ログ・構成変更のログを保管する
- ワークロードアカウント：アプリケーションの実行
2. 管理アカウントに配置したサービス(Organiztions/Control Tower/IAM Identity Center)の概要
AWS Organizations
マルチアカウント管理の根幹をなすサービス。
アカウント単位でSCP/RCPなどのポリシーを付与するほか、ルートユーザの認証情報を削除(=ルートユーザでサインインできなくなる)したり、CloudTrailやConfigなどのセキュリティサービスとマルチアカウント連携し、全アカウントの操作ログやリソース構成変更を一括で有効化・集約したりできる。
Control Tower
統制ルール(コントロールまたはガードレールと呼ばれる)が有効化された状態や、VPCの設定等独自のカスタマイズが入った状態(Landing Zone)でアカウントを払い出すサービス。
Control Towerを使用することで監査アカウント・ログアーカイブアカウントを含むSecurity OUが自動作成され、全アカウントの操作ログ（CloudTrail）や構成変更履歴（AWS Config）を中央に集約する。
コントロールの中には自動適用・変更不可の必須のコントロール(実態はSCP)があり、主にログアーカイブアカウントにログを集約する仕組みが変更されないようになっている。
Control Towerでアカウントを作成すると、Control Tower用のサービスロールなど、Control Towerが各アカウントを管理するために必要なリソースがCloudFormationでデプロイされる。
普段の運用で意識する必要はないが、Control Towerが何をデプロイしているのかは、払い出されたアカウント側のCloudFormationスタックコンソールを開くと確認することができる。
ちなみにスタックは消せてしまうが、リソース自体はSCPで削除がdenyされているためエラーとなる。その状態でもControl Tower側では特段動作に支障はなかったが、正常な状態ではないためらんでぃんートとして請求管理、アカウント作成/閉鎖、OU管理を担う。日常的な作業は実施しない
- 監査アカウント：Security Hub CSPMやGuardDutyの委任管理者として、全アカウントの脅威検知やセキュリティ態勢を一元監視する
- ログアーカイブアカウント:監査ログ・構成変更のログを保管する
- ワークロードアカウント：アプリケーションの実行
2. 管理アカウントに配置したサービス(Organiztions/Control Tower/IAM Identity Center)の概要
AWS Organizations
マルチアカウント管理の根幹をなすサービス。
アカウント単位でSCP/RCPなどのポリシーを付与するほか、ルートユーザの認証情報を削除(=ルートユーザでサインインできなくなる)したり、CloudTrailやConfigなどのセキュリティサービスとマルチアカウント連携し、全アカウントの操作ログやリソース構成変更を一括で有効化・集約したりできる。
Control Tower
統制ルール(コントロールまたはガードレールと呼ばれる)が有効化された状態や、VPCの設定等独自のカスタマイズが入った状態(Landing Zone)でアカウントを払い出すサービス。
Control Towerを使用することで監査アカウント・ログアーカイブアカウントを含むSecurity OUが自動作成され、全アカウントの操作ログ（CloudTrail）や構成変更履歴（AWS Config）を中央に集約する。
コントロールの中には自動適用・変更不可の必須のコントロール(実態はSCP)があり、主にログアーカイブアカウントにログを集約する仕組みが変更されないようになっている。
必須のコントロールの例
- CloudTrail の構成変更の禁止
- ログアーカイブアカウントのS3バケットの削除禁止 など
余談 Control Towerアカウントを払い出しの裏側
Control Towerでアカウントを作成すると、Control Tower用のサービスロールなど、Control Towerが各アカウントを管理するために必要なリソースがCloudFormationでデプロイされる。
普段の運用で意識する必要はないが、Control Towerが何をデプロイしているのかは、払い出されたアカウント側のCloudFormationスタックコンソールを開くと確認することができる。
ちなみにスタックは消せてしまうが、リソース自体はSCPで削除がdenyされているためエラーとなる。その状態になったとき、Control Tower側の動作に支障は無いように見受けられたが、正常な状態ではないため、Control Towerのランディングゾーンをリセットスタックを復旧させた。
IAM Identity Center(IdC)
組織全体の「誰が、どのアカウントに、何の権限で入るか」を一括で管理する。
許可セット(IAMポリシーのコレクション)をOUやアカウントへ紐付けることで、そのアカウント内にIdC管理のIAMロールが作成される。
アカウントアクセス時はIAM Identity Centerポータルにログインし、アクセスしたいアカウントを選択する。
アカウントにアクセスするユーザとしても、複数アカウントに連続してログインする場合、ポータルにログインできるアカウントと権限が一覧で表示され、それをクリックするだけでアクセスできるのは非常に楽。
IAMでジャンプアカウントからクロスアカウントロールする方式と比較すると、許可セットもIAM Identity Center側で一括管理なので、マネージドポリシーで作成した許可セットであれば、アカウントを新規に追加しても既にある許可セットと紐づけるだけでOK。
(※カスタムポリシーは各アカウントで作成する)
同じ許可セットを複数アカウントに紐づけるイメージ
ReadOnly等の全社共通で利用する標準的な権限はマネージドポリシー、プロジェクト固有であったりリソースの設定変更・削除等、強い権限はカスタムポリシーを使ってAPI単位できめ細かく制御することで、運用の負荷を抑えることができると考える。
3. 実効性の高い統制基盤の構築：予防・発見・修復の三段構え
前項はサービス概要やサービスを利用すると自動で有効化される機能についてであったが、本項ではユーザが設計する部分について解説する。
予防：SCPによるガードレール
各アカウントのユーザにさせたくない操作は、SCPでそもそもできなくしておくのが安全だが、日々の運用の中で必要な操作を拒否してしまうと、その操作をしたいときに対象アカウントを別OUに動かす作業が生じる。
一時的に設定を変更するのは戻し忘れのリスクがあるため、発見的コントロールでの検知(後述)やIAMでの権限管理で対応できないか検討する。
(アカウント移動ではなくSCP側を変える、は同じSCPが付与されている他アカウントにも影響するため現実的ではない)
SCPで拒否する操作はControl Towerの予防的コントロールをベースにすると考えやすい。必須のコントロールは自動で有効化されるので、強く推奨、オプションのコントロールで組織のポリシーに合ったものを選ぶ。
強く推奨になっている予防コントロール(ルートユーザのアクセスキー作成禁止、ルートユーザの操作禁止)はOrganizationsの機能でルートアクセスの一元管理ができることもあり、例外的に許可が必要なケースを考えにくいため、Organizationsのrootに適用したい。
発見：ConfigとSecurity Hub CSPMによる監視
一律で拒否してしまうと運用に支障が出る操作は、Control Towerの発見的コントロール(実態はConfig)と各セキュリティサービスで異常を即座に検知する体制を敷く。
発見的コントロールにも強く推奨、オプションのレベル分けがあるが、予防的コントロールと異なり、強く推奨となっている項目でも要件次第で実装が必要なものもある。(S3パブリックアクセス許可、EC2にアタッチされていないEBS、など)
ただし閉域のAWS利用においては原則するべきでない設定・構成なので、どうしてもその設定を入れたいアカウントだけOUを分ける等の対応を検討する。
修復：イベント駆動による「自律的なガバナンス」
検知した後の初動を早めるため、監査アカウントを起点とした自動修復の仕組みを組み込む。
Security Hub CSPMで検知した「非準拠」イベントをEventBridgeでキャッチし、AWS Systems ManagerやLambdaを介して自動的に設定を正す。
例：パブリック公開されたS3バケットを即座にプライベート化する、等。
本番環境は修正といえども自動でリソースの変更がかかることを許容できない場合があるため、その場合は通知のみ飛ばし、人間による対応フローなどで対応する。
おわりに
記事を書く中で、Control Towerを利用するとSCPで拒否する項目の選定・適用をコントロールベースでできて楽だなと再認識できた。