準備存取權檢閱使用者對應用程式的存取權

  • 發行項

Microsoft Entra ID 控管 可讓您將組織的安全性和員工生產力需求與正確的程式與可見度平衡。 其讓您能夠確保適當人員具有適當資源的適當存取權。

具有合規性需求或風險管理計劃的組織具有敏感性或業務關鍵性應用程式。 應用程式敏感度可以根據其用途或其包含的數據，例如組織客戶的財務資訊或個人資訊。 對於這些應用程式，只有組織中所有使用者的子集有權存取，而且只能根據記載的商務需求來允許存取。 Microsoft Entra ID 可以與許多熱門 SaaS 應用程式、內部部署應用程式和組織開發的應用程式整合，並使用 標準通訊協定 和 API 介面。 透過這些介面，Microsoft Entra ID 可以是授權來源，可控制誰可以存取這些應用程式。 當您將應用程式與 Microsoft Entra ID 整合時，您可以使用存取權檢閱來重新認證可存取這些應用程式的使用者，並移除不再需要存取權的使用者存取權。 您也可以使用其他功能，包括使用規定、條件式存取和權利管理，以控管應用程式的存取權，如如何控管環境中應用程式的存取權中所述。

檢閱存取權的必要條件

若要使用 Microsoft Entra 識別符來檢閱應用程式的存取權，您必須在租用戶中擁有下列其中一個授權：

  • Microsoft Entra ID P2 或 Microsoft Entra ID 控管
  • Enterprise Mobility + Security (EMS) E5 授權

雖然使用存取權檢閱功能不需要使用者將那些授權指派給他們使用此功能，但您必須擁有足夠的授權。 如需詳細資訊，請參閱 存取權檢閱的範例授權案例。

此外，雖然不需要檢閱應用程式的存取權，但我們也建議您定期檢閱特殊許可權目錄角色的成員資格，這些角色能夠控制其他使用者對所有應用程式的存取權。 管理員 、、 Cloud Application AdministratorApplication AdministratorUser Administrator和 Privileged Role Administrator 中的 Identity Governance AdministratorGlobal Administrator管理員 istrators 可以變更使用者及其應用程式角色指派，因此請確定已排程這些目錄角色的存取權檢閱。

判斷應用程式如何與 Microsoft Entra 識別元整合

為了讓應用程式使用存取權檢閱，應用程式必須先與 Microsoft Entra ID 整合，並在目錄中表示。 與 Microsoft Entra ID 整合的應用程式表示必須符合下列兩個需求之一：

  • 應用程式依賴 Microsoft Entra ID 進行同盟 SSO，而 Microsoft Entra ID 會控制驗證令牌發行。 如果 Microsoft Entra ID 是應用程式的唯一識別提供者，則只有指派給 Microsoft Entra ID 中其中一個應用程式角色的使用者才能登入應用程式。 檢閱拒絕的使用者會失去其應用程式角色指派，且無法再取得新的令牌來登入應用程式。
  • 應用程式依賴由 Microsoft Entra ID 提供給應用程式的使用者或群組清單。 這項履行可以透過佈建通訊協定來完成，例如「跨網域身分識別管理系統」（SCIM），應用程式透過 Microsoft Graph 查詢 Microsoft Entra ID、Microsoft Entra 將使用者布建到寫入 AD DS 的應用程式資料庫或群組。 檢閱拒絕的使用者會失去其應用程式角色指派或群組成員資格，而且當這些變更可供應用程式使用時，拒絕的使用者將無法再存取。

如果應用程式不符合這兩個準則，因為應用程式不依賴 Microsoft Entra ID，則仍然可以使用存取權檢閱，但會有一些限制。 未在您的 Microsoft Entra 識別碼中或未指派給 Microsoft Entra 識別碼中的應用程式角色的使用者，將不會包含在檢閱中。 此外，如果應用程式不支援任何布建通訊協定，則移除拒絕的變更將無法自動傳送至應用程式。 組織必須改為有一個程式，才能將已完成檢閱的結果傳送給應用程式。

