MySQL資料函式庫合規與安全最佳實踐

– 14 分鐘閱讀

Schrems II 判決對資料跨境傳輸產生重大影響，企業需要更謹慎地處理歐盟公民的個人資料。本文將探討如何在 MySQL 資料函式庫中落實資料合規與安全管理，涵蓋機密資訊的保護、資料函式庫使用者的許可權控管、稽核日誌的設定與應用，以及備份還原策略等導向。同時，文章也將探討如何選擇合適的機密管理方案，並提供程式碼範例，協助讀者更好地理解和應用這些技術。此外，文章也將強調版本控制和架構變更管理的重要性，以確保資料函式庫的穩定性和安全性。最後，本文將討論如何建立完善的備份和還原程式，以應對潛在的資料遺失風險，並滿足合規性要求。

資料合規與MySQL的挑戰

Schrems II判決的影響

2020年，歐盟法院對Facebook愛爾蘭子公司的一起案件做出了判決。這項判決，被稱為Schrems II，對所有在歐盟境內營運並收集歐盟公民資料的美國公司產生了廣泛影響。判決結果取消了原本美國公司在歐盟經營的法律依據——「隱私盾」（Privacy Shield）。歐盟法院認為，「隱私盾」不足以保障歐盟公民的隱私權，特別是在美國政府可能透過法律手段（如《1978年外國情報監視法》）對歐盟公民的個人資料進行監控的問題上。因此，美國公司在歐盟境內收集的歐盟公民的個人識別資料必須保留在歐盟境內，不得傳輸到美國或被美國人員存取。

合規控制的重要性

隨著資料合規法規的日益複雜，公司需要建立健全的合規控制機制。雖然相關法規眾多，但許多工作可以同時滿足多項法規要求，從而提高效率並保持一致性。企業需要了解哪些控制措施是必要的，以及為何需要這些措施。當企業發展到一定規模時，就需要向稽核人員提供合規證據。瞭解每個控制措施的目的將有助於企業更輕鬆地透過稽核。

機密管理（Secrets Management）

在討論如何管理機密之前，我們首先需要明確基礎設施中哪些內容屬於機密範疇：

  • 應用程式與資料函式庫互動的密碼字串
  • 支援人員/操作員管理資料函式庫例項的密碼字串
  • 可存取/修改資料的API令牌
  • SSH私鑰
  • 證書金鑰

企業需要一種安全的方式來管理機密資訊，並將其與組態管理分開。這包括提供和輪換敏感資料，如資料庫存取憑證，無論是供應用程式還是團隊使用。

雲端環境中的機密管理

如果企業在雲端環境中執行應用程式和資料函式庫，建議優先使用雲端服務提供商推薦的機密管理解決方案。這類別解決方案至少應符合美國國家標準與技術研究所（NIST）的加密標準，因為這是許多法規（如HIPAA和FedRAMP）所要求的。

自行託管機密管理解決方案

如果雲端服務提供商沒有合適的機密管理解決方案，企業可能需要自行託管。這需要更廣泛的努力，並需要考慮到相關的複雜性。無論是使用託管解決方案還是自行託管，企業都需要了解相關的權衡，並與法律和安全團隊進行明確的溝通，以避免後續的誤解。

基本的安全實踐

  • 不要共用資料函式庫憑證：不同服務應使用不同的資料函式庫憑證，以減少因資料函式庫憑證洩露而導致的安全風險。
  • 不要將生產資料函式庫憑證儲存在程式碼倉函式庫中：這是一個常見的安全錯誤。企業應透過掃描程式碼倉函式庫來避免這種情況，並在合併請求之前檢查潛在的機密字串。

選擇機密管理解決方案的考量

在選擇機密管理解決方案時，需要考慮相關的權衡，包括安全性、可用性和維護成本。企業需要準備好向長官層解釋為何這項工作對於提高安全態勢和降低風險至關重要。

內容解密：

本章節重點介紹了企業在處理資料合規和MySQL時的挑戰。首先討論了Schrems II判決對美國公司在歐盟經營的影響，接著強調了建立合規控制機制的重要性。然後探討了機密管理的必要性，包括如何在雲端環境中選擇合適的機密管理解決方案，或是在必要時自行託管。最後，本章節強調了一些基本的安全實踐，如避免共用資料函式庫憑證和不將生產資料函式庫憑證儲存在程式碼倉函式庫中，並提出了選擇機密管理解決方案時的考量因素。

