1

在阅读@PerformanceDBA 对历史/可审计数据库的回答时,他发表了以下声明:

在真实的(标准 ISO/IEC/ANSI SQL)数据库中,我们不会向用户授予 INSERT/UPDATE/DELETE 权限。我们仅授予 SELECT 和 REFERENCES(对选定的用户)所有 INSERT/UPDATE/DELETE 都在 Transactions 中编码,这意味着存储过程。然后我们将每个存储过程上的 EXEC 授予选定的用户(使用 ROLES 来减少管理)。

这是真的?这与动态生成 INSERT/UPDATE 的 ORM 工具有何不同?

更新

好的,这里有一个例子。我有一个带有两个界面的 Web 应用程序,一个Admin和一个User。管理端使用重型ORM 能够动态生成数百个甚至数千个不同的 SQL 命令。

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

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

4

2 回答 2

1

我会说这是最好的设计,也是我通常喜欢练习的。由于来自应用程序的即席查询可能很混乱、难以调优,甚至更难以排除故障和跟踪,因此使用存储过程最容易获得抽象级别。应用程序只能进行存储过程调用。将存储过程视为数据库的 API。

因此,如果以上是设计目的,那么应用程序用户只需要SELECTEXECUTE数据库。这就是为什么:

create procedure MyTestProcedure
with execute as 'UserWithDMLRights'
as

    -- your CRUD code

go

如果典型的应用用户只有SELECTand EXECUTE,那么执行上述存储过程的权限就足够了。存储过程中的将INSERT/UPDATE/DELETE在 的安全上下文中执行UserWithDMLRights,并且该数据库用户必须具有INSERT/DELETE/UPDATE权限。

至于 ORM,我倾向于同意你的看法。我相信 L2S 只是使用 进行大量的临时查询调用sp_executesql,所以我相信你会遇到这个理论和使用上述安全实践的问题。

于 2011-12-28T13:15:06.103 回答
1

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

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

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

优秀的 DBA 知道具有表访问权限的安全数据库与仅具有 SP 访问权限的数据库一样安全。说服不那么自信的 DBA 是一件困难得多的事情。

于 2011-12-28T13:29:44.330 回答