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

  • 發行項

適用于此 Azure Well-Architected Framework 安全性檢查清單建議：

SE：05 在所有工作負載使用者、小組成員和系統元件上，實作嚴格、條件式和可稽核的身分識別和存取管理 (IAM) 。 視需要將存取限制為 。 針對所有驗證和授權實作使用新式產業標準。 限制和嚴格稽核不是以身分識別為基礎的存取。

本指南說明驗證和授權嘗試存取工作負載資源之身分識別的建議。

從技術控制的觀點來看， 身分識別一律是主要周邊。 此範圍不只包含工作負載的邊緣。 它也包含工作負載內的個別元件。 一般身分識別包括：

  • 人類。 應用程式使用者、系統管理員、操作員、稽核員和不良動作專案。

  • 系統。 工作負載識別、受控識別、API 金鑰、服務主體和 Azure 資源。

  • 匿名。 尚未提供其身分的任何辨識項的實體。

定義 

字詞 定義
驗證 (AuthN) 驗證身分識別是身分識別或其所說內容的程式。
授權 (AuthZ) 驗證身分識別是否有權執行要求動作的程式。
條件式存取 一組規則，允許根據指定的準則執行動作。
IdP 識別提供者，例如Microsoft Entra識別碼。
角色 具有一組責任和動作的作業函式或標題。
預先共用金鑰 提供者和取用者之間共用的秘密類型，並透過安全且同意的機制使用。
資源身分識別 針對由平臺管理的雲端資源所定義的身分識別。
角色 定義使用者或群組可以執行哪些動作的許可權集。
範圍 允許角色運作的不同組織階層層級。 此外，系統中的一組功能。
安全性主體 提供許可權的身分識別。 它可以是使用者、群組或服務主體。 任何群組成員都取得相同的存取層級。
使用者身分識別 人員身分識別，例如員工或外部使用者。
工作負載身分識別 應用程式、服務、腳本、容器或其他工作負載元件的系統身分識別，用來向其他服務和資源驗證本身。

注意

身分識別可以與其他類似身分識別分組，其父代稱為 安全性主體。 安全性群組是安全性主體的範例。 此階層式關聯性可簡化維護和改善一致性。 由於識別屬性不會在個別層級處理，因此也會減少錯誤的機會。 在本文中， 身分識別 一詞包含安全性主體。

識別提供者的角色

身分識別提供者 (IdP) 是雲端裝載的服務，可儲存和管理使用者作為數位身分識別。

利用受信任 IdP 提供的功能 ，以進行身分識別和存取管理。 請勿實作自訂系統來取代 IdP。 IdP 系統會每天擷取數十億個訊號，經常根據最新的攻擊媒介來改善。 Microsoft Entra識別碼是 Azure 雲端平臺的 IdP。

驗證

驗證是驗證身分識別的程式。 需要要求身分識別，才能提供某種形式的可驗證識別。 例如：

  • 使用者名稱和密碼。

  • 預先共用的秘密，例如授與存取權的 API 金鑰。

  • 共用存取簽章 (SAS) 權杖。

  • TLS 相互驗證中使用的憑證。

請盡可能處理您的 IdP 驗證程式。

授權

授權是允許或拒絕已驗證身分識別所要求的動作的程式。 動作可能可操作或與資源管理相關。

授權需要您將許可權指派給身分識別，您必須使用 IdP 所提供的功能來執行此動作。

主要設計策略

若要全面檢視工作負載的身分識別需求，您必須編目流程、工作負載資產和角色，以及資產和角色將執行的動作。 您的策略必須涵蓋處理 到達工作負載或其元件的所有使用案例，這些流程 (外部存取) ，以及從工作負載連線到其他來源的流程， (內部存取) 。

每個使用案例可能都有自己的一組控制項，您需要以假設缺口思維進行設計。 根據使用案例或角色的身分識別需求，識別條件式選擇。 避免對所有使用案例使用一個解決方案。 相反地，控制項不應該更細微，讓您產生不必要的管理額外負荷。

您必須記錄身分識別存取記錄。 這麼做有助於驗證控制項，而且您可以使用記錄進行合規性稽核。

