数据库权限和 ORM
我最近经常使用 .NET 的实体框架，并且绝对不想再继续使用存储过程。令我震惊的是，我正在为其构建此项目的公司制定了一项政策，即仅向应用程序授予仅有权访问存储过程的帐户！
显然，他们认为允许应用程序直接访问表/视图存在安全风险。我不明白这一点。
- 我的第一个问题是，有人可以告诉我直接访问数据库的应用程序可能会带来什么样的安全风险吗？如果
- 是这样的话，是否有任何其他 ORM 解决方案可以提供解决方法（我想不出任何逻辑可能性 atm），让我能够绕过分配给我的用户帐户的限制？或者我认为我需要表和视图的直接权限是错误的吗？
I've been using .NET's Entity Framework a lot lately and have absolutely no wish to go back to using Stored Procedures. Been shocked though that the company I'm building this project for had a policy where applications were only given accounts that only had permissions to access stored procedures!
Apparently, they believe that there's a security risk involved in allowing applications to access the tables/views directly. I don't get this.
- My first question is, can someone enlighten me as to what kind of security risk applications having direct access to the database may pose? AND
- If that's the case, are there any other ORM solutions that can provide a workaround to this (I can't think of any logical possibility atm) that would allow me to circumvent the restrictions on the user account to be assigned to me? OR is my understanding that I'd need direct permissions for the tables and views wrong?
如果你对这篇内容有疑问，欢迎到本站社区发帖提问 参与讨论，获取更多帮助，或者扫码二维码加入 Web 技术交流群。
绑定邮箱获取回复消息
由于您还没有绑定你的真实邮箱，如果其他用户或者作者回复了您的评论，将不能在第一时间通知您！
发布评论
评论（2）
仔细想想，在特定的上下文中，限制对存储过程的访问是很有意义的。这些过程公开了一个 API 并进行处理（例如检查复杂的约束），这在理论上是没问题的。
没有简单的方法来声明跨列约束，例如“如果 A 列为空，则 B 列应该是 {X, Y, Z} 之一”。多个应用程序可能正在使用过程 API，并且所有应用程序都可以从确保以正确方式处理数据的过程中受益。
然而，任何尝试过在数据库中编写大量逻辑以及在通用 OOP 语言中编写大量逻辑的人都知道，前者往往会导致不可维护的、数据库锁定的难以理解的代码山，而后者是公认的作为“编写复杂应用程序/系统的方式”。
虽然存储过程 API 方法还远未消亡，但如果看到一个新项目开始使用这种模式，我会感到非常惊讶。 ORM 远非完美，但它们确实提供了巨大的好处，这些好处越来越被认为是理所当然的：整个应用程序可以用一种语言（Python、Java、Groovy、Ruby...）编写，你通常可以在几分钟内切换 DBMS（这会产生奇迹，例如当你在 hsqldb 上运行测试，但在生产中使用 postgresql 时），从数据库到数据库的数据打包要简单得多（ORM 通常返回域对象， 。
有鉴于此，应用程序对其数据库中的所有内容具有完全的 CRUD 访问权限是完全可以接受的 另外，如果您的帐户只允许您调用存储过程，我不建议您花时间研究如何规避访问权限：更好地利用您的时间是争取 CRUD 表访问权限。
When you think about it, in a certain context, limiting access to stored procedures makes a lot of sense. The procedures expose an API and handle processing (e.g. check complex constraints) which is in theory fine.
There's no easy way to declare cross-column constraints like "if column A is null, column B should be one of {X, Y, Z}". Multiple applications might be using the procedure API and all could benefit from the procedures making sure the data is treated the right way.
However, anyone who has tried to write a lot of logic in the database and a lot of logic in an general purpose OOP language knows that the former tends lead to an unmaintainable, DB-locked mountain of unintelligable code, while the later is generally recognized as "the way to write complex applications/systems".
While the stored procedure API approach is far from extinct, I would be genuinely surprised to see a new project started using this pattern. ORMs are far from perfect, but they do provide huge benefits which are more and more taken for granted: the whole application can be written in one language (Python, Java, Groovy, Ruby...), you can usually switch the DBMS in a few minutes (which works wonders e.g. when you're running tests on hsqldb, but use postgresql in production), data packaging from and to the database is a lot simpler (the ORM usually returns domain objects, rather than primitives), there are caching advantages etc.
In light of this, it is perfectly acceptable that an application have full CRUD access to everything in it's database. Also, if you have an account which only allows you to invoke stored procedures, I wouldn't recommend spending time looking into how you can circumvent the access rights: a better use of your time would be to argue for CRUD table access privileges.
愚蠢的有限思维 - 除非他们将完整的访问逻辑放入数据库中。，
http://weblogs.asp.net/fbouma/archive/2003/11/18/38178.aspx
有一个很好的解释为什么安全不是一个原因。正如我所说 - 除非完整的业务逻辑验证谁看到数据库中的内容......然后就不再是多层应用程序了。
Idiotic limited thinking - unless they put the complete access logic into the daabase.,
http://weblogs.asp.net/fbouma/archive/2003/11/18/38178.aspx
has a good explanation on why security is NOT a reason. As I said - unless the complete business logic validating who sees what is in the database.... which is then not a multi tier application anymore.