加密我們的備份：達到終點

已發表: 2017-09-02

注意：這篇工程帖子由我們的數據庫管理員 Silvia Botros 撰寫。 在這裡查看她的一些其他 DBA 帖子。

一年前，SendGrid 正在努力爭取 SOC2 認證。 每個人都參與其中。 幾乎每個交付團隊板上都有帶有 SOC2 標籤的故事，因為我們都希望在第三季度末獲得認證。 可以想像，作為數據庫的負責人，堆棧的那一部分肯定有一些工作要做。

在我的這項業務範圍內努力的任務列表中，確保我們的備份是加密的。 由於我熟悉的領域是 DBA 工具，並且知道 Percona 的 xtrabackup 已經支持加密，因此可以預見我會第一次嘗試這項任務。

在測試這種方法時，我考慮了一些重要的事情：

  • 顯然，備份需要加密
  • 需要知道和可接受創建備份的開銷
  • 在恢復時解密備份的開銷需要知道並且可以接受

這意味著首先，我需要能夠跟踪我的備份需要多長時間。

跟踪備份時間

SendGrid 使用 Graphite 作為其基礎設施指標，雖然絕大多數是通過 Sensu 發送的，但 Graphite 很容易直接通過 bash 行發送指標——因為備份腳本在 bash 中，所以非常方便。 請注意，直接在 Graphite 發送指標不是超級可擴展的，但由於這些備份最多每小時運行一次，這對我的需求來說很好。

結果證明這部分相對容易。

為了解釋最後一行發生了什麼，我向 Graphite 發送了我正在發送的度量的路徑（確保它是唯一的）、度量值，然後是紀元格式的當前時間。 為了簡單起見，我決定使用 Netcat，我給它設置了 1 秒的超時時間，否則它永遠不會退出。 `graphite url` 是我們在數據中心的 Graphite 的 DNS 端點。

既然我有了一個可以比較的基線，我們就可以開始測試加密方法了。

按照 Percona 關於如何執行此操作的詳細文檔，我從製作密鑰開始。 如果您仔細閱讀該文檔頁面，您可能會意識到一些事情。

這個密鑰是要直接傳給備份工具的，是可以解密快照的同一個密鑰。 這稱為對稱加密，從本質上講，它在兩個方向上都使用相同的密鑰，不如非對稱加密安全。 我決定繼續測試，看看簡單性是否仍然使這成為一種可行的方法。

使用非常小的數據庫（幾百 MB）進行的測試是成功的。 該工具按預期工作並記錄在案，但這更像是一個功能測試，真正的問題是“在我們更大的數據庫上加密的損失有多大？” SendGrid 中更多的舊實例已從 1-2 TB 增長到單個 18 TB 的野獸。 我打算用於小型實例的東西也必須在較大的實例上也可以接受。

這就是測試和基準測試變得有趣的地方

我的第一個相當大的測試對像是我們擁有的磁盤上 1 TB 的數據庫。 很快我就遇到了一個意想不到的問題。 使用最少的加密設置（1 個線程，默認塊大小），我看到備份失敗並出現以下錯誤：

當時，這些數據庫使用 512MB 作為事務日誌文件大小，這是一個相當繁忙的集群，因此這些文件幾乎每分鐘都在輪換。 通常，這在數據庫性能中會很明顯，但它大多被固態驅動器的奇蹟所掩蓋。 似乎沒有設置任何並行加密線程（閱讀：使用一個）意味著我們花費了太多時間來加密 .ibd 文件，以至於從我們下面滾動的 innodb 重做日誌正在使備份中斷。

所以，讓我們用一些加密線程再試一次。 作為第一次嘗試，我嘗試了 50 個線程。 這裡的訣竅是在不競爭 CPU 的情況下找到快速加密的最佳點。 我還將“ib_logfiles”的大小增加到每個 1 GB。

這是一個更成功的測試，我很樂意讓它在一夜之間沖泡。 在最初的幾個晚上，情況似乎很好。 是時候進行一個不會增長太多的備份了，但是備份過程中的平均盒子負載肯定顯示了添加的步驟。

然而，當我開始測試恢復時，我發現相同備份的恢復過程在添加加密後從 60 分鐘增加到 280 分鐘——這意味著我們承諾的災難恢復時間會受到嚴重影響。

我們需要把它帶回到一個更合理的時間框架。

這就是團隊合作和更簡單的問題解決方案大放異彩的地方。 我們的一位信息安全團隊成員決定看看這個解決方案是否可以簡化。 因此，他進行了更多測試，並帶回了一些更簡單、更安全的東西。 我還沒有了解 gpg2，所以這也成為了我的學習練習。

gpg2 的好處是它支持非對稱加密。 我們創建了一個密鑰對，其中有私有和公共部分。 公共部分用於加密您決定提供給 gpg2 的任何流或文件，而私有機密可用於解密。

對我們的備份腳本進行的更改以添加加密對此進行了提煉。 刪除了一些參數以使其更易於閱讀：

另一方面，在恢復備份時，我們只需確保主機的密鑰環中有一個可接受的密鑰，然後使用以下命令：

由於我也是 gpg2 的新手，這對我來說是一個學習機會。 Colin，我們出色的 InfoSec 團隊成員，繼續使用 gpg2 測試備份和恢復，直到他確認使用 gpg2 比使用 xtrabackup 的內置壓縮具有多種優勢，包括：

  • 它是不對稱的
  • 它的解密秘密管理相對容易輪換（更多內容見下文）
  • 它與工具無關，這意味著任何其他類型的不使用 xtrabackup 的備份都可以使用相同的方法
  • 它在解密時使用了多個內核，這給了我們更好的恢復時間

總是有改進的餘地

我仍然看到改進空間的一個地方是我們如何處理可以解密這些文件的秘密。 目前，我們將它們包含在我們的企業密碼管理解決方案中，但是從那裡獲取它，然後使用它來測試備份是一個手動過程。 我們計劃的下一步是實施 Hashicorp 的 Vault，並使用它無縫地在指定的主機上提取密鑰進行解密，然後將其從本地環中刪除，以便輕鬆用於自動化測試並仍然受到保護。

最終，我們在不犧牲備份性能或災難恢復 SLA 的情況下及時獲得了所有數據庫備份以符合我們的 SOC2 需求。 我和我們的信息安全團隊一起完成這項任務很有趣，並從中學習了新工具。 另外，當最簡單的解決方案最終成為最適合一個人的任務時，這總是很好的。