☰

供 Web 应用程序访问的数据库和数据库用户的命名约定？

tag-icon • tag-icon database-administration web-applications
供 Web 应用程序访问的数据库和数据库用户的命名约定？

当安装一个 Web 应用程序时，如果单个用户习惯与单个数据库（比如 MySQL，但这也适用于其他 RDBMS）通信，则通常会发生如下一系列事件：

CREATE DATABASE wordpress CHARACTER SET utf8;
GRANT ALL PRIVILEGES ON wordpress.* TO 'wordpress'@'localhost' IDENTIFIED BY 'hunter2';

一些指南建议使用与数据库名称不同的用户名，其中其他的建议使用不同的名称，例如用户使用“appuser”，数据库名称使用“app”。

使用相同名称是否存在任何明显的技术缺陷？这样做是否可能在任何地方造成混淆？

编辑：我知道这是一种值得怀疑的安全做法，你应该给你的数据库命名韓國和你的用户弗洛巴多布；然而，(a) 模糊性是一种值得怀疑的工具，并且 (b) 这是每个 webapp 在其文档中给出的示例。

答案1

使用与数据库名称相同的用户名的缺点就是太明显了。如果你查看访问日志，你会发现攻击者经常尝试这种组合，如果你输入了正确的名称，那么你已经成功了。除此之外，你使用什么名称都无关紧要，尽管不使用字典中的单词也有一些好处。

答案2

一旦发生入侵，混淆数据库可提供大约 15-30 秒的防御时间，并可提供大约 1234783562387561235 小时的防御时间。

我认为你应该将角色与用户名联系起来。例如：

app_role

或者：

wordpress_www
wordpress_dba
wordpress_cron

如果我见到wordpress用户，我就知道有些事情不对劲。使用*_dba约定有助于让人们明白，Web 用户不应该拥有数据库对象，只有*_dba's 才应该拥有。对于用户，您只需使用他们的站点用户名。像这样的简单约定使管理权限变得容易，尤其是与SCHEMAs 结合使用时。

下面是我正在开展的一个示例项目，它的作用正是如此：

https://github.com/sean-/flask-skeleton/blob/master/sql/create_roles.sql

https://github.com/sean-/flask-skeleton/blob/master/sql/perms.sql

答案3

我认为缺点不在于技术层面，而在于管理和/或安全层面。您可以这样想，用户名 == 数据库名称对于管理和了解哪些帐户访问哪些数据库来说很简单，但它也使入侵者能够轻松猜出有效的帐户名称，成功率更高。通常，我会在帐户后加上目的和应用程序。像 _wp 这样的东西会减少直观的访问，但数据库管理员仍然可以看到它，以便快速确定帐户的性质。

相关内容