プロビジョニングとは
プロビジョニングとプロビジョニング解除は、複数のシステム間でデジタル ID の一貫性を確保するプロセスです。 これらのプロセスは通常、ID ライフサイクル管理の一部として使用されます。
プロビジョニングは、特定の条件に基づいて、対象のシステムに ID を作成するプロセスです。 プロビジョニング解除は、条件を満たさなくなった ID を対象のシステムから削除するプロセスです。 同期は、ソース オブジェクトとターゲット オブジェクトがほぼ一致するように、プロビジョニングされたオブジェクトを最新の状態に維持するプロセスです。
たとえば、新しい従業員が組織に加わると、その従業員は人事システムに入力されます。 その時点で、人事から Microsoft Entra ID へのプロビジョニングを行うと、Microsoft Entra ID の対応するユーザー アカウントを作成できます。 その新しい従業員のアカウントは、Microsoft Entra ID に対してクエリを実行するアプリケーションで確認できます。 Microsoft Entra ID を使用しないアプリケーションがある場合は、Microsoft Entra ID からそれらのアプリケーションのデータベースへのプロビジョニングにより、ユーザーは、そのユーザーがアクセスする必要があるすべてのアプリケーションに確実にアクセスできるようになります。 このプロセスによって、ユーザーは出社したその日から仕事に着手し、必要なアプリケーションやシステムにアクセスすることができます。 同様に、人事システムでユーザーのプロパティ (部署、雇用状態など) に変更が生じた場合、それらの更新内容を人事システムから Microsoft Entra ID、さらには、他のアプリケーション、ターゲット データベースに同期することで一貫性が確保されます。
プロビジョニングの自動化に関して、Microsoft Entra ID には現在 3 つの領域が用意されています。 以下のとおりです:
- ディレクトリを除く外部の信頼できる記録システムから Microsoft Entra ID へのプロビジョニング (人事主導のプロビジョニングを使用)
- Microsoft Entra ID からアプリケーションへのプロビジョニング (アプリのプロビジョニングを使用)
- Microsoft Entra ID と Active Directory Domain Services の間のプロビジョニング (ディレクトリ間のプロビジョニングを使用)
人事主導のプロビジョニング
人事から Microsoft Entra ID へのプロビジョニングには、人事システム内の情報に基づいてオブジェクトを作成することが含まれます。これは通常、各従業員を表すユーザー ID ですが、部署などの構造を表す別のオブジェクトである場合もあります。
最も一般的なシナリオは、新しい従業員が会社に加わったときの、それらの従業員の人事システムへの入力です。 その場合は、Microsoft Entra ID で新しいユーザーとして自動的にプロビジョニングされるため、新規採用のたびに管理者が関与する必要はありません。 一般に、人事からのプロビジョニングでは、次のシナリオに対応できます。
- 新しい従業員の採用 - 新しい従業員が人事システムに追加された場合は、ユーザー アカウントが Active Directory、Microsoft Entra ID のほか、必要に応じて Microsoft Entra ID でサポートされているプリケーションのディレクトリ内に自動的に作成され、電子メール アドレスが人事システムに書き戻されます。
- 従業員の属性とプロファイルの更新 - Workday で従業員レコード (名前、職名、マネージャーなど) が更新されると、Active Directory、Microsoft Entra ID のほか、必要に応じて Microsoft Entra ID でサポートされているその他のアプリケーションでユーザー アカウントが自動的に更新されます。
- 従業員の退職 - 人事システムで従業員が退職状態になると自動的に、ユーザー アカウントがサインインできないようブロックされるか、Active Directory と Microsoft Entra ID、およびその他のアプリケーションから削除されます。
- 従業員の再雇用 - 従業員がクラウド人事システムで再雇用された場合は、その以前のアカウントを自動的に再アクティブ化または (設定に応じて) 再プロビジョニングできます。
Microsoft Entra ID を使用した人事主導のプロビジョニングには、3 つのデプロイ方法があります。
- Workday または SuccessFactors の単一サブスクリプションを所有していて、Active Directory を使用しない組織向け
- Workday または SuccessFactors の単一サブスクリプションを所有していて、Active Directory と Microsoft Entra ID の両方を使用する組織向け
- 複数の人事システムまたはオンプレミスの人事システム (SAP、Oracle eBusiness、PeopleSoft など) を所有する組織向け
詳細については、「人事主導のプロビジョニングとは」を参照してください。
アプリのプロビジョニング
Microsoft Entra ID におけるアプリのプロビジョニングという用語は、Microsoft Entra ID や Active Directory とは異なる独自のデータ ストアを有するアプリケーションに関して、ユーザーがアクセスする必要のあるアプリケーションに、ユーザー ID のコピーを自動的に作成することを意味します。 アプリのプロビジョニングには、ユーザー ID の作成に加えて、ユーザーの状態または役割が変化したときに、ユーザー ID をメンテナンスしたりそれらのアプリから削除したりすることも含まれます。 一般的なシナリオとしては、Dropbox、Salesforce、ServiceNow といったアプリケーションへの Microsoft Entra ユーザーのプロビジョニングが挙げられます。これらのアプリケーションにはいずれも、Microsoft Entra ID とは異なる独自のユーザー リポジトリがあります。
また、Microsoft Entra ID では、ファイアウォールを開くことなく、オンプレミスまたは仮想マシンでホストされているアプリケーションへのユーザーのプロビジョニングがサポートされています。 アプリケーションで SCIM がサポートされている場合、またはレガシ アプリケーションに接続するために SCIM ゲートウェイを構築済みの場合は、Microsoft Entra プロビジョニング エージェントを使用してアプリケーションに直接接続し、プロビジョニングとプロビジョニング解除を自動化できます。 SCIM をサポートしておらず、LDAP ユーザー ストアまたは SQL データベースに依存しているレガシ アプリケーションや、SOAP または REST API を持つレガシアプリケーションがある場合、Microsoft Entra ID ではそれらもサポートできます。
詳細については、「アプリのプロビジョニングとは」を参照してください。
ディレクトリ間のプロビジョニング
多くの組織は Active Directory と Microsoft Entra ID の両方を利用していて、なおかつ、Active Directory に接続されたアプリケーション (オンプレミスのファイル サーバーなど) を所有している場合があります。
これまで、多くの組織では人事主導のプロビジョニングをオンプレミスでデプロイしているため、すべての従業員のユーザー ID が Active Directory に既に存在する可能性があります。 ディレクトリ間のプロビジョニングの最も一般的なシナリオは、Active Directory に既に存在するユーザーを Microsoft Entra ID にプロビジョニングすることです。 このプロビジョニングは、通常、Microsoft Entra Connect 同期または Microsoft Entra Connect クラウド プロビジョニングによって実現されます。
また、組織が Microsoft Entra ID からオンプレミスのシステムへのプロビジョニングを希望する場合もあります。 たとえば、組織がMicrosoft Entra ディレクトリにゲストを招待し、それらのゲストが、Windows 統合認証 (WIA) を利用するオンプレミスの Web アプリケーションにアプリケーション プロキシ経由でアクセスする必要が生じたとします。 このシナリオでは、Microsoft Entra ID 内のそれらのユーザーのために、オンプレミスの AD アカウントをプロビジョニングする必要があります。
詳細については、「ディレクトリ間のプロビジョニングとは」を参照してください。