共用方式為

對身分識別和存取管理的建議

  • 發行項

適用於此 Power Platform Well-Architected 的安全性檢查清單建議：

SE:05 對所有工作負載使用者、團隊成員和系統元件實施嚴格、有條件且可稽核的身分識別和存取管理 (IAM)。 僅將存取權限縮為根據需要。 使用現代產業標準進行所有身份驗證和授權實施。 限制並嚴格稽核非依據身分識別的存取。

本指南介紹對嘗試存取工作負載資源的身分識別進行驗證和授權的建議。

從技術控制的角度來看，身分識別始終是主要邊界。 此範圍不僅包括工作負載的邊緣。 它還包括工作負載中的個別元件。

一般身分包括：

  • 人員。 應用程式使用者、管理員、動作員、稽核員和不良行為者。
  • 系統。 工作負載身分識別、受控身分識別、API 金鑰、服務主體和 Azure 資源。
  • 匿名。 未提供任何證據證明其身分的實體。

定義

詞彙 定義
驗證 (AuthN) 驗證身分識別是否真實或所聲稱的內容的程序。
授權 (AuthZ) 驗證身分識別是否有權執行所要求動作的過程。
條件式存取 允許根據指定條件執行動作的一組規則。
IdP 識別提供者，例如 Microsoft Entra ID。
角色 具有一系列職責和動作的工作職能或頭銜。
預先共用金鑰 一種在提供者和消費者之間共用，並透過安全且商定的機制使用的密碼。
資源身分識別 為由平台管理的雲端資源定義的身分識別。
角色 一組權限，用於定義使用者或組可以執行的動作。
Scope 允許角色運作的各層級組織階層。 也是系統中的一組功能。
安全性主體 提供權限的身分識別。 它可以是使用者、群組或服務主體。 任何群組成員均可獲得相同層級的存取權限。
使用者身分識別 人員 (如員工或外部使用者) 的身分識別。
工作負載身分識別 應用程式、服務、指令碼、容器或工作負載的其他元件的系統身分識別，用於向其他服務和資源進行驗證。

注意

身分識別可以與其他類似身分識別分組到稱為安全性主體的父級下。 安全性群組是安全性主體的一個範例。 這種階層式關係簡化了維護程序，並提高了一致性。 由於身分識別屬性不是在個人層級處理的，因此出錯的可能性也會降低。 在本文中，術語身分識別包含安全性主體。

Microsoft Entra ID 做為 Power Platform 的識別提供者

所有 Power Platform 產品都使用 Microsoft Entra ID (以前稱為 Azure Active Directory 或 Azure AD) 進行身分識別和存取管理。 Entra ID 使組織能夠保護和管理其混合和多雲端環境的身分識別。 Entra ID 對於管理需要存取 Power Platform 資源的商務訪客也至關重要。 Power Platform 還使用 Entra ID 來管理需要使用服務主體功能與 Power Platform API 整合的其他應用程式。 透過使用 Entra ID，Power Platform 可以利用 EntraID 更進階的安全性功能，例如條件式存取和持續性存取評估。

驗證

驗證是確認身分識別的程序。 要求身分需要提供某種形式的可驗證身分識別。 例如:

  • 使用者名稱和密碼。
  • 預先共用的密碼，例如授予存取權限的 API 金鑰。
  • 共用存取簽章 (SAS) 權杖。
  • 用於傳輸層安全性 (TLS) 相互驗證的認證。

Power Platform 驗證涉及使用者瀏覽器和 Power Platform 或 Azure 服務之間的一系列要求、回覆和重新導向。 此順序遵循 Microsoft Entra ID 驗證代碼授與流程。

連線到資料來源並對其進行驗證的步驟，獨立於驗證 Power Platform 服務的步驟。 如需其他資訊，請參閱連接並驗證資料來源。

授權

Power Platform 使用 Microsoft Entra ID Microsoft Identity Platform 透過業界標準 OAuth 2.0 協定對所有 API 呼叫進行授權。

關鍵設計原則

若要了解工作負載的身分識別需求，需要列出使用者和系統流程、工作負載資產和角色，以及它們將執行的動作。

