任何有脑细胞的人都知道，使用非 root/dbo/etc 的用户会大大提高安全性以及 SQL 注入攻击的有效性。我想知道将这个想法更进一步是否是一个好主意。
基本思想很简单。select对于类似访客的操作（查看），请在数据库上使用仅对事物具有权限的“访客”用户。对于类似用户的操作（添加/编辑），有一个“用户”用户，它只有运行insert和update查询的权限。除此之外，还包括具有类似“管理员”操作的第三个用户，以获得delete能力。
注意：这已被简化为仅涵盖基本的 CRUD 能力
优点：
缺点：
我的问题是：
以这种方式分离角色和权限是否有任何安全好处，如果是这样，这样做的好处是否证明更复杂的代码可以根据操作强制用户切换？
例如，我们只是说检查我是否切换用户只是一个 if 语句，如果该语句失败，那么用户无论如何都不允许执行任何操作，因此切换不会发生第一名。
从理论上讲，这种事情应该总是有帮助（最小特权原则）并且不会真正受到伤害，但如果在实践中你最终得到一个 CMS 中间层持有所有凭据，那么它可能没有多大帮助或根本没有帮助。
一个警钟是您只考虑 SQL 注入。最小特权原则是如此基本，它应该购买比这更多的保护，它应该覆盖整个攻击途径和所有类别的漏洞，而不仅仅是一个。
我认为是否有任何真正的好处取决于您是否可以（例如）也指向一台机器并说“这台机器只有'访客'特权”等。换句话说，当您超越数据库时，这个对整个系统安全性的贡献的论点是否同样简单？
如果结果只是增加了 CMS 的复杂性，那么它实际上可能会适得其反（即引入复杂性往往会导致更多的错误，其中一些往往本身就是安全漏洞，特别是如果错误是在兼顾权限的情况下）。因此，另一个警钟是您似乎预见到 CMS 中的代码混乱。然而，这可能是必要的，也可能不是必要的——你能更简单地做吗？
使事情变得更复杂对安全从来没有好处，但另一方面，给予某人更多他们需要的特权也可能会损害安全性。因此，它在复杂性与附加安全功能或简单性与附加功能之间取得平衡。你的建议听起来很有趣。但是，我的建议是将您的注意力集中在创建强大的数据清理过滤器上。防止 SQL 注入甚至到达数据库。
对每个应用程序启用 SSL/TLS 的 MySQL 实例使用 SSL/TLS 客户端证书。与 MySQL 安全有关的事情有一百万个，它应该得到一组单独的答案。
或许这个问题找对了地方——MySQL Server Hardening。