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

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

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

编辑:我应该澄清,尽管OP中有任何内容,但即使没有代码,您正在做的是逻辑定义应用程序.否则,它只是一个公共数据库,具有自身所需的所有危险.

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

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

从设计的角度来看,没有任何意义,因为如果您想根据任何类型的数据扩展这些帐户(电子邮件地址,员工编号,MyTheme ...),您将无法扩展数据库用户而且你还是需要构建那个用户表.

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

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

你不可能分享conn pooling,你不会比你刚创建一些例如角色账户更安全,并且你不一定能够影响群体变化你需要,或有效地备份.

对我来说似乎存在许多严重的问题,我想其他更有经验的SOers可以列出更多.

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

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

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

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

并且"扩展"不是问题,因为我们为Oracle角色分配了权限,然后将角色分配给用户.使用单个Oracle语句,我们可以更改数百万用户的权限(而不是我们拥有那么多用户).

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