AWS Startup ブログ

G Suite アカウントを用いた AWS へのシングルサインオン

皆さん、こんにちは。Startup Solutions Architect の松田です。

今回はセキュリティのお話です。今日、お客様は AWS のマネジメントコンソールへのログインのセキィリティを強化するために、様々な選択肢をお選びいただくことが可能になっています。一部のお客様は IAM User の管理を楽にするために、外部サービスのアカウントを用いて AWS のマネジメントコンソールへのログインを行っております。

この手法がスタートアップにとって有用なセキュリティオプションとなる場合が多くあります。例えば、フリーランスのエンジニアやインターンなど人の出入りが激しいスタートアップにとって、アカウントを一元管理出来ることはセキュリティの向上に繋がります。あるいは非エンジニアの社員が Amazon S3 のファイルを参照したり更新したりするケースも有るかと思います。

今回はスタートアップで利用が多いと思われる G Suite を例に、外部アカウントを用いた SAML 認証の設定についてご説明致します。なお、あくまで一例であり SAML 2.0 に対応していれば他の IdP もご利用頂くことは可能になっております。代表的な IdP については「サードパーティの SAML ソリューションプロバイダーと AWS の統合」に参照すべきドキュメントの記載があります。

※ 内容は一部 How to Set Up Federated Single Sign-On to AWS Using Google Apps と重複しますが、2019年5月時点の内容で書き直しております。

概要

今回ご紹介するソリューションでは、G Suite ユーザーに AWS マネジメントコンソールへのアクセスを許可するために、AWS Identity and Access Management（IAM）で SAML IDプロバイダー (IdP) を作成して Google IdP との信頼を確立します。AWS の管理者は認証に関する責任を信頼されたIdP (今回はG Suite) に委任し、SAML 2.0 を使用します。これにより、IAM Role はフェデレーションユーザーに AWS マネジメントコンソールにサインインして AWS のリソースにアクセスするためのアクセス許可を付与できます。

設定した後、認証プロセスは上の図の番号の順に処理されます。

  1. ユーザーは、ブラウザで AWS への G Suite 上の SSO リンクをクリックします。ユーザーがまだログインしていない場合は、G Suite アカウントのログインポータルに移動します。
  2. ポータルは、ユーザーの G Suite 認証情報を認証し、ユーザーを識別するアサーションとユーザーに関する属性を含む SAML 認証応答を生成します。ポータルはこの応答をユーザーのブラウザに送信します。
  3. ユーザーのブラウザは AWS サインインエンドポイントにリダイレクトし、SAML Assertion を送信します。
  4. AWS サインインは AssumeRoleWithSAML API を(背後で)呼び出して一時的なセキュリティ認証情報をリクエストしてから、それらの認証情報を使用して AWS マネジメントコンソールのサインイン URL を作成します。
  5. AWS はサインイン URL をリダイレクトとしてユーザーのブラウザに返します。
  6. ユーザーのブラウザは AWS マネジメントコンソールにリダイレクトします。SAML 認証応答に複数の IAM Role に対応する属性が含まれている場合、ユーザーはコンソールへのアクセスに使用する IAM Role を選択するように求められます。(今回ご紹介する手順では単一の Role を登録しています。)フェデレーションユーザーの観点から見ると、このプロセスは透過的に行われます。ユーザーは G Suite ポータル上でアイコンをクリックするだけで、AWS マネジメントコンソールに到達することができます。ユーザー名とパスワードを入力するなど別の認証情報は必要はありません。IAM Role に付加された IAM Policy によって、フェデレーションユーザーがコンソールでどの権限を持っているかが決まります。

ここからは、G Suite を介した SSO アクセスを設定するための具体的な手順について説明します。

セットアップ

G Suite を使用して SAML 2.0 による SSO を設定するには、次の手順に従います。

  1. AWS で利用する SAML 属性を G Suite のユーザープロファイルに追加
  2. G Suite でサービスプロバイダの設定と、IdP メタデータの取得
  3. AWS アカウントで IdP の作成
  4. AWS アカウントで IAM Role の作成
  5. AWS で利用する SAML 属性を G Suite のユーザープロファイルに追加
  6. G Suite で SAML アプリの有効化
  7. ログイン確認

これらのステップの詳細について順に解説します。

Step1: AWS で利用する SAML 属性を G Suite のユーザープロファイルに追加

1. 管理者アカウントで G Suite 管理コンソール にログインし、”ユーザー” をクリック、次の画面で右上の “カスタム属性を管理します” と表示されるアイコンをクリックします。

2. “カスタム属性を追加” をクリックします。

3. 次のようにカスタムフィールドを追加します。

追加せずに既存のフィールドを代用することも可能ですが、新規に作成されたほうがいいかと思います。（その場合、 “部署” フィールドに IAM Role の ARN を登録するなどのようになります。）Role 用のフィールドは必須ですが、 Session Duration は無くても動作するため任意になります。

 

Step 2: G Suite でサービスプロバイダの設定と、IdP メタデータの取得

