sql - OData 是否旨在用于政府和金融环境？我需要什么安全预防措施？

Question

乍一看，OData 似乎只会吸引“开放”数据库，并且永远不会用于需要安全性的环境，尤其是金融或政府客户。

这是当前版本的 OData/WCF 的正确观点吗？如果没有，你能分享我需要改变这种观点的任何东西吗？

更新

当前关注的示例包括:

增加 SQL 注入(inject)的可能性

附加数据验证(复杂的业务逻辑)

未经授权访问数据

增加“原始转储”数据的能力

我的意思是使用 OData 获取 HR 数据更容易，然后是屏幕抓取传统的 ASP.net 页面

更新 2

我也可以执行业务规则吗？例如格式正确的 SSN、电话或 Zip。如何确保填写所有字段？

Answer 1

oData 只是一种通过开放 API 公开结构化数据的方式。它不要求任何特定形式的安全；可以拥有完全开放的数据集(如 wiki 数据库)或世界可读但私有(private)可写的数据集(如国 session 员投票的数据库，因此任何人都可以阅读它，但只有您可以更新它)。它还支持更复杂的安全结构(例如允许客户仅查询自己的历史记录的视频租赁商店)。

关于您的具体问题:

如果您使用 ADO.NET 数据服务作为您的 oData 服务器，则根本不可能进行 SQL 注入(inject)。传入的 oData 请求被解析，然后传递给 IQueryable ，它正确地转义了所有值。

业务层/数据层验证保持不变。 oData 只是为数据层(或业务层，如果它看起来像数据库)提供了一个 API。

除非您允许，否则无法未经授权访问数据。 ADO.NET 数据服务的默认设置是不允许任何访问(甚至是只读访问)，这会强制您明确授权所有访问。

“原始转储”场景正是 oData 如此有用的原因!它是一种允许通过网络有效查询数据源的协议(protocol)，而不是依赖于脆弱的屏幕抓取“解决方案”。如果您不希望有人获得信息，请不要发布它。

目前(据我所知)，ADO.NET 数据服务是唯一可用的 oData 提供程序，默认情况下它是安全的。我想其他人可以编写一个默认不安全或允许 SQL 注入(inject)的 oData 提供程序，但那将是愚蠢的。

另外，请记住 oData 完全脱离了身份验证的概念。您可以使用对您的 API 有意义的任何身份验证。有一个 great recent series of blog posts来自 WCF 团队，讨论了 oData 如何与各种形式的身份验证一起工作。