アプリケーションへのユーザーのアクセスのアクセス レビューを準備する

Microsoft Entra ID Governance を使うと、セキュリティや従業員の生産性に対する組織のニーズと、適切なプロセスや可視性とのバランスを取ることができます。 適切なリソースに対する適切なアクセス権を適切なユーザーに付与できるようになります。

コンプライアンス要件またはリスク管理計画がある組織には、機密性の高いアプリケーションまたはビジネス クリティカルなアプリケーションがあります。 アプリケーションの機密性は、その目的やそれに含まれるデータ (組織の顧客の財務情報や個人情報など) に基づいている可能性があります。 そのようなアプリケーションでは、アクセスが許可されるのは組織内のすべてのユーザーのサブセットのみであり、アクセスの許可は、文書化されたビジネス要件に基づいてのみ行う必要があります。 Microsoft Entra ID は、標準プロトコルと API インターフェイスを使用して、多くの一般的な SaaS アプリケーション、オンプレミスのアプリケーション、自分の組織が開発したアプリケーションと統合することができます。 これらのインターフェイスを介して、Microsoft Entra ID は、それらのアプリケーションにアクセスできるユーザーを制御する権限のあるソースになることができます。 アプリケーションを Microsoft Entra ID と統合すると、アクセス レビューを使って、それらのアプリケーションにアクセスできるユーザーを認定し、アクセスする必要がなくなったユーザーのアクセス権を削除できます。 また、「環境内のアプリケーションへのアクセスを管理する方法」で説明されているように、使用条件、条件付きアクセス、エンタイトルメント管理などの他の機能を使用してアプリケーションへのアクセスを管理することもできます。

アクセスをレビューするための前提条件

アプリケーションへのアクセスのアクセス レビューに Microsoft Entra ID を使用するには、テナントに次のいずれかのライセンスが必要です。

• Microsoft Entra ID P2 または Microsoft Entra ID Governance
• Enterprise Mobility + Security (EMS) E5 ライセンス

アクセス レビュー機能の使用にあたっては、ユーザーがこの機能を使用するために、これらのライセンスをユーザーに割り当てる必要はありませんが、十分なライセンスを所有している必要はあります。 詳細については、「アクセス レビューのライセンスのシナリオ例」を参照してください。

また、アプリケーションへのアクセスをレビューするためには必要ありませんが、すべてのアプリケーションへの他のユーザーのアクセスを制御する機能を持つ特権ディレクトリ ロールのメンバーシップを定期的に確認することもお勧めします。 Global Administrator、Identity Governance Administrator、User Administrator、Application Administrator、Cloud Application Administrator、Privileged Role Administrator の管理者は、ユーザーとそのアプリケーション ロールの割り当てを変更できるため、これらのディレクトリ ロールのアクセス レビューがスケジュールされていることを確認します。

アプリケーションと 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 によってアプリケーションに提供されるユーザーまたはグループの一覧に依存します。 このフルフィルメントは、クロスドメイン ID 管理システム (SCIM) などのプロビジョニング プロトコルを使用して、アプリケーションが Microsoft Graph を介して Microsoft Entra ID を照会すること、Microsoft Entra が AD DS に書き込まれるアプリケーションのデータベースまたはグループにユーザーをプロビジョニングすることによって実行できます。 レビューによって拒否されたユーザーは、アプリケーション ロールの割り当てまたはグループ メンバーシップを失い、それらの変更がアプリケーションで使用可能になると、拒否されたユーザーはアクセスできなくなります。

アプリケーションでこれらの条件がいずれも満たされない場合、アプリケーションは Microsoft Entra ID に依存しないため、アクセス レビューを使用することはできますが、いくつかの制限が生じます。 Microsoft Entra ID 内に存在しないユーザー、または Microsoft Entra ID 内でアプリケーション ロールに割り当てられていないユーザーは、レビューに関与しません。 また、アプリケーションがサポートするプロビジョニング プロトコルがない場合、拒否されたユーザーを削除するための変更をアプリケーションに自動的に送信することはできません。 組織には、代わりに、完了したレビューの結果をアプリケーションに送信するプロセスが必要です。

