【MySQL精通之路】安全(2)-密码安全

密码出现在MySQL中的多个上下文中。

以下部分提供了一些指导原则，使最终用户和管理员能够确保这些密码的安全并避免暴露这些密码。

此外，validate_password插件可用于强制执行可接受密码的策略。

请参阅“密码验证组件”。

1.密码安全的最终用户指南

MySQL用户应该使用以下准则来保护密码的安全。

当您运行客户端程序以连接到MySQL服务器时，不建议以将密码暴露给其他用户发现的方式指定密码。

此处列出了运行客户端程序时可以用于指定密码的方法，以及对每种方法的风险评估。

简而言之，最安全的方法是让客户端程序提示输入密码，或者在受适当保护的配置文件中指定密码。

使用mysql_config_editor实用程序，可以将身份验证凭据存储在名为.mylogin.cnf的加密登录路径文件中。

MySQL客户端程序稍后可以读取该文件，以获取连接到MySQL Server的身份验证凭据。

请参阅“mysql_config_editor--mysql配置实用程序”。

【MySQL精通之路】管理和实用程序-MySQL配置实用程序-mysql_config_editor-CSDN博客

---

在命令行中使用--password=password或-password选项。例如

$> mysql -u francis -pfrank db_name

警告：
这很方便，但不安全。在某些系统上，您的密码对系统状态程序（如ps）可见，其他用户可能会调用这些程序来显示命令行。

MySQL客户端在初始化过程中通常会用零覆盖命令行密码参数。

但是，仍有一个短暂的时间间隔，在此期间该值是可见的。

此外，在一些系统上，这种覆盖策略是无效的，密码对ps仍然可见。（SystemV Unix系统和其他系统可能会遇到这个问题。）

如果您的操作环境设置为在终端窗口的标题栏中显示当前命令，则只要该命令正在运行，即使该命令已滚动到窗口内容区域的视图之外，密码也会保持可见。

---

在没有指定密码值的情况下，在命令行中使用--password或-p选项。在这种情况下，客户端程序以交互方式请求密码：

$> mysql -u francis -p db_name
Enter password: ********

*字符表示您输入密码的位置。

输入密码时不会显示密码。

这样输入密码比在命令行中指定密码更安全，因为其他用户看不到密码。

但是，这种输入密码的方法仅适用于交互式运行的程序。

如果要从非交互运行的脚本中调用客户端，则无法通过键盘输入密码。

在某些系统上，您甚至可能发现脚本的第一行被读取并被（错误地）解释为密码。

---

将您的密码存储在配置文件中。

例如，在Unix上，您可以在主目录中.my.cnf文件的[client]部分列出您的密码：

[client]
password=password

为了确保密码的安全，除了你自己，任何人都不应该访问该文件。要确保这一点，请将文件访问模式设置为400或600。例如

$> chmod 600 .my.cnf

要从命令行命名包含密码的特定配置文件，请使用--defaults file=file_name选项，其中file_name是文件的完整路径名。例如

$> mysql --defaults-file=/home/francis/mysql-opts

“使用配置文件”更详细地讨论了配置文件。

【MySQL精通之路】MySQL的使用(2)-配置-CSDN博客

在Unix上，mysql客户端将已执行语句的记录写入历史文件

（请参阅“mysql客户端日志记录”）。

默认情况下，此文件名为.mysql_history，并在主目录中创建。

密码可以在CREATE USER和ALTER USER等SQL语句中以纯文本形式编写，因此，如果使用这些语句，它们将记录在历史文件中。

为了确保此文件的安全，请使用限制性访问模式，与前面对.my.cnf文件所述的方式相同。

如果您的命令解释器维护历史记录，则保存命令的任何文件都包含在命令行上输入的MySQL密码。

例如，bash使用~/.bash_history。任何此类文件都应具有限制性访问模式。

2.密码安全管理员指南

数据库管理员应使用以下准则来保护密码的安全。

MySQL将用户帐户的密码存储在mysql.user 系统表中。

不应将对此表的访问权限授予任何非管理帐户。

帐户密码可能已过期，因此用户必须重置这些密码。

请参阅“密码管理”和“过期密码的服务器处理”。

validate_password插件可用于对可接受的密码强制执行策略。

请参阅“密码验证组件”。

有权修改插件目录（plugin_dir系统变量的值）或指定插件目录位置的my.cnf文件的用户可以替换插件并修改插件提供的功能，包括验证插件。

应该保护可能写入密码的日志文件等文件。参见下文

3.密码和日志记录

密码可以写成SQL语句中的纯文本，如CREATE USER、GRANT和SET PASSWORD。如果MySQL服务器按照编写的方式记录这些语句，那么任何有权访问日志的人都可以看到其中的密码。

语句日志记录避免将密码写入以下语句的明文：

CREATE USER ... IDENTIFIED BY ...
ALTER USER ... IDENTIFIED BY ...
SET PASSWORD ...
START SLAVE ... PASSWORD = ...
START REPLICA ... PASSWORD = ...
CREATE SERVER ... OPTIONS(... PASSWORD ...)
ALTER SERVER ... OPTIONS(... PASSWORD ...)

这些语句中的密码将被重写，使其不会直接出现在写入常规查询日志、慢速查询日志和二进制日志的语句文本中。重写不适用于其他语句。特别是，mysql.user系统表中引用文字密码的INSERT或UPDATE语句会按原样记录，因此应避免使用此类语句。（无论如何，不鼓励直接修改拨款表。）

对于常规查询日志，可以通过使用--log raw选项启动服务器来抑制密码重写。出于安全原因，不建议将此选项用于生产用途。出于诊断目的，查看服务器接收到的语句的确切文本可能很有用。

默认情况下，审核日志插件生成的审核日志文件的内容不会加密，并且可能包含敏感信息，例如SQL语句的文本。出于安全考虑，审核日志文件应写入一个只有MySQL服务器和有正当理由查看日志的用户才能访问的目录。

请参阅“MySQL企业审核安全注意事项”。

如果安装了查询重写插件，服务器接收的语句可能会被重写（请参阅查询重写插件）。

在这种情况下，--log raw选项影响语句日志记录，如下所示：

如果没有--log-raw，服务器将记录查询重写插件返回的语句。这可能与收到的声明不同。

使用--log raw，服务器会将收到的原始语句记录下来。

密码重写的一个含义是，无法解析（例如，由于语法错误）的语句不会写入常规查询日志，因为它们不可能是无密码的。

需要记录所有语句（包括有错误的语句）的用例应该使用--log raw选项，记住这也可以绕过密码重写。

只有当需要纯文本密码时，才会进行密码重写。

对于具有期望密码哈希值的语法的语句，不会发生重写。

如果为这种语法错误地提供了纯文本密码，则会按照给定的方式记录密码，而无需重写。

要保护日志文件不被不必要的暴露，请将它们定位在限制服务器和数据库管理员访问的目录中。

如果服务器登录到mysql数据库中的表，则只将对这些表的访问权限授予数据库管理员。

副本将复制源服务器的密码存储在其连接元数据存储库中，默认情况下，该存储库是mysql数据库中名为slave_master_info的表。

现在不推荐将数据目录中的文件用于连接元数据存储库，但仍然可以（

请参阅“中继日志和复制元数据存储库”）。

确保只有数据库管理员才能访问连接元数据存储库。

将密码存储在连接元数据存储库中的另一种方法是使用START REPLICA

（或MySQL 8.0.22之前的版本，START SLAVE）或START GROUP_REPLICATION语句指定连接到源的凭据。

使用限制访问模式来保护包括日志表或包含密码的日志文件的数据库备份。