選擇秘密管理解決方案

選擇秘密管理解決方案取決於您執行的環境以及與資料函式庫和應用程式堆積疊的整合能力。方便性和滿足所有需求之間總是存在著權衡。因此，您需要與所有利益相關者（其中一些人不是工程師）明確說明其限制以及可用性或彈性的權衡。您在檢查雲端（或私有）基礎設施可以提供的功能時，應考慮以下幾個權衡因素：

空間限制

許多雲端提供的秘密管理解決方案對秘密的長度做出了假設，如果您想儲存比資料函式庫使用者和密碼對更長的內容，這可能會導致意外。如果您的合規控制需要將更長的文字字串視為秘密（例如 SSH 金鑰或 SSL 私有憑證），您應該檢查特定金鑰的最大儲存大小。一些組織在稍後階段會遇到的一個問題是，隨著秘密數量的增長，需要新的和不同的秘密管理解決方案來容納更長的秘密。現在，他們必須處理遷移（可能會影響正常執行時間）或管理與兩個獨立的秘密解決方案的工具和整合，這帶來了自身的複雜性。

秘密輪換

如果您在公共雲端執行並且可以使用其託管的秘密管理解決方案，那麼有個好訊息：截至目前，三大主要雲端服務供應商都提供了某種自動化輪換秘密的方法，以及版本控制，以使服務過渡到新的秘密無縫進行。但是，如果您選擇的秘密管理解決方案不支援輪換秘密，那麼您需要計劃如何在計劃性變更（如需要定期輪換資料函式庫憑證的控制）或非計劃性緊急變更（如有人意外地將資料函式庫密碼提交到公共儲存函式庫）時進行變更，而不影響正在執行的應用程式？這在很大程度上取決於您如何將組態變更交付給正在執行的應用程式以及您的佈署管道的運作方式。這是協調變更的基本思路。這個變更是一個佈署。即使您的應用程式以組態行的形式存取資料函式庫憑證，您仍然需要將此組態變更傳播到您的所有服務叢集，並且通常還需要協調重新啟動，而不影響整個服務的可用性。

地區可用性

考慮到您的秘密管理解決方案不僅用於儲存秘密，還用於交付它們。如果您要避免像將秘密儲存在程式碼中的不良做法，您需要您的應用程式能夠在執行時檢索它需要的秘密來處理請求。這意味著您現在必須考慮這些秘密將如何被檢索，如果您的應用程式無法存取秘密管理服務會發生什麼，以及這種新的依賴關係引入了哪些故障模式。如果您負責需要在許多地理區域執行的應用程式，您的秘密管理解決方案的區域能力就成為另一個需要考慮的問題。您的雲端服務供應商的解決方案是否會自動將秘密複製到其他區域？或者您必須構建這種能力？

角色和資料的分離

這些監管法律的一個重要目標是根據資料對業務或客戶在洩露時所產生的風險進行分離。這是最小許可權的概念，無論是對於人類存取還是應用程式碼存取。這種分離允許根據資料的型別和相關風險對變更進行更合適的控制和跟蹤。

根據合規原因的分片

一個可能迫使特定資料集分離到專用叢集的軸是具有非常不同的控制措施的不同合規要求。假設您是一家市場行銷傳播提供商，正在建立一個新的、獨立的產品，重點關注醫療保健技術。目前正在使用的資料與健康無關，並且不受許多法律要求的約束。一旦業務進入健康技術領域，您現在有一部分客戶及其資料，您的公司承擔了處理個人健康資訊（PHI）的法律責任。在這種情況下，從一開始就在專用的資料儲存中開發新產品是有意義的，這樣您就可以更合適地應用 HIPAA 合規控制，而不會給現有的資料集及其依賴的應用程式增加不必要的負擔。

獨立的資料函式庫使用者

