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

Microsoft Entra 身分控管可讓您以正確的程式和可見度,平衡組織安全性和員工生產力的需求。 其可為您提供功能,確保正確人員會有正確資源的正確存取權。

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

檢閱存取權的必要條件

若要對應用程式存取權的存取權檢閱使用 Azure AD,您必須在租用戶中擁有下列其中一個授權:

  • Azure AD Premium P2
  • Enterprise Mobility + Security (EMS) E5 授權

雖然使用存取權檢閱功能不需要為使用者指派這些授權即可使用該功能,但您必須在租用戶中至少擁有與將設定為檢閱者的成員 (非來賓) 使用者數目一樣多的授權。

此外,雖然不需要檢閱應用程式的存取權,但也建議您定期檢閱特殊權限目錄角色 (其能夠控制其他使用者對所有應用程式的存取權) 的成員資格。 Global AdministratorIdentity Governance AdministratorUser AdministratorApplication AdministratorCloud Application AdministratorPrivileged Role Administrator 中的系統管理員可以變更使用者及其應用程式角色指派,以確保已排程這些目錄角色的存取權檢閱

判斷應用程式如何與 Azure AD 整合

為了讓Microsoft Entra存取權檢閱用於應用程式,應用程式必須先與 Azure AD 整合。 與 Azure AD 整合的應用程式表示必須符合兩個需求之一:

  • 應用程式依賴 Azure AD 進行同盟 SSO,而 Azure AD 會控制驗證權杖核發。 如果 Azure AD 是應用程式的唯一識別提供者,則只有獲指派 Azure AD 中其中一個應用程式角色的使用者才能登入應用程式。 檢閱所拒絕的使用者會失去其應用程式角色指派,而且不再能取得新的權杖來登入應用程式。
  • 應用程式依賴 Azure AD 提供給應用程式的使用者或群組清單。 透過跨網域身分識別管理系統 (SCIM) 這類佈建通訊協定、透過 Microsoft Graph 來查詢 Azure AD 的應用程式,或寫入至 AD DS 的群組,即可完成此履行。 檢閱拒絕的使用者會失去其應用程式角色指派或群組成員資格,且當這些變更可供應用程式使用時,遭拒絕的使用者將不再有存取權。

如果應用程式不符合上述任一準則,因為應用程式不依賴 Azure AD,則仍可使用存取權檢閱,但可能會有一些限制。 不在 Azure AD 中或未獲指派 Azure AD 中應用程式角色的使用者,將不會包含在檢閱中。 此外,如果沒有應用程式支援的佈建通訊協定,對移除遭拒絕的變更,將無法自動傳送至應用程式。 組織必須改為有一個程序,以將已完成的檢閱結果傳送給應用程式。

為了允許使用 Azure AD 解決各種不同的應用程式和 IT 需求,應用程式如何可以與 Azure AD 整合有多個模式。 下列流程圖說明如何從三個整合模式 A-C 中選取適合用於身分識別控管的應用程式。 了解針對特定應用程式所使用的模式,可協助您在 Azure AD 中設定適當的資源,以準備好進行存取權檢閱。

應用程式整合模式的流程圖

模式 應用程式整合模式 準備存取權檢閱的步驟
A 應用程式支援同盟 SSO,Azure AD 是唯一的識別提供者,而且應用程式不會依賴群組或角色宣告。 在此模式中,您將設定應用程式需要個別的應用程式角色指派,以及使用者將被指派給應用程式。 然後,若要執行檢閱,您將針對指派給此應用程式角色的使用者,建立應用程式的單一存取權檢閱。 檢閱完成時,如果使用者遭到拒絕,則會將其從應用程式角色中移除。 Azure AD 將不再核發該使用者同盟權杖,而且使用者將無法登入該應用程式。
B 如果應用程式除了應用程式角色指派之外,還會使用群組宣告。 應用程式可以使用 AD 或 Azure AD 群組成員資格,其與應用程式角色不同,以表達更精細的存取權。 在這裡,您可以根據您的商務需求選擇要檢閱具有應用程式角色指派的使用者,或是要檢閱具有群組成員資格的使用者。 如果群組未提供完整的存取涵蓋範圍,特別是即便使用者不是這些群組的成員,使用者也可以存取應用程式,則建議您檢閱應用程式角色指派,如上述的模式 A。
C 如果應用程式不只依賴 Azure AD 進行同盟 SSO,但確實透過 SCIM 或透過對使用者或非 AD LDAP 目錄 SQL 資料表的更新來支援佈建。 在此模式中,您將設定 Azure AD 以將具有應用程式角色指派使用者佈建至應用程式的資料庫或目錄、更新 Azure AD 中的應用程式角色指派以加上使用目前具有存取權的使用者清單,然後建立應用程式角色指派的單一存取權檢閱。 如需詳細資訊,請參閱控管應用程式的現有使用者,以更新 Azure AD 中的應用程式角色指派。

