应用程序用户应该是数据库用户吗？答案

【问题标题】：Should application users be database users?应用程序用户应该是数据库用户吗？
【发布时间】：2010-09-25 08:54:50
【问题描述】：

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

假设您不在公共 Intranet 上并与潜在的数百万（潜在恶意）用户打交道，这是一个好的设置吗？还是自己定义处理用户帐户的方式、自己的权限、自己的应用程序安全逻辑，并且只将 RDBMS 帐户分发给有特殊需求的高级用户总是更好？

【问题讨论】：

“恶意用户”不仅仅存在于互联网上——他们中的大多数人都在公司工作，而你现在可能正在与他们中的几个人一起工作——这是有原因的解雇某人时，首先要切断所有用户帐户和物理访问权限
没错，克鲁克斯。我总是难以说服从事该工作的人恶意（以及看起来像恶意的无能）可能发生在我们的“安全”内联网中。但在这种情况下，您只需授予人们只读访问权限或视情况而定。
高级用户是您最需要关心的直接授予数据库权限的用户。他们有足够的知识通过绕过应用程序的内部控制来进行欺诈。

标签： database security authentication

【解决方案1】：

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

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

另一方面，它可能比您或我从头开始做的任何事情都更安全。它将安全性留给操作系统和数据库服务器，我比我自己更信任它们。但是，只有在您努力配置好数据库权限时才会出现这种情况。如果您使用的是一堆具有相同权限的 OS/db 用户，那将无济于事。您仍然会获得审计线索，但仅此而已。

话虽如此，我不知道让普通用户使用他们自己的工具直接连接到数据库是否会舒服。

【讨论】：

【解决方案2】：

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

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

用户对象应该由运行它的系统定义。如果您实际上是在另一个应用程序（数据库）中定义这些对象，那么您将失去控制。

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

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

缩放是不可能的。想象一下您将拥有数万或数十万用户的抽象。这不能作为数据库帐户进行管理，但作为表中的记录，它只是数据。 “好吧，永远只有 X 用户”这个古老的论点对我来说站不住脚，因为当企业认为它可以为客户或公司增加价值时，我看到非常有限的内部应用程序被公开曝光刚被一个现在需要访问权限的大合作伙伴收购。您必须计划合理的可扩展性。

您将无法共享 conn 池，您不会比仅创建少量例如 conn 更安全。角色帐户，并且您不一定能够在需要时影响大规模更改或有效备份。

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

【讨论】：

如果用户可以从应用程序以外的来源访问数据，请不要忘记欺诈的危险。想要窃取的用户可以绕过应用程序中设置的所有内部控制。

【解决方案3】：

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

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

【讨论】：

【解决方案4】：

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

如果 RDBMS 包含以下内容，则不是一个好主意：

HIPAA 或 Sarbanes-Oxley 或官方保密法（英国）涵盖的任何信息
信用卡信息或其他客户信用信息（采购订单、信用额度等）
个人信息（ssn、dob 等）
竞争、专有或知识产权信息

因为当用户可以使用自己的非托管查询工具时，公司无法知道或审核查询的信息或查询结果的发送位置。

哦，@annakata 说了什么。

【讨论】：

数据库有审计工具，就像操作系统一样。另外，你应该有分层的防御，不要假设应用程序没有可以让用户绕过“黄金查询”的错误。
这实际上不是真的。有多个用户使用自己的帐户连接到数据库并不意味着所有用户都具有相同的权限...我数据库用户没有查询表的权限，他将无法做到，无论它包含的数据多么重要......

【解决方案5】：

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

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

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

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

作为开发人员，我们的工作是让人们能够做他们需要做的事情。在你描述的情况下。专门连接数据库，用自己的工具查询。然后我认为除了数据库帐户之外的任何东西要么不安全，要么受到不必要的限制。

【讨论】：

【解决方案6】：

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

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

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

【讨论】：

【解决方案7】：

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

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

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

【讨论】：

【解决方案8】：

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

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

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

我不同意“数据库用户帐户本质上比您的应用程序定义的帐户中的任何东西都更危险”。更改特定于数据库的权限所需的权限通常比更新/删除“PERSONS”表中的单行所需的权限要严格得多。

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

应用程序授权不是一个小问题。许多定制解决方案都有黑客可以轻松利用的漏洞。 Oracle 等大公司在提供强大的应用程序授权系统方面投入了大量精力和代码。我同意使用 Oracle 安全性并不适用于所有应用程序。但我不会这么快就放弃它而支持自定义解决方案。

【讨论】：

一些优点。我认为在这些站起来之前你需要一个“严肃的”像 oracle 这样的 RDBMS，但在某些环境中这可能是合适的。
最重要的是不要越过溪流。要么在数据库权限中表达所有访问控制逻辑，要么在代码中完成。混合使用它们意味着您会失去以数据库为中心的设计的好处，同时保留许多负面因素。

【解决方案9】：

*如果 RDBMS 包含以下内容，则不是一个好主意： * HIPAA 或 Sarbanes-Oxley 或官方保密法（英国）涵盖的任何信息 * 信用卡信息或其他客户信用信息（采购订单、信用额度等） * 个人信息（ssn、dob 等） * 竞争、专有或 IP 信息*

并非如此，我们可以完美地管理数据库用户可以查看哪些数据以及可以修改哪些数据。数据库（至少是 Oracle）还可以审计所有活动，包括选择。拥有数以千计的数据库用户也是完全正常的。

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

【讨论】：

所以如果我理解正确，开发人员/设计师/架构师不应该费心在应用程序中构建任何数据安全性，因为这一切都应该由 dba 完成？
设计师、架构师和 DBA 可以一起设计数据安全策略。不要太晚与您的 DBA 交谈。为了使应用程序对用户更加友好，应该不可能以不允许用户在数据库中更改的形式更改数据。

【解决方案10】：

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

数据库只能根据数据定义限制。即限制特定表或列的选择/插入/更新/删除。我确信一些数据库可以做一些更聪明的事情，但它们永远无法像应用程序那样实现基于业务规则的限制。如果允许某个用户仅将列更新为某些值（例如

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

【讨论】：

如果我正在实现基于数据库用户的安全性，我想我会使用角色和触发器来处理您提到的情况。仍然没有说这是最好的计划；只是这种情况并非不可克服。
触发器是否足够灵活以处理这些限制？也许触发器比我想象的更灵活。
在 Oracle 中，触发器应该足够强大。我不知道其他 RDBMS 系统。

【解决方案11】：

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

【讨论】：

仅通过存储的数据库过程提供对表的访问。
或按行级别安全
或者通过创建视图来限制特定用户看到的记录。并允许访问视图而不是基础表。

【解决方案12】：

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

在数据库上创建大量应用程序用户肯定没有意义（如果您的应用程序将被许多用户使用）。
假设您在数据库上创建了 X（大量）用户。您正在为您的数据库打开一个清晰的门户。

让我们为解决方案举一个场景：

有两种类型的应用程序用户（经理和助理）。两者都需要访问数据库以进行某些事务。

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

我的建议：

为每个角色创建一个数据库帐户。（比如说Manager_Role_Account）
让您的应用程序有业务逻辑来映射具有相应角色的应用程序用户。（具有 Manager 角色的用户 Tom 到 Manager_Role_Account）
使用与#2 中已识别角色对应的数据库用户(Manager_Role_Account) 连接到数据库并执行您的查询。

希望这是有道理的！

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

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

对于Choice of authentication approach for financial app on PostgreSQL下面的Postgresql
1. 对于甲骨文Proxy Authentication

希望这会有所帮助！

【讨论】：