从 Aurora MySQL 版本 3 升级到版本 8.4 时的安全注意事项

从 Aurora MySQL 版本 3（与 MySQL 8.0 兼容）迁移到 Aurora MySQL 版本 8.4 时，您需要仔细规划和考虑多个与安全性相关的重要更改。本指南概述了关键的安全性更改，并给出了帮助您顺利迁移的建议。

身份验证策略（8.4 中新增）

Aurora MySQL 版本 3（与 MySQL 8.0 兼容）使用 default_authentication_plugin 参数，配置在创建数据库用户时使用的默认身份验证插件。在 Aurora MySQL 版本 8.4 中，此参数被 authentication_policy 替换并默认设置为 *:caching_sha2_password。

Aurora MySQL 中支持的值：

如果源集群的 default_authentication_plugin 已设置为 mysql_native_password，则 deprecatedDefaultAuth 会发出警告。升级时，请检查此警告并在目标集群参数组上配置 authentication_policy 参数。

主用户行为

新集群

在集群创建时，使用 authentication_policy 参数设置的身份验证插件创建主用户。如果您使用默认参数组，则使用 caching_sha2_password 身份验证插件创建主用户。如果您使用自定义参数组并将 authentication_policy 参数设置为 *:mysql_native_password，则使用 mysql_native_password 身份验证插件创建主用户。

主用户密码重置

当您通过 AWS 管理控制台、CLI（modify-db-cluster --master-user-password）或 API 重置主用户密码时，Aurora 使用重置时的 authentication_policy 参数定义的当前默认插件。

Secrets Manager 和密码轮换

使用 AWS Secrets Manager 管理主用户密码时，如果您更新 authentication_policy 参数的值，则下一次密码轮换将设置主用户的身份验证插件以匹配新的 authentication_policy 参数值。

升级后创建的数据库用户

升级后，使用 mysql_native_password 身份验证插件的现有数据库用户可以继续使用。在升级后创建但未指定 IDENTIFIED WITH 子句的数据库用户将使用 authentication_policy 参数定义的身份验证插件。当参数使用默认值 *:caching_sha2_password 时，将通过 caching_sha2_password 身份验证插件创建新用户。

要更改所有新用户的默认身份验证插件，请更新 authentication_policy 的值。有关支持的值的更多信息，请参阅身份验证策略（8.4 中新增）。

要使用不同于默认值的身份验证插件创建用户，请在 CREATE USER 语句中明确指定插件：

CREATE USER 'username'@'host' IDENTIFIED WITH authentication-plugin BY 'password';

加密和 TLS 更改

对于所有与 Aurora MySQL 数据库集群建立的用户连接，如需要求使用 TLS，请使用 require_secure_transport 数据库集群参数。默认情况下，在 Aurora MySQL 版本 8.4 中，此参数设置为 ON。

Aurora MySQL 版本 8.4 强制执行更严格的加密标准，该标准与 ssl_ciphers（TLS 1.2）和 tls_ciphersuites（TLS 1.3）数据库集群参数的最新安全要求保持一致。有关更多信息，请参阅 使用 Amazon Aurora MySQL 实现高安全性。

为防止连接中断，请在迁移之前，验证 MySQL 客户端和目标数据库集群的 TLS 配置。

密码验证组件迁移

Aurora MySQL 版本 8.4 引入了 aurora_enable_validate_password_component 集群参数，用于启用或禁用 validate_password 组件，这样就无需手动安装或卸载该组件。如果您之前已安装 validate_password 插件并在升级后启用了该组件，则只有该组件才会生效，插件会被忽略。

从 Aurora MySQL 版本 8.4 开始，如果您之前使用 INSTALL PLUGIN 命令安装了 validate_password 插件，则可以启用参数 aurora_enable_validate_password_component 来迁移到 validate_password 组件，然后在写入器实例上通过 UNINSTALL PLUGIN 命令删除插件。

如果您之前使用 INSTALL COMPONENT 'file://component_validate_password' 手动安装了 validate_password 组件，请确保升级时在目标数据库集群参数组中设置了 aurora_enable_validate_password_component 参数。升级后，该组件将不再在 mysql.component 表中列出。您可以使用 aurora_enable_validate_password_component 全局变量来验证组件的状态。

升级后首次启动数据库引擎时，如果您之前手动安装了该组件，则在 MySQL 错误日志中会看到以下消息：

Component 'file://component_validate_password' is being removed from mysql.component table.
validate_password component can be enabled/disabled through 'aurora_enable_validate_password_component' cluster parameter.

如果源集群上安装了 validate_password 插件，则升级预检查 auroraValidatePasswordPluginCheck 会发出警告。此警告不会阻止升级，但您应计划在升级后转为使用组件。

新增动态权限

Aurora MySQL 版本 8.4 支持以下新权限：

对于您的主用户账户，在升级时这些权限将自动授予到主用户账户权限。

rdsproxyadmin 的受保护用户强制实施

从 Aurora MySQL 版本 8.4.7 开始，rdsproxyadmin 是受保护的用户。引擎拒绝任意主机上针对 rdsproxyadmin 的 CREATE、DROP、RENAME、GRANT、REVOKE 和 SET PASSWORD 操作。有关被拒绝操作和错误示例的完整列表，请参阅 Aurora MySQL 中的预留用户。

Aurora MySQL 版本 3 不预留 rdsproxyadmin 名称。如果您在版本 3 中创建了名为 rdsproxyadmin 的数据库用户（而不是在注册代理目标时让系统创建），在升级到版本 8.4 之前请查看此部分。

升级之前

如果您在版本 3 集群中创建了 rdsproxyadmin 用户，请在升级到版本 8.4 之前重命名或删除该账户。您可以使用版本 3 连接来运行以下语句之一：

-- Rename the existing account to a non-reserved name
RENAME USER 'rdsproxyadmin'@'host' TO 'new_user'@'host';

-- Or drop the account if it is no longer needed
DROP USER 'rdsproxyadmin'@'host';

在开始升级之前，请更新引用了旧用户名的所有应用程序或存储的凭证。

当您在升级之前没有重命名或删除该用户时

如果您升级的集群已具有您创建的 rdsproxyadmin 用户，则升级成功完成。该账户将保留其现有密码和权限，您仍然可以使用原始密码，像 rdsproxyadmin 一样连接到集群。

但在升级后，您将无法修改该账户。如果您尝试对 rdsproxyadmin 执行删除、重命名、修改权限或修改密码的操作，语句会返回错误。

如果您想在升级后删除该账户，或收回 rdsproxyadmin 名称以供 RDS 代理使用，请联系 AWS Support。AWS支持团队可以移除从版本 3 中转移过来的先前存在的 rdsproxyadmin 用户。