内部网络上的 WCF 端点安全最佳实践答案

【问题标题】：WCF Endpoint Security Best Practices on an Internal Network内部网络上的 WCF 端点安全最佳实践
【发布时间】：2012-06-14 20:54:04
【问题描述】：

在我们的组织中，我们托管了许多 WCF 服务，这些服务在我们的内部网络上相互通信。通常，我们为这些服务使用 netTcpBinding 以提高性能。目前关于是否在绑定端点上启用安全性存在争议，我想了解是否有任何具体的指导方针可用于确定是否/何时禁用安全性是合适的。

我倾向于保持开启安全性，因为

争论的另一面是：

我想无论最佳实践是什么，最终的答案最终都是“视情况而定”。但是我想知道在生产环境中应该优先考虑哪种方案。

【问题讨论】：

在 wsHttpBinding（不是 TCP）上测试，不支持 PerSession，安全性为 none。你使用 PerSession。如果是这样测试。没有安全性如何识别通道？

【解决方案1】：

你是对的 - '这取决于'。

安全是一件好事，但如果您不需要它（即您在安全的环境中工作，不需要身份验证），那么它可能会产生很大的开销。

我最近参与了一个项目，在该项目中我们发现 Windows 身份验证导致了巨大的开销，请求大小增加了一倍或三倍（大量微小的请求）。我们只需关闭身份验证即可显着提升性能。

WCF 的好处是安全性是完全可配置的。假设您的代码中没有任何安全依赖项，您可以在以后根据需要通过配置轻松地打开和关闭它。还假设您正在使用配置！

【讨论】：

【解决方案2】：

听起来好像您已经在不安全的情况下运行服务。很明显，有人决定使用您当前的配置。我倾向于非常依赖“如果它没有损坏就不要修复它”原则，因此在您的场景中，更改许多 WCF 服务的配置需要说明为什么需要的时间和精力应该投资这样做。坦率地说，在你的场景中，你提出的支持安全的三点对我来说并不适用。

这与做出新开发或新环境的决定完全不同。在这种情况下，默认的“Security On”（假设工作量、成本和性能影响最小）将是我的首选选项。

【讨论】：

我们有一些可以做，也有一些不能做，但并没有真正的标准。这完全取决于开发人员在哪一方进行初始配置。一旦以一种方式配置了服务，我们就尽量不要返回并更改它，因为这需要跟踪和更新连接到它的每个客户端。

【解决方案3】：

尚未提及，但我也倾向于考虑您传递的数据类型。如果我们谈论的是银行交易或一些重要的事情，我会选择尽可能多的安全性。另一方面，如果只是某些桌面应用程序中显示的数据而不是帐号、社会保险号、信用卡信息等，那么我认为禁用它没有问题。

另外，性能目前是个问题吗？如果您必须满足 SLA 的定义和交易时间，那么禁用安全性可能是一件好事。

它是如此可配置，因为有很多事情需要考虑:)

【讨论】：

对于大多数服务，性能并不是真正的问题。但是，我可以想象，随着越来越多的这些服务相互通信，曾经可以忽略不计的性能差异可能会聚合成开始减慢速度的东西。但是，我确实认为您在考虑中包含正在交换的数据是一个很好的观点。