授予典型用户什么是合理的特权？[关闭]

我发现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有一个更有限的设置。它应该仅限于处理特定的数据库。

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

典型的用户应具有：

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

前四个很明显-尽管您也可以使用only设置“只读”用户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';

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

在所有环境中，应用程序都应该具有所需的内容（通常是“在所有表上选择/插入/更新”和“在所有过程上执行”）。对于较大的系统，您可能具有不同任务的单独应用程序用户（对于例如，一个应用程序负责提供检查数据，另一个应用程序负责生成报告），则应分离他们的特权，使他们拥有最少的需要（报告用户可能不需要并具有写权限）。请确保在测试中复制此特权环境，如果有的话：我已经看到代码在升级为Live时可以在测试中工作，因为测试环境中的所有内容都以sa（MSSQL等效于root）访问数据库。理想情况下，应用程序用户通常不应具有允许其更改架构的特权（CREATE，，DROP...）-对此有一些例外，但它们之间相差无几。

root很好root。在生产中，这仅是您的DBA，应该很少使用-仅用于系统维护（升级到DB设计等）和监视。对于大型系统，特别是在出于责任制目的必须保持对个人的严格控制的规范环境中，您可能根本不允许单个root用户，然后尝试将特权分成较小的角色（我不确定您可以走多远在mysql中使用此功能，但您可以在MSSQL，Oracle等中相当细粒度）。

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

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