Microsoft Entra ID でさまざまなアプリケーションや IT 要件に対処できるようにするために、アプリケーションと Microsoft Entra ID を統合する方法には複数のパターンがあります。 各パターンでは、異なる Microsoft Entra 成果物が使用されます。 次のフローチャートは、アプリケーションで ID ガバナンスに使用するのに適した 3 つの統合パターン A、B、C のいずれかを選択する方法を示したものです。 特定のアプリケーションで使用されているパターンを把握すると、アクセス レビューに備えて適切なリソースを Microsoft Entra ID で構成するのに役立ちます。

その他のオプション

前のセクションで取り上げられた統合パターンは、サード パーティの SaaS アプリケーション、あるいは組織が開発した、または組織用に開発されたアプリケーションに適用されます。

• Exchange Online などの一部の Microsoft オンライン サービスでは、ライセンスが使われます。 ユーザーのライセンスを直接レビューすることはできませんが、割り当てられたユーザーのグループでグループ ベースのライセンス割り当てを使っている場合は、代わりにそれらのグループのメンバーシップをレビューできます。
• 一部のアプリケーションは、委任されたユーザーの同意を使って、Microsoft Graph や他のリソースへのアクセスを制御します。 各ユーザーによる同意は承認プロセスによって制御されないため、Microsoft Entra ID で同意をレビューすることはできません。 代わりに、アプリケーション ロールの割り当てまたはグループ メンバーシップに基づく条件付きアクセス ポリシーを使ってアプリケーションに接続できるユーザーをレビューできます。
• アプリケーションでフェデレーションまたはプロビジョニング プロトコルがサポートされていない場合は、レビューが完了したときに結果を手動で適用するプロセスが必要です。 パスワード SSO 統合のみをサポートするアプリケーションの場合、レビューが完了してアプリケーションの割り当てが削除されると、アプリケーションはユーザーの myapps ページに表示されなくなりますが、パスワードを既に知っているユーザーがアプリケーションに引き続きサインインすることが妨げられることはありません。 オンプレミス アプリケーションに関しては、「プロビジョニングをサポートしていないアプリケーションのユーザーの管理」を参照してください。 SaaS アプリケ―ションの場合は、アプリケーションを更新して標準プロトコルをサポートすることで、フェデレーションまたはプロビジョニングのためにアプリ ギャラリーにオンボードするように、SaaS ベンダーに依頼してください。

アプリケーションがレビューできる状態であることを確認する

アプリケーションの統合パターンがわかったので、Microsoft Entra ID で表されるアプリケーションがレビューできる状態であることを確認します。

1. Microsoft Entra 管理センターに少なくとも ID ガバナンス管理者としてサインインします。

2. >[ID]>[アプリケーション]>[エンタープライズ アプリケーション] の順に移動します。

3. ここで、お使いのアプリケーションが、テナント内のエンタープライズ アプリケーションの一覧に含まれているかどうかを確認できます。

4. アプリケーションがまだ一覧にない場合は、フェデレーション SSO またはプロビジョニング用に統合できるアプリケーションのアプリケーション ギャラリーでアプリケーションが利用できるかを確認します。 ギャラリーにある場合は、チュートリアルに従ってフェデレーション用にアプリケーションを構成し、プロビジョニングをサポートしている場合は、プロビジョニング用にもアプリケーションを構成します。

5. アプリケーションがまだ一覧になく、AD セキュリティ グループを使用していて、Web アプリケーションである場合で、かつ AD 内のさまざまなセキュリティ グループを検索するようにアプリケーションの構成を変更できる場合は、アプリケーション プロキシ経由でアプリケーションをリモート アクセスに追加し、既存の AD セキュリティ グループのメンバーシップを新しい Microsoft Entra グループに移動し、AD へのグループの書き戻しを構成します。 次に、「オンプレミスの Active Directory ベースのアプリ (Kerberos) の管理」で説明されているように、グループの書き戻しによって作成された新しい AD グループをチェックするようにアプリケーションを更新します。

