ユーザー アカウントの統合による連携への影響の評価

Cloud Identity または G Suite を外部 ID プロバイダ(IdP)と連携させる計画で、既存の一般ユーザー向けアカウントを統合する必要がある場合、このドキュメントは連携と統合の相互作用についての理解と評価に役立ちます。このドキュメントでは、既存の一般ユーザー向けアカウントの統合を妨げることなく連携を構成する方法についても説明します。

連携とユーザー アカウントの統合の相互作用

連携の設定では、信頼できるソースが Cloud Identity または G Suite のユーザー アカウントを自動的にプロビジョニングできるように、Cloud Identity または G Suite を外部の信頼できるソースに接続します。

通常、次の不変条件は連携設定に当てはまります。

  1. 信頼できるソースは、ID の唯一のソースです。
  2. Cloud Identity または G Suite には、信頼できるソースによってプロビジョニングされたユーザー アカウント以外のユーザー アカウントはありません。
  3. SAML ID プロバイダは、信頼できるソースがユーザー アカウントをプロビジョニングした ID 以外の ID には Google シングル サインオンを許可しません。

これらの不変条件は、Google Cloud と外部 ID プロバイダの連携に関するベスト プラクティスの内容を反映していますが、既存の一般ユーザー向けアカウントを移行する際には、問題が生じる可能性があります。

  1. 既存の一般ユーザー向けアカウントは、信頼できる提供元から提供されたものではありません。これらのアカウントはすでに存在しており、信頼できるソースが認識する ID にリンクされる必要があります。
  2. 既存の一般ユーザー向けアカウントは、Cloud Identity または G Suite に移行されると、信頼できるソースによってプロビジョニングされていないユーザー アカウントになります。これらの移行されたアカウントは信頼できるソースによって認識され、「承認」される必要があります。
  3. 既存の一般ユーザー向けアカウントの ID は SAML ID プロバイダにとって未知のものであるかもしれませんが、シングル サインオンを使用するように許可される必要があります。

既存の一般ユーザー向けアカウントを統合するには、安全な方法でアカウント統合が行われるように、一時的に連携を設定する必要があります。

アカウント統合で連携を安全に使用する

次の表は、アカウント統合の連携を安全にするための考慮事項を示したものです。外部 IdP を使用する予定で、引き続き既存の一般ユーザー向けアカウントを統合する必要がある場合は、最初にこれらの要件を満たすように設定を行う必要があります。既存の一般ユーザー向けアカウントの移行が完了したら、要件を満たす必要がなくなるため、構成を自由に変更できます。

要件 理由
一般ユーザー向けアカウントの ID でのシングル サインオンを許可する 一般ユーザー向けアカウントを移行するには、アカウントの移行が必要です。Cloud Identity または G Suite 管理者がアカウントの移行を開始しますが、移行を完了するには、一般ユーザー向けアカウントのオーナーが移行に同意する必要があります。いつ同意されるか、つまり移行がいつ実施されるかについては、管理者として制御できることは制限されています。

オーナーが同意し、移行が完了すると、それ以降のログインはすべて、外部 IdP を使用したシングル サインオンの対象となります。

移行が完了したかどうかに関係なく、シングル サインオンを成功させるには、移行を予定しているすべての一般ユーザー向けアカウントの ID に対して、外部 IdP でのシングル サインオンを許可します。

一般ユーザー向けアカウントの ID での自動ユーザー プロビジョニングを禁止する すでに一般ユーザー向けアカウントを持っている ID のユーザー アカウントをプロビジョニングする場合は、競合するアカウントを作成します。競合するアカウントがあると、一般ユーザー向けアカウントの所有権とその構成、関連データが Cloud Identity または G Suite に移行されるのを防ぎます。

多くの外部 IdP のデフォルトの動作では、Cloud Identity または G Suite でユーザー アカウントが事前に作成されます。この動作によって、競合するアカウントが誤って作成されることがあります。

既存の一般ユーザー向けアカウントの ID での自動ユーザー プロビジョニングを防ぐことで、競合するアカウントが誤って作成されるのを避け、一般ユーザー向けアカウントを正常に移行できます。