每個使用案例可能都有自己的一組控制項，您需要以假設入侵的心態進行設計。 根據使用案例或角色的身分識別要求，確定條件選擇。 避免對所有使用案例都使用同一種解決方案。 相反，控制項不應過於精細，以免造成不必要的管理開銷。

您需要記錄身分識別存取軌跡。 這樣做有助於驗證控制項，並且可以使用記錄進行合規性稽核。

確定用於驗證的所有身分識別

由外而內的存取權。 Power Platform 驗證涉及使用者瀏覽器和 Power Platform 或 Azure 服務之間的一系列要求、回覆和重新導向。 此順序遵循 Microsoft Entra ID 驗證代碼授與流程。 Power Platform 會自動對出於各種目的存取工作負載的所有使用者進行驗證。

由內而外的存取權。 您的工作負載將需要存取其他資源。 例如，讀取或寫入資料平台、從密碼存放區中擷取密碼，以及將遙測資料記錄到監視服務。 它甚至可能需要存取第三方服務。 這些都是工作負載身分識別要求。 但是，還需要考慮資源身分識別要求；例如，部署管線的執行方式和驗證方式。

確定授權動作

接下來，您需要知道每個經過驗證的身分正在嘗試執行的動作，以便可以授權這些動作。 這些動作可以根據其所需的存取類型來劃分：

  • 資料平面存取權。 資料平面中發生的動作會導致資料傳輸。 例如，應用程式從 Microsoft Dataverse 中讀取或寫入資料，或將記錄寫入 Application Insights。

  • 控制平面存取權。 在控制平面中發生的動作會導致建立、修改或刪除 Power Platform 資源。 例如，修改環境屬性或建立資料原則。

應用程式通常以資料平面動做為目標，而動作通常會同時存取控制平面和資料平面。

提供角色型授權

根據每個身分的責任，授權應允許的動作。 絕不能允許一個身分識別做超出其需要的事情。 在設定授權規則之前，您需要清楚地了解誰或什麼在發出要求、允許該角色執行哪些動作，以及它可以執行到什麼程度。 這些因素會導向將身分、角色和範圍結合起來的選擇。

請考量下列各項：

  • 工作負載是否需要對 Dataverse 進行資料平面存取以進行讀取和寫入存取？
  • 工作負載是否還需要存取環境屬性？
  • 如果身分識別遭到不良行為者洩露，系統的機密性、完整性和可用性會受到什麼影響？
  • 工作負載是否需要永久存取，或者是否可以考慮條件式存取？
  • 工作負載執行的動作是否需要管理/上呈權限？
  • 工作負載將如何與第三方服務互動？
  • 對於代理程式等智慧型應用程式工作負載，您是否有單一登入 (SSO) 要求？
  • 代理程式是在未經驗證的模式下執行，還是在經過驗證的模式下執行，還是兩者兼而有之？

角色指派

角色是指派給身分識別的一組權限。 指派僅允許該身分完成工作的角色，僅此而已。 當使用者的權限僅限於其作業要求時，可以更輕鬆地識別系統中的可疑或未經授權的行為。

提問以下問題：

  • 唯讀存取權限是否足夠？
  • 身分識別是否需要權限才能刪除資源？
  • 角色是否只需要存取他們建立的記錄？
  • 是否需要根據使用者所在的事業單位進行階層式存取？
  • 角色是否需要管理權限或提升權限？
  • 角色是否需要對這些權限的永久存取權限？
  • 如果使用者換了工作，會發生什麼情況？

限制使用者、應用程式或服務的存取層級可減少潛在的攻擊面。 如果僅授予執行特定工作所需的最低權限，則成功攻擊或未經授權存取的風險將大大降低。 例如，開發人員只需要製作者存取開發環境，而不需要生產環境；他們只需要建立資源的存取權限，而不需要變更環境屬性；他們可能只需要存取 Dataverse 中的讀取/寫入資料，而不需要變更 Dataverse 資料表的資料模型或屬性。

