database - 'real' 数据库授予用户什么权限?

标签 database security database-permissions

<分区>

在阅读@PerformanceDBA 对Historical / auditable database 的回答时他发表了这样的声明:

In a real (standard ISO/IEC/ANSI SQL) database, we do not GRANT INSERT/UPDATE/DELETE permission to users. We GRANT SELECT and REFERENCES only (to chosen users) All INSERT/UPDATE/DELETEs are coded in Transactions, which means stored procs. Then we GRANT EXEC on each stored proc to selected users (use ROLES to reduce administration).

这是真的吗?这与动态生成 INSERT/UPDATE 的 ORM 工具有什么关系?

更新

好的,下面是一个示例。我有一个具有两个界面的 Web 应用程序,AdminUser。管理端使用重型 ORM,能够动态生成数百甚至数千条不同的 SQL 命令。

用户交互要简单得多,我有十几个 SP 可以处理几个投票按钮的任何更新/插入。显然,运行应用程序的用户具有非常不同的权限集。在管理员方面,ORM 的数据库用户对相关表具有完全的 CRUD 访问权限,这个应用程序根本没有使用任何 SP——我不会想到在不通过域模型中的业务逻辑的情况下接触数据.甚至批量数据导入也通过 ORM 进行处理。用户端的 SP 我认为对这一原则的小让步只是因为它们是一种特殊情况。

现在,我发现原始问题中的上述陈述有些令人不安,因为我认为这是一个“真实的”数据库,或者至少接近它。

最佳答案

它就像狂欢中的爷爷一样兴奋。 ORM 可以利用 SP,但不能充分利用它们。

SP Only 肯定是过去的生活方式,它就像第十一条诫命,但正如您指出的那样,ORM 并不是真的那样工作。我曾经认为整个 SP 层本身就是一种青春期前的 ORM,你拿你的关系数据库,进行一堆连接并返回一组数据,其中包含填充你的对象所需的列/属性。

现在,对于动态 ORM 类型的应用程序,需要在表中指定权限,如果您的 DBA 正在做他们的工作,它的安全性也不会降低,只是需要做更多的工作,并且需要就允许的内容进行更多的沟通在表上,如果您不需要 DELETE,那么您的 DBA 需要知道不要为其授予权限。

优秀的 DBA 知 Prop 有表访问权限的安全数据库与仅具有 SP 访问权限的数据库一样安全。让信心不足的 DBA 相信这一点要困难得多。

关于database - 'real' 数据库授予用户什么权限?,我们在Stack Overflow上找到一个类似的问题: https://stackoverflow.com/questions/8656267/

相关文章:

java - 将外键字段添加到 javabean

PHP - 路径操作/输入验证

mysql - CakePHP:对 MySQL 用户和权限使用什么?

security - OpenID Connect 中的注销等效于什么?

python - 是否有推荐的做法或框架来实现 google-app-engine db.Model/ndb.Model 的记录级权限)?

postgresql - 我如何设置权限,以便所有开发人员都获得对任何其他开发人员创建的对象的所有特权?

iphone - 从远程数据库中检索数据

php - 尝试将 php 运算符作为字符串保存在数据库中

php - JSON 数组未设置

c - 此缓冲区溢出是否适用于 Mac OSX?