其他選項

以上所列的整合模式適用於第三方 SaaS 應用程式,或為組織或組織所開發的應用程式。

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

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

既然您已識別應用程式的整合模式,請檢查 Azure AD 中所呈現的應用程式已備妥供檢閱。

  1. 在 Azure 入口網站中,按一下 [Azure Active Directory],按一下 [企業應用程式],然後檢查您的應用程式是否位於 Azure AD 租用戶的企業應用程式清單中。

  2. 如果尚未列出應用程式,則檢查該應用程式是否有可整合以進行同盟 SSO 或佈建的應用程式的應用程式庫中。 如果有在資源庫中,則使用教學課程來設定應用程式以進行同盟,而如果支援佈建,也請設定應用程式以進行佈建。 如果應用程式使用 AD 安全性群組,則請新增應用程式以透過應用程式 Proxy 進行遠端存取,並設定群組回寫至 AD

  3. 應用程式位於您租用戶中的企業應用程式清單之後,請從清單中選取應用程式。

  4. 切換至 [屬性] 索引標籤。驗證 [需要使用者指派?] 選項設定為 [是]。 如果將其設定為 [否],您目錄中的所有使用者 (包括外部身分識別) 都可以存取應用程式,而且您無法檢閱應用程式的存取權。

    顯示規劃應用程式指派的螢幕擷取畫面。

  5. 切換至 [角色和系統管理員] 索引標籤。此索引標籤會顯示系統管理角色,其提供權限來控制應用程式在 Azure AD 中的呈現 (而非應用程式中的存取權限)。 對於具有權限可允許變更應用程式整合或指派,並且具有該系統管理角色指派的每個系統管理角色,請確保該角色中只有獲授權的使用者。

  6. 切換至 [佈建] 索引標籤。如果未設定自動佈建,在檢閱期間拒絕而移除使用者的存取權時,Azure AD 將無法通知應用程式。 如果應用程式為同盟且只依賴 Azure AD 作為其身分識別提供者,或應用程式使用 AD DS 群組,則某些整合模式可能不需要佈建。 不過,如果您的應用程式整合為模式 C,而且應用程式不支援使用 Azure AD 的同盟 SSO 作為唯一的識別提供者,則您必須設定從 Azure AD 佈建至應用程式。 佈建將是必要的,使得 Azure AD 可以在檢閱完成時自動從應用程式移除檢閱的使用者,而且此移除步驟可以透過 SCIM、LDAP 或 SQL 從 Azure AD 傳送至應用程式的變更來完成。

  7. 如果已設定佈建,則按一下 [編輯屬性對應],展開 [對應] 區段,然後按一下 [佈建 Azure Active Directory 使用者]。 檢查屬性對應清單中,當使用者失去存取權時,您要設定為 false 的應用程式資料存放區中有 isSoftDeleted 的屬性對應。 如果此對應不存在,則 Azure AD 不會在使用者超出範圍時通知應用程式,如佈建的運作方式中所述。

  8. 如果應用程式支援同盟 SSO,請切換至 [條件式存取] 索引標籤。檢查此應用程式已啟用的原則。 如果有原則已啟用、封鎖存取、將使用者指派給原則,但沒有其他條件,則這些使用者可能已遭到封鎖,而無法對應用程式使用同盟 SSO。

  9. 切換至 [使用者和群組] 索引標籤。此清單包含指派給 Azure AD 中應用程式的所有使用者。 如果清單空白,則應用程式檢閱會立即完成,因為沒有需要檢閱者執行的任何工作。

  10. 如果您的應用程式使用模式 C 整合,則在開始檢閱之前,您必須確認此清單中的使用者與應用程式內部資料存放區中的使用者相同。 Azure AD 不會自動從應用程式匯入使用者或其存取權限,但您可以透過 PowerShell 將使用者指派給應用程式角色。 請參閱控管應用程式的現有使用者,以了解如何將不同應用程式資料存放區中的使用者帶入 Azure AD,並將其指派給應用程式角色。

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

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

