はじめに

皆さんIdentity Center使ってますか？

小規模な環境であればIAMユーザー(ロール)＋スイッチロールで事足りるかと思いますが、環境が大規模になればなるほどIAM管理が煩雑になり、効率的なIAM管理が求められるようになってきます。
そこで利用可能なのがIdentity Centerです。Identity Centerは複数のアカウントに対して統一された権限でアクセスできるサービスであり、IAMロールを作成しようとすると、”Identity Centerを検討しましたか？"、というようなメッセージが出てきたり、AWSとしても推しているサービスだと思います。
また、最近リリースされたAWSサービスの中にはIdentity Center利用前提のサービスもあり、そういった点からIdentity Centerの利用が必要となるケースもあるでしょう。

今回はこのIdentity CenterのIdPとしてAWS MSADを利用する際のメリットについてまとめたいと思います。
それ以外のIdentity Centerの全容についてはここではあまり触れませんので、公式のDocsをご確認ください。

選択可能なIdP

まずサービス仕様的な話ですが、Identity CenterでIdPとして利用可能なのは以下の3つです。

Identity Centerディレクトリ
外部IDプロバイダー
Active Directory

Identity Centerディレクトリ

Identity Center作成時にデフォルトで作成されるディレクトリです。小規模な環境であればこちらで十分でしょう。
複数のアカウントで許可セットの形で権限の割り当てが可能ですので、統一的な権限管理という観点では十分に機能します。
一方で、結局AWS上でユーザー・グループの管理が必要であり、この点ではIAMによる管理と運用上の差はあまりないと思います。
他のアプリケーションとの統合・拡張性の観点では、Identity Centerの機能としてQuickSightなどのAWSサービスだけでなく、カスタマーマネージドアプリケーションに対しても連携が可能です。
詳細は以下のドキュメントをご確認ください。

Active Directory

Identity CenterではActive DirectoryをIdPとして利用することも可能です。
既に組織内にWindows環境がある場合、認証部分を統合管理出来ますので運用上のメリットとなります。
また、Identity Centerの機能としたAWSサービス/カスタマーマネージドアプリケーションとの連携の他に、ADのレベルでの連携も可能ですので、他システムとの連携といった観点ではこちらもメリットとなるでしょう。

外部IDプロバイダー

OktaやMicrosoft EntraIDをIdPとして利用する場合はこちらになります。
こちらもActive Directoryと同様、既に組織内でこれらのサービスを利用している場合は認証部分を統合管理でき、運用上のメリットとなります。
他アプリケーションの統合・拡張性の観点では、世の中の多くのSaaS製品でこれらのサービスとの連携機能が提供されていることから、ActiveDirectoryと比較してもより多くの点で優位があると思われます。

AWS MSADをIdPとして利用するメリット

前提

要件によってそれぞれの選択肢に対するメリット・デメリットは変わってきますので、ここでは以下のシチュエーションにおけるメリットである点、ご了承ください。

エンタープライズ企業でAWSマルチアカウント環境を運用しており、業務部門に対して標準化されたAWS環境を提供する
組織には明確なセキュリティポリシーが存在しており、遵守が必要となる
チームが管理できるのはAWS環境のみであり、組織全体で利用している別のITシステムは別のチームが管理している

セキュリティポリシーを柔軟に設定できる

まず1点目のメリットとして、セキュリティポリシーをMSAD側で管理できる点が挙げられます。
例えばパスワードポリシーについて、Identity Centerのデフォルトのディレクトリをそのまま利用する場合、以下の内容から変更できません。

