OData打算在政府和金融环境中使用吗？我需要什么安全防范措施？

Question

首先，OData似乎只会吸引“开放”数据库，并且永远不会用于需要安全性的环境中，特别是对于金融或政府客户。

这是正确的观点来与的OData/WCF的当前版本？如果没有，你可以分享我需要改变这个观点吗？

更新

的当前关注

例子包括：

• SQL注入的可能性增高
• 其他数据验证（复杂的业务逻辑）
• 未经授权访问数据
• 增加做数据“原始转储”的能力
  • 我的意思是它更容易使用的OData去人力资源数据，那么它是屏幕刮传统的ASP.net页面

更新2

我是否也可以执行业务规则？例如，格式正确的SSN，电话或邮编。如何确保所有字段都已填写？

Answer 1

的OData只是揭露方式结构化数据通过一个开放的API。它不需要请求任何特定形式的安全性;可以拥有完全开放的数据集（如维基数据库）或世界可读但私人可写的数据库（例如国会成员投票数据库，这样任何人都可以阅读它，但只有您可以更新它）。它还支持更复杂的安全结构（例如视频租赁商店，允许客户只查询自己的历史记录）。

关于你提到的具体问题：

• SQL注入，如果你正在使用ADO.NET数据服务为您的OData服务器是根本不可能的。传入的oData请求会被解析，然后传递给IQueryable，这会正确地转义所有值。
• 业务层/数据层验证保持不变。 oData仅为数据层（或业务层，如果数据库看上去）提供了一个API。
• 未经授权的访问数据是不可能的，除非你允许。 ADO的默认值。NET数据服务是不允许任何访问（即使只读访问），以便强制您明确授权所有访问。
• “原始转储”场景恰好是为什么 oData非常有用！这是一个允许通过网络有效查询数据源的协议，而不是依赖脆弱的屏幕抓取“解决方案”。如果您不希望有人获取信息，请勿发布。

现在（据我所知），ADO.NET Data Services是唯一可用的oData提供程序，并且默认情况下它是安全的。我想其他人可以编写一个默认情况下不安全或允许SQL注入的oData提供程序，但这样做很愚蠢。

另外，请记住oData与身份验证的概念完全脱节。您可以使用任何认证对您的API有意义。 WCF团队提供了一个great recent series of blog posts，它解释了oData如何与各种形式的身份验证配合使用。

Answer 2

确定您可以在政府解决方案中使用它。 OData只是一种访问数据的方式，它与使信息安全无关。您必须在传输级别（SSL）而不是应用级别上实施安全性（向应用程序提供登录名和密码）。

有很多方法可以解决这个问题。一个例子是，如果您使用SSL，则可以强制客户端提供客户端证书并进行身份验证。一旦人有认证，您可以使用您的应用程序来限制他们可以看到（或许他们只能看到自己的客户信息，因此所有的查询自动限制的人看到这一点。）

Answer 3

您使用OData的商业案例是什么？ OData主要用于以平台不可知的方式公开您的数据......以便.NET，Java，Php，Python，REST等客户端都可以访问您的数据。这是你的用例吗？

或者您是否试图通过服务层（一种SOA方法）公开您的数据，以便您的客户端（您控制的）更好地与数据源分离。在这种情况下，OData可能不是正确的解决方案。我将OData视为数据服务层的一部分，并认为它太慢了。我正在寻找Devforce，它为实体框架模型（通过他们的BOS服务）实现基于服务的访问......包括LINQ到服务托管模型在内的全部CRUD操作。

安全性是你想要的水平是可能的，既可以查看OData或通过DevForce。选择正确的数据远程解决方案，然后研究正确的安全实施。