存储在磁盘上的 MySQL 数据库文件是否加密？

不，他们不是。

您可以（相对）轻松地通过将.ibd或.myd文件移动到另一个系统来测试这一点，您仍然可以在其中读取它们。或者您可以直接打开它们，您可能会看到至少一些明文形式的表格内容。

一些 MySQL 引擎确实提供了可选的加密，例如innodb。MySQL 企业版还提供可选的加密。

我可以在不知道我的 MySQL 用户名/密码的情况下直接从这些文件中读取数据吗？

你打赌。

我正在考虑对应用程序中的凭据进行加密和解密，并仅将加密版本存储在数据库中，但这有必要吗？

不要将明文密码存储在您的数据库中，也不要使用对称加密（如果这样做，那么当您的密钥与加密密码一起被盗时，您就会丢失）。

存储密码的方法（在任何地方——无论你将它们存储在平面文件、数据库还是其他地方都无关紧要……）是使用安全的散列函数对它们进行加盐和散列。哈希函数接受一个输入字符串并返回一个固定长度的随机字符串作为输出。您将这个看起来随机的字符串存储在数据库中。

当您想检查是否有人输入了正确的密码时，您可以通过哈希函数运行密码，并根据数据库中的字符串检查结果字符串。

这样，密码就不会暴露（散列函数是单向函数，这意味着您不能不费力气就反转散列函数）。

请注意，仅对密码进行哈希处理是不够的。您必须在对密码进行散列之前将随机盐值连接到密码，然后将散列函数输出和盐值存储在数据库中。您需要这样做有几个原因： 1. 如果您不这样做，那么相同的密码将产生相同的哈希值 2. 有一些时间的人可以预先计算哈希密码表（彩虹表）。使用盐值会使此操作更加昂贵。

有可用于散列密码的散列函数，例如 bcrypt。使用其中一个而不是自己滚动。不要使用标准散列函数，例如 md5 或 sha1。它们都被设计为快速，这与您在密码哈希函数中想要的相反（当密码文件被盗时使暴力攻击更加困难）。

攻击者可以访问此 SQL 的地方

此时，他们已经绕过了您的大部分安全控制并可以访问数据，这通常是攻击的目标（窃取凭据通常是为了访问数据）。用户密码应该被安全地散列（本地 mysql 密码因此保存在数据库中，但可能在应用程序中未加密）。

任何类型的透明加密，例如 LUKS 或 FUSE，对于有权访问正在运行的服务器的攻击者来说也是透明的。

您可能会考虑一些事情，例如散列用户名以使它们更加匿名（考虑 Ashley Maddison 攻击），但如果不了解在游戏的这个阶段您仍在尝试保护什么，很难提出建议。我建议您将注意力集中在防止攻击者走得这么远/检测服务器的潜在危害上会获得更多好处。

Are MySQL database files that are stored on disk encrypted?

不 ，默认情况下 MySQL 不会加密其文件。您不清楚要加密哪种数据，但在您的情况下，最好的解决方案似乎是基于列的加密解决方案。这将允许您加密包含敏感信息的选定列，并为每列定义策略/加密密钥。

一个好的解决方案还应该允许您控制 enc/dec 密钥的生命周期。

所有这些都非常有帮助，特别是对于遵守任何严格的私人数据保护法规。

此解决方案“MyDiamo”是基于列的加密的可行选项，而且定价非常合理。

如果您想要文件级加密，那么我建议您按照上面的建议进行 MySQL Enterprise 加密。