Web services 如何在公司内围绕Web服务实现安全性

最近出现了一个关于Web服务安全性的主题。不一定是WSE 3.0中您可能想到的内容，而是更多关于保护公司内服务的内容

比如说。我们一直在讨论通过一个或多个web服务端点向整个公司提供某些功能的可能性。问题归结到谁可以访问web服务。我看到它们以三种不同的方式被访问：

通过一个网站。此网站可能是也可能不是在模拟访问该网站的用户，因此对web服务的调用可能是以真实用户、IIS服务帐户或我们可能出于其他原因模拟的其他服务帐户的身份进行的

通过批处理程序。也在服务器上运行，但通常作为服务帐户运行

通过用户桌面上的windows应用程序，在这种情况下，将使用用户的凭据

现在，理论上，我们可以让web服务对任何人开放。无知就是幸福，对吗？但问题是，如果攻击者访问我们的网络并发现web服务，他将拥有知识产权的全权。所以开放是没有好处的

我们可以使用一些精心设计的自酿方案来锁定他们，检查IP地址、用户名等，但这似乎是一场管理噩梦

有什么想法吗？我们正在讨论一些想法，但我想看看是否有人已经解决了这类问题

---

如果您正在考虑开放端点供内部使用，那么这是一件事，谢谢您，但是您有多少可能的内部客户

如果端点将驱动Excel电子表格或需要动态数据的BI数据立方体，并且可以被各种各样的人使用，那么您将需要仔细考虑安全性。也许您可以将每天生成的API密钥发布到公司内部网上的一个重要页面上，这样，如果数据的内部用户想要使用端点，他们就会有一点不便，但这不会成为一项讨厌的维护工作

如果端点将被少数定制应用程序使用，那么我建议将应用程序本身的安全性紧密耦合（在配置文件中硬编码，然后加密）。通过这种方式，访问可以被广泛使用，但并不广为人知

---

显然，只允许GET（并确保GET不是帖子或伪装的内容）并记录每个端点，以供高级管理层签署。如果高级管理层对允许访问数据的风险感到满意，那么这实际上只是一场关于如何锁定数据的辩论。

在我的公司，我们使用带有加密签名的X509证书。这将为您的服务提供最大的安全性。若要限制对服务的访问，您只能允许客户端的公共证书。这当然意味着您的客户也必须拥有自己的证书。如果您的客户没有自己的证书，您可以使用OpenSSL创建自己的证书。我自己也使用过这个应用程序，并创建了可用于加密或握手目的的合法证书。此外，我相信您可以为每个客户端创建自定义策略，并通过在每个函数上使用策略属性来限制对服务函数的访问（可能是在撒谎，但我想我在某处偶然发现了这一点）。希望这能有所帮助。

事实上，这只是上述内容的一小部分。web服务的大多数消费者将是我们编写的定制应用程序。有些是Excel电子表格。我们正在讨论使用Kerberos的想法，但没有人真正掌握这项技术，也不确定它是否能解决我们的问题。为什么要使用WSE 3.0？它已经过时了。