準備使用者對應用程式存取權的存取權檢閱
Microsoft Entra ID 控管可讓您透過適當的程序與可見性，平衡組織的安全性需求與員工生產力。 其讓您能夠確保適當人員具有適當資源的適當存取權。
具有合規性需求或風險管理計劃的組織會有敏感性或業務關鍵性應用程式。 應用程式敏感度可能會以其用途或其包含的資料為依據，例如組織客戶的財務資訊或個人資訊。 對於這些應用程式，一般只有組織中所有使用者的一小部分會獲得存取權，而且只應根據記載的商務需求來允許存取。 Microsoft Entra ID 可以與許多熱門 SaaS 應用程式、內部部署應用程式和組織開發的應用程式整合，並使用標準通訊協定和 API 介面。 透過這些介面，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 整合的應用程式表示必須符合兩個需求之一：
- 應用程式依賴 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 ID 中或未獲指派 Microsoft Entra ID 中應用程式角色的使用者，將不會包含在檢閱中。 此外，如果沒有應用程式支援的佈建通訊協定，對移除遭拒絕的變更，將無法自動傳送至應用程式。 組織必須改為有一個程序，以將已完成的檢閱結果傳送給應用程式。
為了允許使用 Microsoft Entra ID 解決各種不同的應用程式和 IT 需求，應用程式如何可以與 Microsoft Entra ID 整合有多個模式。 每個模式都會使用不同的 Microsoft Entra 成品。 下列流程圖說明如何從三個整合模式 A、B 和 C 中選取適合用於身分識別控管的應用程式。 了解針對特定應用程式所使用的模式，可協助您在 Microsoft Entra ID 中設定適當的資源，以準備好進行存取權檢閱。
| 模式 | 應用程式整合模式 | 準備存取權檢閱的步驟 |
|---|---|---|
| A | 應用程式支援同盟 SSO，Microsoft Entra ID 是唯一的識別提供者，而且應用程式不會依賴群組或角色宣告。 | 在此模式中，您會設定應用程式需要個別的應用程式角色指派，以及使用者將被指派給應用程式。 然後，若要執行檢閱，您會針對指派給此應用程式角色的使用者，建立應用程式的單一存取權檢閱。 檢閱完成時，如果使用者遭到拒絕，則會將其從應用程式角色中移除。 Microsoft Entra ID 將不再核發該使用者同盟權杖，而且使用者將無法登入該應用程式。 |
| B | 如果應用程式除了應用程式角色指派之外，還會使用群組宣告。 | 應用程式可以使用 Active Directory 或 Microsoft Entra 群組成員資格，其與應用程式角色不同，以表達更精細的存取權。 在這裡，您可以根據您的商務需求選擇要檢閱具有應用程式角色指派的使用者，或是要檢閱具有群組成員資格的使用者。 如果群組未提供完整的存取涵蓋範圍，特別是即便使用者不是這些群組的成員，使用者也可以存取應用程式，則建議您檢閱應用程式角色指派，如上述的模式 A。 |
| C | 如果應用程式不只依賴 Microsoft Entra ID 進行同盟 SSO，但確實支援透過 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 ID 中所呈現的應用程式是否已備妥，可供檢閱。
以至少身分識別控管系統管理員身分登入 Microsoft Entra 系統管理中心。
瀏覽至 >[身分識別]>[應用程式]>[企業應用程式]。
您可以在這裡檢查您的應用程式是否位於租用戶的企業應用程式清單中。
如果尚未列出應用程式，則檢查該應用程式是否有可整合以進行同盟 SSO 或佈建的應用程式的應用程式庫中。 如果有在資源庫中，則使用教學課程來設定應用程式以進行同盟，而如果支援佈建，也請設定應用程式以進行佈建。
如果應用程式尚未列出，但其使用 AD 安全性群組且是 Web 應用程式，而且應用程式的設定可以變更為尋找 AD 中的不同安全性群組，則請透過應用程式 Proxy 新增應用程式以進行遠端存取，將現有 AD 安全性群組的成員資格移至新的 Microsoft Entra 群組，並設定將群組回寫至 AD。 然後，更新應用程式以檢查群組回寫所建立的新 AD 群組，如控管內部部署 Active Directory 型應用程式 (Kerberos) 中所述。
如果應用程式尚未列出，但其使用 AD 安全性群組且是 Web 應用程式，而且應用程式的設定無法變更為尋找 AD 中的不同安全性群組，則請透過應用程式 Proxy 新增應用程式以進行遠端存取，將現有 AD 安全性群組的成員資格移至新的 Microsoft Entra 群組，並設定將群組回寫至 AD。 然後，更新應用程式正在檢查的現有 AD 安全性群組，以將新群組納入為成員，如控管內部部署Active Directory 型應用程式 (Kerberos) 中所述。
如果應用程式尚未列出、使用 AD 安全性群組且不是 Web 應用程式，而且應用程式的設定可以變更為尋找 AD 中的不同安全性群組，則請將現有 AD 安全性群組的成員資格移至新的 Microsoft Entra 群組，並設定將群組回寫至 AD。 接下來，更新應用程式以檢查群組回寫所建立的新 AD 群組，如控管內部部署 Active Directory 型應用程式 (Kerberos) 中所述。 然後繼續進行下一節。
如果應用程式尚未列出、使用 AD 安全性群組且不是 Web 應用程式，而且應用程式的設定無法變更為尋找 AD 中的不同安全性群組，則請將現有 AD 安全性群組的成員資格移至新的 Microsoft Entra 群組，並設定將群組回寫至 AD。 接下來，更新應用程式正在檢查的現有 AD 安全性群組，以將新群組納入為成員，如控管內部部署Active Directory 型應用程式 (Kerberos) 中所述。 然後繼續進行下一節。
應用程式位於您租用戶中的企業應用程式清單之後，請從清單中選取應用程式。
切換至 [屬性] 索引標籤。驗證 [需要使用者指派?] 選項設定為 [是]。 如果將其設定為 [否]，您目錄中的所有使用者 (包括外部身分識別) 都可以存取應用程式，而且您無法檢閱應用程式的存取權。
切換至 [角色和管理員] 索引標籤。此索引標籤會顯示系統管理角色，其提供權限來控制應用程式在 Microsoft Entra ID 中的呈現 (而非應用程式中的存取權限)。 對於具有權限可允許變更應用程式整合或指派，並且具有該系統管理角色指派的每個系統管理角色，請確保該角色中只有獲授權的使用者。
切換至 [佈建] 索引標籤。如果自動佈建未設定、停止或在處於隔離狀態，則 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。
如果已設定佈建，則選取 [編輯屬性對應]，展開 [對應] 區段，然後選取 [佈建 Microsoft Entra 使用者]。 在屬性對應清單中，檢查是否有對應可將
isSoftDeleted對應至應用程式資料來源中的屬性，讓您可在使用者失去存取權時，將 Microsoft Entra ID 設定為 False。 如果此對應不存在，則 Microsoft Entra ID 不會在使用者離開範圍時通知應用程式，如佈建的運作方式中所述。如果應用程式支援同盟 SSO，請切換至 [條件式存取] 索引標籤。檢查此應用程式的已啟用原則。 如果有原則已啟用、封鎖存取、將使用者指派給原則，但沒有其他條件，則這些使用者可能已遭到封鎖，而無法對應用程式使用同盟 SSO。
切換至 [使用者和群組] 索引標籤。此清單包含指派給 Microsoft Entra ID 中應用程式的所有使用者。 如果清單空白，則應用程式檢閱會立即完成，因為沒有需要檢閱者檢閱的任何存取權。
如果您的應用程式使用模式 C 整合，則在開始檢閱之前，您必須確認此清單中的使用者與應用程式內部資料存放區中的使用者相同。 Microsoft Entra ID 不會自動從應用程式匯入使用者或其存取權限，但您可以透過 PowerShell 將使用者指派給應用程式角色。 請參閱控管應用程式的現有使用者，以了解如何將不同應用程式資料存放區中的使用者帶入 Microsoft Entra ID，並將其指派給應用程式角色。
檢查所有使用者是否獲指派相同的應用程式角色，例如使用者。 如果使用者獲指派給多個角色，則如果您建立應用程式的存取權檢閱，則將一起檢閱所有應用程式角色的所有指派。
檢查指派給角色的目錄物件清單，以確認沒有指派給應用程式角色的群組。 如果有指派給角色的群組，則可以檢閱此應用程式；不過，使用者若屬於指派給該角色的群組成員，且其存取權遭到拒絕，將不會自動從群組中移除。 如果應用程式本身未依賴群組，則建議先將應用程式轉換成具有直接使用者指派，而不是群組的成員，如此一來，在存取權檢閱期間存取權遭到拒絕的使用者，就可以自動移除其應用程式角色指派。 如果應用程式確實依賴群組，而且將所有應用程式的群組都指派給相同的應用程式角色，則您會檢閱群組成員資格，而不是檢閱應用程式指派。
檢查群組是否已準備好進行檢閱
如果您的應用程式不依賴群組，請跳至下一節。 反之，如果應用程式整合也需要檢閱一或多個群組，如模式 B 所述，請檢查每個群組是否已準備好進行檢閱。
- 以至少身分識別控管系統管理員身分登入 Microsoft Entra 系統管理中心。
- 瀏覽至 >[群組]。
- 從清單中搜尋並選取每個群組。
- 在 [概觀] 索引標籤上，驗證 [成員資格類型] 為 [已指派]，且 [來源] 為[雲端]。 如果應用程式使用動態群組，或從內部部署同步群組，則無法在 Microsoft Entra ID 中變更這些群組成員資格。 建議將應用程式轉換成在 Microsoft Entra ID 中建立、具有指派成員資格的群組，然後將成員使用者複製到該新群組。
- 切換至 [角色和管理員] 索引標籤。此索引標籤會顯示系統管理角色，其提供權限來控制群組在 Microsoft Entra ID 中的呈現 (而非應用程式中的存取權限)。 對於允許變更群組成員資格且在該系統管理角色中擁有使用者的每個系統管理角色，請確保在該角色中只有獲授權的使用者。
- 切換至 [成員] 索引標籤。驗證群組的成員是使用者，而且沒有非使用者成員或巢狀群組。 如果檢閱開始時沒有群組的成員，該群組的檢閱將會立即完成。
- 切換至 [擁有者] 索引標籤。確定沒有任何未經授權的使用者顯示為擁有者。 如果您要要求群組擁有者執行群組的存取權檢閱，請確認該群組有一或多個擁有者。
選取適當的檢閱者
當您建立每個存取權檢閱時，管理員可以選擇一或多個檢閱者。 檢閱者可以藉由選擇使用者繼續存取資源或將其移除，來施行檢閱。
資源擁有者通常會負責執行檢閱。 如果您要建立群組的檢閱，作為以模式 B 整合的應用程式檢閱存取權的一部分，則可以選取群組擁有者作為檢閱者。 由於 Microsoft Entra ID 中的應用程式不一定會有擁有者，選取應用程式擁有者作為檢閱者的選項並不可行。 相反地，在建立檢閱時，您可以提供要成為檢閱者的應用程式擁有者的名稱。
您也可以選擇在建立群組或應用程式的檢閱時，進行多階段檢閱。 例如，您可以選取讓每個獲指派使用者的管理員執行檢閱的第一個階段，以及資源擁有者執行第二個階段。 如此一來，資源擁有者就可以專注於已由其管理員核准的使用者。
建立檢閱之前，請先確認您有足夠的 Microsoft Entra ID P2 或租用戶中的 Microsoft Entra ID 控管 SKU 基座。 此外，檢查所有檢閱者是否為具有電子郵件地址的作用中使用者。 存取檢閱開始時，他們都會檢閱來自 Microsoft Entra ID 的電子郵件。 如果檢閱者沒有信箱，當檢閱開始時或以電子郵件寄送提醒時，他們將不會收到電子郵件。 而且，如果他們遭封鎖而無法登入 Microsoft Entra ID，他們將無法執行檢閱。
建立檢閱
找出資源之後，根據整合模式，應用程式和選用的一或多個群組，以及檢閱者應該是誰，您便可以設定 Microsoft Entra ID 以開始檢閱。
若要執行此步驟，您應該在
Identity Governance Administrator角色中。在模式 A 和 C 中，您會建立一個存取權檢閱，並選取應用程式。 遵循指南中建立群組或應用程式的存取權檢閱的指示，以建立應用程式角色指派的檢閱。
如果您的應用程式使用模式 B 整合，請使用相同的指南，以便為每個群組建立額外的存取權檢閱。
注意
如果您建立存取權檢閱並啟用檢閱決策協助程式，則決策協助程式會根據檢閱的資源而有所不同。 如果資源為應用程式，建議會採用 30 天的間隔期間，且根據使用者上次登入應用程式的時間為基準。 如果資源是群組，則建議會根據使用者上次登入租用戶中任何應用程式的間隔，而不只是使用這些群組的應用程式。
存取權檢閱開始時，要求檢閱者提供意見。 依預設，使用者會各自收到來自 Microsoft Entra ID 的電子郵件，其中具有存取面板的連結，他們可以在其中檢閱群組中的成員資格或應用程式的存取權。
檢視檢閱完成時檢視更新的指派
檢閱開始之後，您可以監視其進度，並視需要更新核准者，直到檢閱完成。 然後，您可以確認其存取權遭檢閱者拒絕的使用者，其存取權會從應用程式移除。
監視存取權檢閱，確保檢閱者會選取核准或拒絕使用者對持續存取的需求，直到存取權檢閱完成。
如果建立檢閱時未選取自動套用，則必須在檢閱完成時套用檢閱結果。
等候檢閱的狀態變更為 [已套用結果]。 您應該會看到遭到拒絕的使用者 (若有的話)，在幾分鐘內從群組成員資格或應用程式指派中移除。
如果您先前已設定將使用者佈建至應用程式，則在套用結果時，Microsoft Entra ID 會開始從應用程式取消佈建遭拒絕的使用者。 您可以監視取消佈建使用者的程序。 如果佈建指出應用程式發生錯誤，您可以下載佈建記錄檔，以調查應用程式是否有問題。
如果您已設定已檢閱群組的群組回寫，則請等到群組回寫在 Microsoft Entra 雲端同步中完成，而且變更會傳播到所有網域控制站。
如果未針對您的應用程式設定佈建，您需要個別將遭拒絕的使用者清單複製到應用程式。 例如，針對 Windows Server AD 受控群組的存取權檢閱，請使用此 PowerShell 範例指令碼。 此指令碼概述必要的 Microsoft Graph 呼叫，並匯出 Windows Server AD PowerShell Cmdlet 以執行變更。
如有需要，您也可以下載已完成檢閱的檢閱歷程記錄報告。
遭拒絕持續存取的使用者，能夠繼續使用同盟應用程式的時間長度，取決於應用程式自己的工作階段存留期，以及存取權杖存留期。 如果應用程式已使用 Kerberos，則因為 Kerberos 會在使用者登入網域時快取使用者的群組成員資格，所以使用者可能會繼續擁有存取權，直到其 Kerberos 票證到期為止。 若要深入了解如何控制存取權杖的存留期，請參閱可設定的權杖存留期。