避免針對個別使用者的權限。 精細和自訂權限會造成複雜性和混亂，並且當使用者變更角色並在業務中移動時，或者當具有類似驗證要求的新使用者加入團隊時，可能會變得難以維護。 這種情況可能會建立難以維護的複雜舊設定，並對安全性和可靠性產生負面影響。

權衡：精細的存取控制方法能夠更好地稽核和監控使用者活動。

授予從最小權限開始的角色，並根據您的作業或資料存取需求新增更多權限。 技術團隊必須有明確的指引才能實作權限。

做出條件式存取選擇

不要為所有身分識別提供相同層級的存取權。 可根據兩個主要因素做出決定：

  • 時間： 身分識別可以存取環境的時間長度。
  • 權限。 權限的層級。

這些因素並不相互排斥。 具有更多特殊權限和無限存取持續時間的已洩露身分可以獲得對系統和資料的更多控制權，或者使用該存取權限繼續變更環境。 限制這些存取因素既可以做為預防措施，也可以控制影響範圍。

即時 (JIT) 方法僅在需要時才提供所需的權限。

剛好的存取權限 (JEA) 僅提供所需的權限。

雖然時間和特殊權限是主要因素，但還有其他適用條件。 例如，您還可以使用源自存取的裝置、網路和位置來設定策略。

使用強大的控制來篩選、偵測和阻止未經授權的存取，包括使用者身分識別和位置、裝置運作狀況、工作負載環境、資料分類和異常等參數。

例如，您的工作負載可能需要由第三方身分識別 (如廠商、合作夥伴和客戶) 存取。 他們需要適當的存取層級，而不是您提供給全職員工的預設權限。 明確區分外部帳戶可以更輕鬆地預防和偵測來自這些媒介的攻擊。

嚴重影響帳戶

管理身分識別引入了一些影響最大的安全風險，因為它們執行的工作需要對廣泛的這些系統和應用程式進行特殊權限存取。 洩露或濫用可能會對您的業務及其資訊系統產生不利影響。 管理安全性是最重要的安全性領域之一。

保護特殊權限存取免受確定的對手的攻擊需要您採取完整且周到的方法將這些系統與風險隔離開來。 以下是一些策略：

  • 盡量減少關鍵影響帳戶的數量。

  • 使用獨立的角色，而不是提升現有身分識別的權限。

  • 使用 IdP 的 JIT 功能避免永久或長期存取。 如果出現意外狀況，請遵循緊急存取流程。

  • 使用新式存取協定，如無密碼驗證或多重要素驗證。 將這些機制外部化到您的 IdP。

  • 使用條件式存取原則強制實施關鍵安全性屬性。

  • 停用未使用的管理帳戶。

建立管理身分識別生命週期的流程

對身分識別的存取持續時間不得超過身分識別存取的資源。 確保在團隊結構或軟體元件發生變更時具有停用或刪除身分識別的程序。

本指南適用於原始程式碼管理、資料、控制平面、工作負載使用者、基礎結構、工具、資料監視、記錄、指標和其他實體。

建立身分識別治理程序，管理數位身分識別、高權限使用者、外部/來賓使用者和工作負載使用者的生命週期。 實施存取權檢閱，以確保當身分識別離開組織或團隊時，刪除其工作負載權限。

保護非身分識別型密碼

應用程式密碼 (如預先共用金鑰) 應被視為系統中的易受攻擊點。 在雙向通信中，如果提供者或消費者受到損害，可能會引入重大的安全風險。 這些金鑰也可能很繁瑣，因為它們引入了動作流程。

將這些密碼視為可從密碼儲存中動態拉取的實體。 不應在應用呈是、流程、部署管線或任何其他成品中對它們進行硬編碼。

確保您能夠撤銷密碼。

套用處理金鑰輪換和過期等工作的操作做法。

有關輪換原則的資訊，請參閱自動輪換具有兩組身分驗證憑證之資源的密碼和教學課程：更新 Key Vault 中的認證自動輪換頻率。

保持開發環境安全

對開發人員環境的寫入存取權限應受到限制，對原始程式碼的讀取存取權限應限制為需要知道的角色。 您應該制定一個程序來定期掃描資源並識別最新的漏洞。

