ハイブリッド環境で従業員ユーザーを認証する

Last reviewed 2022-10-02 UTC

この記事は、従業員がハイブリッドコンピューティング環境で認証を行い、サービスを利用できるように、ID 管理ソリューションを Google Cloud に拡張する方法を説明するシリーズの第 1 部です。

シリーズは次のパートで構成されています。

ハイブリッド環境で従業員ユーザーを認証する（この記事）
ハイブリッド環境で従業員ユーザーを認証するパターン

はじめに

ユーザーアカウントを管理して、アプリケーションとコンピューティングリソースへの従業員のアクセスを制御することは、企業の IT 部門にとって重要な責務です。整合性と管理作業の効率性を維持するため、大半の企業は ID 管理を中心的機能と考え、統合されたシステムで ID を管理しています。この目的のため、ほとんどの企業は Microsoft Active Directory Domain Services（AD DS）を使用しています。

ハイブリッド戦略の一環として IT 環境を Google Cloud に拡張する際には、ID を管理する場所を 1 か所に維持することをおすすめします。統一された ID 管理システムを使用することで、アカウント管理とアクセス制御に必要な管理作業を最小限に抑えることができます。これにより、ハイブリッド環境でユーザーとアプリケーションの認証を安全に行うことができます。

この記事では、Google Cloud と ID 管理システムを統合する方法について説明します。この記事の情報を参考にして、要件に最も適したアプローチをお選びください。

説明の大部分は Google Workspace にも当てはまりますが、この記事では Cloud Identity を中心に説明します。

ハイブリッド ID 管理の要件を評価する

ID 管理システムを Google Cloud に拡張する最善の方法は、いくつかの要因によって決まります。

組織内の ID のプール
従業員 ID に認証サービスを提供する ID プロバイダ
従業員ユーザーが Google Cloud でアクセスできるリソースとアプリケーション
ビジネス継続性の要件

以降のセクションで、上記のそれぞれの要素について説明します。

ID

Google Cloud と ID 管理システムを統合するときに最初に考慮するのは、ID の種類とその管理方法です。ほとんどの組織は、次の種類の ID を使用しています。

従業員 ID は、組織の従業員を管理するための ID です。この ID は、ワークステーションへのログイン、メールへのアクセス、企業アプリケーションの利用時に使用します。
外部 ID は、企業リソースへのアクセス権を付与する必要がある請負業者やパートナーなど、従業員以外のユーザーを管理する ID です。
ゲスト ID は、企業リソースにアクセスする必要がある顧客やパートナーなど、別の団体によって管理される ID です。
顧客 ID は、ウェブサイトまたは顧客向けアプリケーションを使用するユーザーを管理する ID です。
ワークロード ID は、アプリケーションが他のアプリケーションや基盤となるプラットフォームを利用する場合に使用する ID です。

多くの場合、従業員 ID は単一の ID プールを形成しています。各従業員には 1 つの ID が割り当てられ、すべての ID は同じシステムを使用して同じ方法で管理されます。ただし、これとは異なる場合もあります。たとえば、合併や買収によって従業員 ID のプールが複数ある場合は、異なるシステムで管理しているケースもあります。このような場合、技術的には複数の LDAP ソース、Active Directory フォレスト、Azure AD テナントなどと Google Cloud の統合が必要になります。

複数のプールが存在する場合、Google Cloud との統合が複雑になります。したがって、次の点を検討する必要があります。

すべての ID プールが Google Cloud にアクセスする必要があるのか、特定のサブセットのみがアクセスする必要があるのか。
すべての ID プールが Google Cloud 内の同じ組織にアクセスする必要があるのか、ID プールごとに異なる組織にアクセスする必要があるのか。
プールの数を減らす方法があるか。たとえば、Active Directory フォレスト間で信頼関係を構築するなど。

多くの場合、外部 ID は従業員 ID と同様に扱われますが、以下のような例外があります。

アカウントの有効期限が制限されている。
デフォルトで付与される権限が少ない。
別々の LDAP ディレクトリ、Active Directory フォレストまたは Azure AD テナントで管理される。

外部 ID とは異なり、ゲスト ID は別の団体によって管理されます。Google Workspace などの SaaS アプリケーションの場合、ゲスト ID を使用すると、ユーザーやパートナーの外部 ID を維持する必要がなくなります。オンプレミス環境でゲスト ID が使用されることはまれです。

この記事では、従業員 ID と外部 ID について説明します。