判斷所有身分識別以進行驗證

  • 外部存取。 您的身分識別設計必須針對各種用途驗證存取工作負載的所有使用者。 例如，透過呼叫 API 來存取應用程式的終端使用者。

    在細微層級，工作負載的元件可能也需要從外部存取。 例如，需要透過入口網站存取或存取計算來執行命令的操作員。

    這兩者都是具有不同角色 的使用者身 分識別範例。

  • 內部存取。 您的應用程式必須存取其他資源。 例如，從資料平臺讀取或寫入資料平臺、從秘密存放區擷取秘密，以及將遙測記錄到監視服務。 它甚至可能需要存取協力廠商服務。 這些存取需要 工作負載身分識別，這可讓應用程式針對其他資源自行驗證。

    概念適用于元件層級。 在下列範例中，容器可能需要存取部署管線，才能取得其設定。 這些存取需要 資源識別。

這些身分識別都應該由您的 IdP 進行驗證。

以下是如何在架構中實作身分識別的範例：

此圖顯示如何在架構中實作身分識別。

決定授權的動作

接下來，您必須知道每個已驗證的身分識別嘗試執行哪些動作，才能授權這些動作。 動作可以除以所需的存取類型：

  • 資料平面存取。 在資料平面中發生的動作會導致資料傳輸，以進行內部或外部存取。 例如，從資料庫讀取資料並將資料寫入資料庫、擷取秘密或將記錄寫入監視接收的應用程式。 在元件層級，提取或推送映射至登錄或從登錄推送映射的計算會被視為資料平面作業。

  • 控制平面存取。 在控制平面中發生的動作會導致建立、修改或刪除 Azure 資源。 例如，對資源屬性所做的變更。

應用程式通常會以資料平面作業為目標，而作業通常會同時存取控制和資料平面。 若要識別授權需求，請記下可在資源上執行的作業動作。 如需每個資源允許動作的相關資訊，請參閱 Azure 資源提供者作業。

提供角色型授權

根據每個身分識別的責任，授權應允許的動作。 不得允許身分識別執行超過需要執行的身分識別。 設定授權規則之前，您必須清楚瞭解提出要求的人員或內容、允許該角色執行哪些動作，以及該角色可以執行的程度。 這些因素會導致結合身分識別、角色和範圍的選擇。

請考慮工作負載身分識別作為範例。 應用程式必須具有資料庫的資料平面存取權，因此必須允許對資料資源的讀取和寫入動作。 不過，應用程式是否需要對秘密存放區的控制平面存取？ 如果工作負載身分識別遭到不良執行者入侵，系統對系統的影響會因機密性、完整性和可用性而造成什麼影響？

角色指派

角色是指派給身分識別 的一組許可權 。 指派只允許身分識別完成工作的角色，而不再指派。 當使用者的許可權受限於其作業需求時，更容易識別系統中的可疑或未經授權的行為。

詢問如下的問題：

  • 唯讀存取是否足夠？
  • 身分識別是否需要許可權才能刪除資源？

限制使用者、應用程式或服務對 Azure 資源所擁有的存取層級，可降低潛在的受攻擊面。 如果您只授與執行特定工作所需的最低許可權，則成功攻擊或未經授權的存取風險會大幅降低。 例如，安全性小組只需要對所有技術環境的安全性屬性進行唯讀存取。 該層級足以評估風險因素、識別潛在風險降低措施，以及報告風險。

在某些情況下，使用者需要更多存取權，因為組織結構和小組組織。 各種角色之間可能會有重迭，或單一使用者可能會執行多個標準角色。 在此情況下，請使用以商務功能為基礎的多個角色指派，而不是為每個使用者建立自訂角色。 這麼做可讓角色更容易管理。

避免明確參考個別資源或使用者的權限。 細微和自訂許可權會建立複雜度和混淆，因為它們不會將意圖傳遞給類似的新資源。 這可以建立複雜的舊版設定，難以維護及對安全性和可靠性造成負面影響。

取捨：細微存取控制方法可讓您更妥善地稽核和監視使用者活動。

角色也有 相關聯的範圍。 角色可以在允許的管理群組、訂用帳戶、資源群組或資源範圍或另一個自訂範圍上運作。 即使身分識別有一組有限的許可權，擴大範圍以包含身分識別作業函式以外的資源是有風險的。 例如，所有原始程式碼和資料讀取存取權可能很危險，而且必須受到控制。

