MySQL 8.0 权限审计实战：揪出那些“权力过大”的用户

王义杰
0 阅读5分钟

MySQL 8.0 权限审计实战：揪出那些“权力过大”的用户 在日常的运维和开发工作中，数据库的安全性是我们绝对不能忽视的一环。随着攻击手段的日益多样化，仅仅设置一个复杂的密码是远远不够的。我们需要定期对数据库的权限进行审计和加固，遵循“最小权限原则”（Principle of Least Privilege），确保每个用户只拥有其完成工作所必需的最小权限。

在 MySQL 8.0 中，权限管理变得更加精细。今天，我将带大家通过几个简单的 SQL 查询，快速锁定两类高风险用户：

  1. 拥有 GRANT OPTION 权限的用户。
  2. 被赋予了特定超级管理员角色的用户（以 rds_superuser_role 为例）。

image.png

一、 揪出拥有“授权”权限的用户

什么是 GRANT OPTION？

GRANT OPTION 是一个非常危险的权限。如果一个用户拥有此权限，他不仅可以自己执行某个操作，还可以将自己拥有的权限授予给其他用户。想象一下，如果一个普通的业务用户 dev_user 意外获得了 GRANT OPTION，他就可以“克隆”自己的权限给任意其他用户，这很容易导致权限失控，为数据库埋下巨大的安全隐患。

因此，定期排查哪些用户拥有此权限至关重要。

如何查询？

在 MySQL 中，用户信息和全局权限存储在 mysql.user 这张系统表中。我们可以直接查询这张表来找到答案。

示例查询语句：

-- 查询所有拥有 GRANT OPTION 权限的用户
SELECT 
    `User`, 
    `Host` 
FROM 
    mysql.user 
WHERE 
    `Grant_priv` = 'Y';

查询结果解析：

执行上述查询后，我们会得到一个列表，其中包含了所有 Grant_priv 字段为 'Y' 的用户及其主机。这个列表上的每一个用户都值得我们重新审视。

实用建议：

  • 严格控制授权：GRANT OPTION 权限通常只应该由数据库管理员（DBA）专属的账号持有。任何业务用户、应用程序账号都不应该拥有此权限。
  • 定期审计：将这个查询做成一个自动化的监控脚本，定期运行并生成报告。一旦发现非预期的用户出现在列表中，立即告警并进行处理。

二、 定位拥有特定角色的用户

MySQL 8.0 引入了“角色”（Role）的概念，它是权限的集合。我们可以将一组权限打包成一个角色，然后将这个角色赋予用户，极大地简化了权限管理。然而，这也意味着一些高权限角色（如 AWS RDS 中常见的 rds_superuser_role）需要被我们重点监控。

什么是 rds_superuser_role？

在很多云数据库服务（如 AWS RDS）中，出于安全和管理的考虑，它们不会直接提供完整的 SUPER 权限，而是提供一个类似 rds_superuser_role 的角色，它打包了一系列高权限操作。拥有这个角色的用户，基本上就是这个数据库实例的“超级管理员”。

如何查询？

用户的角色分配信息存储在 mysql.role_edges 系统表中。这张表记录了哪个用户（TO_USER）被授予了哪个角色（FROM_USER）。

示例查询语句：

-- 查询所有被授予了 'rds_superuser_role' 角色的用户
-- 注意：在 MySQL 中，用户和角色都存储在用户表中，因此这里的 FROM_USER 是角色名，TO_USER 是用户名。
SELECT 
    `TO_USER` AS '用户名',
    `TO_HOST` AS '主机'
FROM 
    mysql.role_edges 
WHERE 
    `FROM_USER` = 'rds_superuser_role';

查询结果解析：

这条查询会返回所有被赋予了 rds_superuser_role 角色的用户名和主机。这个列表同样需要我们高度关注。 GRANT SELECT, INSERT, UPDATE, DELETE, CREATE, DROP, RELOAD, PROCESS, REFERENCES, INDEX, ALTER, SHOW DATABASES, CREATE TEMPORARY TABLES, LOCK TABLES, EXECUTE, REPLICATION SLAVE, REPLICATION CLIENT, CREATE VIEW, SHOW VIEW, CREATE ROUTINE, ALTER ROUTINE, CREATE USER, EVENT, TRIGGER, CREATE ROLE, DROP ROLE ON . TO rds_superuser_role@% WITH GRANT OPTION | | GRANT APPLICATION_PASSWORD_ADMIN,FLUSH_OPTIMIZER_COSTS,FLUSH_STATUS,FLUSH_TABLES,FLUSH_USER_RESOURCES,ROLE_ADMIN,SENSITIVE_VARIABLES_OBSERVER,SESSION_VARIABLES_ADMIN,SET_USER_ID,SHOW_ROUTINE,XA_RECOVER_ADMIN ON . TO rds_superuser_role@% WITH GRANT OPTION

实用建议：

  • 理解角色权限：在审计之前，首先要清楚这个角色到底包含了哪些具体权限。我们可以使用 SHOW GRANTS FOR 'rds_superuser_role'@'%'; 来查看一个角色的具体权限列表。
  • 最小化超级角色：与 GRANT OPTION 类似，只有极少数的管理账号才应该拥有这类“超级角色”。确保你的应用程序账号、普通开发人员账号没有被错误地赋予此类角色。
  • 使用定制角色：与其给用户一个权限过大的“超级角色”，不如根据业务需求创建粒度更细的自定义角色。例如，创建一个 readonly_role 用于只读操作，创建一个 backup_role 用于备份操作，然后按需分配。

总结

数据库安全不是一劳永逸的，它是一场需要持续投入的“攻防战”。通过今天分享的两条简单的 SQL 查询，可以快速地对 MySQL 8.0 的权限进行一次有效的“体检”。

  1. 审计 GRANT OPTION：通过查询 mysql.user 表，确保授权权限没有被滥用。
  2. 审计高权限角色：通过查询 mysql.role_edges 表，确保类似 rds_superuser_role 这样的超级管理员角色只掌握在少数可信的管理员手中。

将这些检查融入我们的日常运维流程中，定期执行，就能极大地降低因权限配置不当而带来的安全风险。希望这篇文章能帮助大家更好地守护你的数据资产！

avatar
文章
阅读
粉丝