Google 広告などのサービスを使用したことがある場合、一部の従業員は各自の従業員 ID に関連付けられていない Google アカウントを持ち、2 種類の ID を使用している可能性があります。その場合は、ID の統合を検討してください。

ID プロバイダ

次に考慮する要因は ID プロバイダです。ID プロバイダ（IdP）は、ワークロードに認証サービスを提供し、最終的にユーザーを認証するかどうかを決定するシステムです。

多くの場合、IdP は認証サービスを提供するだけでなく、ID のライフサイクルの管理を行います。ただし、これは必須の機能ではありません。ID が別の人事システムからプロビジョニングされる場合もあります。

よく利用されている ID プロバイダは次のとおりです。

Active Directory（AD DS）
Azure Active Directory（Azure AD）
ForgeRock、Okta、Ping Identity などの IDaaS プロバイダ
Active Directory ライトウェイトディレクトリサービス（AD LDS）など、その他の LDAP ディレクトリ

1 つのシステムではなく、複数のシステムを使用して、異なるユーザープールの管理や外部アカウントの処理を行うことも可能です。また、同じユーザープールに複数の認証サービスを提供することもできます。同じプールを複数の IdP で管理する例としては、次のような組み合わせがあります。

Active Directory と Azure AD の連携
Active Directory と IDaaS プロバイダ（ForgeRock、Okta、Ping Identity など）の連携
Active Directory と AD LDS レプリカの使用

Google Cloud で IdP を使用する場合は、次の 2 つの方法があります。

ID プロバイダと Cloud Identity の連携: Cloud Identity と連携することで、従業員ユーザーが使用できる追加の IdP として Google を利用できます。また、Google Cloud にデプロイされたアプリケーションでも利用できます。各ユーザーの Google ID を維持する代わりに、連携により ID を自動的に管理できます。また、IdP を信頼できるソースとして維持できます。
ID プロバイダを Google Cloud に拡張する: Google Cloud にデプロイされたアプリケーションで IdP を再利用できます。IdP に直接接続することも、Google Cloud 上に IdP のレプリカを維持することもできます。

ID 管理の他の要因によっては、ハイブリッド環境での使用をサポートするために、両方のアプローチの併用が必要になることもあります。

関連情報

3 つ目の要因は、従業員ユーザーにアクセスを許可する Google Cloud リソースです。これには Google Cloud 自体も含まれます。Google Cloud コンソール、gcloud CLI、または API を使用して、担当チームが Google Cloud を管理できるようにする必要があります。

さらに、次のようなリソースも検討対象になる場合があります。

App Engine、Compute Engine、または Google Kubernetes Engine（GKE）にデプロイされたアプリケーション
Cloud Identity Aware Proxy（IAP）で保護されたアプリケーション
SSH 経由でアクセスする Linux VM
RDP 経由でアクセスする Windows VM
Google Workspace、Looker Studio、Google 広告など、その他の Google ツールとサービス

これらのリソースは、ID プロバイダとして Google を使用する必要があるかどうか、以前に使用できたかどうか、または使用できないかどうか、という点で異なります。以下では、この 3 つのケースについて説明します。

IdP として Google を使用する必要があるリソース

Google を IdP として使用する必要があるリソースには、Google Cloud コンソール、gcloud CLI、IAP で保護されたアプリケーション、その他の Google ツールやサービスなどがあります。これらのリソースへのアクセスを従業員ユーザーに許可するには、各ユーザーに Google ID を設定する必要があります。

個別の Google ID を維持することは、統一された ID 管理を行うという考え方に反します。したがって、これらのリソースへのアクセス権をユーザーに付与することは、IdP を Google Cloud と連携させる必要があることを意味します。

Google Cloud と IdP を連携したら、別の手段でユーザーを認証しているアプリケーションなど、他のリソースでも IdP として Google を使用することを検討します。

以前に IdP として Google を使用できたリソース

条件によっては IdP として Google を使用できるものの、現状では使用していないリソースとしては、次のようなものがあります。

Google Cloud にデプロイする予定の、従業員ユーザーを対象とした新しいアプリケーション。
リフト＆シフトまたは移行と改良で Google Cloud への移行を計画している従業員ユーザーを対象とした既存のアプリケーション。

これらのアプリケーションで IdP として Google を使用できるかどうかは、認証と認可に使用するプロトコルによって異なります。

ウェブのシングルサインオンプロトコル

