🙃

マルチアカウント環境でAWS IAM Identity CenterとEntra IDを連携する

に公開

AWSでマルチアカウント環境を管理するけど、ユーザ管理はEntra IDのようにこれまで使っていたIdPを使いたいよ!と相談されたことはありますか?
わたしはあります。

この記事では、AWSでマルチアカウント環境を管理する上でIdC/Entra IDを利用したユーザ認証の管理方法ついて紹介します。

AWS IAM Identity Center(IdC)とは

IdCとは複数のAWSアカウントやアプリケーションへのアクセスをまとめて管理することができるサービスです。

IdCでできること

主な機能としては以下があります。

  • ユーザとグループの管理
    IdCグループ、IdCユーザをAWS内で作成、管理することができます。
    また既存のIDソースと連携が可能なので、ユーザ管理はEntra IDやOktaにお任せしてユーザ・グループ情報だけ同期するということも可能です。

  • 権限の管理
    IdCグループ、IdCユーザに対して、アカウントを指定して権限を割り当てることができます。この権限のことを許可セットと言います。

    図:許可セット割り当てのイメージ

  • シングルサインオン(SSO)
    許可セットでIdCユーザに権限を割り当てた同じ組織(OU)配下のAWSアカウントに対して、SSOをすることができます。

ログイン
図:IdCのログイン画面

アクセスポータル
図:ログイン後に表示されるアクセスポータル
アカウントがずらっとならびます。

マルチアカウント環境におけるユーザ認証・認可の管理

AWSでマルチアカウント環境を実装する際、AWSマネージドサービスのControlTowerを利用することが多いと思います。
ControlTowerをデプロイする管理アカウントは環境全体に対して非常に強い権限を持つことから、普段使いするアカウントとしてはおすすめされません。
その一方で、ユーザ管理については定期的な棚卸等で利用する機能となります。
そのため、ユーザ管理は管理アカウントが別のAWSアカウントにIdCの管理を委任して管理をすることがセキュリティ的に望ましいです。


図:委任イメージ図


図:委任を設定する画面
管理アカウントのIdCから委任された管理者の設定ができます

※参考:
マルチアカウントの考え方や実装方法(ControlTower、Organizations等)についてまず学習したい場合は、以下のAWSブログをご覧ください。
スタートアップにおけるマルチアカウントの考え方と AWS Control Tower のすゝめ

(補足)IAMとの違い

IdC同様にユーザ認証・認可を管理するAWSサービスとしてIAMがあります。
IAMは単一のAWSアカウント内でユーザと権限を管理することができるサービスで、サービスとしてSSOの機能を持っていません。
そのため、マルチアカウント環境でユーザ認証・認可の管理をする場合はIdCを利用するほうが実装負荷の軽減が可能になります。

IdCと外部IdPの連携

冒頭にも記載しましたが、AWSでマルチアカウント環境へのユーザ認証・認可の管理は実装しながら、ユーザやグループ自体の管理は元々利用しているIdP(Identity Provider)をそのまま使いたいというニーズは多いと思います。

これが実装できると、ユーザ作成や削除等の社内のワークフローは変えずに、かつAWS用にIDを増やすことなく一人一つのユーザIDを管理するだけで良い状態になります。(嬉しい)

ここでは、IdCと外部IdPの連携方法についてEntra IDを例に解説します。

IdCを利用したSSO認証

IdCとEntra ID間で事前に信頼関係を持たせることで、ユーザ管理およびユーザに対する認証はEntra IDで実施し、IdCでマルチアカウントへの権限管理を実施することで、シングルサインオンを実現します。
また、Entra IDで管理するユーザをIdCに同期させること(SCIM[1])が可能で、IdCとEntra ID間の場合は通常40分間隔で実施されます。このように自動で同期させることを自動プロビジョニングと呼びます。

※参考:
チュートリアル: 自動ユーザー プロビジョニング用に AWS IAM Identity Center を構成する

SSO認証の流れを図にすると以下のようになります。
SSO認証のフロー

  1. ユーザはクライアントから組織のポータルに接続し、IDプロバイダへアクセスする
  2. Entra IDのアイデンティティストアでユーザ認証を実施する
  3. ユーザが認証されると、IDプロバイダはユーザ属性情報を含むSAML[2]アサーションを生成し、クライアントへ送信する
  4. クライアントはSAML用のサインインエンドポイントへSAMLアサーションを送付する
  5. サインインエンドポイントはSAMLアサーションのユーザ属性情報を元に、STS(Security Token Service)を使用して一時的な認証情報をリクエストする
  6. AWSはIdCアクセスポータルのURLをリダイレクトとして送信する
  7. クライアントのブラウザはIdCアクセスポータルへリダイレクトされる
  8. ユーザはIdCアクセスポータルでログインするアカウントとロールを選択し、各アカウントへログインする

IdCと外部IdPとの連携設定

IdCと外部IdPの連携方法については、以下のAWSドキュメントの通りに設定をすると実施可能です。
Microsoft Entra ID および IAM アイデンティティセンターによる SAML と SCIM の設定
画面のイメージもつけて理解したいよ、という方は以下の記事がとても参考になります。
AWS IAM Identity CenterとMicrosoft Entra IDを統合させてみる

最後にEntra IDと連携する際の留意事項について、実際にやってみた観点から記載します。

  • 自動プロビジョニングのためにEntra ID上の各ユーザのメールアドレスは一意である必要があります。
  • SCIM の同期が機能するためには、すべてのユーザーが First name (名)、Last name (姓)、Username (ユーザーネーム)、Display name (表示名) の値を指定されている必要があります。
  • SCIM では多値属性 (特定のユーザーに対する複数の E メールや電話番号など) は提供されていません。
  • IdCはEntra IDからユーザー属性を同期するが、属性の削除は同期されません。属性値の変更が同期されます。
脚注
  1. SCIMはユーザーID情報を異なるシステム間で自動的にやり取りするためのオープンな標準プロトコル。正式名称はSystem for Cross-domain Identity Management。 ↩︎

  2. SAMLはIdP(今回はEntra ID)とSP(今回はIdC)間で認証および認可のデータを交換するための標準プロトコル。正式名称はSecurity Assertion Markup Language。 ↩︎

Discussion