維護稽核線索

身分識別管理的一個面向是確保系統可稽核。 稽核會驗證假設入侵策略是否有效。 維護稽核線索可幫助您：

  • 驗證身分是否使用增強式驗證進行驗證。 任何動作都必須是可追蹤的，以防止否認攻擊。

  • 偵測弱的或缺少的驗證協定，並了解和深入解析使用者和應用程式登入。

  • 根據安全性和合規性要求評估從身分識別到工作負載的存取，並考慮使用者帳戶風險、裝置狀態以及您設定的其他準則和原則。

  • 追蹤合規性要求的進度或偏差。

大多數資源都具有資料平面存取權限。 您需要知道存取資源的身分識別及其執行的動作。 您可以將該資訊用於安全診斷。

Power Platform 簡易化

Power Platform 存取控制是其整體安全性架構的重要組成部分。 存取控制點可以確保正確的使用者能夠存取 Power Platform 資源。 在本節中，我們將探討您可以設定的不同存取點及其在整體安全性策略中的作用。

Microsoft Entra ID

所有 Power Platform 產品都使用 Microsoft Entra ID (以前稱為 Azure Active Directory 或 Azure AD) 進行身分識別和存取管理。 Entra ID 使組織能夠保護和管理其混合和多雲端環境的身分識別。 Entra ID 對於管理需要存取 Power Platform 資源的商務訪客也至關重要。 Power Platform 還使用 Entra ID 來管理需要使用服務主體功能與 Power Platform API 整合的其他應用程式。 透過使用 Entra ID，Power Platform 可以利用 EntraID 更進階的安全性功能，例如條件存取和持續性存取評估。

雲端運算系統的示意圖。

授權指派

對 Power Apps 和 Power Automate 存取從獲得權限開始。 使用者可以存取的資產和資料取決於他們擁有的授權類型。 下表概述了不同方案類型的使用者可用資源的差異。 您可以在授權概觀找到詳細的授權資料。

條件式存取原則

條件式存取描述了存取決策的原則。 若要使用條件式存取，需要了解使用案例所需的限制。 透過根據您的動作需求設定存取原則來設定 Microsoft Entra 條件式存取。

如需詳細資訊，請參閱：

持續性存取

當評估某些事件以確定是否應撤銷存取權限時，持續性存取會加速。 傳統上，使用 OAuth 2.0 驗證時，在權杖更新期間進行檢查時會發生存取權杖過期。 透過持續性存取，將持續評估使用者的關鍵事件和網路位置變更，以確定使用者是否仍應保持存取權限。 這些評估可能會導致活動會話提前終止或需要重新進行驗證。 例如，如果使用者帳戶停用，他們應該會失去對應用程式的存取權限。 位置也很重要；例如，權杖可能已從受信任位置授權，但使用者將其連線變更為不受信任的網路。 持續性存取將調用條件式存取原則評估，並且使用者將失去存取權限，因為他們不再從核准的位置進行連接。

目前，在 Dataverse 中，只有 Power Platform 支援持續性存取評估。 Microsoft 正在努力增加對其他 Power Platform 服務和用戶端的支援。 如需詳細資訊，請參閱持續性存取評估。

隨著不斷採用混合式工作模式和雲端應用程式，Entra ID 已成為保護使用者和資源的重要主要安全界限。 條件式存取將該範圍擴展到網路範圍之外，以包括使用者和裝置身分識別。 持續性存取可確保在事件或使用者位置變更時重新評估存取權限。 Power Platform 使用 Entra ID 讓您實施組織級安全治理，您可以在應用程式組合中一致地套用這些治理。 查看這些身分識別管理最佳做法，以獲取更多指引來制定將 Entra ID 與 Power Platform 結合使用的計劃。

群組存取管理

不要向特定使用者授予權限，而是將存取權限指派給 Microsoft Entra ID 中的群組。 如果群組不存在，請與身分識別團隊合作建立一個。 然後，可以在 Azure 外部新增和刪除組成員，並確保權限是最新的。 您還可以將該群組用於其他目的，例如郵件清單。