外部 IdP に一致する ID のない一般ユーザー向けアカウント(正規のアカウントであり、Cloud Identity または G Suite に移行するアカウント)を識別した場合は、連携構成がこれらの一般ユーザー向けアカウントの移行を妨げないようにする必要があります。

要件 理由
外部 IdP に一致する ID のない移行対象アカウントの削除を防ぐ 外部 IdP に一致する ID がないユーザー アカウントが Cloud Identity または G Suite にある場合、IdP はこのユーザー アカウントが孤立しているとみなし、アカウントを停止または削除します。

外部 IdP と ID を照合することなく、移行対象アカウントが外部 IdP によって停止または削除されるのを防ぐことで、影響を受けるアカウントに関連付けられた構成とデータが失われるのを防ぎ、手動でアカウントを構成とデータを一致させることができます。

アカウント統合で Azure AD 連携を安全に使用する

Cloud Identity または G Suite を Azure AD と連携させる場合は、G Suite ギャラリー アプリを使用します。

プロビジョニングを有効にすると、Azure AD に対応するものがない Cloud Identity または G Suite の既存のアカウントが Azure AD によって無視されるため、外部 IdP に一致する ID のない移行対象アカウントの削除を防ぐという要件は必ず満たされます。

ギャラリー アプリの構成方法に応じて、次のことを行う必要があります。

これらの要件を満たす方法はいくつかあります。それぞれにメリットとデメリットがあります。

アプローチ 1: プロビジョニングを構成しない

このアプローチでは、シングル サインオンを処理するようにギャラリー アプリを構成しますが、自動ユーザー プロビジョニングは構成しません。ユーザー プロビジョニングを構成しないことで、一般ユーザー向けアカウントの ID での自動ユーザー プロビジョニングを防ぐことができます。

一般ユーザー向けアカウントの ID でのシングル サインオンを許可するには、既存の一般ユーザー向けアカウントが移行対象の場合でも、最終的に Google サービスにアクセスする必要があるすべての ID にアプリを割り当てます。

既存の一般ユーザー向けアカウントを持つユーザーの場合は、移行リクエストが承認されると、対応する Cloud Identity または G Suite のユーザー アカウントが自動的に作成されます。そのユーザーはすぐにシングル サインオンを使用できます。

Cloud Identity または G Suite にユーザー アカウントがないユーザーの場合は、手動で作成する必要があります。

このアプローチは要件を満たし、最も設定が簡単ですが、Azure AD で行われた属性の変更やユーザーの停止がいずれも Cloud Identity または G Suite に反映されないという制限があります。

アプローチ 2: 2 つのアプリの使用と手動での割り当て

このアプローチでは、既存のアカウントのないユーザーに対し、G Suite または Cloud Identity でアカウントを手動で作成する必要がありません。ここでは、プロビジョニング用とシングル サインオン用の 2 つのギャラリー アプリを使用します。

  • 最初のアプリは、ユーザーとグループのプロビジョニング専用に使用し、シングル サインオンは無効にします。このアプリにユーザーを割り当てることで、Cloud Identity や G Suite にプロビジョニングされるアカウントを制御できます。
  • 2 つ目のアプリはシングル サインオン専用に使用し、ユーザーをプロビジョニングする権限を付与しません。このアプリにユーザーを割り当てることで、サインオンを許可するユーザーを制御できます。

これら 2 つのアプリを使用して、次のようにユーザーを割り当てます。

アプローチ 3: 2 つのアプリの使用とユーザー作成の無効化

プロビジョニングを構成するときは、Cloud Identity または G Suite アカウントを使用して、Azure AD が Cloud Identity または G Suite にアクセスすることを承認する必要があります。通常は、そのための特権管理者アカウントを使用することをおすすめします。特権管理者アカウントはシングル サインオンの適用対象外であるためです(つまり、SSO の構成は適用されず、ログインには引き続きパスワードが使用されます)。

ただし、このシナリオでは、移行用にさらに制限をかけたアカウントを Azure AD に使用させ、Azure AD によりユーザーが作成されないようにします。この操作により、プロビジョニング アプリに割り当てられているユーザーに関係なく、Azure によって、一般ユーザー向けアカウントの ID で、ユーザー アカウントが自動的にプロビジョニングされるのを効果的に防止します