隨著您的產品變得越來越複雜，支援它的技術堆積疊也會隨之複雜，您將開始擁有多個具有資料存取許可權的應用程式。透過不在多個程式碼函式庫之間共用相同的資料庫存取憑證，從一開始就建立良好的資料存取控制非常重要。安全事件和憑證意外洩露是各種規模的公司都會發生的事件，當它們發生時，如果洩露的秘密影響到您業務營運的一個已知且孤立的範圍，那麼您將會受益匪淺，因為您可以快速輪換該秘密。

此圖示說明瞭選擇秘密管理解決方案時需要考慮的多個重要因素，包括空間限制、秘密輪換、地區可用性、角色和資料的分離、根據合規原因的分片以及獨立的資料函式庫使用者。每個因素都在確保安全性和合規性方面發揮著至關重要的作用。

合規控制下的變更追蹤與資料函式庫稽核

許多合規法規要求對特定資料集的變更或存取進行日誌記錄，例如影響財務報告的資料變更、產生發票的系統變更，以及這些變更如何被審查、測試和追蹤。資料函式庫是合規控制首先關注的重點之一。

資料存取日誌記錄

許多合規控制要求維護特定資料集的變更或存取日誌，例如追蹤財務資料的變更，或是 PCI 和 HIPAA 等法規對敏感資料存取的追蹤。可以使用 Percona 的稽核日誌外掛程式（audit log plug-in）或 MySQL Enterprise Audit 外掛程式來實作這一點。

為何不使用觸發器？

雖然觸發器可以用來追蹤表的變更，但不建議這樣做，因為：

  • 觸發器會對寫入效能造成影響。
  • 觸發器將業務邏輯儲存在資料函式庫中，這不是推薦的做法。
  • 儲存在資料函式庫中的程式碼可能會繞過測試、預發布和佈署的流程。
  • 觸發器只能支援追蹤寫入動作，無法追蹤讀取存取。

安裝和調整 Percona 稽核日誌

Percona 的稽核日誌外掛程式預設未安裝或啟用，可以透過以下命令安裝：

INSTALL PLUGIN audit_log SONAME 'audit_log.so';
SHOW PLUGINS;

該外掛程式允許定義需要追蹤的陳述式動詞，以滿足各種控制需求。同時，也需要決定如何處理其輸出。

檢查稽核日誌外掛程式狀態

可以使用以下命令檢查稽核日誌外掛程式是否啟用：

$ mysql -e "show plugins" | grep -w audit_log | grep -iw active
$ mysqladmin variables | grep -w audit_log_policy | grep -iw queries

處理稽核日誌外掛程式的日誌

稽核日誌外掛程式提供了很大的靈活性，但需要決定如何處理其輸出的日誌。可以將日誌輸出到本地檔案，但這可能會增加造成資料函式庫主機磁碟空間不足的風險。也可以使用外掛程式將輸出傳送到 rsyslog，然後將事件轉發到組織的結構化日誌平台。

結構化日誌的重要性

結構化日誌可以使各種變更追蹤變得更加容易，並且有助於企業實作其稽核需求。圖 13-1 展示了不同操作任務如何將結構化日誌傳送到一個地方，從而使稽核變得更加容易。

圖示說明

此圖示展示了不同操作任務將結構化日誌傳送到一個地方，以簡化稽核流程。

@startuml
skinparam backgroundColor #FEFEFE
skinparam componentStyle rectangle

title MySQL資料函式庫合規與安全最佳實踐

package "資料庫架構" {
    package "應用層" {
        component [連線池] as pool
        component [ORM 框架] as orm
    }

    package "資料庫引擎" {
        component [查詢解析器] as parser
        component [優化器] as optimizer
        component [執行引擎] as executor
    }

    package "儲存層" {
        database [主資料庫] as master
        database [讀取副本] as replica
        database [快取層] as cache
    }
}

pool --> orm : 管理連線
orm --> parser : SQL 查詢
parser --> optimizer : 解析樹
optimizer --> executor : 執行計畫
executor --> master : 寫入操作
executor --> replica : 讀取操作
cache --> executor : 快取命中

master --> replica : 資料同步

note right of cache
  Redis/Memcached
  減少資料庫負載
end note

@enduml

程式碼範例與解析

以下是一個使用 MySQL 命令檢查稽核日誌外掛程式狀態的例子：

$ mysql -e "show plugins" | grep -w audit_log | grep -iw active