Google では、認証、認可、シングルサインオンを処理する業界標準プロトコルをサポートしています。サポートされているプロトコルは次のとおりです。

OAuth 2.0。モバイルクライアント、ファットクライアント、ブラウザ以外の他のアプリケーションに適用されます。
OpenID Connect 1.0（OIDC）。ブラウザベースのアプリケーションに適用されます。
SAML 2.0。サードパーティアプリケーションの統合に適用されます。

開発予定のアプリケーションでは、OAuth 2.0 または OIDC を使用することをおすすめします。これらのプロトコルは広く採用されており、実証済みの多くのライブラリやツールを利用できます。また、これらのプロトコルに使用すると、IdP として Google を使用でき、必要に応じて ID プロバイダを柔軟に切り替えることができます。

SAML、OAuth 2.0 または OIDC を使用するアプリケーションでは、コードをほとんど変更することなく、ID プロバイダを Google に切り替えることができます（コードの変更が不要な場合もあります）。

LDAP

認証と認可で最も広く使用され、信頼性の高いプロトコルの 1 つが LDAP（Lightweight Directory Access Protocol）です。アプリケーションが認証と認可に LDAP を使用できる場合、いくつかの方法があります。最も一般的な方法は、次の 2 つのシナリオです。

認証とユーザー情報の照会に LDAP を使用する: この場合、アプリケーションはシングルサインオンを使用しません。ユーザーにユーザー名とパスワードを求めるログインフォームを表示し、指定された認証情報を使用して LDAP bind オペレーションを実行します。処理に成功すると、認証情報は有効とみなされます。また、名前やグループメンバーシップなどのユーザー情報がディレクトリに照会され、アクセスの認可に使用されることもあります。
認証に SAML を使用し、ユーザー情報の照会に LDAP を使用する: この場合、アプリケーションはシングルサインオンプロトコルを使用してユーザーを認証します。ユーザーが認証されると、アプリケーションは LDAP サーバーを使用して、名前やグループメンバーシップなどのユーザー情報を取得します。

この 2 つのシナリオの重要な違いは、最初のシナリオでは、アプリケーションと LDAP サーバーが認証情報の確認にユーザーのパスワードを使用しますが、2 番目のシナリオでは、アプリケーションとサーバーがユーザーのパスワードを必要としない点です。後者の場合、アプリケーションは専用のサービスユーザーを使用して LDAP クエリを実行します。

セキュア LDAP を使用すると、LDAP プロトコルを使用して Cloud Identity のユーザー情報とグループ情報にアクセスできます。Google がプライマリ IdP の場合、セキュア LDAP を使用すると、上の両方のシナリオに対応できます。ただし、Cloud Identity を外部 IdP と統合した場合、Cloud Identity はユーザーパスワードのコピーを保持しません。このため、セキュア LDAP では 2 番目のシナリオのみが有効になります。

Kerberos と NTLM

Windows ベースのワークロードを Google Cloud に移行する場合、アプリケーションの中には標準プロトコルではなく、統合 Windows 認証（IWA）に依存するものもあります。IWA は、Microsoft IIS 上で実行される ASP.NET ベースのアプリケーションで使用されています。IWA を使用すると、ドメインの認証情報を使用して Windows ワークステーションにログインしたユーザーにシームレスなシングルサインオンエクスペリエンスを提供できるため、多くのアプリケーションで利用されています。

IWA は NTLM または Kerberos を使用します。このため、ユーザーのワークステーションとアプリケーションが実行されているサーバーを同じ Active Directory ドメインに参加させるか、信頼するドメインに参加させる必要があります。

NTLM と Kerberos を使用すると、IWA を使用するアプリケーションで Google を IdP として使用できなくなります。ただし、OIDC を使用するようにアプリケーションをリファクタリングすることが可能な場合があります。OIDC の場合、ユーザーのワークステーションやサーバーをドメインに参加させる必要はありません。リファクタリングを行うと、デプロイが簡素化され、別のデプロイオプションも使用できるようになります。

IWA によって提供されるシームレスなシングルサインオンエクスペリエンスを考えると、IWA の代わりに OIDC を使用することは、ユーザーエクスペリエンスの点で一歩後退したように感じるかもしれません。しかし、ユーザーが AD FS または Azure AD にシームレスにサインオンできる場合は、そのようなことはありません。

