先日、IAM Identity Center と AWS Organizations を設定し、マルチアカウント環境を整備しました。
メンバーアカウントへのログインは IAM Identity Center のポータルから行い、日々の作業はメンバーアカウントで進めています。
そして、管理アカウントにログインすることがない ことにふと気が付きました。
設定が完了した後、管理アカウントの出番がほぼなくなったのです。
大事なはずなのに存在感が薄い。
今回は管理アカウントの役割について掘り下げてみます。
本記事は、IAM Identity Center と AWS Organizations を整理していくシリーズの一つです。
1. 存在感の薄い管理アカウント
IAM Identity Center でマルチアカウント設定をした後、日常の作業動線はこうなります。
- IAM Identity Center のポータルにログインする
- メンバーアカウントを選択する
- メンバーアカウントで作業する
この流れの中に、管理アカウントは登場しません。
- IAM Identity Center の有効化
- AWS Organizations の初期設定
- メンバーアカウントの作成
これらが終わってしまえば、管理アカウントにログインすることはほとんどなくなります。
一番初めに作った管理アカウントが日常運用から存在感を消している。
これは良い状態なのでしょうか？
管理アカウントはどうあるべきなのでしょうか？
2. 触らないことが正解
結論から言うと、管理アカウントは 触らないことが正解 です。
IAM Identity Center や AWS Organizations の設定を完了した後、管理アカウントは日常運用の動線から切り離されました。
作業も、ログインも、リソースのデプロイもしません。
そして AWS 公式のベストプラクティスを確認すると、まさにこの状態が推奨されています。
管理アカウントのベストプラクティスとして、以下のような記載があります。
- 管理アカウントにはワークロードをデプロイしない
- 管理アカウントへのアクセスを制限する
- 管理アカウントの使用は Organizations の管理タスクに限定する
触らないことは放置ではなく、意図した設計 ということになります。
3. 触らないのに重要
そして管理アカウントは、当然重要なアカウントです。
ルートユーザーと同様に、Blast radius (爆発半径) が大きい特徴があるためです。
管理アカウントの役割
管理アカウントは、組織全体の制御面を担っています。
- アカウント管理：メンバーアカウントの作成・削除・招待
- SCP (サービスコントロールポリシー)：組織全体に適用するガードレールの起点
- 請求の一元管理：全メンバーアカウントの利用料金を集約
- Organizations の設定変更：組織の構造やポリシーの管理
これらは全て、組織全体に影響する操作です。
Blast radius が最大
もし管理アカウントが侵害されたら何が起きるでしょうか。
- SCP を無効化され、全アカウントのガードレールが消える
- メンバーアカウントに対して横展開される
- 請求情報を含む全組織の情報が漏洩する
- 最悪の場合、組織そのものを解体される
影響範囲は 1 つのアカウントではなく、組織全体 に及びます。
管理アカウントの Blast radius は、組織の中で最大なのです。
日常的に利用すると自ずとミスの発生率が上がる。
ミスが起こると最大の影響範囲が出る。
だからこそ触らない。
最強の権限を持つ場所だからこそ、日常の動線から切り離し、攻撃面を最小化する。
これが管理アカウントの設計思想です。
まとめ
管理アカウントは、ワークロードや検証の場でもなければ、収益を生む場所でもありません。
しかし、組織の全アカウントを束ねるハブであり、最も守るべきアカウントです。
触らないことが、このアカウントの仕事。
存在感が薄いことこそが、正しく運用されている証なのかもしれません。
今日も小さな学びを。
IAM Identity Center (& AWS Organizations) 関連記事