AWS Organizationsという「組織の話」 🐟
AWSの勉強をしていると、
「IAM」だの「Organizations」だの「SCP」だの、
横文字が押し寄せてきます。
「え、IAMで権限管理するんじゃないの？」
ところがどっこい。
AWSは、アカウント単位ですら思っていたよりずっと広い。
今回は、SAA-C03の学習を通して
AWS Organizationsとその周辺で混乱したポイントを整理します。
🔐 IAMの境界設定という考え方
まずはIAM。
AWSを触っていると、避けて通れない存在です。
IAMポリシーを使って、
- このユーザーはEC2を使っていい
- S3は読み取りだけ
といった権限管理を行います。
ただ、IAMポリシーだけだと
「うっかり強すぎる権限を付けてしまう」可能性が残ります。
Permission Boundary（許可ポリシーの境界）
そこで出てくるのが
Permission Boundary（許可ポリシーの境界）。
これは、
IAMポリシーで付与できる
「最大の権限」を制限する仕組み
というもの。
考え方としては、
- Permission Boundary
- 付与していい権限の上限
- IAMポリシー
- 実際に付与する権限
どれだけIAMポリシーを盛っても、
Boundaryで許可されていない操作は実行できません。
人為的な設定ミスを防ぐための、安全ネットという位置づけです。
🏢 AWS Organizationsの基本
IAMで個人の操作を制御できても、
AWSではアカウントがどんどん増えていきます。
その管理をまとめて行うための仕組みが
AWS Organizations。
Organizationsは、次の要素で構成されています。
- 管理アカウント
- Organizations全体を管理する中枢
- OU（Organizational Unit）
- アカウントをまとめるためのグループ
- メンバーアカウント
- 実際にリソースを作成・運用するアカウント
OU単位でアカウントを整理し、
組織全体に共通ルールを適用できるのが特徴。
##🚫 SCP（Service Control Policy）
Organizations配下で使える強力な制御が
SCP（Service Control Policy）。
SCPは、
- アカウント単位
- OU単位
で、
この組織では、そもそも何をしていいか
を定義するポリシーです。
IAMよりも上位にあり、
SCPで許可されていない操作は
IAMで許可していても実行できません。
SCPの2つの方式 ⚖
- ブラックリスト方式（Deny）
- 基本は許可し、禁止したい操作だけを定義
- ホワイトリスト方式（Allow）
- 許可した操作のみ実行可能
どちらを選ぶかで、
組織全体のセキュリティレベルが変わります。
ホワイトリスト方式は安心ですが、
運用コストはそれなりに高そう、という印象です。
🔗 Resource Access Manager（RAM）
「アカウントを分けたら、リソースも完全に分かれるの？」
そうとも限りません。
Resource Access Manager（RAM） を使うと、
AWSアカウント間でリソースを共有できます。
例えば、
- 1つのVPCを
- 複数アカウントで使う
といった構成も可能です。
RAMを使うメリット
- ネットワーク設計がシンプルになる
- アカウント間通信が楽になる
- リザーブドインスタンスはデフォルトで共有ON
分けるところは分ける、
まとめるところはまとめる。
AWSらしい設計です。
🧩 Organizationsと連携するサービス
Organizationsを有効にすると、
組織単位で管理できるサービスが一気に増えます。
代表的なものを挙げると、
- Identity Center：SSO管理
- Artifact：セキュリティレポート取得
- AWS Backup：バックアップ管理
- CloudTrail：操作ログ・監査
- Config：リソース構成の監査
- Tag Policies：タグ付けルールの統一
- GuardDuty：ログの脅威検知
- Macie：S3データの分類・保護
- Firewall Manager：WAFなどの集中管理
- Security Hub：セキュリティ情報の集約
数が多く、最初は把握するだけでも大変。
Organizationsは
セキュリティ・運用・監査の中心として機能します。
📝 Organizationsポリシーという考え方
Organizationsでは、
技術的な設定だけでなく運用ルールも管理できます。
- オプトアウトポリシー
- 機械学習用データ提供の可否
- バックアップポリシー
- バックアップ取得ルール
- サービスコントロールポリシー
- 組織内で許可する操作
- タグポリシー
- タグ命名ルールの統一
ここまでくると、
AWSは単なるインフラというより
「組織のルールを形にする仕組み」に近い印象です。
✅ まとめ
- IAMはユーザーやロール単位の権限管理
- Permission Boundaryで権限の上限を制御
- Organizationsでアカウントをまとめて管理
- SCPで組織全体の操作を制限
- RAMで分断と共有を調整
AWSは自由度が高い分、
統制の仕組みもかなり強力。
引き続き、少しずつ全体像を整理していきます。