プロビジョニングとは

プロビジョニングとプロビジョニング解除は、複数のシステム間でデジタル ID の一貫性を確保するプロセスです。 これらのプロセスは通常、ID ライフサイクル管理の一部として使用されます。

プロビジョニングは、特定の条件に基づいて、対象のシステムに ID を作成するプロセスです。 プロビジョニング解除は、条件を満たさなくなった ID を対象のシステムから削除するプロセスです。 同期は、ソース オブジェクトとターゲット オブジェクトがほぼ一致するように、プロビジョニングされたオブジェクトを最新の状態に維持するプロセスです。

たとえば、新しい従業員が組織に加わると、その従業員は人事システムに入力されます。 その時点で、人事から Azure Active Directory (Azure AD) へのプロビジョニングによって、対応するユーザー アカウントが Azure AD に作成されます。 その新しい従業員のアカウントは、Azure AD に対してクエリを実行するアプリケーションで確認できます。 Azure AD を使用しないアプリケーションがある場合は、Azure AD からこれらのアプリケーションのデータベースへのプロビジョニングにより、ユーザーは、そのユーザーがアクセスする必要があるすべてのアプリケーションに確実にアクセスできるようになります。 このプロセスによって、ユーザーは出社したその日から仕事に着手し、必要なアプリケーションやシステムにアクセスすることができます。 同様に、人事システムでユーザーのプロパティ (部署、雇用状態など) に変更が生じた場合、それらの更新内容を人事システムから Azure AD、さらには、他のアプリケーション、ターゲット データベースに同期することで一貫性が確保されます。

プロビジョニングの自動化に関して、Azure AD には現在 3 つの領域が用意されています。 これらは次のとおりです。

ID ライフサイクル管理の図。

人事主導のプロビジョニング

人事のプロビジョニングの図。

人事から Azure AD へのプロビジョニングには、人事システム内の情報に基づいてオブジェクトを作成することが含まれます。これは通常、各従業員を表すユーザー ID ですが、部署などの構造を表す別のオブジェクトである場合もあります。

最も一般的なシナリオは、新しい従業員が会社に加わったときの、それらの従業員の人事システムへの入力です。 その場合は、Azure AD で新しいユーザーとして自動的にプロビジョニングされるため、新規採用のたびに管理者が関与する必要はありません。 一般に、人事からのプロビジョニングでは、次のシナリオに対応できます。

  • 新しい従業員の採用 - 新しい従業員が人事システムに追加された場合は、ユーザー アカウントが Active Directory、Azure AD のほか、必要に応じて Azure AD でサポートされている他のアプリケーションのディレクトリ内に自動的に作成され、電子メール アドレスが人事システムに書き戻されます。
  • 従業員の属性とプロファイルの更新 - 人事システムで従業員レコード (氏名、職名、管理者など) が更新されると、Active Directory や Azure AD (および必要に応じて Azure AD によってサポートされているその他のアプリケーション) でユーザー アカウントが自動的に更新されます。
  • 従業員の退職 - 人事システムで従業員が退職状態になると自動的に、ユーザー アカウントがサインインできないようブロックされるか、Active Directory と Azure AD、およびその他のアプリケーションから削除されます。
  • 従業員の再雇用 - 従業員がクラウド人事システムで再雇用された場合は、その以前のアカウントを自動的に再アクティブ化または (設定に応じて) 再プロビジョニングできます。

Azure AD を使用した人事主導のプロビジョニングには、3 つのデプロイ方法があります。

  1. Workday または SuccessFactors の単一サブスクリプションを所有していて、Active Directory を使用しない組織向け
  2. Workday または SuccessFactors の単一サブスクリプションを所有していて、Active Directory と Azure AD の両方を使用する組織向け
  3. 複数の人事システムまたはオンプレミスの人事システム (SAP、Oracle eBusiness、PeopleSoft など) を所有する組織向け

詳細については、「人事主導のプロビジョニングとは」を参照してください。

アプリのプロビジョニング

アプリのプロビジョニングのフローを示す図。

Azure AD における アプリのプロビジョニング という用語は、Azure AD や Active Directory とは異なる独自のデータ ストアを有するアプリケーションに関して、ユーザーがアクセスする必要のあるアプリケーションに、ユーザー ID のコピーを自動的に作成することを意味します。 アプリのプロビジョニングには、ユーザー ID の作成に加えて、ユーザーの状態または役割が変化したときに、ユーザー ID をメンテナンスしたりそれらのアプリから削除したりすることも含まれます。 一般的なシナリオとしては、DropboxSalesforceServiceNow といったアプリケーションへの Azure AD ユーザーのプロビジョニングが挙げられます。これらのアプリケーションにはいずれも、Azure AD とは異なる独自のユーザー リポジトリがあります。

詳細については、「アプリのプロビジョニングとは」を参照してください。

ディレクトリ間のプロビジョニング

ディレクトリ間のプロビジョニングを示す図

多くの組織は Active Directory と Azure AD の両方を利用していて、なおかつ、Active Directory に接続されたアプリケーション (オンプレミスのファイル サーバーなど) を所有している場合があります。

これまで、多くの組織では人事主導のプロビジョニングをオンプレミスでデプロイしているため、すべての従業員のユーザー ID が Active Directory に既に存在する可能性があります。 ディレクトリ間のプロビジョニングの最も一般的なシナリオは、Active Directory に既に存在するユーザーを Azure AD にプロビジョニングすることです。 このプロビジョニングは通常、Azure AD Connect 同期または Azure AD Connect クラウド プロビジョニングによって実現されます。

また、組織が Azure AD からオンプレミスのシステムへのプロビジョニングを希望する場合もあります。 たとえば、組織が Azure AD ディレクトリにゲストを招待し、それらのゲストが、Windows 統合認証 (WIA) を利用するオンプレミスの Web アプリケーションにアプリケーション プロキシ経由でアクセスする必要が生じたとします。 このシナリオでは、Azure AD 内のそれらのユーザーのために、オンプレミスの AD アカウントをプロビジョニングする必要があります。

詳細については、「ディレクトリ間のプロビジョニングとは」を参照してください。

次のステップ