授予典型用户的合理权限是什么？

Question

我发现MySQL 提供的特权列表有点让人不知所措。我不确定谁应该拥有什么特权。在我看来，我的情况有三个典型的用户：

1. root
2. developer
3. application

root是不言自明的。对于developer此用户需要能够轻松访问任何数据库，对其进行调整等。对于初学者，我将此用户设置为此权限集：

SELECT, INSERT, UPDATE, DELETE, CREATE, DROP, FILE, REFERENCES, INDEX, ALTER, SHOW DATABASES, CREATE TEMPORARY TABLES, LOCK TABLES, EXECUTE, CREATE VIEW, SHOW VIEW, CREATE ROUTINE, ALTER ROUTINE, EVENT, TRIGGER ON

application有一个更有限的集合。它应该仅限于操作特定的数据库。

我不确定要授予哪些合理的特权。授予开发人员和应用程序的合理权限集是什么？为什么？

Answer 1

一个典型的用户应该具备：

SELECT, INSERT, DELETE, UPDATE, CREATE TEMPORARY TABLES, EXECUTE

前四个非常明显——尽管您也可以设置“只读”用户，并且只使用SELECT.

CREATE TEMPORARY也很方便并且通常无害：临时表可以帮助优化查询，将它们分解成更小和更快的部分。它们仅限于正在执行的连接，并在关闭时自动删除。

EXECUTE取决于您的系统类型。你有存储的例程吗？您希望您的用户访问它们吗？确保您还了解SECURITY=DEFINER/INVOKER存储例程的定义。

在任何情况下，请确保将上述所有内容应用于特定模式。避免使用：

GRANT SELECT, INSERT, UPDATE, DELETE ON *.* TO 'some_user'@'some_host';

因为上面还授予对mysql系统表的权限，有效地允许任何用户创建新帐户或升级他们自己的权限集。相反，请执行以下操作：

GRANT SELECT, INSERT, UPDATE, DELETE ON some_schema.* TO 'some_user'@'some_host';
GRANT SELECT, INSERT, UPDATE, DELETE ON another_schema.* TO 'some_user'@'some_host';

Answer 2

在任何实际规模的系统（即不是个人项目）中，这些用户类型会因环境而异，因此并不是那么简单。

在所有环境中，应用程序都应该有它需要的东西，而不是更多（通常这是“在所有表上选择/插入/更新”和“对所有过程执行”。对于较大的系统，您可能有不同的应用程序用户执行不同的任务（例如例如，一个应用程序负责提供审查员数据，另一个应用程序负责生成报告）您应该将他们的权限分开，以便他们拥有最少的需要（报告用户可能不需要和写权限）。确保在测试中复制这一点环境，如果你有它们：我已经看到代码在升级到 Live 时在测试中失败了，因为测试环境中的所有东西都在访问数据库sa（MSSQL 相当于root）。理想情况下，应用程序用户通常不应具有允许其更改架构的权限（CREATE, DROP, ...) - 也有例外，但它们很少。

root是，嗯，root。在生产中，这只是您的 DBA，应该很少使用 - 仅用于系统维护（升级到 DB 设计等）和监控。对于大型系统，尤其是在出于问责目的而必须密切控制个人的受监管环境中，您可能根本不允许单个root用户并尝试将特权分成更小的卷（我不确定您可以走多远在 mysql 中使用这个，但你可以在 MSSQL、Oracle 等中进行相当细粒度的处理）。

对于开发者用户：他们根本无法访问您的实时环境。这是应用程序用户不应拥有影响权限的架构的原因之一：有权访问开发人员帐户的人可能会以这种方式绕过他们的锁定。在测试环境中，他们通常也没有访问权限：他们会向 QA 提交补丁，而 QA 的 DBA（可能使用root用户）会将更新应用到测试环境（实际上，这在大型组织中通常是自动化的，因此 QA DBA实际上是一组脚本，用于控制每个周期重建测试环境）。在开发环境中，特别是如果开发人员拥有自己的运行服务的本地副本，这些用户当然应该拥有对所有内容的完全访问权限，以便能够进行实验。

以上都是一般性说明：要提出任何具体建议，我们需要更多地了解您的应用程序及其运行环境。目标环境有时比您想象的更重要：取决于您的业务环境您的用户的权利甚至可以直接通过法律法规来规定，即使在开发过程中，如果您的客户允许您访问用于诊断目的的真实数据。