ある会社は、AWS アカウントへのサインインを AWS IAM Identity Center で管理します。社内にはオンプレミスの Active Directory のフォレストが 2 つあり、どちらのフォレストの従業員も、普段の認証情報のまま AWS アカウントへサインインできる必要があります。 ソリューションアーキテクトは、どのステップの組み合わせを完了する必要がありますか。 (2 つ選択)
2 つのフォレストの従業員を、普段の認証情報のまま IAM Identity Center から AWS アカウントへサインインさせる手順を選ぶ
AWS Managed Microsoft AD を作成し、2 つのフォレストそれぞれと双方向の信頼関係を結ぶ。
AWS Managed Microsoft AD は AWS が運用する実際の Microsoft Active Directory で、オンプレミスのフォレストと信頼関係を結べます。2 つのフォレストそれぞれと双方向の信頼を構成すれば、どちらの従業員も自分のフォレストで認証されたまま、この 1 つのディレクトリを通じて扱えるようになります。IAM Identity Center はドメインからユーザーとグループの情報を読み取って同期するため、一方向の信頼では動作しません。
従業員アカウントを AWS 側に複製する必要がなく、フォレストでの管理はそのまま続けられます。IAM Identity Center は、このディレクトリのユーザーだけでなく、信頼関係で接続されたドメインのユーザーも扱えます。
片方のフォレストに AD Connector を接続し、IAM Identity Center の ID ソースにする。
AD Connector は、ディレクトリへの要求をオンプレミスの Active Directory へ転送するディレクトリゲートウェイで、AWS 側に情報をキャッシュせずに既存の認証情報を使わせられます。接続したフォレストの従業員は、この構成で普段の認証情報のままサインインできます。
しかし AD Connector はオンプレミスのドメインと 1 対 1 で対応し、推移的な信頼 (信頼関係が連鎖してほかのドメインにも及ぶ関係) もサポートしません。ID ソースにつながるのは片方のフォレストだけで、もう一方のフォレストの従業員は普段の認証情報でサインインできないため、要件を満たせません。
ID ソースを AWS Managed Microsoft AD に変更し、グループにアクセス許可セットを割り当てる。
IAM Identity Center の ID ソース は、最初は IAM Identity Center ディレクトリになっています。これを信頼関係を結んだ AWS Managed Microsoft AD に変更すると、IAM Identity Center はそのディレクトリを通じて、信頼先のドメインのユーザーとグループも扱えるようになります。
あとは各フォレストのグループにアクセス許可セットを割り当てれば、どちらのフォレストの従業員も普段の認証情報で AWS アカウントへサインインできます。ディレクトリを用意する手順だけでは誰もサインインできないため、ID ソースの変更と割り当てまで含めて 2 つ目の正解になります。
両フォレストのユーザーとグループを、IAM Identity Center ディレクトリに作り直す。
IAM Identity Center ディレクトリ は IAM Identity Center に最初から備わっている ID ストアです。ここにユーザーとグループを作成すれば、そのまま ID ソースとしてアクセス許可セットを割り当てられ、サインインの入口としては成立します。
ただし従業員アカウントは、それぞれのフォレストで管理されています。ここに作成したユーザーはフォレストとは別のアカウントになるため、普段のディレクトリの認証情報ではサインインできません。入社・異動・退職やパスワードの変更も、フォレストと IAM Identity Center の 2 か所で反映し続けることになります。
各 AWS アカウントへディレクトリ共有を設定し、従業員のサインインに使う。
ディレクトリ共有 は、AWS Managed Microsoft AD をほかの AWS アカウントから使えるようにする機能で、共有先のアカウントの Amazon EC2 インスタンスをドメインに参加させられます。
しかし本問で必要なのは、従業員が AWS アカウントへサインインすることです。サインインの入口は IAM Identity Center 側にあるため、ディレクトリの共有範囲を広げても、従業員のコンソールへのアクセスは付与されません。2 つのフォレストを信頼関係でつなぐ手順にも、ID ソースの設定にもならないため誤りです。
IAM Identity Center の ID ソースに Active Directory を使う問題は、認証元のドメインやフォレストの数から考えます。
・ドメインが 1 つ — AD Connector でも足ります。AD Connector はドメインと 1 対 1 で対応して推移的な信頼をサポートせず、同じフォレストでも子ドメインごとに要ります。IAM Identity Center に接続できるディレクトリは一度に 1 つです。
・複数のドメインやフォレスト — AWS Managed Microsoft AD を作り、各フォレストと双方向の信頼関係を結んで束ねます。IAM Identity Center は信頼先のドメインのユーザーとグループも読み取って同期するため、一方向の信頼では動作しません。
・作り直さない — 信頼関係があれば認証は元のフォレストで行われるため、AWS 側でアカウントを作り直す案は外します。
・置き場所 — ディレクトリは管理アカウントか委任管理者アカウントに置き、IAM Identity Center は同じリージョンで有効にします。
「2 つのフォレスト」「普段の認証情報で」と並んだら、信頼関係で束ねた AWS Managed Microsoft AD を選びます。