数据库权限和 ORM答案

【问题标题】：Database permissions and ORMs数据库权限和 ORM
【发布时间】：2010-05-12 22:26:58
【问题描述】：

我最近一直在使用 .NET 的 Entity Framework，并且绝对不想再使用存储过程。尽管我正在为其构建此项目的公司有一项政策，即仅向应用程序授予仅有权访问存储过程的帐户，但我感到震惊！

显然，他们认为允许应用程序直接访问表/视图存在安全风险。我不明白这个。

我的第一个问题是，谁能告诉我直接访问数据库的应用程序可能会带来什么样的安全风险？和
如果是这种情况，是否有任何其他 ORM 解决方案可以解决此问题（我想不出任何合乎逻辑的可能性 atm），可以让我绕过对分配给我的用户帐户的限制?或者我认为我需要对表和视图的直接权限是错误的吗？

【问题讨论】：

您有权更改存储过程吗？存储过程是否具有对表的完全访问权限？ ORM 对表最有效，但一个好的 ORM 通常可以退回到以相当残缺的方式处理存储过程。
哦。我还没有探索过这个选项。

【解决方案1】：

当您考虑它时，在特定上下文中，限制对存储过程的访问非常有意义。这些过程公开了一个 API 并处理处理（例如检查复杂的约束），这在理论上是可以的。没有简单的方法来声明跨列约束，例如“如果 A 列为空，B 列应该是 {X, Y, Z} 之一”。多个应用程序可能正在使用过程 API，并且所有应用程序都可以从确保以正确方式处理数据的过程中受益。

但是，任何尝试在数据库中编写大量逻辑并在通用 OOP 语言中编写大量逻辑的人都知道，前者往往会导致无法维护、数据库锁定的大量无法理解的代码，而后者往往通常被认为是“编写复杂应用程序/系统的方式”。

虽然存储过程 API 方法远未绝迹，但看到一个新项目开始使用这种模式，我真的会感到惊讶。 ORM 远非完美，但它们确实提供了越来越多理所当然的巨大好处：整个应用程序可以用一种语言（Python、Java、Groovy、Ruby...）编写，您通常可以在几分钟内切换 DBMS（这会产生奇迹，例如，当您在 hsqldb 上运行测试，但在生产中使用 postgresql 时），与数据库之间的数据打包要简单得多（ORM 通常返回域对象，而不是原语），有缓存优势等。

鉴于此，应用程序对其数据库中的所有内容具有完全 CRUD 访问权限是完全可以接受的。此外，如果您有一个只允许调用存储过程的帐户，我不建议您花时间研究如何规避访问权限：更好地利用您的时间是争取 CRUD 表访问权限。

【讨论】：

具有跨列约束的多个应用程序不会更好地从实施 SOA 中受益，而不是在后端存储过程吗？在“看到一个新项目开始使用这种模式我真的很惊讶”，然后你会感到震惊和非常失望，因为我希望我们的团队只使用 ORM 而不是传统的存储过程的项目数量（以及 IMO 有问题的 ApplicationBlocks.SqlHelper）
跨栏！=跨表。 ;)
@Jonn 我不确定我们是否在同一页面上，但我可以说是的，我同意你的观点，SOA 比 SOA 更好您描述的情况下的存储过程。
@TomTom 不确定你的意思。我的示例是跨列约束。就此而言，跨表约束和许多其他约束也是如此。
同样，我认为它适用于列或表。不管怎样，Tomislav 不在同一个页面上是什么意思？

【解决方案2】：

愚蠢的有限思维 - 除非他们将完整的访问逻辑放入数据库中。

http://weblogs.asp.net/fbouma/archive/2003/11/18/38178.aspx

对为什么安全不是原因有很好的解释。正如我所说 - 除非完整的业务逻辑验证谁可以看到数据库中的内容......那么它就不再是多层应用程序了。

【讨论】：

我也是这么想的。我想不出为什么我的应用程序不能访问这些表的正当理由。并且没有这样的业务逻辑来验证谁可以看到您所说的数据库中的内容。
那么它就变得零意义了。对于插入/更新，我们可以谈论我们想要的一切，但是纯 SQL 的灵活性对于查询来说是难以超越的。 LINQ 最终允许在编程语言中以本机方式公开它。放弃这一点 - 没有任何回报 - 是公然愚蠢的表现。
有点苛刻，我仍然想尝试了解这种推理背后是否有充分的理由，但我完全同意你的看法。我宁愿不必为每个程序功能使用两种不同的语言。
其实并不苛刻。反对直接表访问有充分的理由 - 但它们大多可以通过视图解决，并且意味着您必须在数据库中具有过滤器逻辑。如果不是这种情况，那么在安全方面什么也得不到——而且在开发速度方面（=金钱）损失了很多。亏本无利通常被认为是愚蠢的；）
有道理，考虑到 sps 浪费的所有时间（也许精通它的人可以管理得更好，但我不是）。