為了允許使用 Microsoft Entra ID 處理各種不同的應用程式和 IT 需求，有多個模式可讓應用程式與 Microsoft Entra ID 整合。 每個模式都會使用不同的 Microsoft Entra 成品。 下列流程圖說明如何從三種整合模式 A、B 和 C 中選取適合用於身分識別控管的應用程式。 瞭解特定應用程式所使用的模式可協助您在 Microsoft Entra 標識碼中設定適當的資源，以準備好進行存取權檢閱。

Flowchart for application integration patterns

模式 應用程式整合模式 準備存取權檢閱的步驟
A 應用程式支援同盟 SSO、Microsoft Entra ID 是唯一的識別提供者，而且應用程式不依賴群組或角色宣告。 在此模式中，您會設定應用程式需要個別的應用程式角色指派，並將使用者指派給應用程式。 然後，若要執行檢閱，您要為應用程式建立指派給此應用程式角色的使用者的單一存取權檢閱。 當檢閱完成時，如果使用者遭到拒絕，則會從應用程式角色中移除它們。 然後，Microsoft Entra ID 將不再發出具有同盟令牌的使用者，而且使用者將無法登入該應用程式。
B 如果應用程式除了應用程式角色指派之外，還使用群組宣告。 應用程式可以使用 Active Directory 或 Microsoft Entra 群組成員資格，與應用程式角色不同，以表達更精細的存取權。 在這裡，您可以根據您的商務需求來選擇擁有已檢閱應用程式角色指派的使用者，或檢閱具有群組成員資格的使用者。 如果群組未提供完整的存取涵蓋範圍，特別是如果使用者無法存取應用程式，即使他們不是這些群組的成員，建議您檢閱應用程式角色指派，如先前模式 A 所示。
C 如果應用程式不只依賴同盟 SSO 的 Microsoft Entra ID，但透過 SCIM 支援透過 SCIM 布建、透過使用者 SQL 資料表的更新、具有非 AD LDAP 目錄，或支援 SOAP 或 REST 布建通訊協定。 在此模式中，您會將 Microsoft Entra ID 設定為將應用程式角色指派佈建至應用程式的資料庫或目錄的使用者、使用目前可存取的使用者清單更新 Microsoft Entra ID 中的應用程式角色指派，然後建立應用程式角色指派的單一存取權檢閱。 如需詳細資訊，請參閱 控管應用程式的現有使用者 ，以更新 Microsoft Entra ID 中的應用程式角色指派。

其他選項

上一節所列的整合模式適用於第三方 SaaS 應用程式，或由或為您的組織開發的應用程式。

  • 某些 Microsoft Online Services，例如 Exchange Online，會使用授權。 雖然無法直接檢閱使用者的授權，但如果您使用群組型授權指派，且具有指派使用者的群組，您可以改為檢閱這些群組的成員資格。
  • 某些應用程式會使用委派的使用者同意來控制對 Microsoft Graph 或其他資源的存取。 由於每個使用者的同意不受核准程式控制，因此無法檢閱同意。 相反地，您可以檢閱能夠透過條件式存取原則連線到應用程式的人員，這些原則可能以應用程式角色指派或群組成員資格為基礎。
  • 如果應用程式不支援同盟或布建通訊協定，則您需要一個程式，才能在檢閱完成時手動套用結果。 對於僅支持密碼 SSO 整合的應用程式，如果在檢閱完成時移除應用程式指派，則應用程式不會顯示在 使用者的 myapps 頁面上，但不會防止已經知道密碼的使用者能夠繼續登入應用程式。 如需內部部署應用程式，請參閱 控管不支援布建的應用程式使用者。 針對 SaaS 應用程式，請 要求 SaaS 廠商透過更新其應用程式以支援標準通訊協定，以上線至應用連結庫 以進行同盟或布建。

檢查應用程式是否已準備好進行檢閱

