Microsoft Cloud for Sovereignty 中使用客戶自控金鑰的加密
計劃實作 Microsoft Cloud for Sovereignty 的客戶可能需要使用資料加密功能來滿足資料主權需求。 對資料主權有嚴格需求的客戶應制定在雲端實作金鑰管理的計畫。 本文指導雲端架構師、加密系統負責人和其他技術決策者制定在 Azure 中實作平台層級加密的計畫。 平台層級的加密規劃通常包括識別金鑰管理需求、進行技術選擇，以及為要使用的 Azure 服務選取設計和設定選項。 此程序需要在三個不同領域中做出技術決策：
- 定義金鑰管理需求：您的組織需要採取哪些措施來保護敏感性客戶資料和敏感性密碼編譯資料？
- 選擇資料加密功能來保護客戶資料：該如何、在何處以及何時加密 Azure 中的客戶資料？
- 選取金鑰管理解決方案以保護客戶金鑰：應使用什麼金鑰存放區來保護用於加密 Azure 中客戶資料的資料加密金鑰？
定義金鑰管理需求
金鑰管理的需求可以包括有關所使用密碼編譯服務的技術需求，以及與效能、安全性和主權相關的作業需求。 對於決定 Azure 工作負載中資料的加密時機和方式，建議以組織的資料分類系統為起點。 讓加密需求與資料分類 (而不是與特定系統或解決方案) 保持一致，組織就會有更的彈性在工作負載移轉規劃期間選擇最佳加密等級。
根據資料分類確定加密需求時，還可以採用分層方法，讓重要程度較低的工作負載可以利用較簡單的解決方案，而將最複雜的設定保留給固有風險較高的工作負載。 此方法的一個範例是，允許使用 Microsoft 管理的金鑰來加密開發環境的儲存體帳戶，而要求生產環境儲存體帳戶使用客戶自控加密金鑰。
組織清楚了解如何將其加密需求與其資料分類產生關聯後，就可以開始為他們計劃使用的 Azure 服務進行功能選擇程序。 其中一些功能的運作方式可能與類似的內部部署系統不同，因此鼓勵組織要熟悉加密在 Azure 中的運作方式，並檢閱設計加密解決方案的建議和最佳做法。 下列文章對客戶需要做出的一些技術選擇提供其他觀點，可以做為有實用價值的的起點，開始討論組織雲端金鑰管理目標。
選取資料加密功能
許多 Azure 服務使用完全由 Azure 產生、儲存和管理的金鑰來啟用加密，無需任何客戶互動。 這些平台管理的金鑰可協助組織以很少的營運開銷來實作加密。 不過，有嚴格資料主權需求的客戶可能必須選取特定平台加密功能，才能保護特定 Azure 服務中處於待用狀態的敏感性資料。
對於高敏感性資料，許多常用的 Azure 服務允許客戶使用客戶自控金鑰 (CMK) 實作雙重加密。 在 Azure 服務中實作客戶自控金鑰可協助客戶保護儲存在這些服務中的資料免於未經授權的存取。
在 Azure 中實作客戶自控金鑰可能會增加工作負載的成本和複雜度，因此鼓勵組織評估每個工作負載和資料分類等級對此功能的需求。 僅針對需要客戶自控金鑰的工作負載和資料類型實作該金鑰有助於為不處理敏感性資料的工作負載減少運營開銷。
如果需要客戶自控金鑰，則必須為每個相應的 Azure 服務設定這些金鑰。 組織可以建立實作這些功能的全組織標準和可重複設計模式，來協助簡化部署或移轉規劃工作。 下列文章提供有關如何在 Azure 中設定待用資料加密的詳細資訊：
了解如何將常用的 Azure 服務設定為使用客戶自控金鑰加密待用資料：
- 將 CMK 與儲存體帳戶搭配使用
- 將機密計算中的 CMK 與 AMD 機密 VM 搭配使用
- 將 CMK 與虛擬機器受控磁碟搭配使用
- 將 CMK 與 Azure SQL DB 搭配使用
- 將 CMK 與 Azure Cosmos DB 搭配使用
- 將 CMK 與 Azure 監視器搭配使用
選取金鑰管理解決方案
雖然使用客戶自控金鑰的的功能 (例如雙重加密) 可協助保護 Azure 服務中維護的客戶資料，但雲端式金鑰管理解決方案也有助於保護加密金鑰以及其他用於加密敏感性資料的密碼編譯資料。 有嚴格資料主權需求的客戶應根據其保障需求和工作負載的風險狀況選擇合適的金鑰管理解決方案。
處理敏感性資料的工作負載可能會受益於 Azure 受控 HSM 解決方案提供的額外保證，包括經過 FIPS-140-2 Level-3 驗證的硬體安全模組，這些模組具有額外的安全控制功能，可保護儲存的加密材料。
下列文章提供指引，客戶可用來為其確定的案例選擇適當的金鑰存放區。 其中還提供有關 Microsoft 如何管理客戶在其加密解決方案中所用密碼編譯服務的資訊。
金鑰管理的操作模型
Azure Key Vault 根據您要使用的是標準/進階層級 Azure Key Vault 還是 Azure Key Vault 受控 HSM，以不同的方式實作角色型存控制。 存取控制中的這些差異可能會影響組織使用這些功能的方式。 本節說明這些差異，以及其如何影響組織選擇設計雲端金鑰管理作業程序的方式。
FIPS-140 Level-3 驗證的合規性限制式
FIPS-140 Level-3 驗證需要身分型操作員識別。 這些安全措施會在支援 Azure 中金鑰保存庫服務的基礎 HSM 硬體中進行部署和驗證。 因此，Azure Key Vault 中的 RBAC 功能依靠基礎硬體的 RBAC 功能。
Azure Key Vault 受控 HSM 利用硬體層級實作的本機 RBAC 指派，並允許在安全性網域範圍 (例如，HSM 範圍) 或根據每個金鑰進行角色指派。 這意味著建立金鑰需要整個安全網域的系統管理權限，因為無法為尚不存在的金鑰指派權限。 此設計的影響是，任何需要在 mHSM 執行個體中儲存金鑰的人都必須對儲存在該安全網域中的所有金鑰具有完整權限，向擁有安全網域所需權限的集中式團隊要求金鑰。 這表示與建議為每個應用程式建立個別金鑰保存庫的 Azure Key Vault 指引相比，有所改變。
Azure Key Vault 受控 HSM 中的金鑰管理作業
為了開發金鑰管理的作業程序，客戶必須判斷是否需要 Azure Key Vault 受控 HSM 做為其解決方案架構的一部分。 計劃使用受控 HSM 的組織應先熟悉管理作業和密碼編譯作業都會使用的存取控制模型，並了解如何指派角色型存取控制。
深入了解受控 HSM 中的存取控制：
計劃使用 Azure Key Vault 受控 HSM 的組織應檢閱受控 HSM 內建 RBAC 角色和允許的作業清單，並具體規劃應對下列作業案例：
- 在受控 HSM 中建立新金鑰
- 使用控制平面管理現有金鑰的作業，例如金鑰更新或金鑰變換
- 應用程式或服務對現有金鑰的資料平面使用方式
目前，指派建立新金鑰的權限的唯一方法是指派一個角色 (例如 Crypto User)，該角色還包含其他權限，例如金鑰變換和刪除。 因此，授與應用程式團隊成員在受控 HSM 中建立自己金鑰所需的權限可能會違反最低權限原則，因為該使用者也有 HSM 中所有金鑰的系統管理權限。 此問題可以引入權限提升的集中式團隊來解決 (此團隊可以促進建立金鑰要求)，或者引入自動化，可透過利用受控 HSM REST API 的 IT 服務管理程序來促進建立新金鑰要求。