在網格上審計數據庫第 2 部分：部署後觀察

在本系列的上一篇文章中，我談到了我們如何收集這個項目的需求、我們如何決定使用什麼工具以及如何規劃部署以避免服務中斷。 正如所承諾的那樣，這篇後續文章的重點是部署後的觀察以及哪些因素使這對我們來說是一個成功的故事。

準備好的語句和命令類過濾

我們對該項目的初始設計旨在利用 percona 插件中的一項功能，該功能可讓您過濾發出的事件，以使用包含的命令列表或排除的命令列表來限制我們實際需要審核的範圍。

該功能依賴於插件標記每個檢測到的 sql 命令，該類基於 mysql 固有的列表，並從那裡在輸出層中決定檢測到的命令類是否應該被抑製或發出。

因此，我們編寫了初始藍圖以利用audit_log_exclude_commands功能來排除任何不會導致寫入或更改行數據的 sql 命令。 我們選擇排除列表是因為我們認為包含列表存在丟失任何範圍內命令類的風險，並且可能成為我們的審計日誌中存在空白的原因。

然而，在我們測試的第一個集群上，我們看到所有被審計的命令都被歸類為錯誤，儘管很明顯這些語句運行成功並且在更改數據的情況下也成功執行了該操作。 我們還看到，所有查詢都被發送到集中式系統日誌服務器，而不管該排除列表似乎與該錯誤分類相關。

這意味著我們在 elasticsearch 中存儲的事件比我們實際需要的要多得多，這肯定會影響我們及時分析和檢測錯誤行為的能力。 通過與安全團隊的合作，我們決定通過他們的錯誤跟踪器將問題通知 Percona，但還將基於命令的過濾下移到中央 syslog 層。

就像工程中的所有事情一樣，這裡的權衡是通過 DB 網絡層發送更多數據，並使集中式 syslog 層中的過濾更加複雜，作為回報，我們的彈性搜索擴展需求更易於管理，數據庫端的配置更簡單。

表現

這個項目中最重要的決定之一是決定使用 rsyslog 工具來捕獲這些日誌並將其發送到集中式 syslog 服務器。

但沒有什麼是沒有優點和缺點的。

這一決定意味著單獨系統的正常運行時間和中間網絡堆棧的可靠性對於提供我們需要的 SLA 以使我們的審計團隊對該審計解決方案充滿信心變得至關重要。

對於那些不願意做出妥協並需要在數據庫堆棧中保持審計日誌持久性的責任的人，我建議在審計插件中使用FILE處理程序，然後使用本地 logstash 獲取日誌並將它們轉發到他們的分析系統選擇。

後一種選擇意味著更多的磁盤 IOP 從數據庫進程中消耗並被審計插件和 logstash 佔用，這意味著您必須在數據庫表文件、操作日誌和審計之間仔細平衡實例上的磁盤空間插件日誌。 權衡你的選擇完全取決於哪個更容易被企業操作/接受，但你仍然有選擇。

在我們的案例中，rsyslog 的選擇被證明對我們繁忙的數據庫影響最小，峰值約為 5400 個事務/秒，在正常操作期間，我們發現對性能沒有影響。 審計插件一直在運行，在不影響數據庫性能的情況下發送其事件。 這一切都是因為我們選擇了一種避免在數據庫端使用基於磁盤的操作的架構。

過去的決定得到回報

當我們開始這個項目時，我們首先擔心的問題之一是它對性能的影響。 範圍內的一個數據庫集群經歷了非常繁忙的時間，它的應用程序對延遲很敏感，因此我們需要確保跟踪每秒事務數、磁盤和 CPU 利用率等性能指標，以便在部署插件後比較數字和看看懲罰是什麼。

看到我們在正常操作中沒有受到太多處罰，真是令人驚喜。 如前所述，因為我們決定使用 SYSLOG 處理程序，這意味著我們通常不需要使用任何本地磁盤容量來跟踪這些審計事件。

但我們也不想僅根據“正常運行”時間進行計劃。

我們還需要知道，當 rsyslog 需要回退到本地假脫機文件時，這些事件不會復合到影響更關鍵數據庫集群的服務中斷中。 通過在生產環境的密切監視下測試 rsyslog 假脫機行為，我們意識到過去幾年在功能上對我們的數據庫進行分片的工作使我們獲得了計劃外的好處，即大量磁盤 IOP 容量來吸收諸如 rsyslog 假脫機到磁盤然後需要重新發送之類的事件所有這些事件。

我們肯定注意到這些事件期間磁盤利用率的增加，但它從未使數據庫實例進入臨界狀態或影響面向客戶的活動。

權衡取捨

就像軟件工程中的所有事情一樣，總是需要權衡取捨。 在這個項目中，我們考慮了一種更可靠且丟失日誌的可能性較小的日誌傳遞方法。 這將涉及將日誌寫入磁盤，然後使用類似 logstash 的東西來攝取並將它們發送到分析目的地以供安全團隊使用。

但這將意味著數據庫端的大量磁盤 IOP 消耗，我們知道這可能會影響面向客戶調用這些數據庫的服務質量。

我們決定通過在 rsyslog 中使用彈性日誌記錄、使用合理大小的假脫機以及使用 TCP 將事件發送到我們的日誌監控堆棧來充分滿足我們的業務需求。 就像生活中的一切一樣，沒有什麼是永恆的。 我們知道，未來可能需要重新審視這一決定。

最後

這個項目雖然包含六個集群和大量實例，但在一個季度內就完成了，而 DB ops 團隊仍在繼續保持快速增長的業務。 如果沒有 DBE 和安全團隊之間的密切合作，並且沒有強大的產品管理來保持範圍有限和已知，以確保我們所有人都將目光投向使我們的業務更加安全的最終目標，這一切就不可能發生。