既然您已識別應用程式的整合模式，請檢查 Microsoft Entra 識別碼中所代表的應用程式已準備好進行檢閱。

  1. 以至少身分識別治理 管理員 istrator 身分登入 Microsoft Entra 管理員 中心。

  2. 流覽至 [>身分>識別應用程式>企業應用程式]。

  3. 您可以在這裏檢查您的應用程式是否位於 租使用者中的企業應用程式 清單中。

  4. 如果尚未列出應用程式，請檢查應用程式是否可供 應用程式資源庫 使用，以取得可針對同盟 SSO 或布建整合的應用程式。 如果是在資源庫中，請使用 教學課程 來設定應用程式以進行同盟，如果支援布建，也 請設定應用程式 以進行布建。

  5. 如果應用程式尚未列出，但使用AD安全組且是Web應用程式，而且應用程式的組態可以變更為在AD中尋找不同的安全組，然後透過應用程式 Proxy 新增應用程式以進行遠端訪問，將現有AD安全組的成員資格移至新的 Microsoft Entra 群組，並設定群組回寫至 AD。 然後，更新應用程式以檢查群組回寫所建立的新 AD 群組，如控管 內部部署的 Active Directory 型應用程式 （Kerberos） 中所述。

  6. 如果應用程式尚未列出，但使用AD安全組且是Web應用程式，且應用程式的設定無法變更為在AD中尋找不同的安全組，然後透過應用程式 Proxy 新增應用程式以進行遠端訪問，將現有AD安全組的成員資格移至新的 Microsoft Entra 群組，並設定群組回寫至 AD。 然後，更新應用程式正在檢查的現有AD安全組，以將新群組納入為成員，如控管 內部部署的 Active Directory型應用程式 （Kerberos） 中所述。

  7. 如果應用程式尚未列出，請使用AD安全組，而且不是Web應用程式，而且應用程式的設定可以變更為在AD中尋找不同的安全組，然後將現有AD安全組的成員資格移至新的 Microsoft Entra 群組，並 設定群組回寫至 AD。 接下來，更新應用程式以檢查群組回寫所建立的新 AD 群組，如控管 內部部署的 Active Directory 型應用程式 （Kerberos） 中所述。 然後在下一節繼續進行。

  8. 如果應用程式尚未列出，請使用AD安全組，而且不是Web應用程式，而且無法變更應用程式的設定來尋找AD中的不同安全組，然後將現有AD安全組的成員資格移至新的 Microsoft Entra 群組，並 設定群組回寫至 AD。 接下來，更新應用程式正在檢查的現有AD安全組，以將新群組納入為成員，如控管 內部部署的 Active Directory型應用程式 （Kerberos） 中所述。 然後在下一節繼續進行。

  9. 一旦應用程式位於租使用者中的企業應用程式清單中，請從清單中選取應用程式。

  10. 變更為 [ 屬性] 索引標籤。確認 [需要使用者指派嗎？] 選項設定為 [是]。 如果設定為 [否]，目錄中的所有使用者，包括外部身分識別，都可以存取應用程式，而且您無法檢閱應用程式的存取權。

    Screenshot that shows planning app assignments.

  11. 變更為 [ 角色和系統管理員] 索引標籤 。此索引標籤會顯示系統管理角色，這些角色會授與許可權，以控制 Microsoft Entra 識別符中應用程式的表示法，而不是應用程式中的訪問許可權。 對於每個具有許可權可允許變更應用程式整合或指派的系統管理角色，並具有該系統管理角色的指派，請確定只有授權的使用者在該角色中。

  12. 變更為 [ 布建] 索引 標籤。如果未設定自動布建、停止或處於隔離狀態，則如果檢閱期間拒絕該存取權，Microsoft Entra ID 將無法在使用者存取權遭到移除時通知應用程式。 如果應用程式是同盟的，且完全依賴 Microsoft Entra ID 做為其識別提供者，或應用程式使用 AD DS 群組，則某些整合模式可能不需要布建。 不過，如果您的應用程式整合是模式 C，而且應用程式不支援與 Microsoft Entra 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 使用者]。 檢查屬性對應 isSoftDeleted 清單中是否有對應至應用程式資料存放區中的屬性，您希望當使用者失去存取權時，Microsoft Entra ID 設定為 false。 如果此對應不存在，則當使用者離開範圍時，Microsoft Entra ID 將不會通知應用程式，如布建的運作方式中所述。

  2. 如果應用程式支援同盟 SSO，請變更為 [ 條件式存取 ] 索引標籤。檢查此應用程式已啟用的原則。 如果已啟用原則、封鎖存取、將使用者指派給原則，但沒有其他條件，則這些使用者可能已經封鎖無法取得應用程式的同盟 SSO。

  3. 變更為 [ 使用者和群組] 索引標籤 。此清單包含所有在 Microsoft Entra ID 中指派給應用程式的使用者。 如果清單是空的，則應用程式的檢閱會立即完成，因為檢閱者沒有任何存取權可供檢閱。

  4. 如果您的應用程式與模式 C 整合，則您需要先確認此清單中的使用者與應用程式內部資料存放區中的使用者相同，再開始檢閱。 Microsoft Entra ID 不會自動從應用程式匯入使用者或其訪問許可權，但您可以 透過 PowerShell 將使用者指派給應用程式角色。 如需如何將來自不同應用程式數據存放區的使用者帶入 Microsoft Entra ID，並將其指派給應用程式角色，請參閱 控管應用程式的現有使用者 。

  5. 檢查是否已將所有使用者指派給相同的應用程式角色，例如 User。 如果使用者被指派給多個角色，則如果您建立應用程式的存取權檢閱，則會一起檢閱所有應用程式角色的所有指派。

  6. 檢查指派給角色的目錄物件清單，以確認沒有指派給應用程式角色的群組。 如果有指派給角色的群組，可以檢閱此應用程式;不過，指派給角色之群組成員的使用者，且其存取遭到拒絕，將不會從群組中自動移除。 如果應用程式本身不依賴群組，則建議您先將應用程式轉換成具有直接使用者指派，而不是群組成員，讓在存取權檢閱期間拒絕其存取權的使用者可以自動移除其應用程式角色指派。 如果應用程式確實依賴群組，且所有應用程式群組都會指派給相同的應用程式角色，則您會檢閱群組成員資格，而不是檢閱應用程式指派。