內容解密：

  1. mysql -e "show plugins"：執行 MySQL 命令以顯示目前載入的外掛程式。
  2. grep -w audit_log：過濾出包含 audit_log 的行。
  3. grep -iw active：在過濾結果中進一步找出包含 active 的行，以確認稽核日誌外掛程式是否啟用。

綜上所述，正確設定和使用稽核日誌外掛程式對於滿足合規控制需求至關重要。同時，結構化日誌的使用可以簡化稽核流程，提高企業的合規效率。

資料函式庫合規管理：MySQL 的最佳實踐

在當今的資料驅動世界中，資料函式庫的安全性和合規性是至關重要的。MySQL 作為一個流行的開源資料函式倉管理系統，需要滿足各種合規控制要求，以確保資料的安全和完整性。本篇文章將探討 MySQL 的合規管理，並提供一些最佳實踐。

使用 Percona Audit Log Plugin 進行稽核

Percona Audit Log Plugin 是一個強大的工具，可以幫助您滿足各種合規控制要求。與使用觸發器相比，它是一個更高效的解決方案，並且可以與組態管理和結構化日誌軟體良好整合，從而為多個利益相關者團隊提供有效的解決方案。

設定與儲存稽核日誌

在使用 Percona Audit Log Plugin 時，您需要確保稽核日誌的輸出被正確儲存，即使是臨時儲存在資料函式庫主機上。如果傳輸這些檔案的方法變慢，外掛中緩衝事件的影響可能會影響資料函式庫伺服器的效能。這種故障狀態很難除錯，因為其唯一的症狀是查詢執行變慢。因此，您需要計劃對整個日誌傳輸管道進行混沌測試，以確保其還原能力。

-- 設定 Percona Audit Log Plugin
INSTALL PLUGIN audit_log SONAME 'audit_log.so';
-- 設定稽核日誌的輸出路徑
SET GLOBAL audit_log_file = 'audit.log';

內容解密：

  1. 安裝 Percona Audit Log Plugin：使用 INSTALL PLUGIN 命令安裝外掛。
  2. 設定稽核日誌的輸出路徑：使用 SET GLOBAL 命令設定稽核日誌的輸出檔案路徑。

版本控制與架構變更

在第 6 章中，我們討論了不同的策略和工具，以便於大規模執行架構變更。現在，讓我們來談談這些策略所啟用的合規問題。使用版本控制來跟蹤和執行架構變更，可以內建跟蹤誰請求了變更、誰審查和批准了變更，以及如何在生產環境中執行變更。

為每個資料函式庫叢集使用單獨的儲存函式庫

隨著公司中的資料函式庫規模不斷增長，您會發現並非所有資料函式庫都是一樣的。有些需要更嚴格的合規性（例如，持有財務資料的資料函式庫），而有些則用於產品實驗，重要性較低。在進行稽核時，擁有每個資料集和叢集的變更記錄將非常方便。

資料函式庫使用者管理

對資料函式庫的變更不僅限於架構變更。您還需要以可跟蹤和可重複的方式管理資料函式庫使用者及其細粒度許可權。讓我們來看看如何滿足一些常見的合規控制要求，這些要求涉及資料庫存取控制。

使用組態管理

使資料函式庫使用者跟蹤符合規範的一個簡單方法是利用您用於使資料函式庫組態變更符合規範的相同流程。您可以在組態管理儲存函式庫中管理所有內容，並使用原始碼控制、提取請求流程和同行評審來提供證據，證明所有對資料函式庫使用者的變更都是以可稽核和可跟蹤的方式進行的。

計劃憑證輪換

無論是因為非計劃的安全事件還是因為您有一個需要按計劃輪換憑證的控制項，您都需要有一個計劃來輪換資料函式庫使用者，而不會影回應用程式的正常執行時間。這可能意味著更改應用程式使用的使用者名稱和密碼字串。

輪換資料函式庫使用者憑證的步驟：
  1. 在資料函式庫中引入新的使用者名稱/密碼對。
  2. 測試新憑證是否具有與舊憑證相同的存取許可權。理想情況下，您可以透過比較 SHOW GRANTS 的結果並確認許可權相同來自動執行此操作。
  3. 建立應用程式佈署，以替換應用程式組態中的憑證。
  4. 重新啟動所有服務例項，以確保新憑證正在使用中。
  5. 刪除舊的使用者名稱和密碼對。
