IAM Identity Centerの権限セット設計とベストプラクティス

IAM Identity Centerを導入した後、最も重要なのは権限セット（Permission Set）の設計です。権限セットの設計が適切でなければ、過剰な権限付与によるセキュリティリスクや、権限不足による業務効率低下を招きます。本記事では、組織の要件に合った権限セットを設計するためのパターンとベストプラクティスを解説します。

権限セットの概念と構成要素

権限セットは、IAM Identity Centerにおいてユーザーに付与する権限を定義するテンプレートです。権限セットをAWSアカウントに割り当てると、対象アカウントにIAMロールが自動作成されます。

権限セットの構成要素

権限セットは、以下の要素で構成されます。

flowchart TB
    subgraph PS[権限セット]
        direction TB
        N[権限セット名]
        D[説明]
        P[ポリシー]
        PB[Permission Boundary<br/>オプション]
        SD[セッション期間]
        RA[リレーステート<br/>オプション]
        
        subgraph "ポリシーの種類"
            AMP[AWS管理ポリシー]
            CMP[カスタマー管理ポリシー]
            INL[インラインポリシー]
        end
        
        P --> AMP
        P --> CMP
        P --> INL
    end

権限セットとIAMロールの関係

権限セットをアカウントに割り当てると、IAM Identity Centerは対象アカウントにIAMロールを自動作成します。このロールは、IAM Identity Center専用のロールとして管理されます。

sequenceDiagram
    participant Admin as 管理者
    participant IdC as IAM Identity Center
    participant Acc as 対象AWSアカウント
    
    Admin->>IdC: 権限セットを作成
    Admin->>IdC: アカウントに割り当て
    IdC->>Acc: IAMロールを自動作成
    Note over Acc: ロール名:<br/>AWSReservedSSO_{権限セット名}_{ID}
    IdC->>Acc: 信頼ポリシーを設定
    IdC->>Acc: アクセス許可ポリシーをアタッチ

自動作成されるロールの特徴は以下の通りです。

ポリシーの種類と使い分け

権限セットには、3種類のポリシーをアタッチできます。それぞれの特徴を理解し、適切に使い分けることが重要です。

AWS管理ポリシー

AWSが作成・管理するポリシーです。AWSサービスの更新に合わせて自動的にメンテナンスされるため、運用負荷が低いのが特徴です。

graph LR
    subgraph "AWS管理ポリシーの特徴"
        A[AWSが作成・管理] --> B[自動更新]
        B --> C[運用負荷低]
        C --> D[汎用的な用途]
    end

代表的なAWS管理ポリシーを以下に示します。

メリット

• AWSが新機能を追加すると自動で対応
• ベストプラクティスに基づいた設計
• すぐに利用可能

デメリット

• 権限が広すぎる場合がある
• 組織固有の要件に対応できない
• カスタマイズ不可

カスタマー管理ポリシー

各AWSアカウントで事前に作成したIAMポリシーを参照します。複数の権限セットで同じポリシーを再利用する場合に有効です。

flowchart TB
    subgraph "権限セットでの参照"
        PS1[権限セット A]
        PS2[権限セット B]
    end
    
    subgraph "各アカウントのカスタマー管理ポリシー"
        A1[アカウント1<br/>CustomPolicy]
        A2[アカウント2<br/>CustomPolicy]
        A3[アカウント3<br/>CustomPolicy]
    end
    
    PS1 -->|参照| A1
    PS1 -->|参照| A2
    PS2 -->|参照| A2
    PS2 -->|参照| A3

重要な注意点

カスタマー管理ポリシーを使用する場合、同じ名前のポリシーが各アカウントに存在する必要があります。存在しない場合、ユーザーはそのアカウントにサインインできません。

メリット

• 組織固有の要件に対応可能
• 複数の権限セットでの再利用
• アカウントごとの微調整が可能

デメリット

• 各アカウントでの事前作成が必要
• アカウント間での一貫性維持が必要
• 管理オーバーヘッドが増加

インラインポリシー

権限セット内に直接JSONポリシーを記述します。その権限セット専用のカスタム権限を定義する場合に使用します。

メリット

• 権限セットと一体で管理
• 各アカウントでの事前準備不要
• きめ細かな制御が可能

デメリット

• 他の権限セットとの再利用不可
• 権限セットのサイズ制限（10,240文字）に影響

ポリシーの組み合わせパターン

実際の運用では、複数のポリシータイプを組み合わせて使用します。

flowchart TB
    subgraph "推奨パターン"
        P1[パターン1: 標準権限<br/>AWS管理ポリシーのみ]
        P2[パターン2: 拡張権限<br/>AWS管理ポリシー + インライン制限]
        P3[パターン3: カスタム権限<br/>カスタマー管理 + インライン補完]
    end

