共用方式為


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

適用於此 Azure 架構完善的架構安全性檢查清單建議:

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

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

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

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

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

  • Anonymous。 尚未提供其身分的任何證據的實體。

定義 

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

注意

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

識別提供者的角色

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

利用受信任 IdP 提供的功能,以進行身分識別和存取管理。 請勿實作自定義系統來取代IdP。 IdP 系統會根據最新的攻擊向量,每天在多個租用戶之間擷取數十億個訊號,經常改善。 Microsoft Entra ID 是 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 ID。 如需詳細資訊,請參閱 本文的 Azure 便利化一節

保護重大影響帳戶

系統管理身分識別引進了一些影響最高的安全性風險,因為其執行的工作需要對這些系統和應用程式進行特殊許可權存取。 入侵或誤用可能對您的業務及其信息系統造成有害影響。 系統管理的安全性是最重要的安全性領域之一。

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

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

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

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

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

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

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

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

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

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

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

本指南適用於原始檔控制、數據、控制平面、工作負載用戶、基礎結構、工具、監視數據、記錄、計量和其他實體。

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

保護非標識符型秘密

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

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

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

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

  • 請確定您能夠 撤銷秘密

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

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

保護開發環境安全

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

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

維護稽核記錄

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

  • 確認已使用強身份驗證來驗證身分識別。 任何動作都必須可 追蹤,以防止否認性攻擊。

  • 偵測弱式或遺失的驗證通訊協定 ,並取得使用者和應用程式登入的可見度和見解。

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

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

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

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

Azure 便利化

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

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

您可以透過 Microsoft 驗證連結庫 (MSAL) 或平臺功能,使用 Microsoft Entra 識別碼進行自定義應用程式的驗證和授權,例如 Web 應用程式的驗證。 其涵蓋 Azure 的管理平面、大部分 Azure 服務的數據平面,以及應用程式的整合功能。

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

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

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

Azure RBAC

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

以下是一些使用案例:

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

如需屬性型控件的相關信息,請參閱 什麼是 Azure ABAC?

工作負載身分識別

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

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

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

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

資源身分識別

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

條件式存取原則

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

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

群組存取管理

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

如需詳細資訊,請參閱 在 entra ID 中使用 Microsoft群組保護訪問控制。

威脅偵測

Microsoft Entra ID Protection 可協助您偵測、調查及補救身分識別型風險。 如需詳細資訊,請參閱 什麼是 Identity Protection?

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

混合式系統

在 Azure 上, 請勿將帳戶同步處理至在現有 Active Directory 中具有高許可權Microsoft Entra 標識符。 此同步處理在預設Microsoft Entra Connect 同步設定中遭到封鎖,因此您只需要確認您尚未自定義此設定。

如需Microsoft Entra標識符中篩選的資訊,請參閱 Microsoft Entra Connect Sync:設定篩選

身分識別記錄

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

捨:記錄會產生成本,因為用來儲存記錄的數據記憶體。 它也可能會對效能造成影響,特別是在程式碼和您新增至應用程式的記錄解決方案上。

範例

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

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

身分識別元件

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

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

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

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

預先共用秘密的安全性對於任何應用程式都很重要。 Azure 金鑰保存庫 為這些秘密提供安全儲存機制,包括 Redis 和第三方秘密。

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

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

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

安全性檢查清單

請參閱一組完整的建議。