-- 建立新的資料函式庫使用者
CREATE USER 'newuser'@'%' IDENTIFIED BY 'newpassword';
-- 賦予新使用者與舊使用者相同的許可權
GRANT SELECT, INSERT, UPDATE ON *.* TO 'newuser'@'%';
-- 檢查新使用者的許可權是否與舊使用者相同
SHOW GRANTS FOR 'newuser'@'%';
SHOW GRANTS FOR 'olduser'@'%';

內容解密：

  1. 建立新的資料函式庫使用者：使用 CREATE USER 命令建立新的使用者。
  2. 賦予新使用者許可權：使用 GRANT 命令賦予新使用者與舊使用者相同的許可權。
  3. 檢查新使用者的許可權：使用 SHOW GRANTS 命令檢查新使用者的許可權是否與舊使用者相同。

資料函式庫合規管理與備份策略

在滿足公司合規需求的過程中，我們會發現許多合規控制措施要求組織追蹤特定資產的任何變更。這些控制措施常見於SOC 2報告中，主要關注提供資料完整性和安全性的證據。

追蹤資料函式庫使用者活動

要確定定義的資料函式庫使用者是否正在使用，有幾種方法可以實作。我們在第3章中詳細介紹了Performance Schema，用於檢查伺服器效能。其中，users表格儲存了曾經連線到伺服的使用者的歷史資訊。這個歷史記錄的儲存時間取決於伺服器程式的生命週期或該表格的最大允許大小。

啟用Performance Schema中的使用者連線監控

mysql> UPDATE performance_schema.setup_instruments
    -> SET ENABLED='YES' WHERE NAME='memory/sql/user_conn';
Query OK, 1 rows affected (0.00 sec)
Rows matched: 1 Changed: 1 Warnings: 0

內容解密：

  1. 這段SQL指令用於啟用Performance Schema中的特定監控工具。
  2. NAME='memory/sql/user_conn'指定了要啟用的監控項，代表與使用者連線相關的記憶體分配。
  3. ENABLED='YES'表示啟用該監控項，以便收集相關效能資料。
  4. 這種設定對於追蹤使用者活動和系統效能至關重要。

一旦啟用，performance_schema.users表格就可以用來查詢相關資訊。如果使用稽核日誌解決方案，例如Percona的外掛程式，可以利用這些日誌來判斷使用者是否在特定時間內連線到例項。

設定使用者帳號清理政策

建議設定一個政策：「六個月內未活動的資料函式庫使用者將被移除」。這有助於防止不必要的存取許可權，減少潛在的安全風險。

合規控制與備份還原程式

管理的資料函式庫將納入需要嚴格合規控制的範圍。隨著公司趨於成熟並考慮提高合規性，需要提供證據，證明生產環境中的資料函式庫變更經過審核和追蹤。此外，還需要證明在發生災難性事件時能夠還原資料和服務的能力，這就需要依賴備份和還原程式。

自動化備份與測試

為滿足合規要求，需要：

  • 自動執行備份程式。
  • 當備份失敗時發出警示。
  • 自動執行備份測試。
  • 對失敗的備份測試進行追蹤。

排程備份與備份測試

需要一種機制，不僅能按排程執行任務，還能將事件傳送到監控系統和工單系統，以便在失敗時發出警示並進行追蹤。可以將備份和備份測試作為監控檢查來執行，但需確保監控系統能夠處理長時間執行的任務。

如果監控系統無法處理長時間任務，可以採用「麵包屑」策略，例如建立一個包含時間戳記的檔案，在每次備份或備份測試結束時更新，以證明任務已完成。

合規控制的核心目標

最終目標是建立備份成功和失敗的完整記錄，並將失敗轉化為可追蹤的工作專案，以滿足SOC 2控制的要求。這不僅是合規的需要，也是確保資料安全性和可用性的關鍵措施。

玄貓 BlackCat

玄貓 BlackCat

技術愛好者，專注於分享程式開發、雲端技術與 AI 應用的心得體會。