次の方法で共有

アプリケーションを Microsoft Entra ID と統合し、レビューされたアクセスのベースラインを確立する

  • [アーティクル]

アプリケーションにアクセスする必要があるユーザー用のポリシーを確立したら、アプリケーションを Microsoft Entra ID に接続し、そのアプリケーションへのアクセスを管理するためのポリシーをデプロイできます。

Microsoft Entra ID ガバナンスは、SAP R/3、SAP S/4HANA などの主要なアプリケーションや、OpenID Connect、SAML、SCIM、SQL、LDAP、SOAP、REST などの標準を使うものなど、さまざまなアプリケーションと統合できます。 これらの標準を介して、多くの一般的な SaaS アプリケーションやオンプレミス アプリケーション (組織が開発したアプリケーションを含む) と共に Microsoft Entra ID を使用できます。 このデプロイ計画では、アプリケーションを Microsoft Entra ID に接続し、そのアプリケーションで ID ガバナンス機能を使用できるようにする方法について説明します。

アプリケーションに Microsoft Entra ID ガバナンスを使うには、最初にアプリケーションを Microsoft Entra ID と統合し、ディレクトリに表示する必要があります。 アプリケーションを Microsoft Entra ID と統合するには、次の 2 つの要件のいずれかを満たす必要があります。

  • アプリケーションが、フェデレーション SSO を Microsoft Entra ID に依存し、Microsoft Entra ID が認証トークンの発行を制御します。 Microsoft Entra ID がアプリケーションの唯一の ID プロバイダーである場合、Microsoft Entra ID でアプリケーションのロールのいずれかに割り当てられているユーザーのみが、アプリケーションにサインインできます。 アプリケーション ロールの割り当てを失ったそれらのユーザーは、アプリケーションにサインインするための新しいトークンを取得できなくなります。
  • アプリケーションが、Microsoft Entra ID によってアプリケーションに提供されるユーザーまたはグループの一覧に依存します。 これは、SCIM などのプロビジョニング プロトコルを使用して、あるいは Microsoft Graph 経由で Microsoft Entra ID にクエリを実行するアプリケーション、または AD Kerberos を使用してユーザーのグループ メンバーシップを取得するアプリケーションで実現できる可能性があります。

アプリケーションが Microsoft Entra ID に依存しない場合など、アプリケーションでこれらの条件がいずれも満たされない場合でも、ID ガバナンスを使うことができます。 ただし、条件を満たさずに ID ガバナンスを使用する場合は、いくつかの制限がある場合があります。 たとえば、Microsoft Entra ID に含まれていない、または Microsoft Entra ID でアプリケーション ロールに割り当てられていないユーザーは、ユーザーがアプリケーション ロールに割り当てるまで、アプリケーションのアクセス レビューに含まれません。 詳細については、「アプリケーションへのユーザーのアクセスのアクセス レビューを準備する」を参照してください。

アプリケーションを Microsoft Entra ID と統合して、承認されたユーザーのみがアプリケーションにアクセスできることを確認する

通常、アプリケーションを統合するこのプロセスが開始されるのは、フェデレーション シングル サインオン (SSO) プロトコル接続を使用して、ユーザー認証のために Microsoft Entra ID に依存するようにアプリケーションを構成し、プロビジョニングを追加するときです。 SSO で最もよく使用されるプロトコルは、SAML と OpenID Connect です。 ツールとプロセスの詳細を確認し、Microsoft Entra ID に対するアプリケーションの認証を確認して移行することができます。

