长期以来，数据库一直是你的平衡架构的重要组成部分，并且可以说是最重要的部分。
如今，压力已经朝向你的大部分一次性和无状态的基础设施，这给你的数据库带来了更大的负担，既要可靠又安全，因为所有其他服务器不可避免地会连同其余数据一起在数据库中存储有状态信息。
你的数据库是每个攻击者想要获取的大奖。
随着攻击变得更加复杂和网络变得更加敌对，采取额外步骤来强化数据库比以往任何时候都更加重要。
MySQL 因其速度和整体易用性而成为开发人员和管理员最受欢迎和喜爱的数据库。不幸的是，这种易用性是以牺牲安全为代价的。即使 MySQL 可以配置有严格的安全控制，你的普通默认 MySQL 配置可能不会使用它们。在本文中，我将介绍强化 MySQL 数据库应采取的五个重要步骤。
第一步：设置强密码
对于所有数据库用户来说，使用强密码很重要。
鉴于大多数人不会经常手动登录数据库，请使用密码管理器或命令行工具 pwgen 为你的数据库帐户创建一个随机的 20 个字符的密码。
即使你使用额外的 MySQL 访问控制来限制特定帐户可以登录的位置（例如将帐户严格限制为 localhost），这依然很重要。
设置密码的最重要的 MySQL 帐户是 root 用户。默认情况下，在许多系统中，该用户没有密码。
特别是，基于 Red Hat 的系统在安装 MySQL 时不会设置密码；
虽然基于 Debian 的系统会在交互式安装期间提示您输入密码，但非交互式安装（就像您可能使用配置管理器执行的那样）会跳过它。
此外，你仍然可以在交互式安装期间跳过设置密码。
你可能认为让 root 用户不输入密码并不是什么大的安全风险。
毕竟，用户设置为 “[email protected]”，你可能认为这意味着你必须先 root 计算机，然后才能成为该用户。不幸的是，这意味着任何可以从 localhost 触发 MySQL 客户端的用户都可以使用以下命令以 MySQL root 用户身份登录：
*$ mysql — user root*
因此，如果你不为 root 用户设置密码，那么任何能够在您的 MySQL 机器上获得本地 shell 的人现在都可以完全控制你的数据库。
要修复此漏洞，请使用 mysqladmin 命令为 root 用户设置密码：
$ sudo mysqladmin password
不幸的是，MySQL 以 root 用户身份运行后台任务。一旦你设置了密码，这些任务就会中断，除非采取额外的步骤将密码硬编码到 /root/.my.cnf 文件中：
[mysqladmin]user = rootpassword = yourpassword
但是，这意味着你必须将密码以纯文本形式存储在主机上。
但是你至少可以使用 Unix 文件权限将对该文件的访问限制为仅 root 用户：
$ sudo chown root:root /root/.my.cnf$ sudo chmod 0600 /root/.my.cnf
第二步：删除匿名用户
匿名帐户是既没有用户名也没有密码的 MySQL 帐户。你不希望攻击者在没有密码的情况下对你的数据库进行任何形式的访问，因此请在此命令的输出中查找使用空白用户名记录的任何 MySQL 用户：
> SELECT Host, User FROM mysql.user;+ — — — — — — — — — — — — + — — — -+| Host | User |+ — — — — — — — — — — — — + — — — -+| 127.0.0.1 | root || ::1 | root || localhost | || localhost | root |+ — — — — — — — — — — — — + — — — -+4 rows in set (0.00 sec)
在这些根用户中间有一个匿名用户（ localhost ），它在 User 列中为空。
你可以使用下面命令清除特定的匿名用户：
> drop user ""@"localhost";> flush privileges;
如果你发现任何其他匿名用户，请确保将其删除。
第三步：遵循最小特权原则
最小特权原则是一项安全原则，可以总结如下：
只为账户提供执行作业所需的访问权限，而不提供更多权限。
此原则可以通过多种方式应用于 MySQL。
首先当使用 GRANT 命令向特定用户添加数据库权限时，请确保仅限制该用户需要访问数据库的权限：
> grant all privileges on mydb.* to someuser@"localhost" identified by 'astrongpassword';> flush privileges;
如果该用户只需要访问一个特定的表（例如，users 表），用 mydb.users 或者任何你的表的名字替换 mydb.*（授予对所有表的权限）。
许多人会授予用户对数据库的完全访问权限；
但是如果你的数据库用户仅仅只需要读取数据而不需要更改数据，则需要额外的步骤授予对数据库的只读访问权限：
> grant select privileges on mydb.* to someuser@"localhost" identified by 'astrongpassword';> flush privileges;
最后，许多数据库用户不会从 localhost 访问数据库，通常管理员会创建他们，
像这样：
> grant all privileges on mydb.* to someuser@"%" identified by 'astrongpassword';> flush privileges;
这将允许 「someuser」从任何网络访问数据库。
但是，如果你有一组定义明确的内部 IP，或者 - 甚至更好 - 已经设置了 VLANS ，以便你所有应用程序服务器与其它主机位于不同的子网中，那么就可以利用这个优势来限制 「someuser」，使得该账户只能从特定网络访问数据库：
> grant all privileges on mydb.* to someuser@10.0.1.0/255.255.255.0 identified by 'astrongpassword';> flush privileges;
第四步：启用 TLS
设置强密码仅只有攻击者可以在网络上读取你的密码或者其他敏感数据的情况下才能达到此目的。
因此，使用 TLS 保护你的所有网络流量比以往任何时候都更加重要。
MySQL 也不例外。幸运的是，在 MySQL 中启用 TLS 比较简单。
一旦你有了你的主机的有效证书，只需要在你的主 my.cnf 文件的 [mysqld] 部分添加以下几行 ：
[mysqld]ssl-ca=/path/to/ca.crtssl-cert=/path/to/server.crtssl-key=/path/to/server.key
为了额外的安全性，还可以添加 ssl-cipher 配置选项，其中包含一个被认可的密码列表，而不是只接受默认的密码列表，这可能包括较弱的 TLS 密码。
我推荐使用 Mozilla Security/Server Side TLS page 所推荐的现代或者中级密码套件。
一旦服务器端设置了 TLS ，你可以限制客户端必须采用 TLS 进行连接，通过在 GRANT 语句中添加 REQUIRE SSL :
> grant all privileges on mydb.* to [email protected]/255.255.255.0 identified by 'astrongpassword' REQUIRE SSL;> flush privileges;
第五步：加密数据库密钥
虽然现在很多人都知道使用单向散列（理想情况下是像 bcrypt 这样慢速散列 ），保护用户数据库存储的密码有多重要，但通常没过多考虑使用加密来保护数据库上其他的敏感数据。
事实上，许多管理员会告诉你他们的数据库是加密的，因为磁盘本身是加密的。
这实际上会影响你的数据库加固，不是因为磁盘加固有缺陷或糟糕的做法，而是因为它会给你一种错误的信任感。
磁盘加密保护你的数据库数据，以防止有人从你的服务器窃取磁盘（或者你买了二手磁盘后忘记擦除磁盘），但是磁盘加密并不能在数据库本身运行时保护你，因为驱动器需要处于解密状态才能被读取。
要保护数据库中的数据，你需要采取额外的措施，在存储敏感字段之前对它们进行加密。
这样如果攻击者找到了某种方法来转存完整的数据库，你的敏感字段仍然会受到保护。
有许多加密数据库中字段的方法，而且 MySQL 支持本地加密命令。
无论你采取哪种加密方法，我都建议避免你需要将解密密钥存储在数据库本身的加密方法。
理想情况下，你会把解密的密钥存储在应用服务器上，作为本地 GPG 密钥（如果你使用 GPG 进行加密）或者将其存储为应用程序服务器上的环境变量。
这样即使攻击者可能找到一种方法来破坏应用程序服务器的服务器，他也必须将攻击转换为本地 shell 访问，以此来获取你的解密密钥。
MySQL 加固原则：掌握最小权限原则
有很多方法来锁定你的 MySQL 服务器。
确切地说，你如何实施这些步骤取决于你如何设置自己的数据库，以及它在网络中的位置。
虽然前面的五个步骤将有助于保护你的数据库，但我认为更需要掌握的最重要的整体步骤是最小权限原则。
你的数据库可能存储来一些非常有用的数据，如果你确保用户和应用程序只具有执行其工作的所需的最小访问权限，那么你将限制攻击者能够做什么，如果黑客找到来危害该用户或者应用程序的方法。
