【設計ガイドライン】会社組織/システムへ AWS lAM / AWS lAM Identity Center を導入する際の検討事項

作成日: 2023/08/07, 更新日: 2025/05/05

AWS IAM Identity Center は、マルチアカウント環境でユーザーやアプリケーションの認証・認可を一元管理するためのサービスです。
それに対して、AWS IAM は、AWS アカウント内のユーザーやアプリケーションの認証・認可を行うためのサービスです。
本記事では、 AWS IAM / AWS IAM Identity Center の概要の説明と会社組織/システムへ導入を検討するにあたって確認すべきポイントを紹介いたします。

改訂履歴
AWS IAM とは？
AWS IAM Identity Center とは？
導入検討
1. ① AWS アカウントはどのような契約形態か？
設計検討
関連ドキュメント

改訂履歴

日付	更新内容
2025/05/05	・「設計検討」 ->「③ IAM 権限設計方針の定義」を追加

AWS IAM とは？

AWS IAM （以下略: IAM）とは、 AWS リソースへのアクセスを管理するためのサービスです。
IAM を使用すると、ユーザー、グループ、およびロールを作成し、これらのエンティティにアクセス許可を付与して、AWS リソースへのアクセスを制御できます。
AWS を利用する上では、IAM は必須のサービスとなり、AWS マネジメントコンソールを操作するユーザーに利用する「IAM ユーザー」、AWS リソースへのアクセス権限を付与する「IAM ロール」を作成することができます。
ただし、後述する AWS IAM Identity Center を利用する場合、IAM ユーザーの作成しない運用も可能です。
- IAM ユーザーを利用する場合は、AWS CLI や SDK でアクセスする場合に認証情報を発行する必要がありますが、AWS IAM Identity Center を利用する場合は認証情報を発行する必要はありません。
- IAM ユーザーで認証情報を発行すると、定期的な認証情報の更新が必要となり、管理コストが増加します。認証情報が漏洩した際に不正利用されるリスクもあります。
- AWS IAM Identity Center を利用する場合は認証情報を発行する必要がなく、AWS アクセスポータルで一時的な認証情報を取得したり、AWS CLI のコマンドを実行する際に一時的な認証情報を取得することができます。

AWS IAM Identity Center とは？

AWS IAM Identity Center （以下略: IIC）とは、 マルチアカウントの AWS 環境において、アイデンティティ管理とアクセス管理を行うためのサービスです。
AWS アクセスポータルという AWS リソースへのアクセスを一元管理するポータルを提供し、各 AWS アカウントへマネジメントコンソールでのアクセスを行うためのリンクを提供します。
アクセス権限はアクセス許可セットという単位で管理され、アクセス許可セットには AWS アカウントへのアクセス権限が設定されています。
各 AWS アカウントへアクセスする一時的な認証情報を取得することも可能で、取得した認証情報を利用して AWS CLI や SDK を利用した AWS リソースの操作が可能です。
外部 ID プロバイダー (IdPs) と連携することで、既存の認証情報を使用してアクセスポータルにサインインできます。2023 年 7 月 30 日現在は、以下の IdPs と連携することができます。
- Azure AD
- CyberArk
- Google Workspace
- JumpCloud
- Okta
- OneLogin
- Ping Identity

導入検討

① AWS アカウントはどのような契約形態か？

マルチアカウント構成なのであれば、 マルチアカウントへのアクセス管理が可能な IIC や Okta、Entra ID などの IDaaS を利用することを推奨します。 IIC は自動的に IAM ロールを各 AWS アカウントへ配布してくれるため、IDaaS と比較すると IAM ロールを配布する運用コストを削減できるメリットがあります。
IIC は管理アカウントで有効化設定を行います。AWS アカウントの契約形態を確認し管理アカウントの機能が使えるのか確認することが重要です。
契約形態に関する詳細は【ガイドライン】会社組織/システムへ AWS Organizations を導入する際の検討事項| Moderniser.repo を参照ください。

設計検討

① 登場するアクターの整理

IAM の設計を策定するにあたって、 組織内のステークホルダーの役割を明確化することが重要です。
AWS 利用標準化ガイドライン策定のベストプラクティス | Amazon Web Services ブログの内容を参考に、言葉の定義を自分なりに整理してみました。
CCoE、共通基盤管理者、セキュリティ担当者、経理・財務の 4 つのアクターは、組織によっては同じ部署や担当者が複数の役割を担う場合もあるかもしれません。