有關詳細資訊，請參閱使用 Microsoft Entra ID 中的群組進行安全存取控制。

威脅偵測

Microsoft Entra ID 保護可以幫助您偵測、調查和修正身分識別型風險。 如需 Intune 的詳細資訊，請參閱什麼是身分識別保護？。

威脅偵測可以採取的形式是對可疑活動警示做出反應，或主動搜尋活動記錄中的例外狀況事件。 Microsoft Sentinel 中的使用者和實體行為分析 (UEBA) 可讓您輕鬆偵測可疑活動。 有關詳細資訊，請參閱在 Microsoft Sentinel 中使用 UEBA 識別進階威脅。

身分識別記錄

可從 Microsoft Purview 合規入口網站追蹤並檢視 Power Apps、Power Automate、Copilot Studio、連接器和資料外洩防護活動記錄。 如需詳細資訊，請參閱 了解 Microsoft Purview。

記錄在具有 Dataverse 資料庫的環境中對客戶記錄所做的變更。 Dataverse 稽核也會透過應用程式或透過環境中的 SDK，來記錄使用者的存取權。 此稽核在環境層級啟用，並且需要對個別資料表和資料行進行其他設定。

服務管理員角色

Entra ID 包含一組預先建立的角色，可以將這些角色指派給管理員，以授予他們執行管理工作的權限。 您可以查看權限矩陣，了解每個角色權限的精細細分。

使用 Microsoft Entra Privileged Identity Management (PIM) 管理 Power Platform 系統管理中心中的高特殊權限管理員角色。

保護 Dataverse 資料

Dataverse 的其中一項重要特性是包含豐富的資訊資訊安全模型，可適應許多業務使用情境。 只有當環境中存在 Dataverse 資料庫時，此資訊資訊安全模型才可用。 做為安全性專業人員，您可能不會自己建置整個資訊資訊安全模型，但可能會參與確保安全性功能的使用符合組織的資料安全性要求。 Dataverse 使用角色安全性，將權限集合集中在一起。 這些資訊安全角色可以直接關聯至使用者，或者可以與 Dataverse 團隊和業務單位相關聯。 如需詳細資訊，請參閱 Microsoft Dataverse 中的安全性概念。

在 Copilot Studio 中設定使用者驗證

Microsoft Copilot Studio 支援幾種驗證選項。 選擇符合您需求的選項。 驗證允許使用者登入，從而授予您的代理程式存取受限資源或資訊的權限。 使用者可以使用 Microsoft Entra ID 或任何 OAuth 2.0 身分識別識別提供者 (例如 Google 或 Facebook) 登入。 如需進一步了解，請參閱在 Copilot Studio 中設定使用者驗證。

透過 Direct Line 型安全性，您可以透過使用 Direct Line 秘密或權杖啟用安全存取來限制對您控制的位置的存取。

Copilot Studio 支援單一登入 (SSO)，這表示代理程式可以為使用者登入。 必須在您的網頁和行動應用程式上實現 SSO。 對於 Microsoft Teams，如果您選擇「僅在 Teams 中」驗證選項，則 SSO 是無縫的。 也可以使用 Azure AD v2 手動設定；但是，在這種情況下，Teams 應用程式必須以 zip 檔案的形式部署，而不是透過 Copilot Studio 的一鍵式 Teams 部署進行部署。

深入了解：

使用客戶加密箱安全存取資料

Microsoft 人員 (包括轉包處理者) 執行的大多數作業、支援和疑難排解不需要存取客戶資料。 藉由 Power Platform 客戶加密箱，我們為客戶提供了一個介面，以便在需要對對客戶資料進行資料存取的極少數情況下審查和核准 (或拒絕) 資料存取要求。 例如當 Microsoft 工程師需要存取客戶資料時，無論是回應客戶發起的支援票證還是 Microsoft 發現的問題，都會使用它。 如需其他資訊，請參閱使用 Power Platform 和 Dynamics 365 中的客戶加密箱安全存取客戶資料。

安全性檢查清單

請參閱完整的建議集。

安全性檢查清單