9

I have an application whereby many users will have access to a MySQL database. Now what I'm confused about is how I manage users. As I see it, there are two different types of user - the APPLICATION user and the DATABASE user. Should these be the same thing, or different?

Let me illustrate. This is how I have it working now:

When users log into the application, a single database account logs in to MySQL and checks if the application username exists, and compares the password hashes. These are all stored in a App Users table in MySQL. All these users use the same MySQL account to access the database.

Should each user in the app be a distinct MySQL user also?

4

1 回答 1

9

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

原因很简单：

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

在此配置中，应用程序负责验证、授权和识别用户访问。

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

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

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

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

于 2013-07-04T18:19:27.593 回答