Azure Key Vault 基本概念

Azure Key Vault 是個可安全儲存及存取祕密的雲端服務。 祕密是指任何您想要嚴密控制存取的項目,例如 API 金鑰、密碼、憑證或密碼編譯金鑰。 金鑰保存庫 服務支援兩種類型的容器:保存庫和受控硬體安全性模組(HSM) 集區。 保存庫支援儲存軟體和由 HSM 支援的金鑰、秘密和憑證。 受控 HSM 集區僅支援由 HSM 支援的金鑰。 如需完整詳細數據,請參閱 Azure 金鑰保存庫 REST API 概觀

以下是其他重要字詞:

  • 使用者:租用戶是擁有和管理 Microsoft 雲端服務特定實例的組織。 它最常用來指組織的 Azure 和 Microsoft 365 服務集合。

  • 保存庫擁有者:保存庫擁有者可以建立密鑰保存庫,並取得其完整存取和控制。 保存庫擁有者也可以設定稽核,以記錄誰存取秘密和金鑰。 系統管理員可以控制金鑰生命週期。 他們可以推出新版本的金鑰、備份金鑰,以及執行相關工作。

  • 保存庫取用者:當保存庫擁有者授與取用者存取權時,保存庫取用者可以在密鑰保存庫內的資產上執行動作。 可用的動作取決於授與的權限。

  • 受控 HSM 管理員 istrators:獲指派 管理員 istrator 角色的使用者可完全控制受控 HSM 集區。 他們可以建立更多角色指派,以將受控存取權委派給其他使用者。

  • 受控 HSM 密碼編譯官/使用者:通常指派給使用者或服務主體的內建角色,這些角色會使用受控 HSM 中的密鑰來執行密碼編譯作業。 加密使用者可以建立新的金鑰,但無法刪除金鑰。

  • 受控 HSM 加密服務加密使用者:通常指派給服務帳戶受控服務識別的內建角色(例如,儲存體 帳戶),以使用客戶管理的密鑰加密待用數據。

  • 資源:資源是可管理的專案,可透過 Azure 取得。 常見的範例包括虛擬機器、儲存體帳戶、Web 應用程式、資料庫和虛擬網路。 還有很多。

  • 資源群組:資源群組是保留 Azure 解決方案相關資源的容器。 該資源群組可包含解決方案的所有資源,或是只包含您想以群組方式管理的資源。 您可決定如何根據對組織最有利的方式,將資源配置到資源群組。

  • 安全性主體:Azure 安全性主體是使用者建立的應用程式、服務和自動化工具用來存取特定 Azure 資源的安全性身分識別。 將其視為具有特定角色的「使用者身分識別」(使用者名稱和密碼或憑證),並嚴格控制權限。 安全性主體應該只需要執行特定動作,不像一般使用者身分識別。 如果您只授與它執行其管理工作所需的最低權限等級,就可以提升安全性。 與應用程式或服務搭配使用的安全性主體稱為 服務主體

  • Microsoft Entra ID:Microsoft Entra ID 是租使用者的 Active Directory 服務。 每個目錄都有一或多個網域。 一個目錄可以有多個與其相關聯的訂用帳戶,但只能有一個租用戶。

  • Azure 租使用者標識碼:租使用者標識符是識別 Azure 訂用帳戶內 Microsoft Entra 實例的唯一方式。

  • 受控識別:Azure 金鑰保存庫 提供安全地儲存認證和其他密鑰和秘密的方式,但您的程式代碼必須驗證以 金鑰保存庫 擷取認證。 使用受控識別可透過給予 Azure 服務在 Microsoft Entra ID 中的自動受控識別,更輕鬆地解決此問題。 您可以使用此身分識別向 Key Vault 或任何支援 Microsoft Entra 驗證的服務進行驗證,而無須在程式碼中有任何認證。 如需詳細資訊,請參閱下圖和 Azure 資源的受控識別概觀。

驗證

若要對 Key Vault 執行任何作業,您必須先通過其驗證。 向 Key Vault 進行驗證的方式有三種:

  • Azure 資源受控識別:當您在 Azure 中將應用程式部署於虛擬機器時,您可以指派身分識別給可存取 Key Vault 的虛擬機器。 您也可以將身分識別指派給 其他 Azure 資源。 此方法的優點是應用程式或服務不必管理第一個祕密的輪替。 Azure 會自動輪替身分識別。 建議以此方法為最佳做法。
  • 服務主體和憑證:您可以使用可存取 Key Vault 的服務主體和相關聯的憑證。 不建議採用此方法,因為應用程式擁有者或開發人員必須輪替憑證。
  • 服務主體和祕密:雖然您可以使用服務主體和祕密向 Key Vault 驗證,但不建議這麼做。 用於向 Key Vault 驗證的啟動程序祕密,很難自動輪替。

