强化 MySQL 概览

无需任何粉饰：攻击者可以在数分钟内轻松扫描整个互联网，并在数秒内破解密码。虽然有时需要将数据库设为可通过公共 IP 网络访问，但这会使您的数据库更容易受到攻击。缓解公共 IP 风险的一个方法是限制只有一组有限的 IP 地址访问数据库。

尽管如此，更好的解决方案是仅允许在虚拟私有云 (VPC) 内访问，并仅允许在堡垒主机内进行运维人员连接。在 Google Cloud 中，此解决方案称为专用 IP。如果您的 MySQL 实例只能在 VPC 内访问，那么攻击者必须先破坏 VPC，然后才能尝试破坏您的实例。

每个 MySQL 次要版本都有版本说明，其中几乎总是包含有关安全更新的部分。如果实例有几个版本已过期，那么您的数据库没有多个版本的安全修复程序。

除持续修复安全问题外，MySQL 还定期引入几项全新的安全功能。例如，MySQL 8.0 引入了多种方法来强化 MySQL 架构和用户的安全，例如角色、登录失败跟踪和随机密码生成。

假设您在一家咖啡店工作，想要运行一些查询，因此您通过店里的免费 Wi-Fi 网络连接到 MySQL。如果您没有使用 TLS（传输层安全协议），就相当于通过 TCP（传输控制协议，互联网的主要协议之一）公开了您的用户名和密码。在 MySQL 实例上强制执行 TLS，您就可以一边品尝拿铁咖啡一边工作，而且不必担心有其他客户在网络上窥探数据。

SQL 注入

通常，最容易受到攻击的不是数据库，而是应用。许多应用都成为了 SQL 注入攻击的受害者。SQL 注入攻击是指攻击者插入您的应用认为是有效 SQL 语句的恶意输入。防范此类攻击的最佳保护措施是在创建 SQL 语句时使用准备好的语句，而不是将用户输入与 SQL 语句串联起来。

代码库中的 Secret

由于开发者无意中将其用户名和密码推送到其源代码库中，无数数据库已遭到破坏。请改用 Google Cloud 的 Secret Manager 之类的工具，这些工具可以管理所有类型的 Secret，包括您的数据库密码。

记录密码

最后，使用日志记录框架的过滤工具从应用日志中过滤掉数据库的密码。例如 Log4j Filters 或 Rails ParameterFilter，但大多数日志记录框架都应具有等效项。否则，您需要确保应用日志是安全的，这样数据库才是安全的。

考虑使用密码验证来确保数据库中的所有密码都足够复杂。应用密码应较长且复杂，并经常轮换。Secret Manager 特别有用，因此您无需记住复杂且经常更改的密码。

如果真人（而不是应用）要使用数据库用户，请遵循 NIST 的标准，并将长度放在首位。密码失效日期和过于复杂的密码要求往往会导致人们使用明文文件和便笺来代替记忆，从而破坏这些规则的全部用途。

您还可以考虑对非应用用户利用 IAM 身份验证。IAM 身份验证将连接建立委派给 Google Cloud 的 IAM 产品，这意味着只有 IAM 用户（而不是 IAM 用户和数据库用户）才会面临风险。

最后，MySQL 默认使用哈希，而不是盐（您的数据库密码）。这意味着，具有相同密码的用户将具有相同的身份验证字符串，从而使攻击者能够通过彩虹表攻击轻易破解安全系数低的密码。请注意以下两个 MySQL 用户如何使用相同的 authentication_string。authentication_string

建议将标志 default_authentication_plugin 设置为 cache_sha2_password。这样可以确保密码相同的两名用户具有不同的哈希值。请注意，下例中，两名用户具有不同的 authentication_string 值。

限制访问不仅意味着保护来自外部的访问，而且还意味着定期审核来自内部的访问。

审核您的应用：如果应用仅从结算、产品和客户表中读取数据，它是否真的需要访问其他所有信息？如果授予数据库 root 访问权限，攻击者可能会对您的数据库造成巨大损害。请思考您的实例具有的每项要求，列出它们需要的权限，然后为每项权限创建一个数据库用户。如果某个攻击者以其中一位数据库用户的身份破坏了您的数据库，您将限制受破坏程度。

审核用户：数据库中有多少用户确实需要具备实例的管理员权限？其中有多少用户仍在您的组织中、已关联到非活跃项目或本身处于非活跃状态？访问令牌可能会泄露，而内部威胁是大多数系统长期关注的一个问题。确保尽可能减少用户数量有助于实例防范这类问题。

审核“管理员”：考虑移除或重命名“root”或“admin”之类的用户。对于攻击者而言，这些是轻而易举的目标，如果它们不存在，那么入侵会略为困难。这称为隐晦式安全，虽然它不应成为第一道防线，但可以为您的 MySQL 数据库添加薄薄的一层安全防护。

定期的数据备份和可验证的数据恢复计划对于健康的数据库管理至关重要。但即使定期备份，您仍然可能会丢失上次备份后写入的所有数据。MySQL 生态系统的一项优势是时间点恢复 (PITR)，让您可以随时恢复数据。如需实现 PITR，请在 Cloud SQL for MySQL 实例上启用二进制日志。

如果您已完成上述所有操作，即表示您已做好充分的准备并受到充分的保护。也就是说，如果没有持续的警惕（数据库审核），任何安全设计都是不完整的。Cloud SQL for MySQL 审核插件可帮助您在发生数据泄露时跟踪异常行为。

有了上述措施，攻击者入侵数据库将变得更加困难。攻击者必须入侵您的应用，并希望该应用的数据库用户有足够的权限进行攻击，或者他们必须破坏您的 VPC，找到现有用户名，破解相应密码，并希望用户有足够的特权来运行攻击。在此期间，您可以查看 MySQL 数据库日志或审核日志，以监控数据库的任何常规行为并相应地做出应对。

这就是从设计上保证安全性的意义。攻击者将继续寻找利用机器的方法。正因如此，在设计系统时，您应尽可能多地增加保护措施，以保护数据库。