有這個有趣的問題我不能解決我自己。如果你幫我，我會很高興。
這是它：
有很多客戶端應用程序發送數據記錄到一個MySQL服務器。
很少有數據記錄不是很重要，但整個數據庫是。 （你能想象這是Facebook的DB :)）
有什麼辦法，以保證從DB保持數據庫信息安全
假設攻擊者可以神祕地獲得對服務器的完全訪問權嗎？
您不能簡單地加密數據客戶端並將其加密存儲，因爲客戶端應用程序是廣泛傳播的，攻擊者可以從中獲取密鑰。
也許在應用程序和數據庫之間添加一些層，或者將客戶端和服務器端的加密方法（使用mysql內置方法）相結合將有所幫助？
只要數據庫需要啓動並無人值守運行，您就無法將密鑰從受損的root帳戶（='神祕的完全訪問'）中隱藏起來。在數據庫可能存儲主密鑰的地方，根目錄也可以訪問。沒有任何數量的業務層或客戶端 - 服務器加密組合會繞過這個簡單的事實。你可以混淆它直到第二天，但如果獎品是值得的，那麼根可以得到它。
一種替代方法是需要手動輔助啓動過程，即。一個人在服務器啓動（或硬件模塊PIN）期間輸入主密鑰密碼，但這在現實世界中難以維護，它需要一個非常值得信賴的員工在尋呼機呼叫時登錄並在任何時候啓動數據庫停機時間。
像TPM這樣的解決方案可以防止服務器的物理損失，但不會對受損的根目錄造成損害。
您的根與數據庫主密鑰一樣重要，所以您必須像密鑰一樣小心保護您的根。這意味着設置操作程序，篩選可以訪問root的用戶，旋轉root密碼等等。一旦有人獲得「神祕的完全訪問權限」，遊戲幾乎失去了。
我不知道這樣的事情是否存在於MySql中，但是Oracle中的行級版本控制使您能夠在行級定義訪問權限IN數據庫：這意味着，無論使用什麼工具被用來訪問數據，用戶只能看到由他/她的憑據確定的相同選擇。
因此，如果我的用戶名/角色只允許查看受某些WHERE子句限制的數據，那麼它可以附加到出現在數據庫中的每個SELECT，而不管它是否來自Web應用程序，SQL查詢工具， 管他呢。
好吧，如果攻擊者獲得對數據庫的完全訪問權（如sysdba/SA），那麼它不值得... – Dani 2009-11-08 17:26:23
我會在它們之間使用第二層和firwall。 所以你有防火牆----網絡服務器---防火牆---第二層服務器---防火牆---分區
在層之間使用不同的平臺是明智的，這一切都取決於多麼重要數據。無論如何， - Web服務器應該無法訪問數據庫。
關於保存排序 - 如果您使用文件encrypotion mechisim - 它只會保護您免受硬盤驅動器的影響。 如果你自己加密數據，如果你巧妙地做到這一點（將密鑰存儲在一個單獨的地方），你將不會失去排序，因爲你會尋找加密條目，而不是真正的 - 但現在你有另一件事保護....
分類和查找加密值：一個好的加密方案應該改變每次使用的密鑰IV意味着即使對於相同的明文，加密文本每次都會更改，因此無法對其進行排序或查找加密值。如果每次使用密鑰都不改變IV，那麼你會打開自己的一些攻擊，特別是嬰兒牀攻擊：http://en.wikipedia.org/wiki/Crib_%28cryptanalysis%29 – 2009-11-08 17:54:25
順便說一句，我的評論是有效的如果你逐個加密表項。對於批量加密方案（文件加密，卷加密或透明數據庫加密），加密後將保留所有排序和查找特徵，因爲該過程對於數據庫是透明的。我想我第一次評論時誤解了你的答案。 – 2009-11-08 17:59:26
因此，這將成爲NONCE（每筆交易的新IV）的主要原因，太多的數據中心擁有「硬殼和軟，耐嚼的中心」，但是如果每筆交易都有一個標題（例如說）[bigFish @ smallpond。數據] - 然後即使使用cbc或cfc也應該爲傳輸提供一個模式。 （No？）即使在破損的根目錄下，唯一的解決方案是遠程清理KeyStore（我猜是使用散列+密碼）。即使如此，人類心智可能是入侵路由的選擇 - db應該只使用前饋，所以在那裏不是擦除大道。 – 2009-11-08 23:56:36
我非常同意Remus Rusanu的回答。
保持良好的安全性很困難，但您可以隨時關注您的工作。當您訪問敏感信息時，請仔細驗證您的查詢，並確保它不能被欺騙或利用來訪問給定客戶無法訪問的信息。
如果您可以推出攻擊者對盒子的物理訪問權限，那麼您可以採取幾項措施來加強安全性。首先，我只配置ssh訪問權限，只允許來自特定IP或IP範圍的連接（當然，沒有root權限）。你也可以在你的防火牆上做到這一點。這意味着最薄弱的環節就是你的服務器（從客戶端接收數據/請求的應用程序，可能是網絡服務器以及你使用的任何腳本）。現在你「只是」必須確保沒有人可以利用你的服務器。你可以做更多的事情來加固你的系統，但它認爲在ServerFault上詢問會更合適。
如果您擔心物理訪問PC，那麼您可以做的事情並不多，在Remus的答案中已經提到了大部分內容。
還有另一種選擇。從速度和易用性來看，這是迄今爲止最無效的方法來開發視點，但它會部分保護您免受任何類型的服務器攻擊（包括物理攻擊）。它實際上很簡單，但實現起來有點難 - 只將加密數據存儲在數據庫中，並使用JavaScript或Flash處理所有加密/解密客戶端。只有客戶端將密鑰和數據總是通過網絡傳輸並以加密格式存儲。最大的缺點是，一旦客戶忘記密鑰，就無法返回，數據無法訪問。
當然，這都是時間，金錢和努力的問題 - 有足夠的這些東西可以被打破。
謝謝，承認這些事實令我難過，但我想這就是事情的真相。數據傳輸鏈中沒有安全的地方。 – bizzz 2009-11-08 19:33:58
有趣的是，Remus已經在這上面得到了芥末和土豆。剛剛發現這篇引用Funky Business Inspector - >（由於金融機構缺乏控制或第三方提供商級別而導致銀行系統入侵的風險）的引用（來自HelpNet Security）。「加密，加密，強大的隔離以及其他所有可以解決問題的方法都只能在包括所謂的do-gooders的矩陣中使用。唯一的解決辦法是將風險限制爲可分配給風險池的金額，即保險業已知的做法。 – 2009-11-08 23:01:58