セッション期間の設計

セッション期間は、ユーザーがAWSアカウントにアクセスできる時間を定義します。セキュリティと利便性のバランスを考慮して設定します。

セッション期間の考慮事項

graph LR
    subgraph "セッション期間のトレードオフ"
        S[短いセッション] -->|高| SEC[セキュリティ]
        S -->|低| CONV[利便性]
        L[長いセッション] -->|低| SEC2[セキュリティ]
        L -->|高| CONV2[利便性]
    end

職務別のセッション期間設計

職務の性質に応じて、適切なセッション期間を設定します。

職務別権限セットの設計パターン

組織の職務に応じた権限セットの設計パターンを紹介します。

設計アプローチ

権限セットの設計では、以下のアプローチを推奨します。

flowchart TB
    A[職務の特定] --> B[必要なAWSサービスの洗い出し]
    B --> C[操作レベルの決定<br/>読み取り/書き込み/管理]
    C --> D[リソース範囲の決定]
    D --> E[条件の検討]
    E --> F[最適なポリシー選択]
    F --> G[テストと検証]

パターン1: 管理者向け権限セット

クラウド管理者向けの権限セットです。全サービスへのフルアクセスを付与しますが、重要な操作にはガードレールを設けます。

権限セット名: CloudAdministrator

構成:

• AWS管理ポリシー: AdministratorAccess
• セッション期間: 1時間

設計のポイント:

• セッション期間を短く設定し、長時間の特権維持を防止
• 必要に応じてPermission Boundaryで組織的な制限を適用
• 監査ログの確実な取得を確保

パターン2: 開発者向け権限セット

開発チーム向けの権限セットです。開発に必要なサービスへのアクセスを許可し、IAM操作や本番環境への影響を制限します。

権限セット名: Developer

構成:

• AWS管理ポリシー: PowerUserAccess
• インラインポリシー: 本番リソースへのアクセス制限
• セッション期間: 4時間

インラインポリシーの例を示します。本番環境タグが付いたリソースへの書き込み操作を制限します。

 1
 2
 3
 4
 5
 6
 7
 8
 9
10
11
12
13
14
15
16
17
18
19
20
21
22
23

{
    "Version": "2012-10-17",
    "Statement": [
        {
            "Sid": "DenyProductionResourceModification",
            "Effect": "Deny",
            "Action": [
                "ec2:TerminateInstances",
                "ec2:StopInstances",
                "rds:DeleteDBInstance",
                "rds:StopDBInstance",
                "s3:DeleteBucket",
                "lambda:DeleteFunction"
            ],
            "Resource": "*",
            "Condition": {
                "StringEquals": {
                    "aws:ResourceTag/Environment": "production"
                }
            }
        }
    ]
}

パターン3: 運用者向け権限セット

インフラ運用チーム向けの権限セットです。監視、ログ分析、インシデント対応に必要な権限を付与します。

権限セット名: Operations

構成:

• AWS管理ポリシー: SystemAdministrator
• インラインポリシー: 追加の運用権限
• セッション期間: 8時間

インラインポリシーで追加する権限の例を示します。

 1
 2
 3
 4
 5
 6
 7
 8
 9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
25
26
27
28
29
30
31
32
33
34
35
36
37
38
39
40
41

{
    "Version": "2012-10-17",
    "Statement": [
        {
            "Sid": "AllowCloudWatchOperations",
            "Effect": "Allow",
            "Action": [
                "cloudwatch:DescribeAlarms",
                "cloudwatch:GetMetricData",
                "cloudwatch:PutMetricAlarm",
                "cloudwatch:DisableAlarmActions",
                "cloudwatch:EnableAlarmActions"
            ],
            "Resource": "*"
        },
        {
            "Sid": "AllowLogsOperations",
            "Effect": "Allow",
            "Action": [
                "logs:DescribeLogGroups",
                "logs:DescribeLogStreams",
                "logs:GetLogEvents",
                "logs:FilterLogEvents",
                "logs:StartQuery",
                "logs:GetQueryResults"
            ],
            "Resource": "*"
        },
        {
            "Sid": "AllowSSMOperations",
            "Effect": "Allow",
            "Action": [
                "ssm:DescribeInstanceInformation",
                "ssm:SendCommand",
                "ssm:GetCommandInvocation",
                "ssm:StartSession"
            ],
            "Resource": "*"
        }
    ]
}

パターン4: 閲覧専用権限セット

監査担当者やステークホルダー向けの権限セットです。リソースの参照のみを許可します。

