Azure Key Vault 安全性

發行項
03/11/2024

Azure Key Vault 會保護密碼編譯金鑰、憑證 (以及與憑證相關聯的私密金鑰)，以及雲端中的祕密 (例如連接字串和密碼)。不過，在儲存敏感性與業務關鍵資料時，您必須採取步驟，以最大化保存庫的安全性以及儲存在其中的資料。

此文章提供 Azure Key Vault 的安全性功能和最佳做法概觀。

注意

如需 Azure Key Vault 安全性建議的完整清單，請參閱 Azure Key Vault 的安全性基準。

網路安全性

您可以透過指定可以存取保存庫的 IP 位址，降低保存庫的暴露程度。 Azure Key Vault 的虛擬網路服務端點可讓您將存取權限制為指定的虛擬網路。這些端點也可讓您將存取權限制為 IPv4 清單 (網際網路通訊協定第 4 版) 上的位址範圍。從這些資源以外連線至您金鑰保存庫的任何使用者存取會遭到拒絕。如需完整詳細資料，請參閱 Azure Key Vault 的虛擬網路服務端點

防火牆規則生效後，使用者只能在其要求源自允許的虛擬網路或 IPv4 位址範圍時，才可以讀取 Key Vault 中的資料。這也適用於從 Azure 入口網站存取 Key Vault。儘管使用者可以從 Azure 入口網站瀏覽至金鑰保存庫，若他們的用戶端機器不在允許清單中，就可能無法列出金鑰、祕密或憑證。如需實作步驟，請參閱設定 Azure Key Vault 防火牆和虛擬網路

Azure Private Link 服務可讓您透過虛擬網路中的私人端點，存取各項 Azure Key Vault 以及 Azure 託管的客戶/合作夥伴服務。 Azure 私人端點是一種網路介面，可讓您私密安全地連線至 Azure Private Link 所提供的服務。私人端點會使用您 VNet 中的私人 IP 位址，有效地將服務帶入您的 VNet 中。服務的所有流量都可以透過私人端點路由傳送，因此不需要閘道、NAT 裝置、ExpressRoute 或 VPN 連線或公用 IP 位址。虛擬網路和服務間的流量會在通過 Microsoft 骨幹網路時隨之減少，降低資料在網際網路中公開的風險。您可以連線至 Azure 資源的執行個體，以提供您存取控制中最高層級的細微性。如需實作步驟，請參閱整合 Key Vault 與 Azure Private Link

TLS 和 HTTPS

Key Vault 前端 (資料平面) 是多租用戶伺服器。這表示來自不同客戶的金鑰保存庫可以共用相同的公用 IP 位址。為了達成隔離，每個 HTTP 要求都會與其他要求分開進行驗證和授權。
HTTPS 通訊協定可讓用戶端參與 TLS 交涉。 用戶端可以強制執行 TLS 版本，而且每當用戶端執行此動作時，整個連線都將使用對應的層級保護。 Key Vault 支援 TLS 1.2 和 1.3 通訊協定版本。

注意

您可使用這裡的範例 Kusto 查詢來監視 Key Vault 記錄，以監視用戶端使用的 TLS 版本。

Key Vault 驗證選項

當您在 Azure 訂用帳戶中建立金鑰保存庫時，它將自動與該訂用帳戶的 Microsoft Entra 租用戶建立關聯。兩個平面中的所有呼叫者必須在此租用戶中註冊並驗證，以存取金鑰保存庫。在這兩種情況下，應用程式都可以透過三種方式存取 Key Vault：

僅限應用程式：應用程式代表服務主體或受控識別。對於定期需要從金鑰保存庫存取憑證、金鑰或祕密的應用程式，此身分識別是最常見的案例。若要讓此案例正常運作，必須在存取原則中指定應用程式的 objectId，而且「不得」指定 applicationId，或者必須是 null。
僅限使用者：使用者會從已在租用戶中註冊的任何應用程式存取金鑰保存庫。這種類型的存取範例包括 Azure PowerShell 和 Azure 入口網站。若要讓此案例正常運作，必須在存取原則中指定使用者的 objectId，而且「不得」指定 applicationId，或者必須是 null。
應用程式加使用者 (有時稱為「複合身分識別」)：使用者必須從特定的應用程式存取金鑰保存庫，「而且」應用程式必須使用代理者驗證 (OBO) 流程來模擬使用者。若要讓此案例正常運作，必須在存取原則中指定 applicationId 和 objectId。 applicationId 會識別所需的應用程式，而 objectId 會識別使用者。目前，此選項不適用於資料平面 Azure RBAC。

