要了解 Azure 資源提供者如何實作靜態加密，你需要了解不同的加密模型及其優缺點。 為了確保語言與分類法一致，Azure 資源提供者會共享這些定義。
Azure 預設會使用平台管理的金鑰來加密靜態資料。 您可以根據自身的安全與合規需求，選擇其他金鑰管理方式。 伺服器端加密包含三種情境：
伺服器端加密，使用平台管理金鑰（預設）。
- Azure 資源提供者負責加密與解密操作。
- Microsoft 會自動管理這些金鑰。
- 預設啟用，無需設定。
- 完整的雲端功能。
伺服器端加密，使用Azure Key Vault中客戶管理的金鑰（可選）。
- Azure 資源提供者負責加密與解密操作。
- 你透過 Azure Key Vault 來控制金鑰。
- 需要客戶設定與管理。
- 完整的雲端功能。
伺服器端加密，透過客戶管理的金鑰在客戶控制的硬體上進行（進階選項）。
- Azure 資源提供者負責加密與解密操作。
- 您可在客戶自行控管的硬體上管理金鑰。
- 複雜的設定與有限的 Azure 服務支援。
- 完整的雲端功能。
伺服器端加密模型指的是 Azure 服務所執行的加密。 在此模型中，資源提供者負責加密與解密操作。 例如，Azure 儲存體可能會以純文字形式接收資料操作，並在內部執行加密與解密。 資源提供者可能會使用由 Microsoft 或客戶管理的加密金鑰，視你的設定而定。
每種伺服器端靜態加密模型在金鑰管理上都有獨特的特性。 這些特性包括你在哪裡以及如何建立和儲存加密金鑰，以及存取模型和金鑰輪替程序。
針對用戶端加密，請考慮：
- Azure 服務無法看到解密的資料。
- 客戶在內部部署環境 (或其他安全的儲存區中) 管理或儲存金鑰。 Azure 服務無法存取金鑰。
- 雲端功能減少。
Azure 支援的加密模型主要分為兩大類：用戶端加密與伺服器端加密。 不論你使用哪種靜態加密模型，Azure 服務總是建議使用安全傳輸方式，例如 TLS 或 HTTPS。 因此，傳輸中的位址加密是透過傳輸協定進行的。 它不應該成為決定採用哪種靜態加密模型的主要因素。
用戶端加密模型
用戶端加密模型指的是服務或呼叫應用程式在資源提供者或 Azure 外部執行的加密。 Azure 中的服務應用程式或在客戶資料中心執行的應用程式可以執行加密。 無論哪種情況，當你使用這種加密模型時，Azure 資源提供者會收到一個加密的資料塊，卻無法以任何方式解密或存取加密金鑰。 在此模型中，呼叫服務或應用程式負責金鑰管理，並保持對 Azure 服務的不透明性。
伺服器端加密，使用平台管理金鑰（預設）
對大多數組織來說，最重要的要求是確保資料在靜態時都被加密。 伺服器端加密使用平台管理金鑰（過去稱為服務管理金鑰）預設提供自動加密，滿足此需求。 這種方式允許靜態加密，無需你設定或管理加密金鑰。 Microsoft 負責金鑰管理任務，如金鑰的發行、輪替與備份。
大多數 Azure 服務將此模型作為預設行為，透過平台管理的金鑰自動加密靜態資料，無需客戶操作。 Azure 資源提供者會建立金鑰、將其存放於安全的儲存體中，並在需要時加以擷取。 該服務擁有對金鑰的完整存取權，並對憑證生命週期管理保持完全控制權。 此控制提供強大的加密保護，且無管理負擔。
伺服器端加密透過平台管理金鑰解決靜態加密需求，且無額外負擔。 Azure 預設在 Azure 服務間啟用此加密，提供自動資料保護，無需任何設定或管理。 您將資料儲存在 Azure 服務中時，立即享有強大的加密保護，無需額外步驟、成本或持續管理。
使用平台管理金鑰進行伺服器端加密，意味著服務擁有完整存取權來儲存和管理金鑰。 雖然有些組織可能希望管理金鑰，因為他們期望更高的安全性，但在評估此模式時，請考慮客製化金鑰儲存解決方案所帶來的成本與風險。 在許多情況下，組織可能會判斷本地部署解決方案的資源限制或風險，比雲端管理靜態加密金鑰的風險更大。 然而，對於需要控制加密金鑰的建立或生命週期，或需要不同人員管理服務加密金鑰（將金鑰管理與整體管理模式分離）的組織來說，這種模型可能不足以應對。
金鑰存取權
當你使用伺服器端加密並使用平台管理的金鑰時，服務會處理金鑰的建立、儲存和服務存取。 通常，基礎的 Azure 資源提供者會將資料加密金鑰存放在靠近資料且可快速存取的儲存庫中，而金鑰加密金鑰則存放在安全的內部儲存庫中。
優勢
- 簡單的設定。
- Microsoft 負責管理金鑰輪換、備份與冗餘。
- 實施自訂金鑰管理方案不會產生成本或風險。
考量
- 無法控制加密金鑰（金鑰指定、生命週期、撤銷等）。 此選項適用於大多數使用情境，但可能無法符合專業的合規要求。
- 無法將金鑰管理與整體服務管理模式分離。 需要職責分離的組織可能需要由客戶管理的金鑰。
使用 Azure Key Vault 和 Azure Key Vault Managed HSM 中客戶管理的金鑰進行伺服器端加密（選用）
對於組織有特定需求控制其加密金鑰（超出預設平台管理加密）的情況，你可以選擇使用客戶管理的 金鑰保存庫 或 Azure Key Vault Managed HSM 中的伺服器端加密。 這種方法建立在預設靜態加密之上，讓你能使用自己的金鑰，而 Azure 則繼續處理加密與解密操作。
有些服務可能只將根金鑰加密金鑰（KEK）儲存在 Azure Key Vault，並將加密資料加密金鑰（DEK）存放在更靠近資料的內部位置。 在這種情況下，你可以使用自帶金鑰（BYOK）模型將金鑰匯入 金鑰保存庫，或在 金鑰保存庫 中產生新金鑰，然後用它們來加密所需的資源。 當資源提供者執行加密與解密操作時，所有加密操作的根金鑰會使用你設定的 KEK。
金鑰加密金鑰一旦遺失，即代表資料將無法存取。 因此，不要刪除金鑰。 在建立或輪替金鑰時，務必備份金鑰。 當 KEK 被旋轉時，服務會將資料加密金鑰包裝成新的金鑰版本——底層資料不會被重新加密。 舊金鑰版本與新金鑰版本都必須保持啟用狀態，直到所有資料加密金鑰都被新金鑰版本封裝。 為防止意外或惡意的密碼學刪除，必須在存放金鑰加密金鑰的保險庫啟用 軟刪除與清除保護 。 請勿刪除金鑰，應將金鑰加密密鑰的 enabled 設置為 false。 使用訪問控制來撤銷 對 Azure Key Vault 或 受控 HSM 中個別用戶或服務的存取權。
警告
如果你懷疑某個金鑰被入侵，不要立刻停用或刪除它。 停用或刪除金鑰會讓所有相依服務離線，但不會使備份並還原到另一個保險庫的金鑰副本失效。 這些副本仍然完全可用。 相反地，先輪換到新的金鑰，並在停用被入侵的金鑰前，遷移所有相依服務。 完整的事件回應程序，請參閱 備份安全考量 與 金鑰入侵回應。
對於客戶管理的金鑰情境，請使用 Azure Key Vault Premium tier（HSM 支援）作為合規要求的最低標準，該要求必須使用 HSM 保護的金鑰。 對於需要金鑰主權或專用 HSM 容量的工作負載，請使用 Azure Key Vault 管理式 HSM。 對於有法規或合約要求金鑰資料必須實體存放於 Microsoft 基礎架構之外的組織，Azure Key Vault Managed HSM 也支援外部金鑰管理（預覽版），將 KEK 完全置於客戶操作的 HSM，且完全置於 Azure 之外。
附註
關於支援 Azure Key Vault 及 Azure Key Vault Managed HSM 中客戶管理金鑰的服務列表，請參見 Services that support CMKs in Azure Key Vault 及 Azure Key Vault Managed HSM。
金鑰存取權
在使用客戶管理金鑰Azure Key Vault的伺服器端加密模型中，服務會存取金鑰以根據需要進行加密與解密。 你透過存取控制政策讓靜止加密金鑰能被服務存取。 此原則會授與服務身分存取權限，以取得金鑰。 您可以將代表關聯訂用帳戶執行的 Azure 服務，設定為使用該訂用帳戶中的身分。 該服務可以執行 Microsoft Entra 驗證，並取得驗證權杖，以識別其為代表該訂用帳戶執行的該服務本身。 服務會將令牌交給 金鑰保存庫，以取得可存取的金鑰。
對於使用加密金鑰的操作，你可以授予服務身份對以下任一操作的存取權限：decrypt、encrypt、unwrapKey、 wrapKeyverifysigngetlistupdatecreateimportdeletebackuprestore。
為了取得用於加密或解密靜態資料的金鑰，Resource Manager 服務實例執行的服務身份必須具備UnwrapKey（以取得解密金鑰）以及WrapKey（在建立新金鑰時插入金鑰至 金鑰保存庫）。
附註
欲了解更多關於 金鑰保存庫 授權的資訊，請參閱「Secure your key vault」。
優勢
- 完全掌控所使用的按鍵。 加密金鑰由你控制的 金鑰保存庫 管理。
- 你可以用一把根金鑰加密多個服務。
- 你可以將金鑰管理與整體服務管理模式分離。
- 你可以定義跨區域的服務與金鑰位置。
弊
- 你對金鑰存取管理負有全部責任。
- 你對金鑰生命週期管理負有全部責任。
- 額外的設置和配置負擔。
在由客戶控制的硬體中使用客戶管理的金鑰進行伺服器端加密（特殊選項）
部分 Azure 服務為具備特殊安全需求的組織，支援「Host Your Own Key」（HYOK）金鑰管理模型。 此管理模式適用於高度管制的情境，需加密靜態資料及在完全不受 Microsoft 控制的專有資料庫中進行金鑰管理。 它超越了 Azure Key Vault 中預設的平台管理加密和可選的客戶管理金鑰。
在此模式下，服務必須使用外部站點的金鑰來解密 DEK。 效能與可用性保證受到影響，且配置也變得更加複雜。 此外，由於服務在加密與解密操作中無法存取 DEK，因此此模型的整體安全保障與 Azure Key Vault 中由客戶管理金鑰時相似。 因此，除非組織有非常特定的法規或安全需求，無法透過平台管理的金鑰或客戶管理的 Azure Key Vault 金鑰來滿足，否則這種模式並不適合大多數組織。 由於這些限制，大多數 Azure 服務不支援伺服器端加密，透過客戶管理的金鑰在客戶控制的硬體中進行加密。 雙重金鑰加密中的兩把金鑰之一遵循此模型。
金鑰存取權
當你在客戶控制的硬體中使用伺服器端加密並使用客戶管理的金鑰時，你會將金鑰加密金鑰保存在你設定的系統中。 支援此模型的 Azure 服務提供一種方式，建立與客戶提供的金鑰庫的安全連線。
優勢
- 你對根金鑰有完全控制權，因為加密金鑰是由客戶提供的商店管理。
- 你可以用一把根金鑰加密多個服務。
- 你可以將金鑰管理與整體服務管理模式分離。
- 你可以定義跨區域的服務與金鑰位置。
弊
- 你對金鑰儲存、安全性、效能和可用性負有全部責任。
- 你對金鑰存取管理負有全部責任。
- 你對金鑰生命週期管理負有全部責任。
- 您將產生大量的設置、設定及持續維護費用。
- 此模型增加了客戶資料中心與 Azure 資料中心間對網路可用性的依賴。