Cloud Identity または G Suite の制限付き管理者ユーザー アカウントには、次の権限のみが付与されます。

  • [組織単位] > [読み取り]
  • [ユーザー] > [読み取り]
  • [ユーザー] > [更新]
  • [グループ]

このアプローチのデメリットは、非マネージド アカウントを持たないユーザーの場合、Cloud Identity または G Suite に手動でアカウントを作成する必要があることです。

Azure AD との連携: 比較

次の表は各アプローチを比較してまとめたものです。

一般ユーザー向けアカウントの ID でのシングル サインオンを許可する 一般ユーザー向けアカウントの ID での自動ユーザー プロビジョニングを禁止する 外部 IdP に一致する ID のない移行対象アカウントの削除を防ぐ 新しいアカウントを自動プロビジョニングする 移行対象アカウントを自動更新する
アプローチ 1: プロビジョニングを設定しない X X
アプローチ 2: 2 つのアプリの使用と手動での割り当て 手動によるエラーが発生しやすい
アプローチ 3: 2 つのアプリの使用とユーザー作成の無効化 X

アカウント統合で Active Directory 連携を安全に使用する

Cloud Identity または G Suite を Active Directory と連携させる予定の場合は、Google Cloud Directory Sync と Active Directory フェデレーション サービス(AD FS)を使用できます。Cloud Directory Sync と AD FS を構成する際には、次のことを確実に行う必要があります。

これらの要件を満たす方法はいくつかあります。それぞれにメリットとデメリットがあります。

アプローチ 1: Cloud Directory Sync を無効にする

このアプローチでは、AD FS でシングル サインオンを設定しますが、非マネージドのユーザー アカウントの移行が完了するまでは Cloud Directory Sync を有効にしません。Cloud Directory Sync を無効にすると、一般ユーザー向けアカウントの ID での自動ユーザー プロビジョニングを防ぐことができます

一般ユーザー向けアカウントの ID でのシングル サインオンを許可するには、既存の一般ユーザー向けアカウントが移行対象の場合でも、AD FS でカスタムのアクセス制御ポリシーを作成し、最終的に Google サービスにアクセスする必要があるすべての ID に割り当てます。

既存の一般ユーザー向けアカウントを持つユーザーの場合は、移行リクエストが承認されると、対応する Cloud Identity または G Suite のユーザー アカウントが自動的に作成されます。カスタムのアクセス制御ポリシーを使用すると、ユーザーがすぐにシングル サインオンを使用できるようになります。

Cloud Identity または G Suite にユーザー アカウントがないユーザーの場合は、手動で作成する必要があります。

このアプローチは要件を満たし、最も設定が簡単ですが、Active Directory で行われた属性の変更やユーザーの停止がいずれも Cloud Identity または G Suite に反映されないという制限があります。

アプローチ 2: Cloud Directory Sync の使用と手動での割り当て

このアプローチでは、既存のアカウントを持たないユーザー用に Cloud Identity または G Suite でユーザー アカウントを手動で作成する必要があります。

このアプローチの主な制限事項は、外部 IdP に一致する ID のない移行対象アカウントの削除を防ぐことができないことです。したがって、このアプローチは、外部 IdP に一致する ID のない一般ユーザー向けアカウントがない場合にのみ適用できます。

アプローチ 3: Cloud Directory Sync によるユーザーの作成を許可しない

プロビジョニングを構成するときは、Cloud Directory Sync が Cloud Identity や G Suite にアクセスできるようにする必要があります。通常は、そのための特権管理者アカウントを使用することをおすすめします。特権アカウントはシングル サインオンの適用対象外であるためです(つまり、SSO の構成は適用されず、ログインには引き続きパスワードが使用されます)。

ただし、このシナリオでは、移行用にさらに制限をかけたアカウントを Cloud Directory Sync で使用し、ユーザーが作成されないようにできます。この操作により、効果的に Cloud Directory Sync によって一般ユーザー向けアカウントの ID で、自動的にプロビジョニングされるのを防止し、外部 IdP に一致する ID のないアカウントが削除されるのを防ぎます

Cloud Identity または G Suite の制限付き管理者ユーザー アカウントには、次の権限のみが付与されます。

  • [組織部門]
  • [ユーザー] > [読み取り]
  • [ユーザー] > [更新]
  • [グループ]
  • [スキーマの管理]
  • [ドメインの管理]

