使用客戶管理的金鑰 適用於 MySQL 的 Azure 資料庫 數據加密

  • 發行項

適用於： 適用於 MySQL 的 Azure 資料庫 - 單一伺服器

重要

適用於 MySQL 的 Azure 資料庫 單一伺服器位於淘汰路徑上。 強烈建議您升級至 適用於 MySQL 的 Azure 資料庫 彈性伺服器。 如需移轉至 適用於 MySQL 的 Azure 資料庫 彈性伺服器的詳細資訊，請參閱 適用於 MySQL 的 Azure 資料庫 單一伺服器會發生什麼事？

適用於 MySQL 的 Azure 資料庫使用客戶管理金鑰的資料加密，可讓您攜帶自己的金鑰 (BYOK) 來保護待用資料。 此外也可讓組織在金鑰和資料的管理中實作職責區分。 使用客戶管理的加密，您必須負責密鑰生命週期、金鑰使用許可權，以及金鑰作業稽核的完整控制權。

使用客戶管理的金鑰進行數據加密，適用於 MySQL 的 Azure 資料庫，會設定在伺服器層級。 對於指定的伺服器，稱為金鑰加密金鑰 （KEK） 的客戶管理密鑰會用來加密服務所使用的數據加密密鑰 （DEK）。 KEK 是非對稱密鑰，儲存在客戶擁有和客戶管理的 Azure 金鑰保存庫 實例中。 本文稍後會詳細說明金鑰加密金鑰 （KEK） 和數據加密金鑰 （DEK）。

金鑰保存庫 是雲端式的外部金鑰管理系統。 它具有高可用性，可為 RSA 密碼編譯金鑰提供可調整且安全的記憶體，並選擇性地由 FIPS 140 驗證 的硬體安全性模組 （HSM） 支援。 它不允許直接存取預存密鑰，但會提供加密和解密的服務給授權的實體。 金鑰保存庫 可以產生金鑰、匯入金鑰，或從內部部署 HSM 裝置傳輸密鑰。

注意

這項功能僅支援「一般用途記憶體 v2（最多支援 16TB）」記憶體，可用於一般用途和記憶體優化定價層。 如需詳細資訊，請參閱 儲存體 概念。 如需其他限制，請參閱 限制 一節。

福利

使用客戶管理的金鑰進行資料加密，適用於 MySQL 的 Azure 資料庫 提供下列優點：

  • 數據存取完全由您控制，因為能夠移除密鑰並讓資料庫無法存取
  • 完整控制金鑰生命週期，包括密鑰輪替以符合公司原則
  • Azure 金鑰保存庫 中的密鑰集中管理和組織
  • 能夠實作安全性人員與 DBA 與系統管理員之間的職責區隔

術語和描述

數據加密金鑰 （DEK）：用來加密資料分割或數據區塊的對稱 AES256 金鑰。 使用不同的金鑰加密每個數據區塊，會讓密碼編譯分析攻擊更加困難。 資源提供者或應用程式實例需要存取 DEK，以加密和解密特定區塊。 當您以新的金鑰取代 DEK 時，只有其相關聯區塊中的數據必須以新的金鑰重新加密。

金鑰加密金鑰 （KEK）：用來加密 DEK 的加密金鑰。 永不離開 金鑰保存庫KEK可讓DEK本身進行加密和控制。 可存取 KEK 的實體可能與需要 DEK 的實體不同。 由於 KEK 需要解密 DEK，因此 KEK 實際上是一個單一點，可藉由刪除 KEK 來有效地刪除 DEK。

使用 KEK 加密的 DEK 會分開儲存。 只有具有KEK存取權的實體才能解密這些DEK。 如需詳細資訊，請參閱 待用加密的安全性。

使用客戶管理的金鑰進行數據加密的方式

Diagram that shows an overview of Bring Your Own Key

為了讓 MySQL 伺服器使用儲存在 金鑰保存庫 的客戶自控密鑰來加密 DEK，金鑰保存庫 系統管理員會提供下列伺服器存取權限：

  • get：用於擷取金鑰保存庫中密鑰的公用部分和屬性。
  • wrapKey：若要能夠加密 DEK。 加密的 DEK 會儲存在 適用於 MySQL 的 Azure 資料庫 中。
  • unwrapKey：若要能夠解密 DEK。 適用於 MySQL 的 Azure 資料庫 需要解密的 DEK 來加密/解密數據

金鑰保存庫系統管理員也可以啟用 金鑰保存庫 稽核事件的記錄，以便稍後進行稽核。

當伺服器設定為使用儲存在金鑰保存庫中的客戶自控金鑰時，伺服器會將 DEK 傳送至金鑰保存庫以進行加密。 金鑰保存庫 會傳回儲存在用戶資料庫中的加密 DEK。 同樣地，必要時，伺服器會將受保護的 DEK 傳送至密鑰保存庫以進行解密。 如果已啟用記錄，稽核員可以使用 Azure 監視器來檢閱 金鑰保存庫 稽核事件記錄。