傳輸中資料加密

Azure 金鑰保存庫 會強制執行傳輸層安全性 (TLS) 通訊協定,以在 Azure 金鑰保存庫與客戶端之間移動時保護數據。 用戶端會與 Azure Key Vault 交涉 TLS 連線。 TLS 支援增強式驗證、訊息隱私權、完整性 (可偵測訊息竄改、攔截和偽造)、互通性、演算法彈性,以及輕鬆部署和使用。

完美轉寄保密 (PFS) 可透過唯一金鑰保護客戶客戶端系統與 Microsoft 雲端服務之間的連線。 連線也採用 RSA 型 2,048 位元加密金鑰長度。 此組合讓人難以攔截和存取傳輸中的資料。

Key Vault 角色

使用下表來進一步瞭解 Key Vault 如何協助滿足開發人員和安全性系統管理員的需求。

角色 問題說明 由 Azure 金鑰保存庫 解決
Azure 應用程式的開發人員 「我想為 Azure 撰寫使用金鑰進行簽署和加密的應用程式。 但我希望這些金鑰是來自我的應用程式外部,讓解決方案適用於地理位置分散的應用程式。

我希望這些密鑰和秘密受到保護,而不需要自行撰寫程式代碼。 我也希望這些金鑰和秘密能夠輕鬆地從應用程式使用,並獲得最佳效能。
√金鑰會儲存在保存庫中,並視需要由 URI 叫用。

azure 會使用業界標準演算法、金鑰長度和硬體安全性模組來保護√密鑰。

√金鑰會在與應用程式位於相同 Azure 資料中心的 HSM 中處理。 這個方法提供比位於不同位置的密鑰更好的可靠性和降低延遲,例如內部部署。
軟體即服務開發人員 (SaaS) 「我不希望客戶租使用者密鑰和秘密的責任或潛在責任。

我希望客戶擁有和管理他們的密鑰,以便我可以專注於盡我最大的努力,這是提供核心軟體功能。
√客戶可以將自己的密鑰匯入 Azure,並加以管理。 當 SaaS 應用程式需要使用客戶的金鑰來執行密碼編譯作業時,金鑰保存庫 代表應用程式執行這些作業。 應用程式看不到客戶的金鑰。
首席安全官(CSO) 「我想知道我們的應用程式符合 FIPS 140 層級 3 HSM 以進行安全密鑰管理。

我想要確保我的組織能夠控制密鑰生命週期,並可監視密鑰使用狀況。

雖然我們使用多個 Azure 服務和資源,但我想從 Azure 中的單一位置管理密鑰。
√針對已驗證的 FIPS 140 HSM 選擇保存庫或受控 HSM
√為 FIPS 140-2 層級 3 驗證的 HSM 選擇 受控 HSM 集 區。

√ 金鑰保存庫的設計目的是讓 Microsoft 看不到或擷取您的密鑰。
√金鑰使用方式會近乎即時地記錄。

√保存庫提供單一介面,不論您在 Azure 中有多少保存庫、支援哪些區域,以及哪些應用程式都使用這些保存庫。

任何具有 Azure 訂用帳戶的人都可以建立和使用金鑰保存庫。 雖然 Key Vault 可讓開發人員和安全性系統管理員受益,但它可由管理其他 Azure 服務的組織的系統管理員實作和管理。 例如,此系統管理員可以使用 Azure 訂用帳戶登入、建立保存庫以讓組織在其中儲存金鑰,然後負責這類作業工作:

  • 建立或匯入金鑰或秘密
  • 撤銷或刪除金鑰或秘密
  • 授權使用者或應用程式存取金鑰保存庫,以便他們可管理或使用其金鑰和秘密
  • 設定金鑰使用方式 (例如,簽署或加密)
  • 監視金鑰使用方式

此系統管理員之後會提供開發人員 URI,以從其應用程式呼叫。 此系統管理員也會將金鑰使用方式記錄資訊提供給安全性系統管理員。

Overview of how Azure Key Vault works

開發人員也可以使用 API 直接管理金鑰。 如需詳細資訊,請參閱 金鑰保存庫 開發人員指南

下一步

Azure 金鑰保存庫 可在大部分區域中使用。 如需詳細資訊,請參閱 金鑰保存庫 定價頁面