よくあるお悩みトピック/ユーザーのクロスアカウントアクセス環境実装
本サイトは Classmethod Cloud Guidebook (CCG) のデモサイトです
デモサイトのため、実際の内容と相違がある点にご留意ください。
クラスメソッドメンバーズをご契約中のお客様は下記リンクからアクセスください。
Classmethod Cloud Guidebook
本ページの要旨
ユーザー管理の大方針
- 認証情報は可能な限り集約管理する
ユーザー管理のアーキテクチャ
- 各アカウントでIAMユーザーを管理
- 1つのアカウントでIAMユーザーを管理して他アカウントにスイッチロール
- 外部IDプロバイダーでユーザー管理して各アカウントにスイッチロール
- AWS IAM Identity Centerで管理(独自IDストア or 外部IDプロバイダー)
どのアーキテクチャを選択すべきか
- まずは IAM Identity Center 活用を検討する
- 社内で既存の認証基盤がある場合は、それをAWSアカウントアクセスに活用できないか検討する
ユーザー管理の大方針
大方針として 認証は可能な限り集約管理する ことを意識します。 ここでいう認証情報はAWSアカウントへサインインするための情報、 つまりIDやパスワード、アクセスキーです。
アンチパターンとしては『各アカウントにIAMユーザーを作成する方法』があります。 この方法は認証情報が各アカウントに散らばってしまい管理が煩雑になります。 セキュリティリスクにも繋がるため非推奨です。
ユーザー管理のアーキテクチャ
| アーキテクチャ | 認証情報の管理場所 | AWS Organizationsの必要有無 | 実装工数 | 利用者のAWSサインイン方法 | 推奨度 |
|---|---|---|---|---|---|
| 各アカウントでIAMユーザーを管理 | 各AWSアカウント | - | 中 | マネジメントコンソールへサインイン | 非推奨 |
| 1つのアカウントでIAMユーザーを管理して他アカウントにスイッチロール | Jumpアカウントで一元管理 | - | 大 | マネジメントコンソールへサインインしてからスイッチロール | - |
| 外部IDプロバイダーでユーザー管理して各アカウントにスイッチロール | 外部IDプロバイダーで一元管理 | - | 中 | 外部IDプロバイダーのポータルからサインイン | - |
| AWS IAM Identity Centerで管理(独自IDストアでユーザー管理) | IAM Identity Centerで一元管理 | 必須 | 小 | AWS IAM Identity CenterのAWSアクセスポータルからサインイン | 推奨 |
| AWS IAM Identity Centerで管理(外部IDプロバイダーでユーザー管理) | 外部IDプロバイダーで一元管理 | 必須 | 小 | AWS IAM Identity CenterのAWSアクセスポータルからサインイン 外部IDプロバイダーのポータルからサインイン |
推奨 |
それぞれの仕組みについて、以降で詳しく説明します。
各アカウントでIAMユーザーを管理
注意
マルチアカウント管理において、この方法は非推奨です。
各AWSアカウントへ IAMユーザーを作る方法です。 各アカウント上に認証情報を保持する必要があります。
各アカウントへIAMユーザーを展開するため、以下のようなデメリットがあります。
- 『誰がどのAWSアカウントへアクセスできるか』の把握が困難
- 『認証情報の複数管理』が大変 (これはセキュリティリスク増大にも繋がります)
1つのアカウントでIAMユーザーを管理して他アカウントにスイッチロール
IAMユーザー管理用アカウントで IAMユーザーを作成します。
各作業対象のアカウントには、 利用者の職務に対応した IAMロールを作成しておきます。
なお、この「IAMユーザー管理用アカウント」は Jumpアカウント と呼ばれることが多いです。
利用者は IAMユーザーへログイン後、各作業対象のアカウントへ スイッチロール(AssumeRole) してアクセス します。
Jumpアカウント上で認証情報を集中管理出来る点はメリットです。 しかし、現在はよりAWSマネージドに集中管理する手段(後述のIAM Identity Center)があるため、第一候補にはなりません。
実装周りは以下ブログが参考になります。
外部IDプロバイダーでユーザー管理して各アカウントにスイッチロール
外部IDプロバイダー(Active DirectoryやIDaaS)の認証情報を使って 各アカウントへアクセスする手法(Single Sign-On:SSO)です。
前提: SAMLについて
SSOの実現に Security Assertion Markup Language (SAML) を使用しています。 SAMLは IDプロバイダーによるユーザー認証を使って、ほかサービス(今回の例: AWS)で使える認証トークンを渡すための規格です。
SAMLについて詳しくは以下参照ください。
簡単に利用者のAWSアクセスの流れを説明します。 まず、事前に『IDプロバイダー』と 『AWS(サービスプロバイダー)』との間で信頼関係を結んでおく必要があります。
利用者は通常通りログインして、IDプロバイダーから認証されます。 その後 AWS(サービスプロバイダー) からアカウントへアクセスするための「IAMロールの一時セキュリティ認証情報」を受け取り、 AWSへアクセスできるようになります。
説明した流れの詳細は以下 AWS BlackBelt が参考になります。
認証情報は外部IDプロバイダーのものを使うので、 AWS環境内にて認証情報を管理する必要がありません。
以降でIAM SAMLを使ったアクセスパターンを 2つ紹介します。
アクセスパターンその1 #AWSアカウントごとに信頼関係を作る
そのまま横に拡張させたパターンです。 IDプロバイダーとの信頼関係は AWSアカウントごとに結ぶ必要があります。 IDプロバイダー側で「誰がどのAWSアカウントのどのロールにアクセスできるか」を集中管理できる構成です。
アクセスパターンその2 #代表1アカウントで信頼関係を作る
IDプロバイダーと信頼関係を結ぶ 代表 1アカウント( SAML連携用アカウント )を作るパターンです。 SAML連携用アカウントから 前述のJumpアカウントと同じように 各アカウントへスイッチロールします。
今後増えるアカウントに対して IDプロバイダーとの信頼関係と結ぶ手間は省けます。 IDプロバイダー視点ではアクセスする(見える)アカウントは SAML連携用アカウントのみ です。 集中管理の面ではデメリットになりえます。
上に紹介した 2パターンはどちらも一長一短あるので、要件に合わせて選択します。
AWS IAM Identity Centerで管理
AWS IAM Identity Center(旧称 AWS SSO)はAWS アカウントおよびクラウドアプリケーションへのアクセスの認証・認可を一元管理するサービスです。 AWS Organizations を有効化している場合は、追加料金無しで利用できます。
利用者は IAM Identity Center 専用のポータル画面へログインしてから、 各アカウントへアクセスします。
アクセスの仕組み自体は 前述の IAM SAML と同じですが、 よりAWSマネージド になっています。 例えば AWSアカウントへのIAMロールの作成が自動化されています。
IAM Identity CenterのIDストアは以下から選択します(1つのみ)。
- AWS IAM Identity Center独自IDストア
- 外部IDストア (Active Directory)
- 外部IDストア (Azure ADやOktaなどのIDプロバイダー)
どのアーキテクチャを選択すべきか
まずは IAM Identity Center を採用できないか 、検討しましょう。 アクセス先のメンバーアカウント上に必要なIAMロールをAWS側で作成してくれます。 より簡単にアクセス基盤を作成できて、運用負荷を軽減できます。
IAM Identity Center を使う場合は、 社内要件に併せてIDストアを指定 します。 デフォルトでは「AWS IAM Identity Center独自IDストア」となっています。 社内環境にて Azure AD や Okta などの認証基盤を利用されている場合は、それをIDストアとして活用できます。
「社内でID・アクセス管理サービスを活用しており、 AWS含めアプリケーションのアクセスを集中管理したい」といった要件がある場合は 既存IDプロバイダー活用(IAM SAML) も候補に上がります。 IDプロバイダー側で、「誰がどのアカウントにどの権限でアクセスするのか」を管理できるようにします。
AWS Organizationsを使えない環境で、活用できる既存IDプロバイダーも無い場合は、 IAMユーザーからスイッチロール する仕組みを利用します。 AWSアクセスに必要な認証情報をユーザー管理アカウント(Jumpアカウント)へ集約できます。 しかし、スイッチロールアクセスの仕組みを1から作成するため、AWS IAMに対する理解が必須になってきます。