【ガイドライン】AWS lAM・AWS lAM Identity Center

作成日: 2023/08/07, 更新日: 2023/08/10

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

AWS lAM とは？
AWS lAM Identity Center とは？
導入検討
1. ① AWS アカウントはどのような契約形態か？
ガイドライン策定
1. ① ガイドラインに登場するアクターの整理
2. ② 役割分担整理（IAM 権限委譲の範囲・方法の決定）
関連ドキュメント

AWS lAM とは？

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

AWS lAM Identity Center とは？

AWS lAM 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 を参照ください。

ガイドライン策定

① ガイドラインに登場するアクターの整理

ガイドラインを策定するにあたって、組織内のステークホルダーの役割を明確化することが重要です。
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 ユーザー、ロールなどを作成する必要があるため、管理コストが増加する可能性があります。