このアプローチのデメリットは、非マネージド アカウントを持たないユーザーの場合、Cloud Identity または G Suite に手動でアカウントを作成する必要があることです。

Active Directory との連携: 比較

次の表は各アプローチを比較してまとめたものです。

一般ユーザー向けアカウントの ID でのシングル サインオンを許可する 一般ユーザー向けアカウントの ID での自動ユーザー プロビジョニングを禁止する 外部 IdP に一致する ID のない移行対象アカウントの削除を防ぐ 新しいアカウントを自動プロビジョニングする 移行対象アカウントを自動更新する
アプローチ 1: プロビジョニングを構成しない X X
アプローチ 2: GCDS の使用と手動での割り当て 手動によるエラーが発生しやすい X
アプローチ 3: GCDS にユーザーの作成を許可しない X

アカウント統合で Okta 連携を安全に使用する

Cloud Identity や G Suite と Okta を連携させるには、Okta の管理インターフェースで使用可能なアプリケーションのライブラリから G Suite または Google Cloud アプリを使用できます。これらのアプリの機能は補完的なものであるため、次のように組み合わせて使用する必要があります。

プロビジョニングに G Suite アプリを使用する場合、Okta に対応するものがない Cloud Identity または G Suite の既存のユーザーが Okta によって無視されるため、外部 IdP の ID で一致しない移行対象アカウントの削除を防ぐという要件は必ず満たされます。

Okta の構成方法に応じて、次の操作を行う必要があります。

これらの要件を満たす方法はいくつかあります。それぞれにメリットとデメリットがあります。

アプローチ 1: プロビジョニングを構成しない

このアプローチでは、シングル サインオンを処理するように G Suite または Google Cloud のアプリを構成し、プロビジョニングは構成しません。ユーザー プロビジョニングを構成しないことで、一般ユーザー向けアカウントの ID での自動ユーザー プロビジョニングを防ぐことができます。

一般ユーザー向けアカウントの ID でのシングル サインオンを許可するには、既存の一般ユーザー向けアカウントが移行対象の場合でも、最終的に Google サービスにアクセスする必要があるすべての ID にアプリを割り当てます。アプリに割り当てられたすべての ID の Okta ホームページに、G Suite または Google Cloud のアイコンが表示されます。ただし、対応するユーザー アカウントが Google 側に存在しないと、ログインは失敗します。

既存の一般ユーザー向けアカウントを持つユーザーの場合は、移行リクエストが承認されると、対応する Cloud Identity または G Suite のユーザー アカウントが自動的に作成されます。そのユーザーはすぐにシングル サインオンを使用できます。

このアプローチは要件を満たし、最も設定が簡単ですが、Okta で行われた属性の変更やユーザーの停止がいずれも Cloud Identity または G Suite に反映されないという制限があります。このアプローチのもう 1 つのデメリットは、既存の一般ユーザー向けアカウントを持たないすべてのユーザーのアカウントを Cloud Identity または G Suite で手動で作成する必要があることです。

アプローチ 2: プロビジョニングと手動による割り当て

このアプローチでは、シングル サインオンとプロビジョニングを処理するように G Suite アプリを構成しますが、次のプロビジョニング機能のみを有効にします。

  • ユーザーの作成
  • ユーザー属性の更新
  • ユーザーの無効化

ユーザーの Okta ホームページに Google Cloud アイコンを追加するには、必要に応じて Google Cloud アプリを構成します。アプリに ID を割り当てる際、最終的に Google サービスにアクセスする必要がある ID を含めますが、既存の一般ユーザー向けアカウントを持っている ID はすべて除外します。この操作により、一般ユーザー向けアカウントの ID での自動ユーザー プロビジョニングを防ぐことができます。

ユーザーが移行リクエストを承認したらすぐに、シングル サインオンを使用して G Suite または Google Cloud にアクセスできるように、ユーザーをアプリに割り当てます。

このアプローチのデメリットの 1 つは、割り当てに誤りがあると、すぐに競合するアカウントが作成される可能性があるため、他のアプローチよりもリスクが高くなります。