設定 適用於 MySQL 的 Azure 資料庫 數據加密的需求

以下是設定 金鑰保存庫 的需求：

  • 金鑰保存庫 和 適用於 MySQL 的 Azure 資料庫 必須屬於相同的 Microsoft Entra 租使用者。 不支援跨租使用者 金鑰保存庫和伺服器互動。 之後移動 金鑰保存庫 資源會要求您重新設定數據加密。
  • 在金鑰保存庫上啟用虛刪除功能，並將保留期限設定為 90 天，以防止意外刪除金鑰（或 金鑰保存庫）刪除時遺失數據。 默認會保留虛刪除的資源 90 天，除非保留期間明確設定為 <=90 天。 復原和清除動作在 金鑰保存庫 存取原則中有自己的許可權。 虛刪除功能預設為關閉，但您可以透過PowerShell或 Azure CLI 加以啟用（請注意，您無法透過 Azure 入口網站 加以啟用）。
  • 在 金鑰保存庫上啟用清除保護 功能，保留期間設定為 90 天。 只有在啟用虛刪除之後，才能啟用清除保護。 它可透過 Azure CLI 或 PowerShell 開啟。 當清除保護開啟時，在保留期間通過之前，無法清除處於已刪除狀態的保存庫或物件。 仍可復原虛刪除的保存庫和物件，以確保會遵循保留原則。
  • 使用其唯一的受控識別，將密鑰保存庫的存取權授與 適用於 MySQL 的 Azure 資料庫 get、wrapKey 和 unwrapKey 許可權。 在 Azure 入口網站 中，在 MySQL 上啟用數據加密時，會自動建立唯一的「服務」身分識別。 如需使用 Azure 入口網站 時的詳細逐步指示，請參閱設定 MySQL 的數據加密。

以下是設定客戶自控金鑰的需求：

  • 用來加密 DEK 的客戶自控密鑰只能是非對稱 RSA 2048。
  • 金鑰啟用日期 (若已設定) 必須是過去的日期和時間。 未設定到期日。
  • 金鑰必須處於「已啟用」狀態。
  • 密鑰必須具有 虛刪除 ，保留期間設定為 90 天。這會隱含地設定必要的密鑰屬性 recoveryLevel：“Recoverable”。 如果保留期設定為 < 90天，則recoveryLevel：「CustomizedRecoverable」，這不是必要條件，因此請確定將保留期限設定為 90天。
  • 金鑰必須 啟用清除保護。
  • 如果您要將現有的金鑰匯入金鑰保存庫中，請務必以支援的檔案格式 （.pfx、 、 .byok.backup） 提供它。

建議

當您使用客戶管理的金鑰使用資料加密時，以下是設定 金鑰保存庫 的建議：

  • 設定 金鑰保存庫 的資源鎖定，以控制誰可以刪除此重要資源，並防止意外或未經授權的刪除。

  • 啟用所有加密金鑰的稽核和報告。 金鑰保存庫 提供容易插入其他安全性資訊和事件管理工具的記錄。 Azure 監視器 Log Analytics 是已整合的服務範例之一。

  • 請確定 金鑰保存庫 和 適用於 MySQL 的 Azure 資料庫 位於相同的區域中，以確保 DEK 包裝和解除包裝作業的存取速度更快。

  • 將 Azure KeyVault 鎖定為僅限 私人端點和選取的網路 ，只 允許受信任的 Microsoft 服務保護資源。

    trusted-service-with-AKV

以下是設定客戶自控金鑰的建議：

  • 將客戶管理的金鑰復本保留在安全的地方，或將它委付給委付服務。

  • 如果 金鑰保存庫 產生金鑰，請在第一次使用金鑰之前建立密鑰備份。 您只能將備份還原至 金鑰保存庫。 如需備份命令的詳細資訊，請參閱 Backup-AzKeyVaultKey。

無法存取客戶管理的金鑰條件