No ➖➖	担当者 ➖➖➖➖➖➖➖	役割 ➖➖➖➖ ➖➖➖➖➖➖➖➖➖➖➖➖➖➖➖➖➖➖➖➖➖➖➖➖	タスク ➖➖➖➖➖➖➖ ➖➖➖➖➖➖➖➖➖➖➖➖➖➖➖➖➖➖➖➖➖➖➖➖➖➖➖➖➖➖➖➖➖➖
01	CCoE	クラウド活用の推進および運営の中心	ガイドラインの整備
02	共通基盤管理者	クラウド環境におけるシステム横断的な共通基盤・機能を提供	共通基盤の構築・運用
03	セキュリティ	クラウド環境におけるセキュリティの維持	セキュリティポリシー定義, セキュリティ機能の構築・運用, セキュリティ監視・運用
04	システム担当	クラウド環境上で稼働するシステムの構築・運用	AWS リソースの構築・運用, システム構築・運用
05	運用	クラウド環境における運用管理	システム監視・運用
06	経理・財務	AWS利用コストの配分および適正化	コストの配分方針検討, 購入オプション検討, コスト監視, AWS利用料金の支払い

② 役割分担整理（IAM 権限委譲の範囲・方法の決定）

IAM の管理権限をどこまでシステム担当へ委譲するのか、委譲する場合にどのような方法や制限を行うのかを決定いたします。
管理する IAM の要素として、「IAM ユーザー」「IAM グループ」「IAM ロール」「IAM ポリシー」の 4 つがあります。
すべてを共通基盤管理者が管理するという選択肢もありますが、システムが大きくなるにつれて管理コストが増加するため、IAM の管理権限を利用者へ委譲することを検討します。
基本的には、SCP（サービスコントロールポリシー）を利用して、アカウントレベルで特定の操作を禁止することで、システム担当への委譲を行うことを第一に検討します。
ここでは代表的なユースケースを 6 つ紹介します。

ユースケース１：IAM ユーザー/グループ以外の管理権限を委譲する

要件項目	内容
AWS Organizations（SCP）や IIC の利用	○ 利用できる
ユーザー管理の委譲	× システム担当へ委譲できない
ロール/ポリシー管理の委譲	○ システム担当へ委譲できる

内部不正対策として有力なのが、不要なユーザーの削除です。
AWS アカウントへアクセスするユーザーは定期的な棚卸しを行い、不要なユーザーを削除する必要があります。
システム担当側へユーザー管理を委譲せず、共通基盤管理者がユーザー管理を行うことで、ユーザーの削除漏れを防ぐことができます。
IAM ロールの信頼ポリシーが不正に設定されることを防ぐため、Access Analyzer を利用して検知することも検討します。

ユースケース２：Permissions Boundary を利用して、IAM ユーザー/グループ以外の管理権限を委譲する

要件項目	内容
AWS Organizations（SCP）や IIC の利用	× 利用できない
ユーザー管理の委譲	○ システム担当へ委譲できる
ロール/ポリシー管理の委譲	○ システム担当へ委譲できる

管理アカウントの機能が利用できない場合、Permissions Boundary を利用して IAM ロールに付与できる権限を制限することで、システム担当への委譲を行うことができます。

ユースケース３：システム専用の踏み台アカウントを作成し、IAM の全管理権限を委譲する

要件項目	内容
AWS Organizations（SCP）や IIC の利用	○/× 利用できる/利用できない
ユーザー管理の委譲	○ システム担当へ委譲できる
ロール/ポリシー管理の委譲	○ システム担当へ委譲できる

システム担当へ IAM ユーザーの管理権限を委譲する場合、システム担当が一元的に管理する踏み台アカウントを作成する手段もあります。

ユースケース４：IAM グループ以外の IAM の管理権限を委譲する

要件項目	内容
AWS Organizations（SCP）や IIC の利用	× 利用できない
ユーザー管理の委譲	○ システム担当へ委譲できる
ロール/ポリシー管理の委譲	○ システム担当へ委譲できる

IAM グループは共通基盤管理者が管理を行い、システム担当は IAM グループにユーザーを所属させることで、IAM ユーザーへの権限を付与します。
IAM ユーザーの権限は共通基盤管理者が統制するため、システム担当が不正に権限を付与することを防ぐことができます。
- 権限設計を行うための工数を削減できるメリットもあります。

ユースケース５：IAM の全管理権限を委譲しない

要件項目	内容
AWS Organizations（SCP）や IIC の利用	○/× 利用できる/利用できない
ユーザー管理の委譲	× システム担当へ委譲できない
ロール/ポリシー管理の委譲	× システム担当へ委譲できない

共通基盤管理者が IAM の全管理権限を保持することで、システム担当への委譲を行わない選択肢もあります。
システム担当から申請ベースで IAM ユーザー、ロールなどを作成する必要があるため、管理コストが増加する可能性があります。

③ IAM 権限設計方針の定義