もう 1 つのデメリットは、移行対象アカウントの一時的なロックアウトが発生することです。移転リクエストを受信した後、ユーザーは後続のすべてのサインオンを Okta を介して実行する必要があります。ユーザーを Okta のアプリに割り当てるまで、このサインオン試行は失敗することになります。

アプローチ 3: プロビジョニングとユーザー作成の無効化

このアプローチでは、シングル サインオンとプロビジョニングを処理するように G Suite を構成しますが、次のプロビジョニング機能のみを有効にします。

  • ユーザー属性の更新
  • ユーザーの無効化

[ユーザーの作成] オプションは無効のままにします。

ユーザーの Okta ホームページに Google Cloud アイコンを追加するには、必要に応じて Google Cloud アプリを構成します。最終的に Google サービスにアクセスする必要があるすべての ID をアプリに割り当てます。既存の一般ユーザー向けアカウントの ID を含めて、一般ユーザー向けアカウントの ID でのシングル サインオンを許可します。

Okta によるアカウントの作成を許可しないことで、Okta による一般ユーザー向けアカウントの ID でのユーザー アカウントの自動的プロビジョニングを防ぎます。それに加えて、この構成では Okta に引き続き、対応する Google アカウントを持つユーザーのために Cloud Identity や G Suite に属性変更やユーザー停止を伝播させることができます。

Cloud Identity または G Suite に対応するユーザー アカウントがない ID の場合、Okta が Okta 管理コンソールにエラー メッセージを表示することがあります。

Okta エラー メッセージ。

既存の一般ユーザー向けアカウントを持つユーザーの場合は、移行リクエストが承認されると、対応する Cloud Identity または G Suite のユーザー アカウントが自動的に作成されます。そのユーザーはすぐにシングル サインオンを使用できます。この時点でユーザー アカウントは機能していますが、ユーザーの Okta ホームページにはアイコンがまだ表示されず、代わりに管理 UI にエラー メッセージが表示される場合もあります。解決するには、Okta の管理者ダッシュボードで割り当てタスクを再試行します。

このアプローチでは、Okta によって一般ユーザー向けアカウントの ID で、自動的にプロビジョニングされるのを防止できますが、一般ユーザー向けアカウントの ID でのシングル サインオンは依然として可能です。また、2 つ目の方法よりも構成のミスが発生しにくくなります。既存の一般ユーザー向けアカウントを持たないユーザーの場合、Cloud Identity または G Suite でユーザー アカウントを手動で作成する必要があるというデメリットはそのままです。

アプローチ 4: 2 つのアプリの使用と手動による割り当て

1 つはプロビジョニング用、もう 1 つはシングル サインオン用に 2 つのアプリを使用することで、これまでのアプローチの欠点がいくつか克服されます。

  • プロビジョニングのみを処理するように G Suite アプリを構成します。アプリのシングル サインオン機能は使用されません。このアプリにユーザーを割り当てることで、Cloud Identity や G Suite にプロビジョニングされるアカウントを制御できます。[ユーザーに対してアプリケーション アイコンを表示しない] オプションを有効にすると、アプリがユーザーに表示されなくなります。
  • Google Cloud アプリまたは G Suite アプリの別のインスタンスを、シングル サインオン専用に構成します。このアプリにユーザーを割り当てることで、サインオンが許可されるユーザーや Okta のホームページに Google Cloud アイコンが表示されるユーザーを制限できるようになります。

これら 2 つのアプリを使用して、次のようにユーザーを割り当てます。

Okta との連携: 比較

次の表は各アプローチを比較してまとめたものです。

一般ユーザー向けアカウントの ID でのシングル サインオンを許可する 一般ユーザー向けアカウントの ID での自動ユーザー プロビジョニングを禁止する 外部 IdP に一致する ID のない移行対象アカウントの削除を防ぐ 新しいアカウントを自動プロビジョニングする 移行対象アカウントを自動更新する
アプローチ 1: プロビジョニングを設定しない X X
アプローチ 2: プロビジョニングと手動による割り当て X リスクが高い
アプローチ 3: プロビジョニングとユーザー作成の無効化 X
アプローチ 4: 2 つのアプリの使用と手動による割り当て リスクが高い

次のステップ