當您在 金鑰保存庫 中使用客戶管理的金鑰設定數據加密時，伺服器必須持續存取此金鑰，才能保持在線狀態。 如果伺服器在 金鑰保存庫 中失去客戶管理的金鑰存取權，伺服器就會在 10 分鐘內開始拒絕所有連線。 伺服器發出對應的錯誤訊息，並將伺服器狀態變更為 無法存取。 伺服器可以連線到此狀態的一些原因如下：

  • 如果我們為已啟用數據加密的 適用於 MySQL 的 Azure 資料庫 建立時間點還原伺服器，新建立的伺服器將會處於無法存取的狀態。 您可以透過 Azure 入口網站 或 CLI 來修正此問題。
  • 如果我們為已啟用數據加密的 適用於 MySQL 的 Azure 資料庫 建立讀取複本，複本伺服器將會處於無法存取的狀態。 您可以透過 Azure 入口網站 或 CLI 來修正此問題。
  • 如果您刪除 KeyVault，適用於 MySQL 的 Azure 資料庫 將無法存取密鑰，而且會移至無法存取的狀態。 復原 金鑰保存庫 並重新驗證數據加密，讓伺服器可供使用。
  • 如果我們從 KeyVault 刪除金鑰，適用於 MySQL 的 Azure 資料庫 將無法存取金鑰，而且會移至無法存取的狀態。 復原金鑰並重新驗證數據加密，讓伺服器可供使用。
  • 如果儲存在 Azure KeyVault 中的金鑰過期，金鑰將會變成無效，且 適用於 MySQL 的 Azure 資料庫 會轉換成無法存取的狀態。 使用 CLI 擴充金鑰到期日，然後重新驗證數據加密，讓伺服器 可供使用。

意外從 金鑰保存庫 撤銷金鑰

如果某人擁有足夠的訪問許可權，金鑰保存庫 不小心停用對密鑰的伺服器存取，可能會發生下列情況：

  • 撤銷伺服器金鑰保存庫的 get、 wrapKey和 unwrapKey 許可權。
  • 刪除金鑰。
  • 刪除金鑰保存庫。
  • 變更金鑰保存庫的防火牆規則。
  • 刪除 Microsoft Entra ID 中伺服器的受控識別。

在 金鑰保存庫 中監視客戶管理的金鑰

若要監視資料庫狀態，以及啟用遺失透明數據加密保護裝置存取的警示，請設定下列 Azure 功能：

  • Azure 資源健康狀態：在資料庫第一次連線遭到拒絕之後，無法存取客戶密鑰的資料庫會顯示為「無法存取」。

  • 活動記錄：當客戶管理 金鑰保存庫 中的客戶金鑰存取失敗時，專案會新增至活動記錄。 如果您為這些事件建立警示，您可以儘快恢復存取權。

  • 動作群組：定義這些群組，以根據您的喜好設定傳送通知和警示。

在 Key Vault 中使用客戶管理的金鑰進行還原和複寫

適用於 MySQL 的 Azure 資料庫 使用儲存在 金鑰保存庫 中的客戶受控金鑰加密之後，也會加密任何新建立的伺服器複本。 您可以透過本機或異地還原作業，或透過讀取複本來建立這個新複本。 不過，可以變更複本，以反映新客戶的加密受控密鑰。 當客戶管理的金鑰變更時，伺服器的舊備份會開始使用最新的密鑰。

若要避免在還原或讀取複本建立期間設定客戶管理的數據加密時發生問題，請務必在來源和還原/複本伺服器上遵循下列步驟：

  • 從來源 適用於 MySQL 的 Azure 資料庫 起始還原或讀取複本建立程式。
  • 讓新建立的伺服器（還原/復本）處於無法存取的狀態，因為其唯一的身分識別尚未獲得 金鑰保存庫 的許可權。
  • 在還原/復本伺服器上，在數據加密設定中重新驗證客戶管理的密鑰，以確保新建立的伺服器會包裝和解除包裝儲存在 金鑰保存庫 中的密鑰許可權。

限制

對於 適用於 MySQL 的 Azure 資料庫，使用客戶管理的金鑰 （CMK） 對待用數據加密的支援很少 -

  • 此功能的支援僅限於 一般用途 和 記憶體優化 定價層。

  • 只有區域和伺服器才支援此功能，其支援一般用途記憶體 v2（最多 16 TB）。 如需支援記憶體最多 16 TB 的 Azure 區域清單，請參閱這裡的檔 中的記憶體一節

    注意

    • 在支援一般用途記憶體 v2 的 Azure 區域中 建立的所有新 MySQL 伺服器，都 支援使用客戶管理員密鑰進行加密。 還原時間點 （PITR） 伺服器或讀取複本在理論上不會符合「新」資格。
    • 若要驗證布建的伺服器一般用途記憶體 v2，您可以移至入口網站中的定價層刀鋒視窗，並查看布建伺服器所支援的記憶體大小上限。 如果您可以將滑桿移至 4TB，您的伺服器位於一般用途記憶體 v1 上，且不支援使用客戶管理的密鑰進行加密。 不過，數據會隨時使用服務管理密鑰來加密。 如果您有任何問題，請連絡 AskAzureDBforMySQL@service.microsoft.com 。

  • 只有 RSA 2048 密碼編譯金鑰才支援加密。

下一步

  • 瞭解如何使用 Azure 入口網站 和 Azure CLI，為適用於 MySQL 的 Azure 資料庫設定客戶自控密鑰的數據加密。
  • 瞭解 適用於 MySQL 的 Azure 資料庫 - 單一伺服器的記憶體類型支援