我以前的工作涉及维护和编程一个包含大量数据的大型数据库.用户主要通过intranet web界面查看这些数据.每个用户帐户不是一个用户帐户表，而是RDBMS中真正的一级帐户，它允许用户使用自己的查询工具等进行连接，并允许我们通过RDBMS本身而不是使用自己的应用程序逻辑来控制访问.
假设你不在公共内联网上，并且与数百万(潜在恶意)用户打交道，这是一个好的设置吗？或者，定义自己处理用户帐户的方法、权限、应用程序安全逻辑，并且只向有特殊需要的高级用户分发RDBMS帐户，这是否总是更好？
我以前的工作涉及维护和编程一个包含大量数据的大型数据库.用户主要通过intranet web界面查看这些数据.每个用户帐户不是一个用户帐户表，而是RDBMS中真正的一级帐户，它允许用户使用自己的查询工具等进行连接，并允许我们通过RDBMS本身而不是使用自己的应用程序逻辑来控制访问.
假设你不在公共内联网上，并且与数百万(潜在恶意)用户打交道，这是一个好的设置吗？或者，定义自己处理用户帐户的方法、权限、应用程序安全逻辑，并且只向有特殊需要的高级用户分发RDBMS帐户，这是否总是更好？
我不同意将数据库用于用户访问控制是危险的，正如其他人所说的那样.我来自Oracle Forms Development领域，在那里这种类型的用户访问控制是常态.就像任何设计决策一样，它也有它的优点和缺点.
其中一个优点是，我可以从数据库中的单个设置控制每个表的 Select /插入/更新/删除权限.在一个系统上，我们有4个不同的应用程序(由不同的团队管理，使用不同的语言)访问相同的数据库表.我们可以声明只有具有Manager角色的用户才能在特定表中插入/更新/删除数据.如果我们没有通过数据库进行管理，那么每个应用程序团队都必须在整个应用程序中正确地实现(复制)该逻辑.如果一个应用程序出错，那么其他应用程序就会受到影响.另外，如果您想要更改单个资源的权限，则需要管理重复的代码.
另一个优点是，我们不需要担心将用户密码存储在数据库表中(以及随之而来的所有限制).
我不同意"数据库用户帐户本质上比您的应用程序定义的帐户中的任何帐户都更危险"的说法.更改特定于数据库的权限所需的权限通常比更新/删除"PERSONES"表中的一行所需的权限严格得多.
"扩展"不是问题，因为我们为Oracle角色分配了权限，然后为用户分配了角色.只需一条Oracle语句，我们就可以更改数百万用户的权限(并不是说我们有那么多用户).
应用程序授权不是一个微不足道的问题.许多自定义解决方案都有漏洞，黑客可以很容易地利用这些漏洞.像甲骨文这样的大牌公司在提供健壮的应用程序授权系统方面投入了大量的思想和代码.我同意使用Oracle安全性并不适用于所有应用程序.但我不会这么快就放弃它，转而采用定制的解决方案.