数据库权限和ORMs

最近我一直在使用.NET的实体框架，绝对不想回到使用存储过程。我很震惊，虽然我正在建立这个项目的公司有一个政策，应用程序只给予帐户，只有权限访问存储过程！数据库权限和ORMs

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

我的第一个问题是，有人能告诉我哪种安全风险应用程序可以直接访问数据库吗？ AND
如果是这样的话，有没有其他ORM解决方案可以提供解决方法（我想不出任何逻辑可能性atm），这将允许我规避要分配给用户帐户的限制我？ OR是我的理解，我需要对表和视图的直接权限错误？

2010-05-12 Jonn

您是否有权更改存储过程？存储过程是否可以完全访问表？ ORM对表格的工作效果最好，但是一个好的ORM通常会退化为以相当残缺的方式处理存储过程。 – 2010-05-12 11:16:42

哦。我还没有探索过这个选择。 – Jonn 2010-05-12 22:47:31

当你考虑这个问题时，在某个上下文中，限制对存储过程的访问是非常有意义的。这些过程公开了一个API并处理理论上很好的处理（例如检查复杂约束）。没有简单的方法来声明交叉列约束，如“如果列A为空，列B应该是{X，Y，Z}之一”。多个应用程序可能会使用过程API，并且所有程序都可以从程序中受益，从而确保以正确的方式处理数据。但是，任何试图在数据库中编写大量逻辑并且使用通用OOP语言编写大量逻辑的人都知道，前者倾向于导致无法维护的，DB锁定的不可理解代码的高峰，而后来通常被认为是“编写复杂应用程序/系统的方式”。

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

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

来源

2010-05-12 07:42:06

具有跨列约束的多个应用程序是否不会受益于实施SOA而不是在后端存储了特效？关于“我真的很惊讶地看到一个新项目开始使用这种模式”，那么你会感到震惊并且非常失望，因为我希望我们的团队只使用ORM而不是传统存储的项目数量procs（以及IMO可疑的ApplicationBlocks.SqlHelper） – Jonn 2010-05-12 08:09:01

Cross column！=交叉表。 ;） – TomTom 2010-05-12 08:13:32

@Jonn我不确定我们是否在同一页面上，但我可以说是的，我同意你的看法，SOA在存储过程中是一种更好的方法。 – 2010-05-12 08:20:27

白痴局限的思维 - 除非他们把整个访问逻辑到daabase，

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

对安全为何不是理由了很好的解释。正如我所说的 - 除非完整的业务逻辑验证谁看到数据库中的内容......然后再不是多层应用程序。

来源

2010-05-12 06:25:19 TomTom

这就是我想到的。我想不出为什么我的应用程序不应该访问表的正当理由。并没有这样的业务逻辑验证谁看到了数据库中的内容，正如你所说的那样。 – Jonn 2010-05-12 07:55:51

然后它变得毫无意义。我们可以谈论插入/更新所需的全部内容，但纯SQL的灵活性难以胜任查询。 LINQ最终允许它在编程语言中本地暴露。放弃这一点 - 没有任何可以获得的回报 - 是一种公然的愚蠢迹象。 – TomTom 2010-05-12 08:14:16

有点苛刻，我仍想试着了解这个推理背后是否有一个很好的理由，但我不能同意你的看法。我宁愿不必为每一个程序功能使用两种不同的语言。 – Jonn 2010-05-12 08:32:28

数据库权限和ORMs

回答

相关问题