问题描述
我以前的工作涉及对具有大量数据的超大型数据库进行维护和编程.用户主要通过Intranet Web界面查看此数据.每个用户帐户都没有一个用户帐户表，而是RDBMS中真正的一流帐户，它允许他们使用自己的查询工具等进行连接，并允许我们通过RDBMS本身来控制访问使用我们自己的应用程序逻辑.
My previous job involved maintenance and programming for a very large database with massive amounts of data. Users viewed this data primarily through an intranet web interface. Instead of having a table of user accounts, each user account was a real first-class account in the RDBMS, which permitted them to connect with their own query tools, etc., as well as permitting us to control access through the RDBMS itself instead of using our own application logic.
如果您不在公共Intranet上并与潜在的数百万(可能是恶意)用户或其他事物打交道，这是一个很好的设置吗?还是定义自己的方式来处理用户帐户，您自己的权限，您自己的应用程序安全逻辑，并且只分发RDBMS帐户来满足有特殊需要的用户总是更好的选择?
Is this a good setup, assuming you're not on the public intranet and dealing with potentially millions of (potentially malicious) users or something? Or is it always better to define your own means of handling user accounts, your own permissions, your own application security logic, and only hand out RDBMS accounts to power users with special needs?
推荐答案
我不同意使用数据库进行用户访问控制会像其他人指出的那样危险.我来自Oracle Forms Development领域，这种类型的用户访问控制是常态.就像任何设计决策一样，它也有其优点和缺点.
I don't agree that using the database for user access control is as dangerous others are making it out to be. I come from the Oracle Forms Development realm, where this type of user access control is the norm. Just like any design decision, it has it's advantages and disadvantages.
优点之一是，我可以从数据库中的单个设置控制EACH表的选择/插入/更新/删除特权.在一个系统上，我们有4个不同的应用程序(由不同的团队以不同的语言管理)命中相同的数据库表.我们能够声明只有具有Manager角色的用户才能在特定表中插入/更新/删除数据.如果我们没有通过数据库进行管理，那么每个应用程序团队都必须在整个应用程序中正确实现(复制)该逻辑.如果一个应用程序出错，那么其他应用程序将遭受损失.另外，如果您想更改单个资源的权限，则将需要重复的代码来管理.
One of the advantages is that I could control select/insert/update/delete privileges for EACH table from a single setting in the database. On one system we had 4 different applications (managed by different teams and in different languages) hitting the same database tables. We were able to declare that only users with the Manager role were able to insert/update/delete data in a specific table. If we didn't manage it through the database, then each application team would have to correctly implement (duplicate) that logic throughout their application. If one application got it wrong, then the other apps would suffer. Plus you would have duplicate code to manage if you ever wanted to change the permissions on a single resource.
另一个优点是，我们不必担心将用户密码存储在数据库表中(及其附带的所有限制).
Another advantage is that we did not need to worry about storing user passwords in a database table (and all the restrictions that come with it).
我不同意数据库用户帐户本质上比您的应用程序定义的帐户中的任何内容都危险".更改数据库特定特权所需的特权通常比更新/删除"PERSONS"表中的单行所需的特权要严格得多.
I don't agree that "Database user accounts are inherently more dangerous than anything in an account defined by your application". The privileges required to change database-specific privileges are normally MUCH tougher than the privileges required to update/delete a single row in a "PERSONS" table.
扩展"不是问题，因为我们为Oracle角色分配了权限，然后为用户分配了角色.使用一条Oracle语句，我们可以更改数百万用户的特权(不是我们拥有那么多用户).
And "scaling" was not a problem because we assigned privileges to Oracle roles and then assigned roles to users. With a single Oracle statement we could change the privilege for millions of users (not that we had that many users).
应用程序授权不是一个小问题.许多自定义解决方案都有漏洞，黑客可以轻松利用这些漏洞.像Oracle这样的大人物已经为提供强大的应用程序授权系统投入了大量的思想和代码.我同意使用Oracle安全性并不是对每个应用程序都有效.但是我不会很快就拒绝它，而赞成使用自定义解决方案.
Application authorization is not a trivial problem. Many custom solutions have holes that hackers can easily exploit. The big names like Oracle have put a lot of thought and code into providing a robust application authorization system. I agree that using Oracle security doesn't work for every application. But I wouldn't be so quick to dismiss it in favor of a custom solution.
这篇关于应用程序用户应该是数据库用户吗?的文章就介绍到这了，希望我们推荐的答案对大家有所帮助，也希望大家多多支持！