資料加密模型
若要了解 Azure 中的各種資源提供者如何實作待用加密，就務必了解各種加密模式及其優缺點。 這些定義會跨 Azure 中的所有資源提供者進行共用，以確保為通用的語言和分類法。
伺服器端加密有三種情節：
使用服務管理之金鑰的伺服器端加密
- Azure 資源提供者執行加密和解密作業
- Microsoft 管理金鑰
- 完整的雲端功能
在 Azure Key Vault 中使用客戶管理金鑰的伺服器端加密
- Azure 資源提供者執行加密和解密作業
- 客戶透過 Azure Key Vault 控制金鑰
- 完整的雲端功能
在客戶控制的硬體上使用客戶管理金鑰的伺服器端加密
- Azure 資源提供者執行加密和解密作業
- 客戶在客戶控制的硬體上控制金鑰
- 完整的雲端功能
伺服器端加密模型是指 Azure 服務所執行的加密。 在這個模型中，資源提供者會執行加密和解密作業。 例如，Azure 儲存體可能會在純文字作業中接收資料，並在內部執行加密和解密。 資源提供者可能會使用由 Microsoft 或客戶管理的加密金鑰，根據提供的設定而定。
每個伺服器端靜態加密模型都表示金鑰管理的特殊特性。 這包括加密金鑰所建立及儲存的位置和方式，以及存取模型和金鑰輪替程序。
針對用戶端加密，請考慮下列各項：
- Azure 服務無法查看解密的資料
- 客戶在內部部署環境 (或其他安全的儲存區中) 管理或儲存金鑰。 金鑰無法供 Azure 服務使用
- 縮減的雲端功能
Azure 中支援的模型如先前所述區分成兩個主要群組：「用戶端加密」和「伺服器端加密」。 除了所使用的加密靜態模型之外，Azure 服務一律建議使用諸如 TLS 或 HTTPS 等安全的傳輸。 因此，傳輸中的加密應該由傳輸通訊協定來處理，且不應作為要使用哪個靜態加密模型的主要判斷因素。
用戶端加密模型
用戶端加密模型是指由服務或呼叫應用程式在資源提供者或 Azure 外部執行的加密。 加密可由 Azure 中的服務應用程式或客戶資料中心內執行的應用程式執行。 在任一案例中，利用此加密模型時，Azure 資源提供者無需以任何方式解密的能力或具有加密金鑰的存取權，即可接收加密的 blob 資料。 在此模型中，金鑰管理是由呼叫服務/應用程式所完成，且對 Azure 服務不透明。
使用服務管理金鑰的伺服器端加密
對許多客戶而言，基本需求就是確保在靜態時會將資料加密。 使用服務管理之金鑰的伺服器端加密會啟用這個模型，方法是允許客戶標示特定的資源 (儲存體帳戶、SQL DB 等) 以進行加密，並將諸如金鑰發佈、輪替和備份等所有金鑰管理層面保留給 Microsoft。 大部分支援靜態加密的 Azure 服務通常會支援這個將加密金鑰管理卸載至 Azure 的模型。 Azure 資源提供者會建立金鑰、將其放置在安全的儲存體，並在需要時加以擷取。 這表示服務具有金鑰的完整存取權，且服務可完整控制認證生命週期管理。
使用服務管理之金鑰的伺服器端加密因此能快速解決靜態加密的需求，並為客戶提供低額外負荷。 情況允許時，客戶通常會開啟目標訂用帳戶和資源提供者的 Azure 入口網站，並勾選方塊以指示要加密資料。 在部分 Resource Manager 中，使用服務管理金鑰的伺服器端加密預設為開啟。
搭配 Microsoft 管理之金鑰的伺服器端加密確實表示服務具有儲存及管理金鑰的完整存取權。 雖然部分客戶會因為認為可獲得更高的安全性而要管理金鑰，但在評估此模型時，應該考慮自訂金鑰儲存解決方案的相關成本和風險。 在許多情況下，組織可能會判斷資源限制或內部部署解決方案的風險可能會大於在雲端管理靜態加密金鑰的風險。 不過，對於需要控制加密金鑰的建立或生命週期，或是使用與管理服務不同的人員來管理服務的加密金鑰 (也就是說，將金鑰管理與服務的整體管理模型隔離) 的組織而言，此模型可能並不足夠。
金鑰存取權
使用具服務管理之金鑰的伺服器端加密時，金鑰建立、儲存和存取服務都是由服務所管理。 一般而言，基本的 Azure 資源提供者會將資料加密金鑰儲存在接近資料、快速可用且可存取的儲存區中，而金鑰加密金鑰則是儲存在安全的內部儲存區中。
優點
- 簡單設定
- Microsoft 會管理金鑰輪替、備份與備援
- 客戶沒有與實作相關聯的成本，或自訂金鑰管理配置的風險。
缺點
- 沒有加密金鑰 (金鑰規格、生命週期、撤銷等) 的客戶控制權
- 無法從服務的整體管理模型將金鑰管理隔離
在 Azure Key Vault 中使用客戶管理金鑰的伺服器端加密
在需要將待用資料加密並控制加密金鑰的情節中，客戶可以使用 Key Vault 中使用客戶管理之金鑰的伺服器端加密。 某些服務可能只會在 Azure Key Vault 中儲存根金鑰加密金鑰，並將加密的資料加密金鑰儲存在較接近資料的內部位置。 在該案例中，客戶可以將自己的金鑰帶到 Key Vault (BYOK – 自備金鑰) 或產生新的金鑰，並使用它們來加密所需的資源。 資源提供者執行加密和解密作業時，此項目會使用設定的金鑰加密金鑰作為所有加密作業的根金鑰。
遺失金鑰加密金鑰表示遺失資料。 基於這個理由，您不應該刪除金鑰。 每當建立或輪替時，都應備份金鑰。 在儲存金鑰加密金鑰的任何保存庫上都必須啟用虛刪除和清除保護，以防止意外或惡意的密碼編譯清除。 建議您不要刪除金鑰，而是建議在金鑰加密金鑰上將已啟用設定為 false。 使用存取控制來撤銷 Azure Key Vault 或受控 HSM 中個別使用者或服務的存取權。
金鑰存取
Azure Key Vault 中使用客戶管理之金鑰的伺服器端加密模型，需讓服務視需要存取金鑰來進行加密和解密。 透過存取控制原則，服務可以存取靜態加密金鑰。 此原則授與服務身分識別存取，以接收金鑰。 代表相關聯的訂用帳戶所執行的 Azure 服務，可以使用該訂用帳戶中的身分識別來加以設定。 服務可以執行 Microsoft Entra 驗證，並接收驗證權杖，會將其本身識別為代表訂用帳戶的該服務。 接著會將該權杖提供給 Key Vault，從而取得已獲得存取權的金鑰。
針對使用加密金鑰的作業，可以授與服務識別存取任何下列作業：解密、加密、解除包裝金鑰、包裝金鑰、驗證、簽署、取得、列出、更新、建立、匯入、刪除、備份和還原。
若要取得用於將靜態資料加密或解密的金鑰，Resource Manager 服務執行個體所要執行的服務識別必須擁有「解除包裝金鑰」(可取得解密金鑰) 和「包裝金鑰」(建立新的金鑰時，可將金鑰插入保存庫金鑰)。
注意
如需關於 Key Vault 授權的詳細資訊，請參閱 Azure Key Vault 文件中的「保護您的金鑰保存庫」頁面。
優點
- 完整控制所使用的金鑰 – 加密金鑰會在客戶控制下的 Key Vault 中進行管理。
- 能夠將多個服務加密到一個主機
- 可從服務的整體管理模型將金鑰管理隔離
- 可跨區域定義服務與金鑰位置
缺點
- 客戶對於金鑰存取管理擁有完全責任
- 客戶對於金鑰生命週期管理擁有完全責任
- 安裝與設定的其他額外負荷
在客戶控制的硬體中使用客戶管理金鑰的伺服器端加密
某些 Azure 服務可允許「裝載您自己的金鑰」(HYOK) 金鑰管理模型。 當需要加密待用資料並在不受 Microsoft 控制的專屬存放庫中管理金鑰時，便適用此管理模式。 在此模型中，服務必須使用來自外部網站的金鑰來解密資料加密金鑰 (DEK)。 效能和可用性保證會受到影響，且設定會更為複雜。 此外，因為服務在加密和解密作業期間可存取 DEK，此模型的整體安全性保證會與在 Azure Key Vault 中由客戶管理金鑰時類似。 因此，此模型不適用於大部分的組織，除非組織有特定金鑰管理需求。 由於這些限制，大部分的 Azure 服務不支援在客戶所控制的硬體中使用客戶自控金鑰的伺服器端加密。 雙重金鑰加密中兩個金鑰的其中一個遵循此模型。
金鑰存取
在客戶所控制的硬體中採用使用客戶自控金鑰的伺服器端加密時，主要加密金鑰會保留在客戶所設定的系統上。 支援這個模型的 Azure 服務可提供方法，來建立與客戶提供之金鑰儲存區的安全連線。
優點
- 完整控制所使用的根金鑰 – 金鑰加密會由客戶提供的儲存區進行管理
- 能夠將多個服務加密到一個主機
- 可從服務的整體管理模型將金鑰管理隔離
- 可跨區域定義服務與金鑰位置
缺點
- 對於金鑰儲存、安全性、效能和可用性擁有完全責任
- 對於金鑰存取管理擁有完全責任
- 對於金鑰生命週期管理擁有完全責任
- 安裝、設定和持續維護的成本高昂
- 客戶資料中心與 Azure 資料中心之間網路可用性的相依性增加。
支援客戶管理金鑰的服務 （CMK）
以下是使用客戶管理金鑰支援伺服器端加密的服務：
* 此服務不會保存資料。 如果有適用物件，暫時性快取會使用 Microsoft 金鑰加密。
** 此服務支援將資料儲存在您自己的金鑰保存庫、儲存體帳戶或保存已支援使用客戶自控金鑰的伺服器端金鑰服務的其他資料。
*** 任何暫時儲存在磁碟上的暫存資料 (例如分頁檔或交換檔) 都會使用 Microsoft 金鑰 (所有層) 或客戶自控金鑰 (使用 Enterprise 和 Enterprise Flash 層) 進行加密。 如需詳細資訊，請參閱在 Azure Cache for Redis 中設定磁碟加密。