您可以使用角色型存取控制 (RBAC) ，將角色指派給身分識別。 請一律使用 IdP 提供的 RBAC 來利用可讓您一致地套用存取控制並嚴格撤銷的功能。

使用內建角色。 其設計目的是要涵蓋大部分的使用案例。 自訂角色的功能強大且有時很有用，但您應該針對內建角色無法運作的案例保留這些角色。 自訂會導致複雜度，其會增加混淆，並使得自動化更為複雜、具挑戰和脆弱。 這些因素都會對安全性造成負面影響。

授與以最低許可權開始的角色，並根據您的作業或資料存取需求新增更多角色。 您的技術小組必須有清楚的指導方針，才能實作許可權。

如果您想要更精細地控制 RBAC，請根據內容在角色指派上新增條件，例如動作和屬性。

選擇條件式存取

請勿將所有身分識別授與相同層級的存取權。 根據兩個主要因素做出決策：

  • 時間。 身分識別可以存取您的環境的時間長度。

  • 許可權。 許可權層級。

這些因素不互斥。 具有更多許可權和無限制存取持續時間的遭入侵身分識別，可以進一步控制系統和資料，或使用該存取權繼續變更環境。 將這些訪問因素限制為預防性量值，並控制彈射半徑。

  • Just In Time (JIT) 方法只有在需要時才提供所需的許可權。

  • Just Enough Access (JEA) 僅提供所需的許可權。

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

使用強式控制項來篩選、偵測和封鎖未經授權的存取，包括使用者身分識別和位置、裝置健康情況、工作負載內容、資料分類和異常等參數。

例如，您的工作負載可能需要由協力廠商身分識別存取，例如廠商、合作夥伴和客戶。 他們需要適當的存取層級，而不是您提供給全職員工的預設許可權。 外部帳戶的清楚區別可讓您更輕鬆地防止和偵測來自這些向量的攻擊。

您選擇的 IdP 必須能夠提供該差異、提供內建功能，以根據最低許可權授與許可權，並提供內建威脅情報。 這包括監視存取要求和登入。Azure IdP 是Microsoft Entra識別碼。 如需詳細資訊，請參閱本文的 Azure 功能一節 。

重大影響帳戶

系統管理身分識別引進了一些最高影響的安全性風險，因為它們執行的工作需要特殊許可權存取一組廣泛的系統與應用程式。 危害或誤用可能會對您的業務及其資訊系統造成負面影響。 系統管理的安全性是最重要的安全性領域之一。

為保護特殊權限存取的安全以對抗這些積極的攻擊者，您必須採取完整且深思熟慮的方法來隔絕這些系統風險。 部分策略如下：

  • 將重大影響帳戶的數目降到最低。

  • 使用個別角色 ，而不是提高現有身分識別的許可權。

  • 使用 IdP 的 JIT 功能來避免永久或常設存取。 針對急用的情況，請遵循緊急存取程式。

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

  • 使用 條件式存取原則強制執行金鑰安全性屬性。

  • 解除委任未使用的系統管理帳戶 。

跨環境使用單一身分識別，並將單一身分識別與使用者或主體產生關聯。 跨雲端和內部部署環境的身分識別一致性可降低人為錯誤和產生的安全性風險。 在這兩個環境中管理資源的 Teams 都需要一致的授權來源，才能符合安全性保證。 請與您的中央身分識別小組合作，以確保混合式環境中的身分識別已同步處理。

風險：與同步處理高許可權身分識別有關聯的風險。 攻擊者可以完全控制內部部署資產，這可能會導致雲端帳戶成功遭到入侵。 篩選出可新增至受攻擊面的帳戶，以評估您的同步處理策略。

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

身分識別的存取不得超過身分識別存取的資源。 確定您在小組結構或軟體元件有所變更時，有停用或刪除身分識別的程式。

本指南適用于原始檔控制、資料、控制平面、工作負載使用者、基礎結構、工具、監視資料、記錄、計量和其他實體。

建立身分識別治理程式 ，以管理數位身分識別、高許可權使用者、外部/來賓使用者和工作負載使用者的生命週期。 實作存取權檢閱，以確保身分識別離開組織或小組時，會移除其工作負載許可權。

保護非實體型秘密

預先共用金鑰之類的應用程式秘密應該視為系統中易受攻擊點。 在雙向通訊中，如果提供者或取用者遭到入侵，可能會帶來重大的安全性風險。 這些金鑰也可能很麻煩，因為它們引進了作業程式。

