应用用户应该是数据库用户吗？

Question

我之前的工作涉及对包含大量数据的大型数据库进行维护和编程。用户主要通过Intranet Web界面查看此数据。每个用户帐户都不是拥有用户帐户表，而是RDBMS中真正的一流帐户，允许他们连接自己的查询工具等，并允许我们通过RDBMS本身来控制访问使用我们自己的应用程序逻辑。

这是一个很好的设置，假设您不在公共内部网上并与潜在的数百万（潜在恶意）用户或其他东西打交道？或者，最好定义自己的处理用户帐户，自己的权限，自己的应用程序安全逻辑的方法，并且只分发RDBMS帐户以满足有特殊需求的用户的需求？

Answer 1

编辑：我应该澄清，尽管OP中有任何内容，但即使没有代码，您正在做的是逻辑定义应用程序。否则它只是一个公共数据库，其中包含所有危险。

也许我会因为这篇文章而被烧死，但我认为这在安全和设计方面是一种极其危险的反模式。

用户对象应由其运行的系统定义。如果您实际在另一个应用程序（数据库）中定义这些对象，则会失去控制权。

从设计的角度来看，没有任何意义，因为如果您想根据任何类型的数据扩展这些帐户（电子邮件地址，员工编号，MyTheme ......），您将无法延长数据库用户，无论如何你都需要构建那个用户表。

数据库用户帐户本质上比应用程序定义的帐户中的任何内容都更危险，因为它们不仅可以被数据库和任何通过的DBA提升，删除，访问或以其他方式操纵，还可以被连接到数据库的任何其他内容。您已将关键系统元素公开为公开。

缩放是不可能的。想象一下，您将拥有数十或数十万用户的抽象概念。这不像DB帐户那样可管理，但作为表中的记录，它只是数据。这个古老的论点“好吧，有些人将成为X用户”并没有任何关注，因为我看到非常有限的内部应用程序在公司认为可以为客户或公司增加价值时公开曝光刚刚被一个现在需要访问的巨大合作伙伴买走了。您必须计划合理的可扩展性。

你不能分享conn pooling，你不会比你刚刚创建了一些例如conn pooling更安全。角色帐户，当您需要或有效备份时，您不一定能够影响批量更改。

对我来说似乎有很多严重的问题，我想其他更有经验的SOers可以列出更多。

Answer 2

我不同意使用数据库进行用户访问控制同样危险，其他人正在努力实现这一目标。我来自Oracle Forms Development领域，这种类型的用户访问控制是常态。就像任何设计决定一样，它有其优点和缺点。

其中一个优点是我可以从数据库中的单个设置控制EACH表的select / insert / update / delete权限。在一个系统上，我们有4个不同的应用程序（由不同的团队和不同的语言管理）命中相同的数据库表。我们能够声明只有具有Manager角色的用户才能在特定表中插入/更新/删除数据。如果我们没有通过数据库管理它，那么每个应用程序团队都必须在整个应用程序中正确地实现（复制）该逻辑。如果一个应用程序错了，那么其他应用程序将受到影响。另外，如果您想要更改单个资源的权限，则需要管理重复的代码。

另一个优点是我们不需要担心将用户密码存储在数据库表中（以及随之而来的所有限制）。

我不同意“数据库用户帐户本身比应用程序定义的帐户中的任何内容都更危险”。更改特定于数据库的权限所需的权限通常比更新/删除“PERSONS”表中的单个行所需的权限更难。

“扩展”不是问题，因为我们为Oracle角色分配了权限，然后将角色分配给用户。使用单个Oracle语句，我们可以更改数百万用户的权限（而不是我们拥有那么多用户）。

申请授权不是一个小问题。许多自定义解决方案都有黑客可以轻易利用的漏洞。像Oracle这样的大公司已经投入了大量的思想和代码来提供强大的应用程序授权系统。我同意使用Oracle安全性并不适用于所有应用程序。但我不会那么迅速地拒绝支持自定义解决方案。

Answer 3

“每个用户帐户都是RDBMS中真正的一流帐户，允许他们使用自己的查询工具等连接，”

如果RDBMS包含：

，这不是一个好主意

• HIPAA或萨班斯 - 奥克斯利法案或“官方保密法”（英国）所涵盖的任何信息

• 信用卡信息或其他客户信用信息（PO，信用额度等）

• 个人信息（ssn，dob等）

• 竞争，专有或知识产权信息

因为当用户可以使用他们自己的非托管查询工具时，公司无法了解或审核查询的信息或查询结果的交付位置。

哦和@annakata说的话。

Answer 4

我认为一般。在您的传统数据库应用程序中，它们不应该。由于已经给出的所有原因。在传统的数据库应用程序中，有一个处理所有安全性的业务层，这是因为与应用程序交互的人与与数据库交互的人之间存在如此强大的界限。

在这种情况下，通常最好自己管理这些用户和角色。您可以决定需要存储哪些信息，以及您记录和审核的内容。最重要的是，您可以基于纯业务规则而不是数据库规则来定义访问权限。它与他们访问哪些表无关，以及是否可以在此处插入业务操作。然而，这些不是技术问题。这些是设计问题。如果这是您需要控制的，那么自己管理用户是有意义的。

您已经描述了一个允许用户直接查询数据库的系统。在这种情况下，为什么不使用DB帐户。如果您尝试分析用户编写的查询并根据您设计的某些规则对其进行审查，他们将比您更好地完成工作。对我来说，这听起来像是一个编写和维护的噩梦系统。

