はじめに
AWS SAAの学習をしていて、IAMユーザーだの、IAM Identity Centerでユーザー管理だの、AWS Organizationsでアカウント管理だの出てきてややこしいのでまとめてみました。
IAMとは
AWSアカウント内で「誰に」「どんな操作を」「どんな条件で」許可するかを制御する仕組み
ユーザーやアプリケーションにアクセス権限を付与・制御できる
IAMユーザー
AWSを利用する「人」や「システム」に割り当てるアカウント
特徴
- 1ユーザー = 1つの認証情報（パスワード、アクセスキー）を持つ
- ポリシーを直接割り当ててアクセス制御
- コンソールログイン、CLI/APIアクセスが可能
- アカウントごとに管理し、複数のユーザーやロール、ポリシーを作成できる
例
- user用のIAMユーザーを作成 → S3への読み取り権限だけ付与
IAMポリシー
どのリソースの、どんな操作を、どんな条件で許可/拒否するか」をJSONで定義する文書
{
"Effect": "Allow",
"Action": "s3:GetObject",
"Resource": "arn:aws:s3:::my-bucket/*"
}
| 項目 | 説明 |
|---|---|
| Effect | 許可または拒否 Allow or Deny（明示的Denyが最優先） |
| Principal | 誰が（アクセス制限） |
| Action | どうする（操作） |
| Resource | 何を（対象） |
| Condition | IP/MFA/時間帯などの条件（任意） |
IAMロール
一時的に誰か（または何か）が引き受けられる「使い捨ての権限セット」
- EC2インスタンスがS3にアクセスする
- 他アカウントやIdentity Centerからアクセスする
- 一時的な権限でアクセスさせる（AssumeRole）
信頼ポリシー（Trust Policy）
「誰がこのロールを引き受け（Assume）られるか」を定義するポリシー
IAMロールの作成時に必須で、AssumeRoleを制御する
{
"Version": "2012-10-17",
"Statement": [
{
"Effect": "Allow",
"Principal": {
"AWS": "arn:aws:iam::123456789012:user/userName"
},
"Action": "sts:AssumeRole"
}
]
}
アクセス制限ポリシー（Permission Policy）
「このロールにどんな操作（アクション）を許可するか」を定義するポリシー。
{
"Version": "2012-10-17",
"Statement": [
{
"Effect": "Allow",
"Action": "s3:*",
"Resource": "*"
}
]
}
| 種類 | 説明 |
|---|---|
| 信頼ポリシー | 「誰がこのロールを引き受けられるか」を定義（例：EC2、IAMユーザーなど） |
| アクセス権限ポリシー | 引き受けた後に「何ができるか」を定義（通常のIAMポリシーと同じ） |
AWS Organizationsとは
複数のAWSアカウントを一元管理・制御するサービス
企業や組織で、開発用・本番用・検証用などのアカウントを組織的に管理しやすくするのが目的
主な機能
| 機能 | 内容 |
|---|---|
| アカウントの一元管理 | 複数のAWSアカウントを1つの組織（Organization）にまとめて管理 |
| サービスコントロールポリシー（SCP） | 組織・アカウント単位で、最大権限の境界（ガードレール）を設定 |
| 統合請求（Consolidated Billing） | すべてのアカウントの請求を1つのマスターアカウントに統合できる |
| アカウント分離によるセキュリティ強化 | 開発・本番などの環境をアカウント単位で物理的に分離 |
Organaizationsの構成イメージ
AWS Organization（組織）
├─ 管理アカウント（root）
├─ Organizational Unit（OU）
│ ├─ dev アカウント
│ ├─ test アカウント
│ └─ prod アカウント
└─ SCP（OU単位で制限をかけられる）
IAM Identity Centerとは
AWSアカウントやSaaSへのログインを一元管理するサービス
組織内のユーザーに対して「どのアカウントで」「どのロールで」アクセスできるかを制御できる
主な機能
| 機能 | 説明 |
|---|---|
| ユーザー管理 | 社内ユーザーや外部IdPと連携したユーザーの一元管理（SCIM対応） |
| アカウントアクセス制御 | 組織内のAWSアカウントごとに、どのユーザーにどのロールを割り当てるか設定 |
| SSOログイン | 一度のログインで複数のAWSアカウントやアプリケーションにアクセス可能 |
| Permission Set（権限セット） | 各ロールに割り当てるIAM権限テンプレート（実態はIAMロール＋ポリシー） |
| 監査ログ出力 | CloudTrail連携により、誰がどのアカウントで何をしたか記録可能 |
Identity Centerの構成イメージ
[ユーザー（Identity Center）]
↓ ログイン（SSO）
[ダッシュボードでアカウント/ロールを選択]
↓
[該当アカウントに一時的にAssumeRole]
↓
[AWSの各サービスにアクセス可能]
組織でのベストプラクティス
アカウントの分離（業務・環境ごとに）
- 「prod」「dev」「test」などで環境ごとに分離
- 障害・コスト・セキュリティの影響範囲を分けられる
OU（Organizational Units）による階層管理
Root OU
├── Infrastructure OU（管理/共通基盤）
│ ├── management
│ └── shared-services
└── Workloads OU（プロダクト環境）
├── dev
├── test
└── prod
Identity Center（SSO）の運用ベストプラクティス
グループベースの割り当てを徹底
- 個人単位ではなく 「開発者グループ」や「監視チーム」などのグループで割り当て
- 人事異動時もグループのメンバー変更だけで対応可能
Permission Set（ロール）の設計
- ロールごとにPermission Setを作成（例：AdminAccess, ReadOnlyAccess, BillingAccess）
- AWS管理ポリシーを使うか、必要に応じてカスタムで作成
1ユーザーに複数アカウント＋ロールを付与
- 例：prodはReadOnly、devはAdmin など柔軟に制御
- 利用ログもCloudTrailに記録され、監査可能
全体構成
AWS Organizations（Root OU）
├── Infrastructure OU
│ ├── management（監査・請求・SCP）
│ └── shared-services（監視・ログ・CI/CD）
└── Workloads OU
├── dev（開発環境）
├── test（検証環境）
└── prod（本番環境）
↓ Identity Center
- dev × AdminAccess（開発者グループ）
- prod × ReadOnlyAccess（監視者グループ）
- test × OperatorAccess（QAグループ）
まとめ
Organizationsで環境ごとにアカウントを作って、Identity Centerで各アカウントに対するロールを割り当ててSSOできるようにするのが良いみたいですね。