6. アプリケーションがまだ一覧になく、AD セキュリティ グループを使用していて、Web アプリケーションである場合で、かつ AD 内のさまざまなセキュリティ グループを検索するようにアプリケーションの構成を変更できない場合は、アプリケーション プロキシ経由でアプリケーションをリモート アクセスに追加し、既存の AD セキュリティ グループのメンバーシップを新しい Microsoft Entra グループに移動し、AD へのグループの書き戻しを構成します。 次に、「オンプレミスの Active Directory ベースのアプリ (Kerberos) の管理」で説明されているように、アプリケーションがチェックしていた既存の AD セキュリティ グループを更新して、新しいグループをメンバーとして含めます。

7. アプリケーションがまだ一覧になく、AD セキュリティ グループを使用していて、Web アプリケーションではない場合で、かつ AD 内のさまざまなセキュリティ グループを検索するようにアプリケーションの構成を変更できる場合は、既存の AD セキュリティ グループのメンバーシップを新しい Microsoft Entra グループに移動し、AD へのグループの書き戻しを構成します。 次に、「オンプレミスの Active Directory ベースのアプリ (Kerberos) の管理」で説明されているように、グループの書き戻しによって作成された新しい AD グループをチェックするようにアプリケーションを更新します。 次に、次のセクションに進みます。

8. アプリケーションがまだ一覧になく、AD セキュリティ グループを使用していて、Web アプリケーションではない場合で、かつ AD 内のさまざまなセキュリティ グループを検索するようにアプリケーションの構成を変更できない場合は、既存の AD セキュリティ グループのメンバーシップを新しい Microsoft Entra グループに移動し、AD へのグループの書き戻しを構成します。 次に、「オンプレミスの Active Directory ベースのアプリ (Kerberos) の管理」で説明されているように、アプリケーションがチェックしていた既存の AD セキュリティ グループを更新して、新しいグループをメンバーとして含めます。 次に、次のセクションに進みます。

9. アプリケーションがテナント内のエンタープライズ アプリケーションの一覧に表示されたら、一覧からアプリケーションを選択します。

10. [プロパティ] タブに移動します。[ユーザーの割り当てが必要ですか?] オプションが [はい] に設定されていることを確認します。 [いいえ] に設定されている場合は、外部 ID を含むディレクトリ内のすべてのユーザーがアプリケーションにアクセスでき、アプリケーションへのアクセスをレビューすることはできません。

    

11. [ロールと管理者] タブに移動します。このタブには、管理ロールが表示されます。このロールは、アプリケーションでのアクセス権ではなく、Microsoft Entra ID でのアプリケーションの表示を制御する権限を付与します。 アプリケーションの統合または割り当てを変更できるアクセス許可を持ち、その管理ロールへの割り当てを持つ各管理ロールについて、承認されたユーザーのみがそのロールに含まれることを確認します。

12. [プロビジョニング] タブに移動します。自動プロビジョニングが構成されておらず停止されているか検疫状態である場合は、Microsoft Entra ID には、ユーザーのアクセスがレビューで拒否された場合にアクセスが削除されたことをアプリケーションに通知する方法がありません。 アプリケーションがフェデレーションされ、その ID プロバイダーとして Microsoft Entra ID にのみ依存している場合や、アプリケーションが AD DS グループを使用している場合など、統合パターンによってはプロビジョニングが必要ないこともあります。 しかし、アプリケーションの統合パターンが C であり、アプリケーションで Microsoft Entra ID を唯一の ID プロバイダーとするフェデレーション SSO がサポートされていない場合は、Microsoft Entra ID からアプリケーションへのプロビジョニングを構成する必要があります。 プロビジョニングが必要なのは、レビューが完了したときに、Microsoft Entra ID がレビューされたユーザーをアプリケーションから自動的に削除できるようにするためであり、この削除ステップは、SCIM、LDAP、SQL、SOAP、または REST を介して Microsoft Entra ID からアプリケーションに送信される変更を通じて実行できます。

    • このアプリケーションがプロビジョニングをサポートするギャラリー アプリケーションの場合は、プロビジョニング用にアプリケーションを構成します。
    • アプリケーションがクラウド アプリケーションであり、SCIM をサポートしている場合は、SCIM を使ってユーザー プロビジョニングを構成します。
    • アプリケーションがオンプレミス アプリケーションであり、SCIM をサポートしている場合は、オンプレミスの SCIM ベースのアプリ用のプロビジョニング エージェントでアプリケーションを構成します。
    • アプリケーションが SQL データベースに依存している場合は、オンプレミスの SQL ベースのアプリケーション用のプロビジョニング エージェントを使用するアプリケーションを構成します。
    • アプリケーションが別の LDAP ディレクトリに依存している場合は、オンプレミスの LDAP ベースのアプリケーション用のプロビジョニング エージェントでアプリケーションを構成します。
    • アプリケーションに SOAP または REST API を使用して管理されるローカル ユーザー アカウントがある場合は、Web サービス コネクタとプロビジョニング エージェントを使用してアプリケーションを構成します。
    • アプリケーションに MIM コネクタを使用して管理されるローカル ユーザー アカウントがある場合は、カスタム コネクタとプロビジョニング エージェントを使用してアプリケーションを構成します。
    • アプリケーションが NetWeaver AS ABAP 7.0 以降の SAP ECC である場合は、SAP ECC で構成された Web サービス コネクタとプロビジョニング エージェントを使用してアプリケーションを構成します。

