開源和廉價的“靜態數據”加密解決方案
所以我正在探索一些關於數據庫加密的選項。最好的選擇是商業 (TDE)。我正在尋找一個開源實現。MySQL 和 MariaDB 的最新版本具有靜態數據功能：
MariaDB
https://mariadb.com/kb/en/mariadb/why-encrypt-mariadb-data/
MySQL 5.7.11 帶有 InnoDB 表空間加密
https://dev.mysql.com/doc/refman/5.7/en/innodb-tablespace-encryption.html
在此實施中（對於公司而言）重要的是：這些是否符合 PCI-DSS / HIPAA 等？
來自 MariaDB：
MariaDB file_key_management 外掛允許在文件中配置密鑰。密鑰文件在系統啟動時讀取，執行時無需額外訪問。加密的安全性取決於對密鑰文件的訪問限制。密鑰文件本身可以加密，提供額外的保護層。
從我的角度來看，這意味著在啟動（和作業系統重新啟動）期間提供密鑰的解密？因此，每當我們（重新）啟動系統時，這是否意味著我們需要手動提供此密鑰？讓這個密鑰在伺服器本身上是可讀的，首先會破壞靜態數據加密的使用。
在 MySQL 5.7.11+
非企業版 MySQL 中的 InnoDB 表空間加密功能使用 keyring_file 外掛進行加密密鑰管理，這不是一種合規性解決方案。PCI、FIPS 等安全標準要求使用密鑰管理系統來保護、管理和保護密鑰庫或硬體安全模組 (HSM) 中的加密密鑰。
MySQL 企業版提供了 keyring_okv 外掛，其中包括一個 KMIP 客戶端 (KMIP v1.2)，它與 Oracle Key Vault (OKV) 一起提供加密密鑰管理。OKV 等安全可靠的加密密鑰管理解決方案對於安全性和遵守各種安全標準至關重要。除其他好處外，使用密鑰保管庫可確保密鑰安全儲存、永不失去，並且只有授權的密鑰管理員知道。密鑰保管庫還維護加密密鑰歷史記錄。
現在我想知道，這可以符合安全標準嗎？使用此靜態數據時，root 或 mysql 使用者是否可以訪問密鑰，因為他們可以從記憶體中讀取加密密鑰？
靜態數據
這裡可能存在術語問題。靜態數據加密通常意味著
- 儲存加密
- 不是點對點或任何其他形式的使用數據加密。
關於建議的加密形式，我建議遠離那些特定於 RDBMS 的解決方案，因為它們比PostgreSQL 建議的其他選項測試更少
儲存加密可以在文件系統級別或塊級別執行。Linux 文件系統加密選項包括eCryptfs和 EncFS，而 FreeBSD 使用 PEFS。塊級或全盤加密選項包括 Linux 上的 dm-crypt + LUKS 和 FreeBSD 上的 GEOM 模組 geli 和 gbde。許多其他作業系統支持此功能，包括 Windows。
如果驅動器或整個電腦被盜，此機制可防止從驅動器中讀取未加密的數據。這並不能在掛載文件系統時防止攻擊，因為在掛載時，作業系統會提供未加密的數據視圖。但是，要掛載文件系統，您需要通過某種方式將加密密鑰傳遞給作業系統，有時密鑰儲存在掛載磁碟的主機上的某個位置。
本質上，不同的作業系統和文件系統抽象層提供了一種更好、更好測試的方法來處理靜態數據加密。
是的，這意味著你有一把鑰匙。是的，這意味著如果密鑰被洩露，則可以讀取數據。但是，如果您的數據庫被洩露而不是密鑰，則數據是安全的。而且，這就是為什麼它是靜態數據。
因此，您通常儲存 root 擁有的密鑰。讓 root 安裝安全位置，並讓
postgres使用者訪問該位置。顯然 PostgreSQL 需要訪問數據並且必須知道如何解密它。
postgres現在，如果其他使用者在機器上，除非他們是他們的使用者，否則他們無法訪問數據。此外，他們無法訪問密鑰。如果他們確實設法破壞數據，甚至竊取物理加密備份，他們就無法在沒有密鑰的情況下訪問它。
從 v 5.7.20 開始，（免費）Percona 現在使用儲存在（免費）遠端 HashiCorp Vault 伺服器中的密鑰提供靜態數據加密。文件並不是很容易遵循，但即使我設法讓它執行。
（不幸的是，它沒有滿足我對每個客戶端數據庫擁有 1 個密鑰的要求）