権限セット名: ReadOnlyAccess

構成:

• AWS管理ポリシー: ViewOnlyAccess
• セッション期間: 8時間

設計のポイント:

• ReadOnlyAccessとViewOnlyAccessの違いを理解して選択
• ViewOnlyAccessはより広範なサービスの読み取りをサポート
• センシティブなデータへのアクセスが必要な場合は追加制限を検討

パターン5: セキュリティ監査向け権限セット

セキュリティチーム向けの権限セットです。セキュリティ関連のリソースとログへのアクセスを許可します。

権限セット名: SecurityAuditor

構成:

• AWS管理ポリシー: SecurityAudit
• インラインポリシー: 追加の監査権限
• セッション期間: 4時間

 1
 2
 3
 4
 5
 6
 7
 8
 9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
25
26
27
28
29
30
31
32
33

{
    "Version": "2012-10-17",
    "Statement": [
        {
            "Sid": "AllowSecurityHubAccess",
            "Effect": "Allow",
            "Action": [
                "securityhub:Get*",
                "securityhub:List*",
                "securityhub:Describe*"
            ],
            "Resource": "*"
        },
        {
            "Sid": "AllowGuardDutyAccess",
            "Effect": "Allow",
            "Action": [
                "guardduty:Get*",
                "guardduty:List*"
            ],
            "Resource": "*"
        },
        {
            "Sid": "AllowIAMAccessAnalyzer",
            "Effect": "Allow",
            "Action": [
                "access-analyzer:Get*",
                "access-analyzer:List*"
            ],
            "Resource": "*"
        }
    ]
}

パターン6: 請求閲覧権限セット

経理担当者向けの権限セットです。請求情報とコスト分析へのアクセスのみを許可します。

権限セット名: BillingViewer

構成:

• AWS管理ポリシー: Billing
• AWS管理ポリシー: AWSBillingReadOnlyAccess
• セッション期間: 8時間

権限セット設計マトリックス

組織全体での権限セット設計を整理するマトリックスを作成します。

Permission Boundaryとの組み合わせ

権限セットにPermission Boundaryを設定することで、権限の上限を組織的に制御できます。

Permission Boundaryの適用シナリオ

flowchart TB
    subgraph "Permission Boundaryなし"
        PS1[権限セット<br/>PowerUserAccess] --> R1[有効な権限<br/>IAM以外すべて許可]
    end
    
    subgraph "Permission Boundaryあり"
        PS2[権限セット<br/>PowerUserAccess]
        PB[Permission Boundary<br/>特定サービスのみ]
        PS2 --> INT[交差]
        PB --> INT
        INT --> R2[有効な権限<br/>共通部分のみ]
    end

Permission Boundaryポリシーの例

開発者が特定のサービスのみを使用できるよう制限するPermission Boundaryの例です。

 1
 2
 3
 4
 5
 6
 7
 8
 9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
25
26
27
28
29
30
31
32
33
34
35
36
37
38
39
40
41
42
43
44

{
    "Version": "2012-10-17",
    "Statement": [
        {
            "Sid": "AllowedServices",
            "Effect": "Allow",
            "Action": [
                "ec2:*",
                "s3:*",
                "lambda:*",
                "dynamodb:*",
                "rds:*",
                "cloudwatch:*",
                "logs:*",
                "sns:*",
                "sqs:*",
                "apigateway:*",
                "cloudformation:*"
            ],
            "Resource": "*"
        },
        {
            "Sid": "DenyOrganizationChanges",
            "Effect": "Deny",
            "Action": [
                "organizations:*",
                "account:*"
            ],
            "Resource": "*"
        },
        {
            "Sid": "DenySecurityServiceChanges",
            "Effect": "Deny",
            "Action": [
                "guardduty:DeleteDetector",
                "guardduty:DisassociateFromMasterAccount",
                "securityhub:DisableSecurityHub",
                "config:DeleteConfigRule",
                "config:DeleteConfigurationRecorder"
            ],
            "Resource": "*"
        }
    ]
}

権限セットへのPermission Boundary適用手順

1. 各対象アカウントにPermission Boundaryポリシーを作成
2. IAM Identity Centerで権限セットを編集
3. 「Permission Boundary」セクションでカスタマー管理ポリシーを指定
4. ポリシー名が各アカウントで一致していることを確認
5. 変更を保存

属性ベースのアクセス制御（ABAC）の活用

IAM Identity Centerでは、ユーザー属性を利用したABAC（Attribute Based Access Control）を実装できます。

ABACの概念

