有这个有趣的问题我不能解决我自己。如果你帮我，我会很高兴。
这是它：
有很多客户端应用程序发送数据记录到一个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