OData是否打算在政府和金融环境中使用？我需要哪些安全预防措施？

Question

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

这是与当前版本的OData/WCF一起使用的正确视角吗？如果没有,你能分享我需要改变的观点吗？

更新

目前关注的例子包括:

• 增加了SQL注入的可能性
• 附加数据验证(使业务逻辑复杂化)
• 未经授权访问数据
• 提高了对数据进行"原始转储"的能力
  • 通过这个我的意思是使用OData更容易获得HR数据,然后它是屏幕刮取传统的ASP.net页面

更新2

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

Answer 1

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

关于您的具体问题:

• 如果您使用ADO.NET数据服务作为oData服务器,则无法进行SQL注入.传入的oData请求被解析,然后传递给a IQueryable,它正确地转义所有值.
• 业务层/数据层验证保持不变.oData只为数据层(或业务层,如果它看起来像数据库)提供API.
• 除非您允许,否则无法对数据进行未经授权的访问.ADO.NET数据服务的默认设置是不允许任何访问(甚至是只读访问),因此强制您明确授权所有访问权限.
• "原始转储"的情景正是为什么的OData是非常有用!它是一种允许通过Web有效查询数据源的协议,而不是依赖于脆弱的屏幕抓取"解决方案".如果您不希望某人获取信息,请不要发布.

现在(据我所知),ADO.NET Data Services是唯一可用的oData提供程序,默认情况下它是安全的.我想其他人可以编写一个默认情况下不安全或允许SQL注入的oData提供程序,但那是愚蠢的.

另外,请记住oData完全脱离了身份验证的概念.您可以使用对您的API有意义的任何身份验证.有一个伟大的最近的一系列博客文章从WCF团队解决的OData如何处理各种形式的认证.