1

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

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

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

2 回答 2

2

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

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

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

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

于 2010-05-12T07:42:06.797 回答
1

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

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

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

于 2010-05-12T06:25:19.583 回答