您可以避免使用秘密， 並考慮使用身分識別型驗證來存取應用程式本身，而不只是使用其資源。

下列清單提供指引摘要。 如需詳細資訊，請參閱 應用程式秘密的建議。

  • 將這些秘密視為可從秘密存放區動態提取的實體。 它們不應該硬式編碼在您的應用程式程式碼、IaC 腳本、部署管線或任何其他成品中。

  • 請確定您能夠 撤銷秘密。

  • 套用處理 金鑰輪替和到期等工作的作業做法。

如需輪替原則的相關資訊，請參閱自動輪替具有兩組驗證認證的資源秘密和教學課程：以金鑰保存庫更新憑證自動輪替頻率。

保護開發環境安全

所有程式碼和腳本、管線工具和原始檔控制系統都應該視為工作負載資產。 應透過自動化和對等檢閱來限制寫入的存取權。 原始程式碼的讀取權限應該受限 于需要知道的角色。 程式碼存放庫必須具有版本控制，且對等 的安全性程式碼檢閱 必須是與開發生命週期整合的一般做法。 您必須具備 定期掃描資源的 程式，並識別最新的弱點。

使用工作負載身分識別來授與部署環境中的資源存取權，例如 GitHub。

維護稽核記錄

身分識別管理的一個層面是確保系統可稽核。 稽核會驗證假設缺口策略是否有效。 維護稽核記錄可協助您：

  • 確認已使用增強式驗證來驗證身分識別。 任何動作都必須可追蹤 ，以避免遭到否認性攻擊。

  • 偵測弱式或遺失的驗證通訊協定 ，並深入瞭解使用者和應用程式登入的深入解析。

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

  • 追蹤進度或與 合規性需求偏差。

大部分的資源都有資料平面存取權。 您必須知道存取資源的身分識別及其執行的動作。 您可以使用該資訊進行安全性診斷。

如需詳細資訊，請參閱 安全性監視和威脅分析的建議。

Azure 指導

建議您一律使用新式驗證通訊協定來考慮所有可用的資料點，並使用條件式存取。 Microsoft Entra識別碼會在 Azure 中提供身分識別和存取管理。 它涵蓋 Azure 的管理平面，並與大部分 Azure 服務的資料平面整合。 Microsoft Entra識別碼是與工作負載訂用帳戶相關聯的租使用者。 它會追蹤和管理身分識別及其允許的許可權，並簡化整體管理，以將監督或人為錯誤的風險降到最低。

這些功能原生整合至使用者區段的相同Microsoft Entra身分識別和許可權模型：

您可以使用Microsoft Entra識別碼，透過 Microsoft 驗證程式庫 (MSAL) 或平臺功能來驗證和授權自訂應用程式，例如 Web 應用程式的驗證。 它涵蓋 Azure 的管理平面、大部分 Azure 服務的資料平面，以及應用程式的整合功能。

您可以流覽Microsoft Entra識別碼的新功能，以保持最新狀態。

取捨：Microsof Microsoft Entra識別碼是單一失敗點，就像任何其他基礎服務一樣。 在 Microsoft 修正中斷之前，沒有任何因應措施。 不過，豐富的功能集Microsoft Entra超過使用自訂解決方案的風險。

Azure 支援開放通訊協定，例如 OAuth2 和 OpenID Connect。 建議您使用這些標準驗證和授權機制，而不是設計您自己的流程。

Azure RBAC

Azure RBAC 代表Microsoft Entra識別碼中的安全性主體。 所有角色指派都是透過 Azure RBAC 完成。 利用內建角色來提供您所需的大部分許可權。 如需詳細資訊，請參閱Microsoft Entra內建角色。

以下是一些使用案例：

如需 RBAC 的詳細資訊，請參閱 Azure RBAC 的最佳做法。

如需屬性型控制項的相關資訊，請參閱 什麼是 Azure ABAC？。

工作負載身分識別

Microsoft Entra識別碼可以處理應用程式的身分識別。 與應用程式相關聯的服務主體可以指定其存取範圍。

如需詳細資訊，請參閱 什麼是工作負載身分識別？。

當您使用受控識別時，服務主體也會抽象化。 優點是 Azure 會管理應用程式的所有認證。