檢查群組是否已準備好進行檢閱

如果您的應用程式不依賴群組，請跳至下一節。 否則，如果應用程式整合也需要檢閱一或多個群組，如模式 B 中所述，請檢查每個群組是否已準備好進行檢閱。

  1. 以至少身分識別治理 管理員 istrator 身分登入 Microsoft Entra 管理員 中心。
  2. 流覽至 >群組。
  3. 從清單中搜尋並選取每個群組。
  4. 在 [概觀] 索引標籤上，確認 [已指派成員資格類型]，且 [來源] 為 [雲端]。 如果應用程式使用動態群組或從內部部署同步處理的群組，則無法在 Microsoft Entra ID 中變更這些群組成員資格。 建議將應用程式轉換成 Microsoft Entra ID 中建立且具有指派成員資格的群組，然後將成員用戶複製到該新群組。
  5. 變更為 [ 角色和系統管理員] 索引標籤 。此索引標籤會顯示系統管理角色，以控制 Microsoft Entra ID 中群組的表示法，而不是應用程式中的訪問許可權。 對於每個允許變更群組成員資格且具有該系統管理角色的用戶的系統管理角色，請確定只有授權的用戶位於該角色中。
  6. 變更為 [ 成員 ] 索引標籤。確認群組的成員是使用者，而且沒有非用戶成員或巢狀群組。 如果檢閱開始時沒有群組的成員，該群組的檢閱會立即完成。
  7. 變更為 [ 擁有者] 索引標籤。請確定沒有未經授權的用戶會顯示為擁有者。 如果您要要求群組擁有者執行群組的存取權檢閱，請確認該群組有一或多個擁有者。

選取適當的檢閱者

當您建立每個存取權檢閱時，系統管理員可以選擇一或多個檢閱者。 檢閱者可以選擇用戶繼續存取資源或移除資源，以執行檢閱。

資源擁有者通常會負責執行檢閱。 如果您要建立群組的檢閱，作為檢閱模式 B 中整合之應用程式的存取權的一部分，您可以選取群組擁有者作為檢閱者。 由於 Microsoft Entra 識別碼中的應用程式不一定有擁有者，因此無法選取應用程式擁有者作為檢閱者的選項。 相反地，建立檢閱時，您可以提供應用程式擁有者的名稱做為檢閱者。