不要因为可以把事情锁定。向负责人解释安全隐患，但不要试图阻止人们做事，因为你可以。特别是当他们习惯于直接访问数据时。

我们作为开发人员的工作是让人们做他们需要做的事情。在你所描述的情况下。具体来说，连接到数据库并使用自己的工具进行查询。然后我认为除了数据库帐户以外的任何东西要么是不安全的，要么是不必要的限制。

Answer 5

我会避免提供任何用户数据库访问权限。后来，当这开始引起问题时，取消他们的访问变得非常困难。

至少，让他们访问数据库的只读副本，这样他们就不会因为查询错误而终止整个公司。

Answer 6

现在很多数据库查询工具都非常先进，为了添加限制而重新实现世界会感到非常遗憾。只要数据库用户权限被正确锁定，它就可以了。但是在许多情况下你无法做到这一点，你应该向数据库公开一个高级API，以便正确地在多个表上插入对象，而无需用户进行特定的培训，他们应该“只需在那里的表中添加一个地址，为什么不工作？“。

如果他们只想使用数据在Excel等生成报告，那么也许您可以使用像BIRT这样的报告前端。

基本上如此：如果用户了解数据库，并且实现适当前端的资源很少，请继续这样做。然而，资源确实出现了，可能是时候让人们的需求为他们创建一个更简单，面向任务的前端。

Answer 7

这在某种程度上类似于：is sql server/AD good for anything

我认为在数据库本身中抛出安全模型（至少是一个基本模型）并不是一个坏主意。您可以在化妆品的应用程序层中添加限制，但无论用户使用哪个帐户访问数据库，无论是基于应用程序还是用户，最好只将该帐户限制为允许用户操作。

我并不代表所有应用程序，但有很多我已经看到捕获密码就像在记事本中打开代码一样简单，使用包含的DLL来解密配置文件，或者找到备份文件（例如，asp.net中的web.config.bak）可以从浏览器访问。

Answer 8

*如果RDBMS包含以下内容，那不是一个好主意：     * HIPAA或Sarbanes-Oxley或The Official Secrets Act（英国）所涵盖的任何信息     *信用卡信息或其他客户信用信息（PO，信用额度等）     *个人信息（ssn，dob等）     *竞争，专有或IP信息*

不成真，人们可以完美地管理数据库用户可以看到哪些数据以及可以修改哪些数据。数据库（至少是Oracle）也可以审计所有活动，包括选择。拥有数千个数据库用户也是完全正常的。

构建良好的安全应用程序更加困难，因为您必须对此安全性进行编程，数据库提供此安全性，您可以以声明方式对其进行配置，无需代码。

Answer 9

我知道，我正在回复一个非常古老的帖子，但最近在我目前的项目中遇到了同样的情况。我也在考虑类似的问题，“应用程序用户是否是数据库用户？”。 这是我分析的：

1. 当然，在数据库上创建大量应用程序用户是没有意义的（如果您的应用程序将被许多用户使用）。
2. 假设您在数据库中创建了X（大量）用户。您正在打开一个清晰的数据库网关。

我们来看一个解决方案的场景：

有两种类型的应用程序用户（Managers和Assistant）。对于某些事务，两者都需要访问数据库。

很明显，您将创建两个角色，一个用于数据库中的每种类型（Manager和Assistant）。但是如何从应用程序连接数据库用户。如果您为每个用户创建一个帐户，那么最终将在数据库上线性创建帐户。

我建议：

1. 为每个角色创建一个数据库帐户。 （让我们说Manager_Role_Account）
2. 让您的应用程序具有业务逻辑，以便为具有相应角色的应用程序用户进行映射。（具有管理员角色的用户Tom为Manager_Role_Account）
3. 使用与＃2中已识别角色对应的数据库用户（Manager_Role_Account）连接到数据库并执行查询。

希望这是有道理的！

更新：正如我所说，我在我的项目中遇到了类似的情况（关于后端的Postgresql数据库和前端的Java Web应用程序），我发现了一些非常有用的东西称为代理验证

这意味着您可以作为一个用户登录数据库，但可以根据代理用户限制或扩展您的权限。 我发现非常好的链接解释相同。

1. 对于Choice of authentication approach for financial app on PostgreSQL以下的Postgresql

   1. For Oracle Proxy Authentication

希望这有帮助！

Answer 10

这取决于（像大多数事情一样）。

让多个数据库用户否定连接池，因为大多数库根据连接字符串和用户帐户处理池。

另一方面，它可能是一个比你或我从头开始做的更安全的解决方案。它将安全性留给操作系统和数据库服务器，我比我更信任。但是，只有在您努力配置数据库权限的情况下才会出现这种情况。如果您使用具有相同权限的一堆OS / db用户，则无济于事。你仍然会得到审计线索，但就是这样。

所有这一切，我不知道让普通用户使用他们自己的工具直接连接数据库我感觉很舒服。

Answer 11

我认为值得强调其他答案所涉及的内容：

数据库只能根据数据定义限制。即限制特定表或列上的选择/插入/更新/删除。我确信某些数据库可以做一些更聪明的事情，但它们永远无法像应用程序那样实现基于业务规则的限制。如果允许某个用户仅将某个列更新为某些值（例如＆lt; 1000）或仅增加价格，或者更改两列中的任何一列但不更改两列，该怎么办？

我会说，除非你绝对确定除了表/列粒度之外你永远不需要任何东西，这本身就足够了。

Answer 12

对于将多个用户的数据存储在同一个表中并且您不希望一个用户能够读取或修改其他用户数据的任何应用程序，这不是一个好主意。在这种情况下你会如何限制访问？