Active Directory と AD FS を Google Cloud と連携する場合、AD FS で構成された認証方法が適用されます。IWA を許可するように AD FS を構成すると、ドメインの認証情報を使用して Windows ワークステーションにログインしたユーザーは、Google を IdP として使用するすべてのアプリケーションにシームレスに認証されます。
Google Cloud と Azure AD を連携する場合、Azure AD のシームレス SSO を有効にすると、同じ結果を得ることができます。

次の図は、Cloud Identity、AD FS、IWA を使用して、ウェブアプリケーションにシームレスなシングルサインオンを実装する簡単な例を示しています。

Cloud Identity、AD FS、IWA を使用してウェブアプリケーションにシームレスなシングルサインオンを実装する方法

ブラウザが、保護されたページをウェブブラウザを介してリクエストします。
ウェブアプリケーションは、OIDC（OIDC 認証フロー）を使用してログインを開始します。このフローは、ブラウザを Google ログインエンドポイントにリダイレクトします。
Google ログインエンドポイントがユーザーに Google のログインページを返し、メールアドレスの入力を求めます。
ユーザーがメールアドレスを入力します。
入力されたメールアドレスに基づいて、Google ログインエンドポイントが Cloud Identity アカウントを確認し、SSO の使用が構成されていることを認識します。認識すると、ログインエンドポイントによって AD FS を使用した SAML ログインが開始されます。
IWA の使用が構成されている AD FS がブラウザに Kerberos チケットの提示をリクエストします。ブラウザが、基盤となる Windows オペレーティングシステムに適切なチケットの取得をリクエストします。
適切なチケットがキャッシュに保存されていない場合、Windows は Active Directory キー配布センター（KDC）に接続し、ユーザーが Windows にログインしたときに取得したチケット保証チケット（TGT）に基づいて適切なサービスチケットをリクエストします。
ブラウザが、新しく取得したチケットを AD FS に提示します。
AD FS は、暗号署名を確認してチケットを検証し、チケットからユーザー ID を抽出して、Google ログインエンドポイントに SAML トークンを発行します。
Google ログインエンドポイントは、SAML トークンからの認証情報を使用して OIDC ログインを完了し、OpenID Connect トークンをウェブアプリケーションに発行します。
ユーザーが認証されると、保護されたページがユーザーに返されます。

SSH 公開鍵認証

Google Cloud で Linux 仮想マシン（VM）を実行する場合、これらのマシンに SSH 経由でアクセスする必要がある場合があります。SSH で最も一般的な認証方法は公開鍵認証です。

前述のシングルサインオンプロトコルとは異なり、SSH 公開鍵認証では認証に中央の IdP を必要としません。認証は分散型で行われます。各マシンは、認証された公開鍵のローカルセットに基づいて認証を処理します。

OS Login を使用して、分散型の SSH 公開鍵認証と ID の一元管理のギャップを埋めることができます。OS Login では、次の方法で SSH 認証鍵のライフサイクルがユーザーアカウントのライフサイクルに関連付けられます。

ユーザーが作成されたとき、または初めて SSH を使用するときに SSH 公開鍵を公開する。
ユーザーがアクセスできるマシンにユーザーの公開鍵をプロビジョニングする。
アカウントのアクセス権の取り消し、無効化または削除が行われたときに、ユーザーの公開鍵のプロビジョニングを解除する。

OS Login を使用すると、実質的に Cloud Identity が Linux インスタンスの IdP になります。

Google を IdP として使用できないリソース

一部のリソースは Google を IdP として直接使用できません。ただし、次の 2 つの方法を組み合わせることで、Google Cloud でこれらのリソースを調整できます。

外部 IdP を Google Cloud と連携する。企業ユーザーが Google Cloud コンソールや gcloud CLI を使用できます。Google を IdP として使用する必要があるリソースや使用できるリソースも使用できます。
IdP を Google Cloud に拡張する。Google を IdP として使用できないリソースを Google Cloud で実行できるようにします。

Google IdP でサポートされていないプロトコルに依存しているリソースは Google を IdP として使用できません。サポートされていないプロトコルは次のとおりです。

認証用の LDAP: セキュア LDAP を使用すると、LDAP 経由で Cloud Identity からユーザー情報を取得できますが、外部 IdP と連携している場合、Cloud Identity は認証に LDAP を使用できません。