接下來,如果應用程式整合也需要檢閱一或多個群組,如模式 B 所述,請檢查每個群組是否已準備好進行檢閱。

  1. 在 Azure AD Azure 入口網站體驗中,按一下 [群組],然後從清單中選取群組。
  2. 在 [概觀] 索引標籤上,驗證 [成員資格類型] 為 [已指派],且 [來源] 為[雲端]。 如果應用程式使用動態群組,或從內部部署同步群組,則無法在 Azure AD 中變更這些群組成員資格。 建議將應用程式轉換成在 Azure AD 中建立、具有指派成員資格的群組,然後將成員使用者複製到該新群組。
  3. 切換至 [角色和系統管理員] 索引標籤。此索引標籤會顯示系統管理角色,其提供權限來控制群組在 Azure AD 中的呈現 (而非應用程式中的存取權限)。 對於允許變更群組成員資格且在該系統管理角色中擁有使用者的每個系統管理角色,請確保在該角色中只有獲授權的使用者。
  4. 切換至 [成員] 索引標籤。驗證群組的成員是使用者,而且沒有非使用者成員或巢狀群組。 如果檢閱開始時沒有群組的成員,該群組的檢閱將會立即完成。
  5. 切換至 [擁有者] 索引標籤。請確定沒有獲授權的使用者顯示為擁有者。 如果您要要求群組擁有者執行群組的存取權檢閱,請確認該群組有一或多個擁有者。

選取適當的檢閱者

當您建立每個存取權檢閱時,管理員可以選擇一或多個檢閱者。 檢閱者可以藉由選擇使用者繼續存取資源或將其移除,來施行檢閱。

資源擁有者通常會負責執行檢閱。 如果您要建立群組的檢閱,作為以模式 B 整合的應用程式檢閱存取權的一部分,則可以選取群組擁有者作為檢閱者。 由於 Azure AD 中的應用程式不一定會有擁有者,選取應用程式擁有者作為檢閱者的選項並不可行。 相反地,在建立檢閱時,您可以提供要成為檢閱者的應用程式擁有者的名稱。

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

建立檢閱之前,請檢查您的租用戶中至少有與獲指派為檢閱者的成員使用者一樣多的 Azure AD Premium P2 授權。 此外,檢查所有檢閱者是否為具有電子郵件地址的作用中使用者。 存取權檢閱開始時,他們都會檢閱來自 Azure AD 的電子郵件。 如果檢閱者沒有信箱,當檢閱開始時或以電子郵件寄送提醒時,他們將不會收到電子郵件。 而且,如果他們遭封鎖而無法登入 Azure AD,他們將無法執行檢閱。

建立檢閱

找出資源之後,根據整合模式,應用程式和選用的一或多個群組,以及檢閱者應該是誰,您便可以設定 Azure AD 以開始檢閱。

  1. 在此步驟中,您必須是 Global administratorIdentity Governance administrator 角色。

  2. 在模式 A 和 C 中,您將建立一個存取權檢閱,並選取應用程式。 遵循指南中建立群組或應用程式的存取權檢閱的指示,以建立應用程式角色指派的檢閱。

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

    注意

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

  4. 存取權檢閱開始時,要求檢閱者提供意見。 依預設,使用者會各自收到來自 Azure AD 的電子郵件,其中具有存取面板的連結,他們可以在其中檢閱群組中的成員資格或應用程式的存取權

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

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

  1. 監視存取權檢閱,確保檢閱者會選取核准或拒絕使用者對持續存取的需求,直到存取權檢閱完成

  2. 如果建立檢閱時未選取自動套用,則必須在檢閱完成時套用檢閱結果。

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

  4. 如果您先前已設定將使用者佈建至應用程式,則在套用結果時,Azure AD 將會開始從應用程式取消佈建遭拒絕的使用者。 您可以監視取消佈建使用者的程序。 如果佈建指出應用程式發生錯誤,您可以下載佈建記錄檔,以調查應用程式是否有問題。

  5. 如果您已設定已檢閱群組的群組回寫,則請等到群組回寫在 Azure AD Connect 中完成,而且變更會傳播到所有網域控制站。

  6. 如果未針對您的應用程式設定佈建,您可能需要個別將遭拒絕的使用者清單複製到應用程式。 例如,針對 Windows Server AD 受控群組的存取權檢閱,請使用此 PowerShell 範例指令碼。 此指令碼概述必要的 Microsoft Graph 呼叫,並匯出 Windows Server AD PowerShell Cmdlet 以執行變更。

  7. 如有需要,您也可以下載已完成檢閱的檢閱歷程記錄報告

  8. 遭拒絕持續存取的使用者,能夠繼續使用同盟應用程式的時間長度,將取決於應用程式自己的工作階段存留期,以及存取權杖存留期。 如果應用程式已使用 Kerberos,則因為 Kerberos 會在使用者登入網域時快取使用者的群組成員資格,所以使用者可能會繼續擁有存取權,直到其 Kerberos 票證到期為止。 若要深入了解如何控制存取權杖的存留期,請參閱可設定的權杖存留期

下一步