次に、アプリケーションでプロビジョニング プロトコルが実装される場合は、ユーザーをアプリケーションにプロビジョニングするように Microsoft Entra ID を構成し、ユーザーにアクセス権が付与されたとき、またはユーザーのアクセス権が削除されたときに、Microsoft Entra ID がアプリケーションに通知できるようにする必要があります。 これらのプロビジョニング シグナルにより、アプリケーションは、従業員によって作成され、管理者に任せられたコンテンツを再割り当てするなどの、自動修正を行うことができます。

  1. アプリケーションがエンタープライズ アプリケーションの一覧またはアプリケーション登録の一覧に含まれているかどうかを確認します。 アプリケーションがテナントに既に存在する場合は、このセクションの手順 5 に進みます。

  2. アプリケーションがテナントにまだ登録されていない SaaS アプリケーションの場合は、フェデレーション SSO 用に統合できるアプリケーションのアプリケーション ギャラリーでアプリケーションを使用できるかどうかを確認します。 ギャラリー内にある場合は、チュートリアルを使用してアプリケーションを Microsoft Entra ID と統合します。

    1. チュートリアルに従って、Microsoft Entra ID を使用してフェデレーション SSO 用にアプリケーションを構成します。
    2. アプリケーションがプロビジョニングをサポートする場合は、プロビジョニング用にアプリケーションを構成します。
    3. 完了したら、この記事の次のセクションに進んでください。 SaaS アプリケーションがギャラリーにない場合は、SaaS ベンダーにオンボードを依頼してください。

  3. これがプライベート アプリケーションまたはカスタム アプリケーションの場合は、アプリケーションの場所と機能に基づいて、最も適切なシングル サインオン統合を選択することもできます。

  4. アプリケーションに複数のロールがある場合、各ユーザーはアプリケーションで 1 つのロールしか持たず、アプリケーションは Microsoft Entra ID に依存して、アプリケーションにサインインするユーザーの要求としてユーザーの単一のアプリケーション固有のロールを送信し、アプリケーションの Microsoft Entra ID でそれらのアプリ ロールを構成してから、各ユーザーをアプリケーション ロールに割り当てます。 アプリ ロール UI を使って、これらのロールをアプリケーション マニフェストに追加できます。 Microsoft 認証ライブラリを使用している場合、アプリケーション内のアプリ ロールを使用してアクセス制御を行う方法のコード サンプルがあります。 ユーザーが複数のロールを同時に持つ可能性がある場合、アクセス制御にアプリ マニフェストのアプリ ロールを使用する代わりに、トークン要求または Microsoft Graph を介して使用できるセキュリティ グループをチェックするアプリケーションを実装できます。

  5. アプリケーションがプロビジョニングをサポートしている場合は、Microsoft Entra ID からそのアプリケーションへの、割り当て済みユーザーとグループのプロビジョニングを構成します。 これがプライベート アプリケーションまたはカスタム アプリケーションの場合は、アプリケーションの場所と機能に基づいて、最も適切なシングル サインオン統合を選択することもできます。

  6. アプリケーションで Microsoft Graph を使って Microsoft Entra ID のグループのクエリを実行する場合は、テナントから読み取ることができる適切なアクセス許可をアプリケーションに付与することに同意します。

  7. アプリケーションに割り当てられたユーザーに対してのみアプリケーションへのアクセスが許可されるように設定します。 この設定は、条件付きアクセス ポリシーが有効になる前に、ユーザーが誤って MyApps にアプリケーションを表示して、アプリケーションへのサインインを試みることを防ぎます。

最初のアクセス レビューを実行する

これは、組織が以前に使用していない新しいアプリケーションで、そのために誰も既存のアクセス権を持っていない場合、またはこのアプリケーションのアクセス レビューを既に実行している場合は、次のセクションに進みます。

ただし、アプリケーションが環境内に既に存在して、ユーザーが手動または帯域外のプロセスを通じて過去にアクセス権を取得している可能性がある場合は、それらのユーザーによるアクセスが、今後もまだ必要でかつ適切であることをレビューする必要があります。 より多くのユーザーがアクセスを要求できるようにするポリシーを有効にする前に、アプリケーションへのアクセス権を既に持っているユーザーのアクセス レビューを実行することをお勧めします。 このレビューは、すべてのユーザーが少なくとも 1 回レビューされるというベースラインを設定し、それらのユーザーが継続的なアクセスを許可されていることを確認します。

  1. 「アプリケーションへのユーザーのアクセスのアクセス レビューを準備する」の手順に従います。
  2. アプリケーションが Microsoft Entra ID または AD を使っておらず、プロビジョニング プロトコルをサポートしているか、基となる SQL または LDAP データベースがある場合、すべての既存のユーザーを取り込み、それらのためのアプリケーション ロールの割り当てを作成します。
  3. アプリケーションが Microsoft Entra ID または AD を使っておらず、プロビジョニング プロトコルもサポートしていない場合は、アプリケーションからユーザーの一覧を取得し、それぞれに対してアプリケーション ロールの割り当てを作成します。
  4. アプリケーションが AD セキュリティ グループを使用していた場合は、それらのセキュリティ グループのメンバーシップをレビューする必要があります。
  5. アプリケーションが独自のディレクトリまたはデータベースを保持し、プロビジョニング用に統合されていなかった場合は、レビューが完了した後に、アプリケーションの内部データベースまたはディレクトリを手動で更新して、拒否されたユーザーを削除することが必要になる場合があります。
  6. アプリケーションが AD セキュリティ グループを使用し、それらのグループが AD 内に作成されていた場合は、レビューが完了した後に、AD グループを手動で更新して、拒否されたユーザーのメンバーシップを削除する必要があります。 その後、拒否されたアクセス権が自動的に削除されるようにするには、Microsoft Entra ID 内に作成され Microsoft Entra ID に書き戻された AD グループを使用するようにアプリケーションを更新するか、またはメンバーシップを AD グループから Microsoft Entra グループに移動し、書き戻されたグループを AD グループの唯一のメンバーとして入れ子にすることができます。
  7. レビューが完了してアプリケーション アクセスが更新された場合、またはアクセス権を持つユーザーがいない場合は、次の手順に進み、アプリケーションの条件付きアクセスとエンタイトルメント管理ポリシーを展開します。

これで既存のアクセスがレビューされたことを確認するベースラインが作成されたので、継続的なアクセスと新しいアクセス要求に関する組織のポリシーを展開できます。

次のステップ