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

Question

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

让我说明一下。这就是我现在的工作方式：

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

应用程序中的每个用户是否也应该是一个独特的MySQL用户？

Answer 1

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

原因很简单：

尝试将数据库帐户与应用程序帐户同步是一场噩梦;并且，因为应用程序控制所有SQL数据访问和查询（即没有直接登录），所以几乎不需要在数据库访问级别方面将用户A与用户B分开。 / p>

在此配置中，应用程序负责对用户访问进行身份验证，授权和识别。

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

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

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

因为听起来你还在滚动 - 另一个身份验证器，花时间正确实现salt（大随机）+哈希（bcrypt / scrypt / pbkdf2 - 没有sha！）。或者，考虑外部身份验证器或现有的审查库。并且，与往常一样，使用占位符。