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

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

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

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

最佳答案

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

原因很简单:

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

在这种配置下,应用程序承担验证,授权和识别用户访问的责任。

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

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

  • 对于 Multi-Tenancy 应用程序,每个租户可能有一个“app_user”帐户(可能还有架构或数据库)。

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

    关于database - 应用程序用户==数据库用户?,我们在Stack Overflow上找到一个类似的问题:https://stackoverflow.com/questions/17475805/

    10-10 09:37
    查看更多