期待新課程開始招生 我們將繼續發布一系列關於 MySQL 加密的文章。
在本系列的上一篇文章中，我們討論了 . 今天，我們根據前面了解的知識，來看一下主要按鍵的輪換。
主密鑰輪換涉及生成一個新的主密鑰並使用這個新密鑰重新加密表空間密鑰（存儲在表空間頭中）。
讓我們回憶一下加密表空間的表頭是什麼樣的：
從上一篇文章我們知道，服務器在啟動時會讀取所有加密表空間的表頭，並記住最大的KEY ID。 例如，如果我們有三個帶有 KEY 的表ID = 3 和一張帶 KEY 的表ID = 4，則最大密鑰 ID 將為 4。我們稱此 KEY ID - MAX KEY ID。
主密鑰輪換的工作原理
1.用戶執行ALTER INNODB MASTER KEY。
2、服務端請求keyring用服務端UUID和KEY生成新的master keyID等於一加MAXKEYID。 所以我們得到等於 INNODB 的主密鑰 id密鑰-UUID-(MAXKEYID + 1). 成功生成主密鑰後，MAX KEY ID 加一（即 MAXKEYID=最大KEY身份證+1）。
3. 服務器掃描所有用主密鑰加密的表空間，對於每個表空間：
-
用新的主密鑰加密表空間密鑰；
-
將密鑰 ID 更新為新的 MAXKEYID;
-
如果 UUID 與服務器 UUID 不同，則更新服務器 UUID。
我們知道，用於解密表的主密鑰 ID 由一個 UUID 和一個從表空間頭中讀取的 KEY ID 組成。 我們現在正在做的是更新表空間加密標頭中的此信息，以便服務器收到正確的主密鑰。
如果我們有來自不同位置的表空間，例如不同的備份，那麼它們可能使用不同的主密鑰。 當服務器啟動時，所有這些主密鑰都需要從存儲庫中檢索。 這會減慢服務器啟動速度，尤其是在使用服務器端密鑰庫時。 通過主密鑰輪換，我們使用對所有表空間都相同的單個主密鑰重新加密表空間密鑰。 服務器現在應該在啟動時只收到一個主密鑰。
當然，這只是一個令人愉快的副作用。 主密鑰輪換的主要目的是讓我們的服務器更安全。 如果主密鑰以某種方式從保險庫中被盜（例如，從保險庫服務器），則可以生成一個新的主密鑰並重新加密表空間密鑰，從而使被盜密鑰無效。 我們安全了……差不多了。
在之前的文章中，我談到了一旦表空間密鑰被盜，第三方可以使用它來解密數據。 前提是可以訪問我們的磁盤。 如果主密鑰被盜而您可以訪問加密數據，您可以使用被盜的主密鑰解密表空間密鑰並獲得解密數據。 如您所見，主密鑰的輪換在這種情況下無濟於事。 我們使用新的主密鑰重新加密表空間密鑰，但用於加密/解密數據的實際密鑰保持不變。 因此，“黑客”可以繼續利用它來解密數據。 早些時候我暗示過 可以執行真正的表空間重新加密，而不僅僅是簡單的表空間密鑰重新加密。 此功能稱為加密線程。 但是，此功能目前仍處於試驗階段。
當主密鑰被盜時，主密鑰輪換很有用，但攻擊者無法使用它來解密表空間密鑰。
閱讀更多：
來源： www.habr.com