コンテンツにスキップ

よくあるお悩みトピック/ユーザーのクロスアカウントアクセス環境実装

本サイトは Classmethod Cloud Guidebook (CCG) のデモサイトです

デモサイトのため、実際の内容と相違がある点にご留意ください。
クラスメソッドメンバーズをご契約中のお客様は下記リンクからアクセスください。
Classmethod Cloud Guidebook

はじめに

本ページでは マルチアカウント環境のユーザー認証 実現について説明します。 ここでいうユーザー認証とは、各AWS利用者が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ユーザーを作る方法です。 各アカウント上に認証情報を保持する必要があります。

img

各アカウントへIAMユーザーを展開するため、以下のようなデメリットがあります。

  • 『誰がどのAWSアカウントへアクセスできるか』の把握が困難
  • 『認証情報の複数管理』が大変 (これはセキュリティリスク増大にも繋がります)

1つのアカウントでIAMユーザーを管理して他アカウントにスイッチロール

IAMユーザー管理用アカウントで IAMユーザーを作成します。 各作業対象のアカウントには、 利用者の職務に対応した IAMロールを作成しておきます。 なお、この「IAMユーザー管理用アカウント」は Jumpアカウント と呼ばれることが多いです。

利用者は IAMユーザーへログイン後、各作業対象のアカウントへ スイッチロール(AssumeRole) してアクセス します。

img

Jumpアカウント上で認証情報を集中管理出来る点はメリットです。 しかし、現在はよりAWSマネージドに集中管理する手段(後述のIAM Identity Center)があるため、第一候補にはなりません。

実装周りは以下ブログが参考になります。

外部IDプロバイダーでユーザー管理して各アカウントにスイッチロール

外部IDプロバイダー(Active DirectoryやIDaaS)の認証情報を使って 各アカウントへアクセスする手法(Single Sign-On:SSO)です。

img

前提: SAMLについて

SSOの実現に Security Assertion Markup Language (SAML) を使用しています。 SAMLは IDプロバイダーによるユーザー認証を使って、ほかサービス(今回の例: AWS)で使える認証トークンを渡すための規格です。

SAMLについて詳しくは以下参照ください。

簡単に利用者のAWSアクセスの流れを説明します。 まず、事前に『IDプロバイダー』と 『AWS(サービスプロバイダー)』との間で信頼関係を結んでおく必要があります。

利用者は通常通りログインして、IDプロバイダーから認証されます。 その後 AWS(サービスプロバイダー) からアカウントへアクセスするための「IAMロールの一時セキュリティ認証情報」を受け取り、 AWSへアクセスできるようになります。

説明した流れの詳細は以下 AWS BlackBelt が参考になります。

img

認証情報は外部IDプロバイダーのものを使うので、 AWS環境内にて認証情報を管理する必要がありません。

以降でIAM SAMLを使ったアクセスパターンを 2つ紹介します。

アクセスパターンその1 #AWSアカウントごとに信頼関係を作る

img

そのまま横に拡張させたパターンです。 IDプロバイダーとの信頼関係は AWSアカウントごとに結ぶ必要があります。 IDプロバイダー側で「誰がどのAWSアカウントのどのロールにアクセスできるか」を集中管理できる構成です。

アクセスパターンその2 #代表1アカウントで信頼関係を作る

img

IDプロバイダーと信頼関係を結ぶ 代表 1アカウント( SAML連携用アカウント )を作るパターンです。 SAML連携用アカウントから 前述のJumpアカウントと同じように 各アカウントへスイッチロールします。

今後増えるアカウントに対して IDプロバイダーとの信頼関係と結ぶ手間は省けます。 IDプロバイダー視点ではアクセスする(見える)アカウントは SAML連携用アカウントのみ です。 集中管理の面ではデメリットになりえます。

上に紹介した 2パターンはどちらも一長一短あるので、要件に合わせて選択します。

AWS IAM Identity Centerで管理

AWS IAM Identity Center(旧称 AWS SSO)はAWS アカウントおよびクラウドアプリケーションへのアクセスの認証・認可を一元管理するサービスです。 AWS Organizations を有効化している場合は、追加料金無しで利用できます。

img

利用者は 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プロバイダー)

どの手段を選択すべきか

改めて「ユーザー認証の仕組み」の候補を掲載します。

ユーザーの管理方法 認証情報の管理場所 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 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に対する理解が必須になってきます。