为MySQL用户提供最低权限

对于Web应用程序,在创建将连接到MySQL数据库的用户时,您可以选择权限.假设该用户打算执行的唯一操作是SELECT/INSERT/UPDATE/DELETE,那么只提供这些权限似乎是有意义的,但我从未在任何地方看到过推荐 - 这是什么原因支持和反对方法？

1> sr2012..：

---

我在这里不同意比尔,Atomix的思路更合适.除非能够以其他方式证明,否则Bill的回答会大大增加数据库受到威胁的风险.

也许对于非常有经验的开发人员来说,还有其他安全措施,但是对于其他开发人员来说,如果没有必要,那么给脚本提供完整的,不受限制的访问来对数据库执行任何操作都会产生麻烦.

这里应该使用最小特权原则.对于MySQL,拥有一个具有所有权限的超级用户,用于创建表,删除数据库等.理想情况下,在任何PHP文件或Web服务器上的任何文件中都不会看到此用户名和密码.(我使用PHP作为示例,但它适用于其他Web应用程序).您只能使用PHPMyAdmin或MySQL Workbench之类的用户名和密码.

然后,对于PHP脚本,有一个具有最低要求的脚本,例如INSERT,SELECT,UPDATE,甚至可能不是DELETE,具体取决于您的PHP脚本.这将是在PHP文件中,也就是说,实际上只有文档根目录的一个文件,这是大多数人推荐的.

原因是:是的,每个Web应用程序用户都不需要MySQL用户.但是应该适用最小特权原则(http://en.wikipedia.org/wiki/Principle_of_least_privilege).如果您的MySQL超级用户因为意外地将您的MySQL连接脚本命名为.txt而不是.php,或者某人获得了对Web服务器文件的访问权而被泄露,那么至少他们能做的"最差"是SELECT,UPDATE和INSERT. ..无论如何,虽然可能会造成大问题,但并不像给DROP DATABASE,DROP TABLES和更糟糕的事情那样糟糕.

另外,在我目前的项目中,由于敏捷开发实践(我不推荐,但推荐http://www.agilealliance.org/),一两个"非技术"团队成员直接使用PHPMyAdmin进行直接更改MySQL数据库.这是因为不需要创建用于简单直接数据输入的CMS.在这种情况下,第三个具有合理但又"恰好"特权的MySQL用户适合他们.我们不希望以极少的权限削弱团队成员,但当然他们不应该意外删除或更改内容.

由于MySQL没有ROLES(截至原始问题的时间,并且根据Bill),因此允许任何Web脚本只使用一个超级用户访问MySQL是非常危险的.

2> Bill Karwin..：

---

在普通应用程序中,用户可能还需要其他权限,例如:

创建临时表

执行(存储过程)

文件(用于SELECT INTO和LOAD DATA)

锁表

还有一种可能性,即最小权限只能表示某些表上的SELECT,而只能表示其他表上的SELECT和UPDATE等.每当应用程序的功能得到增强时,这都可能会发生变化.并且有一些奇怪的情况,例如需要对您永远不会查询的表具有SELECT权限,因为它是由您更新的表中的外键引用的.因此,跟踪最小特权是一种皇家的痛苦.

你想用SQL权限限制什么？您是编写所有代码的人,因此不需要以精细的粒度管理SQL权限.坦率地说,如果您的用户能够上传和运行您未经过审查的SQL语句,那么您会遇到更大的问题:

SELECT * FROM mytable, mytable, mytable, mytable, mytable ORDER BY 1;

您要管理的实际任务不在数据库级别,而是在应用程序业务级别.例如,CMS具有创建页面,编辑页面,管理注释等操作.这些任务比SQL权限更高级别.您可以使用SQL角色(它们是特权组)来模仿它们,但不广泛支持SQL角色.

我不知道有谁将他们的应用程序用户映射到不同的MySQL用户.在应用程序连接到数据库之后,它们是您在应用程序中进行身份验证的用户(用户只是数据库中的数据行).

因此,您可能最好让您的Web应用程序使用具有完全权限的单个MySQL用户.

---

有趣......但你应该给用户一个完全的特权似乎很疯狂.我在这里错过了什么吗？为什么不让一个"WebUser"具有对所有DB的读写权限.也许不是分钟.特权,但肯定不完整.为什么甚至邀请用户做"DROP MyDatabase"的可能性 命令？当然,你的代码不应该允许执行原始的SQL ...但是会出错,而这只是一个较低的级别.