应用程序用户==数据库用户？

Question

我有一个应用程序，许多用户都可以访问MySQL数据库。现在，我很困惑的是如何管理用户。如我所见，有两种不同类型的用户-APPLICATION用户和DATABASE用户。这些应该是同一件事还是不同？

让我举例说明。这就是我现在如何工作的方式：

当用户登录到应用程序，一个单一的数据库帐户登录到MySQL并检查应用程序的用户名存在，并且比较了密码哈希值。这些都存储在MySQL的App Users表中。所有这些用户使用相同的MySQL帐户访问数据库。

应用程序中的每个用户都应该是一个单独的MySQL用户吗？

Answer 1

在仅通过受控应用程序（或Web服务）才允许访问数据库的情况下，通常使用针对所有应用程序帐户的单个数据库帐户。在没有集中用户管理的环境中尤其如此。在AD上的SQL Server中（例如在使用SharePoint的情况下），有时可以使用集成身份验证。

原因很简单：

尝试将数据库帐户与应用程序帐户同步成为噩梦；并且，由于该应用程序控制着所有SQL数据访问和查询（即没有直接登录），因此就数据库访问级别而言，几乎不需要将用户A与用户B分开。

在此配置中，应用程序承担验证，授权和标识用户访问的责任。

话虽这么说，拥有不同访问级别的数据库帐户是一件好事。这些可能类似于：

1. app_user; 可以完成普通应用程序用户需要做的所有事情。在不可变的设计中，这可能会排除对大多数/所有表的删除/更新访问。我还没有遇到过为不同类型的“正常”用户创建其他帐户的情况；再次，访问的责任就在此时。
2. app_admin; 可以做app_user可以做的所有事情，并且可以[更新]访问只有高级管理员才应该拥有的特殊表-这是正在运行的应用程序的“ root”帐户。该帐户不应允许架构修改；这不是大多数应用程序的“实时”方面。
3. database_admin; 好吧，可以更改数据库的人。重要的是：请勿使用此帐户从应用程序连接。这是开发人员/ SA帐户-它可以执行所有操作，包括进行架构更改。

对于多租户应用程序，每个租户可能有一个“ app_user”帐户（可能还有模式或数据库）。

由于听起来好像您正在滚动另一个身份验证器，所以请花一些时间正确实现salt（大随机数）+哈希（bcrypt / scrypt / pbkdf2-不行！）。或者，考虑使用外部验证器或现有的经过审核的库。和往常一样，使用占位符。