[！] この記事は公開されてから1年以上経過しています。情報が古い可能性がありますので、ご注意ください。
クラウドサービスのWebコンソール（管理画面）へのログインは、クラウドごとに作成したユーザーIDを利用できます。ユーザーが少ない場合はユーザーIDの手動作成も可能ですが、ユーザーが多くなるとActive Directory（AD）のようなID基盤を活用することが現実的な選択肢となってきます。
この投稿では、ADアカウントでAmazon Web Services（AWS）、Microsoft Azure、Google Cloud Platform（GCP）を扱うための認証連携の仕組みを紹介します。なお、ADと連携した統合認証基盤の存在を前提としています。
AWS Management Consoleへのログイン
一般的なアプローチ
AWSでは、ADと連携してAWSマネジメントコンソールにログインする方法を複数提供しています。
SAML 2.0ベースのID フェデレーションを利用
SAMLは、認証情報を提供するIdentity Provider（IdP）と認証情報を利用するService Provider（SP）間で、認証情報を交換する仕組みです。AWSでは、SAML 2.0ベースのIDフェデレーションをサポートしており、SAMLに対応した認証サービスからコンソールにログインすることが可能になります。
AWS Directory ServiceのAD Connectorを利用
AD Connectorは、オンプレミス環境に存在する既存のディレクトリサービスに接続して、AWSから利用できるようにするサービスです。AD Connectorを始めとするAWS Directory Serviceでは、SaaS型のAWSサービスやコンソールにシングルサインオンする機能を提供しています。
AWS Single Sign-On（SSO）を利用
AWS SSOは、複数のAWSアカウントのコンソールにSSOアクセスを可能にするサービスです。また、AWSアカウントのコンソールだけではなく、G SuiteやMicrosoft 365といったビジネスアプリケーションへのログインもサポートしています。ただし、「東京リージョンではまだサービス提供していない（2020年7月時点）」、「AWS Organizations のマスターアカウント管理権限が必要」という制約があります。
当社でのアプローチ
当社は、請求代行業者が一元管理している組織（Organization）のメンバーアカウントとしてAWSを利用しているため、AWS SSOが選択肢から外れます。残る2つのアプローチのうち、ADユーザーの認証はできるだけ構築済みの統合認証基盤にて実施するという方針のもと、SAML 2.0ベースのID フェデレーションを採用しました。
次の図は、SAMLによるAWSマネジメントコンソールへのログインについて処理の流れを示したものです。
一般的な SAML フェデレーションと同様ですが、当社やAWS独自の部分が存在するので補足します。
統合認証基盤では、ADドメインのユーザーとパスワードを利用して、ユーザー認証を可能にする設定がされています（処理2）。当社ではAWSを利用するプロジェクトについて、利用者の所属するADグループを用意しています。統合認証基盤からのSAMLレスポンスには、認証済みユーザーが利用できるプロジェクト名が含まれるように設定しています（処理3）。
この認証情報を利用するAWS側の挙動を見ていきます。まず、統合認証基盤で認証されたADユーザーに割り当てるアクセス権限（IAM ロール）を、あらかじめプロジェクトごとに作成しています。IAMロール名はプロジェクト名と同一にしています。
SAMLを利用したAWSへのシングルサインオンでは、以下のような処理が行われます。
- SAMLレスポンスを受け取ったAWS SSOエンドポイントは、一時的な認証情報をリクエストし、サインイン URL を作成（処理5）
- エンドポイントは、サインインURLをブラウザにリダイレクトとして送信（処理6）
- ブラウザがAWSマネジメントコンソールにリダイレクト（処理7）
SAMLレスポンスの属性に複数のプロジェクト名が含まれる場合は、どのプロジェクトでコンソールにアクセスするのかを選択する画面が表示されます。AWSマネジメントコンソールにおけるすべての操作は、ここで選択したプロジェクトに対応するIAM ロールで実行することになります。
Azure Portalへのログイン
一般的なアプローチ
Azureでは、Active Directoryと連携して、Azure Portal ⧉にログインする方法としてAzure ADが提供されています。Azureの認証をAzure ADだけを利用して行うことも可能ですが、オンプレミス環境と連携して共通のユーザーID（ハイブリッド ID）を利用することもできます。
Azure ADでは、ハイブリッドIDを実現する認証方法が複数提供されており、いずれかを利用してADアカウントによるログインを行うのが一般的です。
パスワード ハッシュの同期（PHS）を利用
Azure AD Connectを利用して、オンプレミスADからAzure ADにパスワードのハッシュを同期する方法です。オンプレミスに必要なサーバが少なくて済む、オンプレミスADに接続できなくても、Azure ADでの認証が可能などの利点があります。
パススルー認証（PTA）を利用
Azure ADに送られた認証情報をオンプレミスに展開されたエージェントが取得して、オンプレミスのADに検証を要求することによりユーザーのサインインを検証する方法です。Azure ADにパスワードのハッシュを保存する必要がない、展開と管理が比較的容易などの利点があります。
フェデレーション（AD FS）を利用
信頼のおける別のシステム（AD FSやサードパーティのフェデレーションシステムなど）が、Azure ADから認証プロセスを引き継いでユーザーのサインインを検証する方法です。サーバの冗長化や証明書の管理など、運用コストは高くなりますが、多要素認証やスマートカード認証など高い柔軟性が実現できます。
当社でのアプローチ
当社では、既にMicrosoft 365（旧Office 365）を導入しており、オンプレミスADドメインをMicrosoft 365用Azure ADテナントに同期しています。Azure AD Connectは、複数のAzure ADテナントへの同じユーザーの同期をサポートしていない ⧉ため、他のAzure AD テナントへの同期を行うことができません。
このため、ハイブリッドIDを実現する一般的な認証方式は使えず、代わりにAzure ADの企業間（B2B）コラボレーションを採用しています。B2Bコラボレーションは、外部ユーザーをAzure ADテナントに「ゲスト」ユーザーとして招待すると、各自の資格情報を使用してリソースへのアクセスを可能にする機能です。当社では、既存のMicrosoft 365のユーザーをAzureに招待することでAzureへのログインを実現しています。
GCPにおけるコンソールログイン
一般的なアプローチ
Google Cloudに限らず、すべてのGoogleサービスは、メールアドレス形式のユーザーアカウントを利用して認証します。プライベートな用途であれば、Gmailのような個人所有のメールアドレスを登録して、作成されたコンシューマーアカウントを全て自分で管理できます。しかし、組織としてGoogleサービスを利用する場合には、管理者によるアカウントの一元管理が一般的でしょう。これを実現するには、Cloud Identity ⧉ および G Suiteが提供する（マネージド）アカウントを利用する必要があります。
このアカウントには、Cloud Identityで手動作成したもの以外に、既存のADドメインで管理されているアカウントも利用できます。ただし、外部IDプロバイダによりSAML認証が行われる前に、認証の対象であるアカウントがCloud IdentityまたはG Suiteに既に存在している必要があります。Google Cloudのリファレンスアーキテクチャ ⧉によれば、これを実現する方法として以下の2つが紹介されています。
SAML準拠のIDプロバイダを利用
Google Cloud Directory Syncというツールを利用して、ADドメインからCloud Identityにユーザー同期を行い、GCPコンソール ⧉へのシングルサインオンにSAML準拠のIDプロバイダを利用する方法です。
⧉
なお、この方法では、ADドメインの代わりに一般的なLDAPディレクトリも利用できます。
Azure ADをIDプロバイダとして利用
GCPコンソールへのシングルサインオンに、クラウドベースのID管理サービスであるAzure Active Directory（Azure AD）を利用する方法です。ADドメインからCloud Identityへのユーザー同期は、Azure ADにより自動で行われます。
⧉
SAML準拠のIDプロバイダを利用するアプローチと比べて、Azureも含めたシングルサインオン、Google Cloud Directory Syncが不要になるなどの利点があります。
当社でのアプローチ
前に述べたように、ADユーザーの認証はできるだけ統合認証基盤にて実施するという方針に基づき、GCPでもIDプロバイダとして利用する方法を採用しました。
次の図は、GCPコンソールへのログインについて処理の流れを示したものです。
- GCPコンソールにアクセス
- Cloud Identityにリダイレクト
- Cloud Identityからメールアドレスの入力要求
- 入力されたメールアドレスがCloud Identityアカウントとして存在するか確認し、統合認証基盤にリダイレクト
- 統合認証基盤から認証情報の要求
- Active Directoryを使用して認証情報の検証
- 検証結果をCloud Identityに返却
- Cloud Identityはセッションを確立し、ブラウザをGCPコンソールに戻す
おわりに
当社におけるAWS、Azure、GCPのWebコンソール利用方法についてまとめます。
認証連携については、AWSとGCPは統合認証基盤を利用したSAMLフェデレーションを採用しています。これに対して、Azureではマイクロソフトの仕様であるWS-Federationを採用しています。
ADアカウントと権限の関連付けを管理する場所も異なります。AWSでは、IAMロールとの関連付けを統合認証基盤にて管理しています。これに対して、GCPではCloud IAMメンバーとの関連付けをCloud Identityで、AzureではAzureロールの関連付けをAzure ADとクラウド側で管理します。
| クラウド | AWS | Azure | GCP |
|---|---|---|---|
| IDプロバイダ | 統合認証基盤 | AD FS | 統合認証基盤 |
| フェデレーションプロトコル | SAML 2.0 | WS-Federation | SAML 2.0 |
| 権限管理 | 統合認証基盤 | Azure AD | Cloud Identity |
なお、AWS、GCPともにAzure ADによるSSOをサポートしています。Microsoftのクラウドサービス（Azure、Microsoft 365等）を利用しているなら、Azure ADで一元管理するのも有力な選択肢になるでしょう。
参考資料
AWS
Azure
- Azure Active Directory でのハイブリッド ID とは | Microsoft Docs ⧉
- Azure AD Connect:サポートされるトポロジ | Microsoft Docs ⧉
- Azure Active Directory での B2B コラボレーションとは | Microsoft Docs ⧉
GCP