flowchart LR
    subgraph "ABAC"
        UA[ユーザー属性<br/>Department: Engineering<br/>Project: Alpha]
        RA[リソースタグ<br/>Department: Engineering<br/>Project: Alpha]
        
        UA --> MATCH{属性一致?}
        RA --> MATCH
        MATCH -->|Yes| ALLOW[アクセス許可]
        MATCH -->|No| DENY[アクセス拒否]
    end

IAM Identity Centerでの属性の設定

IAM Identity Centerでは、ユーザーに属性を割り当て、それをセッションタグとしてAWSアカウントに渡すことができます。

利用可能な属性ソース:

• Identity Center ディレクトリのユーザー属性
• 外部IdPから受け取るSAML属性
• SCIMでプロビジョニングされた属性

ABACを活用した権限セットの例

プロジェクトタグに基づいてアクセスを制御するインラインポリシーの例です。

 1
 2
 3
 4
 5
 6
 7
 8
 9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
25
26
27
28
29
30

{
    "Version": "2012-10-17",
    "Statement": [
        {
            "Sid": "AllowProjectBasedEC2Access",
            "Effect": "Allow",
            "Action": [
                "ec2:StartInstances",
                "ec2:StopInstances",
                "ec2:RebootInstances"
            ],
            "Resource": "*",
            "Condition": {
                "StringEquals": {
                    "ec2:ResourceTag/Project": "${aws:PrincipalTag/Project}"
                }
            }
        },
        {
            "Sid": "AllowProjectBasedS3Access",
            "Effect": "Allow",
            "Action": [
                "s3:GetObject",
                "s3:PutObject",
                "s3:DeleteObject"
            ],
            "Resource": "arn:aws:s3:::*-${aws:PrincipalTag/Project}-*/*"
        }
    ]
}

ABACのメリット

権限セットの運用ベストプラクティス

権限セットを効果的に運用するためのベストプラクティスを紹介します。

命名規則の統一

権限セットの命名規則を統一することで、管理性と可読性が向上します。

最小権限の原則の適用

flowchart TB
    A[広い権限で開始] --> B[CloudTrailでアクセス分析]
    B --> C[IAM Access Analyzerで<br/>未使用権限を特定]
    C --> D[不要な権限を削除]
    D --> E[テストで検証]
    E --> F[最小権限の達成]
    F --> B

実装のステップ:

1. 初期は業務遂行に必要と思われる権限を付与
2. CloudTrailとIAM Access Analyzerで実際の使用状況を分析
3. 30〜90日間のデータを収集
4. 未使用の権限を特定して削除
5. 定期的にレビューを繰り返す

変更管理プロセス

権限セットの変更は、適切な承認プロセスを経て実施します。

定期的な棚卸しと監査

権限セットと割り当ての定期的な監査を実施します。

監査項目チェックリスト:

ドキュメント化

権限セットの設計意図と用途をドキュメント化します。

ドキュメントに含める内容:

• 権限セット名と説明
• 対象ユーザー/グループ
• 付与される権限の概要
• 制限事項と注意点
• 承認者と作成日
• 変更履歴

トラブルシューティング

権限セットに関する一般的な問題と解決方法を紹介します。

権限が不足している場合

カスタマー管理ポリシーのエラー

flowchart TD
    A[サインインエラー] --> B{エラーメッセージを確認}
    B -->|ポリシーが見つからない| C[対象アカウントに<br/>ポリシーを作成]
    B -->|権限不足| D[ポリシーの内容を確認]
    C --> E[ポリシー名が<br/>完全一致しているか確認]
    E --> F[権限セットを<br/>再プロビジョニング]

プロビジョニングの失敗

権限セットのプロビジョニングが失敗する場合の確認項目です。

まとめ

本記事では、IAM Identity Centerの権限セット設計とベストプラクティスについて解説しました。

• 権限セットはポリシー、セッション期間、Permission Boundaryで構成されます
• AWS管理ポリシー、カスタマー管理ポリシー、インラインポリシーを適切に使い分けます
• セッション期間はセキュリティと利便性のバランスを考慮して設定します
• 職務別の権限セット設計パターンを参考に、組織に適した構成を設計します
• Permission Boundaryで権限の上限を組織的に制御できます
• ABACを活用することで、スケーラブルなアクセス制御を実現できます
• 定期的な監査と最小権限の原則の適用が重要です

次回の記事では、IAM Identity Centerと外部IdP（Azure AD/Okta）の連携について解説します。

参考リンク

• AWS IAM Identity Center User Guide - Permission sets
• AWS IAM Identity Center User Guide - Create and manage permission sets
• AWS IAM Identity Center User Guide - Session duration
• AWS IAM User Guide - Permissions boundaries
• AWS IAM User Guide - ABAC for AWS