詳細については、「Microsoft Entra ID とアプリケーションの統合」を参照してください。

1. プロビジョニングが構成されている場合は、[属性マッピングの編集] を選択し、[マッピング] セクションを展開して、[Microsoft Entra ユーザーのプロビジョニング] を選択します。 属性マッピングの一覧に、ユーザーがアクセス権を失ったときに Microsoft Entra ID に false に設定させたい、アプリケーションのデータ ストア内の属性への isSoftDeleted のマッピングがあることを確認します。 このマッピングが存在しない場合、「プロビジョニングのしくみ」で説明されているように、ユーザーがスコープ外になったときに Microsoft Entra ID はアプリケーションに通知を行いません。

2. アプリケーションがフェデレーション SSO をサポートしている場合は、[条件付きアクセス] タブに移動します。このアプリケーションで有効になっているポリシーを調べます。 ポリシーが有効になっていて、アクセスがブロックされ、ポリシーにユーザーが割り当てられていて、しかしそれ以外に条件がない場合、それらのユーザーは既にアプリケーションへのフェデレーション SSO を取得できないようにブロックされている可能性があります。

3. [ユーザーとグループ] タブに移動します。この一覧には、Microsoft Entra ID でアプリケーションに割り当てられているすべてのユーザーが含まれます。 一覧が空の場合、レビュー担当者がレビューを行うためのアクセスがないため、アプリケーションのレビューは即座に完了します。

4. アプリケーションがパターン C で統合されている場合は、レビューを開始する前に、この一覧内のユーザーが、アプリケーションの内部データ ストアのユーザーと同じであることを確認する必要があります。 Microsoft Entra ID は、自動的にはユーザーとそのアクセス権をアプリケーションからインポートしませんが、PowerShell を介してユーザーをアプリケーション ロールに割り当てることができます。 さまざまなアプリケーション データ ストアのユーザーを Microsoft Entra ID に取り込み、アプリケーション ロールに割り当てる方法については、「アプリケーションの既存のユーザーを管理する」を参照してください。

5. すべてのユーザーが、同じアプリケーション ロール (User など) に割り当てられているかどうかを調べます。 ユーザーが複数のロールに割り当てられている場合、アプリケーションのアクセス レビューを作成すると、アプリケーションのすべてのロールに対するすべての割り当てが一緒にレビューされます。

6. ロールに割り当てられているディレクトリ オブジェクトの一覧を調べて、アプリケーション ロールに割り当てられたグループがないことを確認します。 ロールに割り当てられたグループがある場合は、このアプリケーションをレビューできます。ただし、ロールに割り当てられているグループのメンバーであるユーザーは、アクセスを拒否されても、グループから自動的に削除されることはありません。 アプリケーション自体がグループに依存していない場合は、アクセス レビュー中にアクセスが拒否されたユーザーのアプリケーション ロールの割り当てを自動的に削除できるように、まず、グループのメンバーではなく、直接のユーザー割り当てを持つようにアプリケーションを変換することをお勧めします。 アプリケーションがグループに依存し、アプリケーションのグループがすべて同じアプリケーション ロールに割り当てられている場合は、アプリケーションの割り当てを確認するのではなく、グループ メンバーシップを確認します。