1. G Suite 管理コンソール のトップん戻り、”アプリ” > “SAML アプリ” の順にクリックします。

2. 新規作成を選択し、”Amazon Web Services” をクリックします。。

3. “ダウンロード” ボタンから IdP メタデータをダウンロードして下さい。

4. “サービス プロバイダの詳細” は変更箇所はありません。

5. “属性のマッピング” 設定を行います。

どのような情報を引き渡せばいいかは 認証レスポンスの SAML アサーションを設定する に記載がありますが、”RoleSessionName” と “Role” は必須になります。”RoleSessionName” はユーザ毎にユニークであることが好ましいのでメールアドレスを利用します。

また、デフォルトの Session の有効期間は1時間であり、作業中に切れることも多いかと思います。パラメータで可変にするためには属性名に https://thinkwithwp.com/SAML/Attributes/SessionDuration を設定し、値に “Session Duration” を設定します。

Step 3: AWS アカウントで IdP の作成

1. IAM の管理画面を開き、”ID プロバイダー” を選択し “プロバイダの作成” を行います。

2. 先ほどダウンロードしたメタデータをアップロードし、任意のプロバイダー名を設定して下さい。

Step 4: AWS アカウントで IAM Role の作成

1. IAM の管理画面を開き、”ロール” を選択し “ロールの作成” を行います。

2. “SAML 2.0 フェデレーション” を選択し、先ほど作成した ID プロバイダーを選択します。

3. SAML 経由で認証したユーザに割り当てる権限を設定します。今回は試しに ReadOnlyAccess を付与します。

4. 任意のロール名をつけて作成します。

Step5: AWS で利用する SAML 属性を G Suite のユーザープロファイルに追加

1. 属性を設定するユーザのプロファイルを開き、”ユーザー情報” をクリックします。

2. AWS の項目を入力します。

設定する内容は 認証レスポンスの SAML アサーションを設定する に記載がありますが、Role については Role ARN と ID プロバイダーの ARN をコンマ区切りで記載する必要があります。今回の例だと arn:aws:iam::123456789012:role/GsuiteReadOnly,arn:aws:iam::123456789012:saml-provider/GSuite のようになります。（アカウント ID はご自身のものを設定して下さい。）

また、今回は Session の有効期間を最大の12時間 (43200秒) に設定しておりますが、こちらは推奨値という訳でははないのでお客様の要件に合わせて設定頂く必要があります。

6. G Suite で SAML アプリの有効化

設定直後は無効化されているため、SAML アプリを有効化する必要があります。

今回はテストのためすべてのユーザーに対して有効化しますが、実際には部門ごとにロールアウトしていく方が好ましいかと思います。また、 SAML アプリが有効になっていても、前述の SAML 属性が設定されていない場合は認証に失敗します。

7. ログインできるかの確認

一通り設定が終わったら、アプリランチャーの最下部に “Amazon Web Services” のアイコンが表示されます。（アイコンは “SAML アプリ” の設定で変更可能ですが割愛します）

こちらをクリックすることで AWS のマネジメントコンソールへログインすることが出来るようになります。

ログイン後にコンソールに表示されるアカウント情報を確認すると、次のように表示されているはずです。

G Suite 側のメールアドレスで各個人はユニークに識別されつつ、権限的には IAM Role のものが適用されます。

※ Role を複数設定している場合は次のような画面が表示されます。

より高度なアクセスコントロールをする場合

ここまでの情報で簡単に設定ができ、認証基盤を統一出来ることが確認できたかと思います。

しかしお気づきの方もいらっしゃると思いますが、権限や Session の有効期限などの情報が個人のアカウントに紐付いており、ユーザや部署が非常に多いケースや AWS のアカウントを多く保有しているケースでは管理が煩雑になることも予想されます。

そのような場合は AWS Single Sign-On (AWS SSO) をご検討下さい。組織 (OU) 単位でのアクセスコントロールや、AWS 以外の SAML 2.0 に対応したサービスまで含めて管理することが可能です。（ユーザの管理については AWS SSO 内に持つこともできますし、既にお持ちの Microsoft AD をご利用頂くことも可能です。詳細はドキュメントを御覧ください。）

以上踏まえた上でライトにシングルサインオンを導入したい場合は、管理するものが少ない今回ご紹介した方法を検討してみてください。スタートアップの場合は、エンジニア以外もマネジメントコンソールにアクセスすることがあるかと思いますので、場合によってはエンジニアは IAM User で、営業や経理担当の社員は G Suite アカウント経由で ReadOnly 権限で、のように併用することがマッチするケースもあるかと思います。

自社の状況を踏まえた上で最適なソリューションをお選び頂くことが重要ですが、判断が難しい・悩んでいる場合は AWS Loft Tokyo で行っている Ask An Expert でご相談頂ければと思います。

このブログの著者

松田 和樹（Kazuki Matsuda）

Container とか Serverless, BigData が好きなスタートアップ ソリューションアーキテクト。