並非所有服務都支援受控識別。 如果您無法使用受控識別，您可以使用服務主體。 不過，使用服務主體會增加管理額外負荷。 如需詳細資訊，請參閱什麼是適用於 Azure 資源的受控識別？。

資源身分識別

受控識別的概念可以延伸至 Azure 資源。 Azure 資源可以使用受控識別向支援Microsoft Entra驗證的其他服務驗證自己。 如需詳細資訊，請參閱 可使用受控識別來存取其他服務的 Azure 服務。

條件式存取原則

條件式存取會描述存取決策的原則 。 若要使用條件式存取，您必須瞭解使用案例所需的限制。 設定Microsoft Entra條件式存取，方法是根據您的作業需求設定其存取原則。

如需詳細資訊，請參閱 條件式存取：使用者、群組和工作負載身分識別。

群組存取管理

不要將許可權授與特定使用者，而是將存取權指派給Microsoft Entra識別碼中的群組。 如果群組不存在，請與您的身分識別小組合作來建立群組。 然後，您可以在 Azure 外部新增和移除群組成員，並確定許可權是最新的。 您也可以將群組用於其他用途，例如郵寄清單。

如需詳細資訊，請參閱在Microsoft Entra識別碼中使用群組來保護存取控制。

威脅偵測

Microsoft Entra ID Protection可協助您偵測、調查及補救以身分識別為基礎的風險。 如需詳細資訊，請參閱 什麼是 Identity Protection？。

威脅偵測可以採取回應可疑活動警示的形式，或主動搜尋活動記錄中的異常事件。 Microsoft Sentinel 中的使用者和實體行為分析 (UEBA) 可讓您輕鬆地偵測可疑的活動。 如需詳細資訊，請參閱 使用 UEBA 識別進階威脅。

混合式系統

在 Azure 上，請勿將帳戶同步處理至在現有 Active Directory 中具有高許可權的Microsoft Entra識別碼。 此同步處理會在預設Microsoft Entra Connect Sync 組態中遭到封鎖，因此您只需要確認您尚未自訂此設定。

如需Microsoft Entra識別碼中篩選的資訊，請參閱Microsoft Entra Connect Sync：設定篩選。

身分識別記錄

在 Azure 資源上啟用診斷設定 ，以發出您可以做為稽核線索的資訊。 診斷資訊會顯示哪些身分識別嘗試存取哪些資源和這些嘗試的結果。 收集的記錄會傳送至 Azure 監視器。

取捨：記錄會產生成本，因為用來儲存記錄的資料儲存體。 它也可能造成效能影響，特別是對程式碼和您新增至應用程式的記錄解決方案。

範例

下列範例顯示身分識別實作。 不同類型的身分識別會一起使用，以提供所需的存取層級。

顯示身分識別實作的圖表。

身分識別元件

  • 系統受控識別。 Microsoft Entra識別碼可讓您存取沒有面向使用者的服務資料平面，例如 Azure 金鑰保存庫和資料存放區。 這些身分識別也會控制透過 RBAC 存取工作負載元件、部署代理程式和小組成員的 Azure 管理平面。

  • 工作負載身分識別。 Azure Kubernetes Service (AKS) 叢集中的應用程式服務會使用工作負載身分識別向解決方案中的其他元件進行驗證。

  • 受控身分識別。 用戶端角色中的系統元件會使用系統受控識別，包括組建代理程式。

  • 人類身分識別。 使用者和操作員驗證會委派給Microsoft Entra識別碼或Microsoft Entra識別碼， (原生、B2B 或 B2C) 。

預先共用秘密的安全性對於任何應用程式而言都很重要。 Azure 金鑰保存庫提供這些秘密的安全儲存機制，包括 Redis 和協力廠商秘密。

輪替機制可用來協助確保秘密不會遭到入侵。 OAuth 2 和 OpenID Connect Microsoft 身分識別平臺實作的權杖可用來驗證使用者。

Azure 原則是用來確保金鑰保存庫等身分識別元件使用 RBAC，而不是存取原則。 JIT 和 JEA 可為人類操作員提供傳統的常設許可權。

透過Azure 診斷，或透過程式碼元件的程式碼，在所有元件上啟用存取記錄。

安全性檢查清單

請參閱一組完整的建議。

安全性檢查清單