您也可以在建立群組或應用程式的檢閱時選擇多 階段檢閱。 例如，您可以選取讓每個獲指派使用者的管理員執行檢閱的第一個階段，以及資源擁有者第二個階段。 如此一來，資源擁有者就可以專注於已由其管理員核准的使用者。

建立檢閱之前，請先確認您的租使用者中有足夠的 Microsoft Entra ID P2 或 Microsoft Entra ID 控管 SKU 基座。 此外，請確認所有檢閱者都是具有電子郵件位址的作用中使用者。 存取權檢閱開始時，他們都會檢閱來自 Microsoft Entra ID 的電子郵件。 如果檢閱者沒有信箱，當檢閱開始時或電子郵件提醒時，他們將不會收到電子郵件。 而且，如果封鎖他們無法登入 Microsoft Entra ID，他們將無法執行檢閱。

建立評論

一旦識別出資源之後，應用程式會根據整合模式，以及檢閱者應是誰，選擇性地設定一或多個群組，然後您可以設定 Microsoft Entra ID 來開始檢閱。

  1. 在此步驟中，您必須在 或 Identity Governance administrator 角色中Global administrator。

  2. 在 A 和 C 模式中，您會建立一個存取權檢閱，然後選取應用程式。 依照指南 中的指示來建立群組或應用程式的存取權檢閱，以建立應用程式的角色指派檢閱。

  3. 如果您的應用程式與模式 B 整合，請使用相同的 指南 ，為每個群組建立額外的存取權檢閱。

    注意

    如果您建立存取權檢閱並啟用檢閱決策協助程式，則決策協助程式會根據正在檢閱的資源而有所不同。 如果資源是應用程式，建議會根據使用者上次登入應用程式的時間，根據30天的間隔期間而定。 如果資源是群組，則建議是根據使用者上次登入租使用者中任何應用程式的間隔，而不只是使用這些群組的應用程式。

  4. 存取權檢閱開始時，請要求檢閱者提供輸入。 根據預設，他們都會收到來自 Microsoft Entra ID 的電子郵件，其中包含存取面板的連結，其中會 檢閱群組中的成員資格或應用程式的存取權。

檢視檢視檢視完成時更新的指派

檢閱開始之後，您可以監視其進度，並視需要更新核准者，直到檢閱完成為止。 然後，您可以確認檢閱者拒絕其存取權的使用者已從應用程式移除其存取權。

  1. 監視存取權檢閱，確保檢閱者進行選取以核准或拒絕使用者持續存取的需求，直到 存取權檢閱完成為止。

  2. 如果在建立檢閱時未選取自動套用，則您需要在檢閱完成時套用檢閱結果。

  3. 等候檢閱的狀態變更為 [已套用結果]。 您應該會在幾分鐘內看到遭到拒絕的使用者從群組成員資格或應用程式指派中移除。

  4. 如果您先前已設定將使用者布建至應用程式，則套用結果時，Microsoft Entra ID 會開始取消布建來自應用程式的拒絕使用者。 您可以 監視取消佈建用戶的程式。 如果布建指出應用程式發生錯誤，您可以 下載布建記錄 檔來調查應用程式是否有問題。

  5. 如果您已 設定已檢閱群組的群組回寫，請等到群組回 寫在 Microsoft Entra Cloud Sync 中完成，而變更會傳播到所有域控制器。

  6. 如果未為您的應用程式設定布建，則您必須將拒絕的使用者清單個別複製到應用程式。 例如，在 Windows Server AD 受控群組的存取權檢閱中，使用此 PowerShell 範例腳本。 腳本概述必要的 Microsoft Graph 呼叫，並匯出 Windows Server AD PowerShell Cmdlet 以執行變更。

  7. 如果您想要的話，您也可以下載 已完成評論的檢閱歷程記錄報告 。

  8. 拒絕持續存取的用戶能夠繼續使用同盟應用程式的時間，取決於應用程式自己的會話存留期，以及存取令牌存留期。 如果應用程式使用 Kerberos，因為 Kerberos 會在使用者登入網域時快取使用者的群組成員資格，因此使用者可以繼續存取，直到其 Kerberos 票證到期為止。 若要深入瞭解控制存取令牌的存留期，請參閱 可設定的令牌存留期。

下一步