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

【问题标题】：Application user == database user?应用程序用户 == 数据库用户？
【发布时间】：2013-07-02 18:50:13
【问题描述】：

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

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

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

应用程序中的每个用户也应该是不同的 MySQL 用户吗？

【问题讨论】：

不，我认为这意味着您将应用程序用户凭据从应用程序登录，当您使用数据库用户凭据直接登录到 phpMyAdmin 或您正在使用的任何东西时，不确定虽然
您想单独管理“许多”MySQL 帐户吗？我不会。通常，控制所有数据库访问的应用程序本身将充当门卫——这与单个用户被授予直接访问权限不同！话虽如此，请考虑可能存在一种或两种不同类型的帐户，它们对可以更新/删除的内容有不同的限制（即普通用户和“数据管理员”）——区分这些帐户是有意义的甚至可以稍微提高安全性。
目前我只有两个类别，普通和root。 Root 可以创建新的应用用户、删除表等。普通只能选择、插入或更新。
@Amoeba 这听起来不错！将它们作为两个不同的 SQL 用户/角色/模式加上强大的 DAL 听起来是一种可靠的方法。但是，不要公开可以运行 DDL 的帐户 - 可以是数据管理员而无需更改架构（这是开发人员/SA 工作）。跨度>
Should application users be database users?的可能重复

【解决方案1】：

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

原因很简单：

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

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

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

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

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

由于听起来您正在滚动另一个身份验证器，因此请花时间正确实施盐（大随机）+ 散列（bcrypt/scrypt/pbkdf2 - 没有 sha！）。或者，考虑 external 身份验证器或现有的 vetted 库。而且，一如既往，使用占位符。

【讨论】：