数据库权限和ORM

Question

我最近一直在使用.NET的实体框架，并且绝对不希望回到使用存储过程。虽然我正在构建这个项目的公司制定了一项政策，其中只有只有权访问存储过程的帐户，但我感到震惊！

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

1. 我的第一个问题是，有人可以告诉我直接访问数据库的安全风险应用程序可能带来什么样的风险？ AND
2. 如果是这种情况，是否有任何其他ORM解决方案可以为此提供解决方法（我无法想到任何逻辑可能性atm），这将允许我规避对我分配的用户帐户的限制？或者我的理解是，我需要对表和视图的直接权限错误吗？

Answer 1

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

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

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

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

Answer 2

白痴有限思维 - 除非他们将完整的访问逻辑放入daabase。，

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

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