在所有類型的存取中，應用程式會使用 Microsoft Entra ID 進行驗證。應用程式會根據應用程式類型使用任何支援的驗證方法。應用程式會取得平面中資源的權杖，以授與存取權。資源是管理或資料平面中以 Azure 環境為基礎的端點。應用程式會使用此權杖，對 Key Vault 傳送 REST API 要求。若要深入了解，請參閱整個驗證流程。

這兩個平面的單一驗證機制模型有幾個優點：

組織可以集中控制其組織中所有金鑰保存庫的存取權。
如果使用者離開，他們就會立即失去組織中所有金鑰保存庫的存取權。
組織可以藉由使用 Microsoft Entra ID 中的選項來自訂驗證，例如啟用多重要素驗證以提升安全性。

如需詳細資訊，請參閱 Key Vault 驗證基礎。

存取模型概觀

金鑰保存庫的存取權可透過兩個介面來控制︰管理平面和資料平面。管理平面是您管理 Key Vault 的位置。此平面中的作業包括建立和刪除金鑰保存庫、擷取 Key Vault 屬性，以及更新存取原則。資料平面是您處理儲存在金鑰保存庫中資料的位置。您可以新增、刪除和修改金鑰、祕密和憑證。

這兩個平面都使用 Microsoft Entra ID 進行驗證。針對授權，管理平面會使用 Azure 角色型存取控制 (Azure RBAC)，而資料平面會使用 Key Vault 存取原則和 Azure RBAC 來進行 Key Vault 資料平面作業。

若要在任一平面中存取金鑰保存庫，所有呼叫者 (使用者或應用程式) 都必須具有適當的驗證和授權。驗證是建立呼叫者的身分識別。授權會決定呼叫者可執行哪些作業。使用 Key Vault 進行驗證時，會與 Microsoft Entra ID 搭配使用，其會負責驗證任何指定安全性主體的身分識別。

安全性主體是物件，代表要求存取 Azure 資源的使用者、群組、服務或應用程式。 Azure 會為每個安全性主體指派唯一的物件識別碼。

使用者安全性主體會識別在 Microsoft Entra ID 中具有設定檔的個人。
群組安全性主體會識別在 Microsoft Entra ID 中建立的一組使用者。指派給群組的任何角色或權限都會授與群組內的所有使用者。
服務主體是一種安全性主體，會識別應用程式或服務 (也就是一段程式碼，而不是使用者或群組)。服務主體的物件識別碼稱為其用戶端識別碼，作用就像其使用者名稱。服務主體的用戶端密碼或憑證作用就像其密碼。許多 Azure 服務都支援使用用戶端識別碼和憑證的自動化管理來指派受控識別。受控識別是在 Azure 內進行驗證最安全且最建議的選項。

如需向 Key Vault 驗證的詳細資訊，請參閱向 Azure Key Vault 驗證。

條件式存取

金鑰保存庫提供對 Microsoft Entra 條件式存取原則的支援。藉由使用條件式存取原則，您可以在需要時套用對 Key Vault 的正確存取控制，以確保組織處於安全狀態，並在不需要時阻擋使用者的存取。

如需詳細資訊，請參閱條件式存取概觀

特殊權限存取

授權會決定呼叫者可執行哪些作業。 Key Vault 中的授權會在管理平面上使用 Azure 角色型存取控制 (Azure RBAC)，以及在資料平面上使用 Azure RBAC 或 Azure Key Vault 存取原則。

保存庫的存取會透過兩個介面或平面進行。這些平面包括管理平面和資料平面。

管理平面是您管理 Key Vault 本身的位置，而且這是用來建立和刪除保存庫的介面。您也可以讀取 Key Vault 屬性並管理存取原則。
資料平面可讓您處理金鑰保存庫中儲存的資料。您可以新增、刪除和修改金鑰、祕密和憑證。

應用程式會透過端點存取平面。這兩個平面的存取控制可獨立運作。若要對應用程式授與使用金鑰保存庫中金鑰的存取權，您可以使用 Azure RBAC 或 Key Vault 存取原則來對資料平面授與存取權。若要對使用者授與讀取 Key Vault 屬性和標籤的存取權，但不授與讀取資料 (金鑰、祕密或憑證) 的存取權，您可以使用 Azure RBAC 來對管理平面授與存取權。