アプリケーションで認証に LDAP を使用できるようにするには、オンプレミスの LDAP ディレクトリを複製または公開します。あるいは、Active Directory を Google Cloud に拡張します。
WS-Trust、WS-Federation: AD FS を使用している場合、WS-Trust または WS-Federation を使用してトークンベースの認証を処理できる場合があります。影響を受けるアプリケーションを変更して SAML または OpenID Connect を使用できるようにできない場合は、オンプレミス AD FS を Google Cloud に公開し、アプリケーションで AD FS を直接使用することをおすすめします。
OpenID Connect と AD FS 固有のクレーム: AD FS と Google は OpenID Connect をサポートします。AD FS を OpenID Connect プロバイダとして使用している場合、Google がサポートしていない AD FS 固有のクレームを使用できることがあります。その場合は、社内の AD FS を Google Cloud に公開し、影響を受けるアプリケーションで直接 AD FS を使用することを検討してください。
Kerberos、NTLM: 認証に Kerberos または NTLM を使用しているアプリケーションがある場合は、代わりに OpenID Connect または SAML を使用するように変更できる場合があります。この変更ができない場合、これらのアプリケーションをドメインに参加している Windows サーバーにデプロイし、オンプレミスの Active Directory を Google Cloud に複製または公開できます。
Windows 仮想マシン: Windows ワークロードを Google Cloud で実行する場合、リモートデスクトッププロトコル（RDP）、リモートデスクトップゲートウェイなどを介して VM にログインする必要があります。ユーザーが VM を作成した Google Cloud プロジェクトへの書き込みアクセスを許可されている場合は、ユーザーとパスワードを作成して、VM のローカルセキュリティアカウントマネージャー（SAM）データベースにアカウントを作成できます。この Windows SAM アカウントはユーザーの Google アカウントに接続していないため、アカウントのライフサイクルも異なります。ユーザーの Google アカウントを一時停止または削除しても、Windows SAM アカウントは影響を受けず、引き続き VM へのアクセスに使用できる場合があります。

Windows VM とこれらのマシンにログインする必要があるユーザー数が少ない場合、ユーザーに Windows ユーザーアカウントとパスワードの作成を許可することもできます。しかし、数多くの Windows サーバーを管理する場合は、オンプレミスの Active Directory を Google Cloud に拡張して、各サーバーをドメインに参加させることをおすすめします。ネットワークレベルの認証を行う場合は、ドメインに参加しているサーバーも必要になります。

可用性

最後の要素は可用性です。多くのワークロードにとってユーザーを認証する機能は非常に重要であり、IdP が停止した場合の影響は広範囲に及ぶ可能性があります。Google Cloud をどのように使用し、ハイブリッド戦略に合わせるのかによって、適切な可用性を維持する方法が異なります。

分散ワークロード

各コンピューティング環境が提供するユニークな機能を最大限に活用するには、ハイブリッドなマルチクラウドアプローチを採用し、コンピューティング環境ごとにワークロードを分散させます。この環境は、ワークロードの可用性に重大な影響を与える別の環境に依存している可能性があります。依存関係には、VPN トンネルや相互接続、相互に通信するアプリケーション、コンピューティング環境間でデータにアクセスするシステムなどが考えられます。

外部 IdP を Google Cloud に連携または拡張する場合、外部 IdP と認証に必要な他のシステムの可用性が、他の重要な依存関係の可用性と同じか、それを上回っている必要があります。これは、外部 IdP とその依存関係を冗長にデプロイし、冗長なネットワーク接続を維持する必要があります。

冗長なワークロード

ビジネスの継続性を維持するために Google Cloud を使用する場合、Google Cloud のワークロードは、コンピューティング環境のワークロードの一部を反映したものになります。このような設定は、障害が発生した場合に 1 つのコンピューティング環境が他の環境の役割を引き継ぐことを目的としています。したがって、これらの環境間の依存関係をすべて調べる必要があります。

Google Cloud をオンプレミスで実行する外部 IdP に依存させることで、依存関係が作成されます。この依存関係は、Google Cloud をコンピューティング環境の独立したコピーにするという意図を損なう可能性があります。

Google Cloud のすべてのワークロードがオンプレミスコンピューティング環境の停止や Google Cloud とオンプレミスネットワーク間の接続の影響を受けないように、IdP を Google Cloud に複製してください。

次のステップ

ハイブリッド環境で従業員ユーザーを認証する一般的なパターンを確認する。
Google Cloud の ID プロビジョニングオプションを確認する。
Google Cloud に関するリファレンスアーキテクチャ、図、ベストプラクティスを確認する。Cloud アーキテクチャセンターをご覧ください。