【AWS SAA】IAM,AWS Organizations,IAM Identity Centerについてまとめてみた

# はじめに
AWS SAAの学習をしていて、IAMユーザーだの、IAM Identity Centerでユーザー管理だの、AWS Organizationsでアカウント管理だの出てきてややこしいのでまとめてみました。

---

# IAMとは
AWSアカウント内で「誰に」「どんな操作を」「どんな条件で」許可するかを制御する仕組み  
ユーザーやアプリケーションにアクセス権限を付与・制御できる

## IAMユーザー
AWSを利用する「人」や「システム」に割り当てるアカウント

**特徴**
- 1ユーザー = 1つの認証情報（パスワード、アクセスキー）を持つ
- ポリシーを直接割り当ててアクセス制御
- コンソールログイン、CLI/APIアクセスが可能
- アカウントごとに管理し、複数のユーザーやロール、ポリシーを作成できる

**例**
- user用のIAMユーザーを作成 → S3への読み取り権限だけ付与

## IAMポリシー
どのリソースの、どんな操作を、どんな条件で許可/拒否するか」をJSONで定義する文書

```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を制御する

```json
{
  "Version": "2012-10-17",
  "Statement": [
    {
      "Effect": "Allow",
      "Principal": {
        "AWS": "arn:aws:iam::123456789012:user/userName"
      },
      "Action": "sts:AssumeRole"
    }
  ]
}
```

### アクセス制限ポリシー（Permission Policy）
「このロールにどんな操作（アクション）を許可するか」を定義するポリシー。

```json
{
  "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できるようにするのが良いみたいですね。