下表顯示管理和資料平面的端點。

存取平面	存取端點	Operations	存取控制機制
管理平面	全域： management.azure.com:443 由 21Vianet 營運的 Microsoft Azure： management.chinacloudapi.cn:443 Azure US Gov︰ management.usgovcloudapi.net:443 Azure 德國︰ management.microsoftazure.de:443	建立、讀取、更新及刪除金鑰保存庫設定 Key Vault 存取原則設定 Key Vault 標籤	Azure RBAC
資料平面	全域： <vault-name>.vault.azure.net:443 由 21Vianet 營運的 Microsoft Azure： <vault-name>.vault.azure.cn:443 Azure US Gov︰ <vault-name>.vault.usgovcloudapi.net:443 Azure 德國︰ <vault-name>.vault.microsoftazure.de:443	金鑰：encrypt、decrypt、wrapKey、unwrapKey、sign、verify、get、list、create、update、import、delete、recover、backup、restore、purge、rotate (預覽)、getrotationpolicy (預覽)、setrotationpolicy (預覽)、release (預覽) 憑證：managecontacts、getissuers、listissuers、setissuers、deleteissuers、manageissuers、get、list、create、import、update、delete、recover、backup、restore、purge 祕密：get、list、set、delete、recover、backup、restore、purge	Key Vault 存取原則或 Azure RBAC

管理 Key Vault 的系統管理存取權

當您在資源群組中建立金鑰保存庫時，您可以使用 Microsoft Entra ID 來管理存取權。您可以授與使用者或群組管理資源群組中金鑰保存庫的能力。您可以指派適當的 Azure 角色，以授與特定範圍層級的存取權。若要對使用者授與管理金鑰保存庫的權限，您可以在特定範圍對使用者指派預先定義的 key vault Contributor 角色。下列範圍層級可以指派給 Azure 角色：

訂用帳戶：在訂用帳戶層級指派的 Azure 角色，會套用至該訂用帳戶內的所有資源群組和資源。
資源群組：在資源群組層級指派的 Azure 角色，會套用至該資源群組內的所有資源。
特定資源：針對特定資源指派的 Azure 角色，會套用至該資源。在此情況下，資源是特定的金鑰保存庫。

有數個預先定義的角色。如果預先定義的角色不符合您的需求，您可以定義您自己的角色。如需詳細資訊，請參閱 Azure RBAC：內建角色。

重要

使用存取原則權限模型時，如果使用者具有金鑰保存庫管理平面的 Contributor 權限，就可以透過設定 Key Vault 存取原則，對自己授與資料平面的存取權。您應該嚴格控制對具有存取原則權限模型的金鑰保存庫擁有「Contributor」角色的人員，以確保只有獲得授權的人員可以存取和管理您的金鑰保存庫、金鑰、密碼和憑證。建議您使用新的角色型存取控制 (RBAC) 權限模型，以避免此問題。使用 RBAC 權限模型時，權限管理僅限於「擁有者」和「使用者存取管理員」角色，這允許在安全性作業與一般管理作業的角色之間區分職責。

控制對 Key Vault 資料的存取

您可以使用 Azure RBAC 或 Key Vault 存取原則來控制對 Key Vault 金鑰、憑證和祕密的存取。

如需更多資訊，請參閱

記錄和監視

Key Vault 記錄會儲存在保存庫上執行之活動的相關資訊。如需完整的詳細資料，請參閱 Key Vault 記錄。

您可以將 Key Vault 與事件方格整合，以便在金鑰保存庫中儲存的金鑰、憑證或祕密狀態變更時收到通知。如需詳細資料，請參閱使用 Azure 事件方格監視 Key Vault

也請務必監視金鑰保存庫的健康情況，以確保您的服務會如預期般運作。若要了解如何執行此作業，請參閱 Azure Key Vault 的監視和警示。

備份及復原

Azure Key Vault 虛刪除和清除保護可讓您復原已刪除的保存庫和保存庫物件。如需完整的詳細資料，請參閱 Azure Key Vault 虛刪除概觀。

您也應該在更新/刪除/建立保存庫中的物件時，定期備份保存庫。