IAM 権限を設計するうえで難関となるのが、最小権限の原則を適用するうえでどこまで権限を絞り込むのか、という点です。
ベストプラクティスとしては、IAM ユーザーや IAM ロールに付与する権限を最小限に絞り込むことが推奨されます。
ただし、IAM ユーザーや IAM ロールに付与する権限を絞り込むことは、システム担当の運用負荷を増加させる可能性があります。
そのため、 予め付与した IAM 権限によるビジネスリスクを評価し、リスクを許容できる範囲で IAM 権限を付与することが重要です。
- IAM 権限制御だけでなく、AWS Organizations の SCP を併用することによって、IAM 権限設計の負荷を軽減することができます。
- AWS アカウントを適切に分割することも重要です。AWS アカウントを分割することによって、IAM 権限が不正に付与されても、影響範囲を限定化することができます。
IAM 権限を付与する方法として、以下の3つのポリシーを利用することができます。
- インラインポリシー
- AWS マネージドポリシー
- カスタマー管理ポリシー
このうち「AWS マネージドポリシー」は AWS が提供するポリシーで、AWS が権限を適切に評価したうえで提供されています。このポリシーを利用することで、AWS サービス毎に書込み、読み取りの権限を付与することができます。
基本的にはこの AWS マネージドポリシーを利用することを推奨しますが、AWS マネージドポリシーでは権限が過剰に付与されている場合もあるため、必要に応じて「カスタマー管理ポリシー」や「インラインポリシー」を利用して権限を絞り込むことも検討します。
例として、以下のようなパターンでは「カスタマー管理ポリシー」や「インラインポリシー」を利用して権限を絞り込むことを検討します。

パターン1）KMS キーの管理権限を付与する場合

AWS マネージドポリシーを利用して KMS キーの管理権限を付与する場合、AWS マネージドポリシー「AWSKeyManagementServicePowerUser」を利用することができます。
- 参考： AWSKeyManagementServicePowerUser - AWS 管理ポリシー
ただし、このポリシーを利用すると、KMS キーの作成や削除、IAM ポリシーの変更など、KMS キーに対して強力な権限が付与されてしまいます。
- そのため、 IAM ポリシーを利用して特定の KMS キーに対してのみ権限を付与することを検討します。
例えば、以下の IAM ポリシーを利用することで、特定のタグが付与された KMS キーで暗号化されたデータを復号化する権限を付与することができます。

{
    "Version": "2012-10-17",
    "Statement": [
        {
            "Effect": "Allow",
            "Action": [
                   "kms:Decrypt",
                   "kms:GenerateDataKey"
            ],
            "Resource": "*",
            "Condition": {
                "StringEquals": {
                    "aws:ResourceTag/System": "SystemA"
                }
            }
        }
    ]
}

パターン2）SSM オートメーション / Lambda / Step Functions などの実行権限を付与する場合

Lambda や Step Functions などの実行権限を付与すると、その AWS リソースを実行した際の権限を付与することになります。
- 実行されることによりビジネスリスクが発生する場合は、IAM ポリシーを利用して実行権限を制限することを検討します。
例えば、以下の IAM ポリシーを利用することで、特定の命名規則の Lambda 関数を実行する権限を付与することができます。

{
    "Version": "2012-10-17",
    "Statement": [
        {
            "Effect": "Allow",
            "Action": [
                   "lambda:InvokeFunction"
            ],
            "Resource": [
                "arn:aws:lambda:ap-northeast-1:123456789012:function:SystemA-*"
            ]
        }
    ]
}

パターン3）外部アカウントの IAM ロールを AssumeRole する場合

外部アカウントの IAM ロールを AssumeRole する場合、IAM ポリシーを利用して AssumeRole の権限を付与することができます。
- これは、AWS マネージドポリシーでは付与できないため、IAM ポリシーを利用して権限を付与する必要があります。
例えば、以下の IAM ポリシーを利用することで、特定の IAM ロールを AssumeRole する権限を付与することができます。

{
    "Version": "2012-10-17",
    "Statement": [
        {
            "Effect": "Allow",
            "Action": [
                   "sts:AssumeRole"
            ],
            "Resource": [
                "arn:aws:iam::123456789012:role/SystemA-*"
            ]
        }
    ]
}

パターン4）データの管理者/利用者が異なる場合

S3 や DynamoDB などのデータストアを利用する場合、データの管理者/利用者が異なる場合があります。
例えば、S3 バケットの管理者が異なる場合、IAM ポリシーを利用して特定の S3 バケットの管理者に対して権限を付与することができます。

{
    "Version": "2012-10-17",
    "Statement": [
        {
            "Effect": "Allow",
            "Action": [
                   "s3:PutObject",
                   "s3:GetObject"
            ],
            "Resource": [
                "arn:aws:s3:::systema-bucket",
                "arn:aws:s3:::systema-bucket/*"
            ]
        }
    ]
}