グループがレビューできる状態であることを確認する

アプリケーションがグループに依存していない場合は、次のセクションまでスキップしてください。 それ以外の場合は、パターン B で説明されているように、アプリケーションの統合で 1 つ以上のグループもレビューする必要がある場合は、各グループでレビューの準備ができていることを確認します。

1. Microsoft Entra 管理センターに少なくとも ID ガバナンス管理者としてサインインします。
2. >[グループ] に移動します。
3. 一覧で各グループを検索して選択します。
4. [概要] タブで、[メンバーシップの種類] が [割り当て済み] で、[ソース] が [クラウド] であることを確認します。 アプリケーションで動的グループ、またはオンプレミスから同期されたグループが使用されている場合、それらのグループ メンバーシップを Microsoft Entra ID で変更することはできません。 Microsoft Entra ID で作成されてメンバーシップが割り当てられたグループにアプリケーションを変換してから、その新しいグループにメンバー ユーザーをコピーすることをお勧めします。
5. [ロールと管理者] タブに移動します。このタブには、管理ロールが表示されます。このロールは、アプリケーションでのアクセス権ではなく、Microsoft Entra ID でのグループの表示を制御する権限を付与します。 グループ メンバーシップの変更が許可されていて、ユーザーが含まれる各管理ロールについて、承認されたユーザーのみがそのロールに含まれるようにします。
6. [メンバー] タブに移動します。グループのメンバーがユーザーであり、ユーザーではないメンバーまたは入れ子になったグループが含まれないことを確認します。 レビューの開始時にグループにメンバーが存在しない場合は、そのグループのレビューは即座に完了します。
7. [所有者] タブに移動します。承認されていないユーザーが所有者として表示されていないことを確認します。 グループの所有者にグループのアクセス レビューの実行を求める場合は、グループに 1 人以上の所有者がいることを確認します。

適切なレビュー担当者を選択する

各アクセス レビューを作成するとき、管理者は 1 人以上のレビュー担当者を選ぶことができます。 レビュー担当者は、レビューを実行し、リソースに継続的にアクセスするユーザーを選択または削除することができます。

通常は、リソースの所有者がレビューの実行を担当します。 パターン B で統合されたアプリケーションのアクセス レビューの一環として、グループのレビューを作成する場合は、グループ所有者をレビュー担当者として選択できます。 Microsoft Entra ID のアプリケーションには所有者がいるとは限らないため、アプリケーションの所有者をレビュー担当者として選択することはできません。 代わりに、レビューを作成するときに、アプリケーション所有者の名前をレビュー担当者として指定できます。

グループまたはアプリケーションのレビューを作成するときに、複数ステージのレビューの作成を選ぶこともできます。 たとえば、割り当てられた各ユーザーのマネージャーがレビューの最初のステージを実行し、リソース所有者が 2 番目のステージを実行するようにできます。 こうすることで、リソース所有者は、マネージャーによって既に承認されているユーザーに集中できます。

レビューを作成する前に、テナントに十分な Microsoft Entra ID P2 または Microsoft Entra ID ガバナンス SKU シートがあることを確認します。 また、すべてのレビュー担当者がメール アドレスを持つアクティブなユーザーであることを確認します。 アクセス レビューが始まったら、各自が Microsoft Entra ID からのメールをレビューします。 レビュー担当者がメールボックスを持っていない場合、レビュー開始時のメールまたはメール リマインダーを受け取りません。 また、Microsoft Entra ID へのサインインができないようにブロックされている場合は、レビューを実行できません。

レビューを作成する

統合パターンに基づいて、リソース、アプリケーション、必要に応じて 1 つ以上のグループを特定し、さらにレビュー担当者を特定すると、レビューを開始するように Microsoft Entra ID を構成できます。

