本記事は ガバメントクラウド Advent Calendar 2024 の 14 日目の投稿となります。
@takeda_h です。みなさん元気にガバメントクラウドの CSP 環境にシングルサインオン（SSO）してますか！？AWS だとなんとなく AWS access portal のリンク踏んでマネジメントコンソールにアクセスすることも多いと思うのですが、これがどうやって実装されているか気になったりしないでしょうか？
そこで、ガバメントクラウドをお題に、AWS 環境への SSO について、具体的には AWS IAM Identity Center を使った SSO について調べて実際に設定してみましたので、よろしければお付き合いください。
ガバメントクラウドの AWS 環境へのアクセスについて
ガバメントクラウドで使う CSP 環境へのアクセスは、GCAS アカウントによるシングルサインオン（SSO）で行うことになっています。
GCAS とは
ここで、GCAS とは何でしょうか？Google Cloud の Web サイト Google Cloud が、デジタル庁ガバメントクラウドの利用を促進するサーバレスの Web アプリケーション開発を支援 から引用してみます。
デジタル庁ガバメントクラウドの利用を支援する Web アプリケーション「GCAS（Government Cloud Assistant Service：ガバメントクラウド活用支援サービス）」が開発され、Google Cloud は、クラウド サービスやアーキテクティングの面からこの構築をご支援しています。GCAS はデジタル庁内製主導で開発され、2023 年 4 月より提供開始されています。
ガバメントクラウド移行の本格化に向け、今後、省庁や 1,741 ある地方公共団体、準公共と呼ばれる領域からのクラウド利用申請が急激な勢いで増加していくことが予測されています。これを自動化・効率化し、デジタル施策推進を支援する仕組みが GCAS です。
ユーザー登録・認証
Cloud Identity で多要素認証や端末の識別を行い、シングル サインオン（SSO）先の制御や管理を行います。各省庁職員に限らず、地方公共団体職員や開発ベンダーも対象としたユーザー認証が可能です。
GCAS は、SSO の機能を持つ外部 Identity Provider (IdP) としての役割もあるものと理解できます。
AWS 環境へのアクセス管理の実装
次に SSO について、デジタル庁の ガバメントクラウド概要解説 を見てみます。以下引用です。
3.3.2 ユーザーの全体像
管理者権限以外の各ユーザーアカウントは令和6年度より展開される、GCASアカウントによる各CSP環境へシングルサインオン機能の利⽤前後で以下の対応とする。
シングルサインオン機能利⽤開始後
GCASアカウントによる各CSP環境へのシングルサインオンが可能になるため、各CSP環境内でユーザーアカウント作成は不要であり禁⽌する。
それでは、ガバメントクラウドの AWS 環境へのアクセスについての実装はどうなっているでしょうか？
同じくデジタル庁のガバメントクラウド AWS 利用ガイドの アカウント構成説明(AWS編) を見ると、デジタル庁の Organizations による管理が行われ、各利用組織（地方自治体など）ごとに OU やユーザーが払い出される仕組みとなっていることが分かります。
以上のことから、ガバメントクラウドで使う AWS 環境へのシングルサインオンの実装は、IAM Identity Center が使われていることが分かります。
今回試してみたい AWS への SSO について
ガバメントクラウドの AWS 環境では、デジタル庁が Organizations と IAM Identity Center 及び外部 IdP である GCAS を管理しており、地方自治体が直接 SSO の設定をすることなく運用ができるようになっており、地方自治体にとっては運用負荷が軽減されています。
一方で、AWS の利用においては、認証認可が極めて重要なため、SSO の実装を知っておくことは役に立つと思います。
そこで今回、個人の AWS アカウントでガバメントクラウドに見立てた Organizations を作り、外部 IdP と連携した IAM Identity Center での SSO の設定を試してみたいと思います。
外部 IdP には Entra ID を採用しました。ちなみに Organizations と IAM Identity Center を使う分には AWS 利用料はかかりません。外部 IdP にかかる費用だけでできます。
ちなみに今回は、私が よくできた社畜なので 個人で契約している Microsoft 365 Business Premium があり、これには IAM Identity Center に Entra ID グループを自動プロビジョニングするのに必要な Entra ID P1 ライセンスが付いているので、これを使いたいと思います（真っ当な人は真似しないで、月額 899 円の Entra ID P1 ライセンスで試すとよいです。もっと真っ当な人は会社の金で検証すべきです。）
目標のシングルサインオン構成
次の図のとおり、外部 IdP として Entra ID に作った特定のグループとそのグループに所属するユーザーが、IAM Identity Center へ自動プロビジョニングされ、これら IAM Identity Center ユーザーごとに、Organizations 内の各 AWS アカウントに必要な権限を持って SSO できることを目指します。
それでは早速やっていきましょう。
Organizations の作成
Organizations の管理者アカウントにしたい AWS アカウントのマネジメントコンソールから、Organizations コンソールで「組織を作成」します。
組織を作成したら、Organizations のメンバーアカウントにする AWS アカウントを、Organizations コンソールから追加するか、既存の AWS アカウントがあるなら招待します。詳細は公式のチュートリアルを参照。
なお、Organizations の機能は OU 単位で AWS アカウントを管理したり、SCP で AWS アカウントの操作権限を統制したり、こちらもガバメントクラウドでは重要な役割を果たしていると思われますが、今回は OU や SCP については割愛します。
IAM Identity Center の有効化
Organizations の管理者 AWS アカウントのマネジメントコンソールから、IAM Identity Center コンソールで「IAM Identity Center を有効」にします。
外部 Identity Provider (IdP) を設定する
IAM Identity Center からメタデータファイルをダウンロード
IAM Identity Center コンソールから、「設定」→「アイデンティティソース」の「Actions」から「アイデンティティソースの変更」に進みます。「アイデンティティソースを選択」で「外部 ID プロバイダー」を選択します。
「メタデータファイルをダウンロード」からメタデータファイルを適当な場所にダウンロードします。
この画面は開いたまま、Microsoft Entra 管理センターを開きます。
Microsoft Entra 管理センターで SAML のセットアップ
Microsoft Entra 管理センターから、「ID」→「アプリケーション」→「エンタープライズ アプリケーション」を開き、「AWS IAM Identity Center」を追加します。
「シングル サインオン」から「SAML1 によるシングル サインオンのセットアップ」で「メタデータ ファイルをアップロードする」を開き、先ほどダウンロードしたメタデータファイルをアップロードします。
「基本的な SAML 構成」が正しく設定されたら、「SAML 証明書」の「フェデレーション メタデータ XML」を適当な場所にダウンロードします。
IAM Identity Center コンソールに戻ります。
IAM Identity Center でアイデンティティソースを変更
IAM Identity Center コンソールで、先ほどダウンロードしたフェデレーションメタデータ XML をアップロードします。
問題がなければ次の画面に進み、「ID ソースの変更」をします。
詳細な手順は AWS、Microsoft それぞれに公式のチュートリアルがあるのでこちらを参照しましょう。
自動プロビジョニングの設定
IAM Identity Center で自動プロビジョニングを有効化
IAM Identity Center コンソールで、「設定」から自動プロビジョニングを「有効にする」を実行します。
SCIM2 エンドポイントとアクセストークンをコピーしておきます。
Microsoft Entra 管理センターでプロビジョニングモードの変更
Microsoft Entra 管理センターから、「ID」→「アプリケーション」→「エンタープライズ アプリケーション」→「AWS IAM Identity Center」に進み、「プロビジョニング」を開きます。
「プロビジョニングモード」を自動に設定し、先ほどコピーした SCIM エンドポイントを「テナントの URL」に、アクセストークンを「シークレット トークン」にそれぞれ設定します。
「マッピング」から「Provision Microsoft Entra ID Groups」と「Provision Microsoft Entra ID Users」を有効に設定します。
Entra ID グループの割り当て
Entra ID で作成した特定のグループを IAM Identity Center のユーザーに自動で割り当てられるようにします。
Microsoft Entra 管理センターから、「ID」→「アプリケーション」→「エンタープライズ アプリケーション」→「AWS IAM Identity Center」に進み、「ユーザーとグループ」から「ユーザーまたはグループの追加」をします。
ここでは Entra ID で事前に「AWSAdmins」「AWSDevelopers」という名前のグループを作っておき、これを追加しました。Entra ID でこれらのグループに属するユーザーを作成すると自動的に IAM Identity Center へ追加されるようにするためです。
プロビジョニングが成功すると、以下のような画面となります。グループがプロビジョニングされたことで、グループに所属しているユーザーもプロビジョニングされていることが分かります。
ちなみに「AWSDevelopers」グループに所属している Entra ID ユーザーは次の通りです。これらのユーザーも IAM Identity Center にプロビジョニングされているはずです。
IAM Identity Center コンソール側でもグループが作成されていることが確認できます。
「AWSDevelopers」グループに所属しているユーザーもちゃんとプロビジョニングされていました。
こちらも Microsoft の公式チュートリアルに詳細があります。
IAM Identitiy Center でグループに許可セットを割り当て
許可セットの割り当てが一番重要なポイントです。IAM Identity Center のユーザーが、Organizations のどの AWS アカウントに対して、どういったアクセスを許可するかのポリシーを設定することで、権限を統制することができる肝となる機能です。
許可セットの作成
事前に IAM Identity Center コンソールで許可セットを作成します。
今回は検証のため、「事前定義された許可セット」から、「AdministratorAccess」と「SystemAdministrator」の許可セットを作成しています。本番運用ではカスタム許可セットを作成して実現したい統制を設計するのが良いと思います。
許可セットを作成できました。
グループへ許可セットを割り当て
IAM Identity Center コンソールから「マルチアカウント許可」→「AWS アカウント」に進むと、Organizations の OU と AWS アカウントが表示されますので、許可セットを設定したい AWS アカウントにチェックを入れて「ユーザーまたはグループを割り当て」を実行します。
まずは割り当てるグループを選びます。ここでは sandbox という AWS アカウントに、これまでの作業で IAM Identity Center に自動プロビジョニングした「AWSAdmins」グループのユーザーがアクセスできるよう、割り当てをします。
次に割り当てたグループに許可する許可セットを選びます。ここでは「AWSAdmins」グループに「AdministratorAccess」「SystemAdministrator」許可セットを割り当ててみます。
同様に「AWSDevelopers」グループに「SystemAdministrator」許可セットを割り当てました。
許可セットの割り当て状況は以下のとおり確認できます。
許可セットの割り当てが完了したら、いよいよ AWS アカウントのマネジメントコンソールに期待したとおりアクセスできるか確認します。
AWS access portal の確認
IAM Identity Center コンソールのダッシュボードにある AWS access portal URL へアクセスします。
Entra ID の画面に遷移するので、Entra ID で今回 IAM Identity Center へ自動プロビジョニングした Entra ID ユーザーで正しく認証したら、AWS access portal に画面が遷移します。
これまでの設定で正しくグループや許可セットを割り当てた通りに Organizations の AWS アカウントが表示できており、リンクからマネジメントコンソールにアクセスして、正しく権限が設定されていることが確認できれば成功です。
いかがでしたでしょうか？ガバメントクラウドでも、恐らく同じような形でデジタル庁が IAM Identity Center を管理しているのだと思います。
IAM Identity Center を使うことの利点は、AWS CLI などを使う時にも IAM Identity Center ユーザーで認証認可ができるため、IAM ユーザーを作成してアクセスキーを発行しなくてもよいことが挙げられますので、ぜひ個人開発の場面でも使うといいと思います。
なお、ガバメントクラウドは基本的に閉域で使うため、閉域のオンプレミス環境から AWS CLI を IAM Identity Center ユーザーで認証することは難しいかもしれません。