パスワードでは、大文字と小文字が区別されます。
パスワードの長さは8文字から64文字の間でなければなりません。
パスワードには、次の 4 つカテゴリから少なくとも 1 文字を含める必要があります。
小文字 a〜z
大文字 A〜Z
数字 (0〜9)
英数字以外の文字 (~!@#$%^&*_-+=`|(){}]:;"'<>,.?/)
最後の3つのパスワードは再使用できません。
第三者から漏洩したデータセットを通じて公に知られているパスワードは使用できません。

一方で多くの企業では、セキュリティポリシーの中で、
・一定回数失敗時のロック
・15文字以上
・パスワード有効期限
などの要件を課していることがあり、デフォルトのディレクトリの設定ではこれらの要件を満たすことが出来ません。

MSADをIdPとして利用すると、パスワード要件はMSAD側の設定に従いますので、企業のセキュリティポリシーの要件を満たせる可能性が高いです。

これらの要件は、Identity Center ディレクトリで作成されたユーザーにのみ適用されます。認証用に IAM Identity Center 以外の ID ソース (Active Directory や外部の ID プロバイダーなど) を設定している場合、ユーザーのパスワードポリシーは IAM Identity Center ではなく、それらのシステムで定義および適用されます。

また、往々にして企業のセキュリティポリシーはWindowsのAD設定やLinuxの設定を見据えて定められていることが多く、ポリシーを素直に解釈して設定・適用しやすいのもメリットと言えるでしょう。

同一の人物に対して複数のユーザーを割り当てられる

Identity Centerではユーザー名とEメールアドレスが一意である必要があります。

IAM Identity Center では、ユーザーのすべてのユーザー名と E メールアドレスが、NULL ではない一意なものである必要があります。

そのため、Identity CenterデフォルトのディレクトリやOktaなどの外部IDプロバイダをIdPとして利用する場合、一人の人間に対して1つの(Identity Centerの)ユーザーが割り当てられることになります。

一方、エンタープライズなAWSマルチアカウント環境を考えると、同じOrganizationsの中で本番・検証・開発のOUが分離されており、企業のセキュリティポリシーとしてこれらの環境を認証の観点でも分割することを求められるケースがあります。

このとき、IdPとしてMSADを利用すれば、本番・検証・開発の環境毎にユーザーを用意しておくことでIdentity Centerのユーザーを分けることができ、認証観点での環境分割を実現することが出来ます。
(この場合はemails[?primary].valueが重複しないよう、属性マッピングを適宜調整してください)

チーム内で管理を完結しやすい

企業のEntra IDの認証情報でAWSにアクセスさせたい、というのはよくあるシチュエーションだと思います。
一方、エンタープライズ企業において、Entra IDを管理するチームとAWS環境を管理するチームが同じということはまずありません。
その結果発生する問題として聞かれるのが、リードタイムの長期化です。

例えば新しくAWSを利用したい利用者が現れた場合

利用者はまずEntra ID管理チームにグループ作成を依頼する
Entra ID管理チームがグループを作成する
AWS管理チームは利用者からグループ情報をヒアリングし、グループをIdentity Centerに同期する
AWS管理チームは許可セットの紐づけを行う

このやりとりが利用者が増えるたび、追加・変更・削除のたびに発生しますからちょっと大変ですよね。

AWS管理チームが管理できるMSADをIdPにする場合、やりとりが利用者とAWS管理チームで完結しますので、短期のリードタイムで対応出来るようになります。
プラットフォームの拡大・利用者の増加による手続きの煩雑化・リードタイムの長期化は運用フェーズにおけるよくある課題の一つですので、これもMSADを利用する大きなメリットと思います。

まとめ

今回は私の実体験も交えて、Identity CenterのIdPとしてMSADを選択したときのメリットを記載しました。
読んでいただくと分かる通り、本記事は色々な前提をおいており、実際はシチュエーションによって最適なIdPは異なります(当然ですが)。
あまり詳しく書いていませんが、MSADを利用するということはADの運用が発生するということですので、デフォルトのディレクトリや外部のIDプロバイダと比較して運用負荷が高くなる可能性もあります。
実際の案件では要件をもとに適切なものを選択するようにしてください。
例えば、できるだけ認証基盤を統一したい、というような方針を持つ企業であれば、Okta・Entra IDのような一つの外部IDプロバイダに極力寄せるべきでしょう。
もし対応方針が、認証基盤を適切な粒度で分離したい、ということでしたら、本記事の内容は参考になるかと思います。

ここまで読んでいただきありがとうございました。