1. この手順では、Identity Governance Administrator ロールに含まれている必要があります。

2. パターン A と C では、1 つのアクセス レビューを作成し、アプリケーションを選択します。 グループまたはアプリケーションのアクセス レビューの作成に関するガイドの指示に従って、アプリケーションのロール割り当てのレビューを作成します。

3. アプリケーションがパターン B で統合されている場合は、同じガイドを使って、グループごとに追加のアクセス レビューを作成します。

   注意

   アクセス レビューを作成し、レビュー意思決定ヘルパーを有効にした場合、意思決定ヘルパーはレビュー対象のリソースによって異なります。 リソースがアプリケーションの場合、推奨事項は、ユーザーがアプリケーションに最後にサインインしたときに応じた 30 日の期間に基づきます。 リソースがグループの場合、推奨事項は、それらのグループを使用するアプリケーションだけでなく、ユーザーがテナント内の任意のアプリケーションに最後にサインインした間隔に基づきます。

4. アクセス レビューが開始すると、レビュー担当者は入力を求められます。 既定では、それぞれが、アクセス パネルへのリンクが含まれたメールを Microsoft Entra ID から受け取り、そこでグループのメンバーシップまたはアプリケーションへのアクセスをレビューします。

レビューの完了時に更新される割り当てを表示する

レビューが開始したら、レビューが完了するまで、その進行状況を監視し、必要に応じて承認者を更新できます。 その後、レビュー担当者によってアクセスを拒否されたユーザーのアクセス権が、アプリケーションから削除されていることを確認できます。

1. アクセス レビューが完了するまで、アクセス レビューを監視し、ユーザーの継続的なアクセスの必要性を、レビュー担当者が承認または拒否していることを確認します。

2. レビューの作成時に自動適用が選択されていなかった場合は、完了時にレビュー結果を適用する必要があります。

3. レビューの状態が [結果を適用済み] に変わるまで待ちます。 拒否されたユーザーが存在する場合は、それらのユーザーが数分以内にグループ メンバーシップまたはアプリケーション割り当てから削除されることを確認できます。

4. 以前にアプリケーションへのユーザーのプロビジョニングを構成していた場合、結果が適用されると、Microsoft Entra ID は、拒否されたユーザーのアプリケーションからのプロビジョニング解除を開始します。 ユーザーのプロビジョニング解除のプロセスを監視できます。 プロビジョニングでアプリケーションに関するエラーが示される場合は、プロビジョニングのログをダウンロードして、アプリケーションに問題があったかどうかを調査できます。

5. レビューされるグループのグループの書き戻しを構成している場合は、Microsoft Entra クラウド同期でグループの書き戻しが完了し、それらの変更がすべてのドメイン コントローラーに伝達されるまで待機します。

6. アプリケーションにプロビジョニングが構成されていなかった場合は、拒否されたユーザーの一覧をアプリケーションに個別にコピーする必要があります。 たとえば、Windows Server AD マネージド グループのアクセス レビューでは、この PowerShell サンプル スクリプトを使います。 このスクリプトでは、必要な Microsoft Graph の呼び出しの概要が示されており、変更を行うための Windows Server AD PowerShell コマンドレットがエクスポートされます。

7. 必要に応じて、完了したレビューのレビュー履歴レポートをダウンロードすることもできます。

8. 継続的なアクセスを拒否されたユーザーが、フェデレーション アプリケーションを引き続き使用できる期間は、アプリケーション自体のセッションの有効期間と、アクセス トークンの有効期間によって決まります。 アプリケーションが Kerberos を使用した場合は、ドメインへのサインイン時に Kerberos がユーザーのグループ メンバーシップをキャッシュするため、ユーザーはその Kerberos チケットの有効期限が切れるまで引き続きアクセスできます。 アクセス トークンの有効期間の制御について詳しくは、構成可能なトークンの有効期間に関する記事をご覧ください。

次のステップ

• Microsoft Entra アクセス レビューの展開を計画する
• グループまたはアプリケーションのアクセス レビューを作成する
• アプリケーションへのアクセスを管理する