【问题标题】:WCF wsHttpBinding within the data-centre - typical usage pattern数据中心内的 WCF wsHttpBinding - 典型使用模式
【发布时间】:2012-03-14 20:04:35
【问题描述】:

这是一个架构问题 - 我希望这是正确的堆栈交换 - 这些似乎没有一个自然的家......

我工作的系统分布在数据中心内 - DMZ 中的 Web 服务器然后调用安全区域中的 Web 服务(通过防火墙)以访问数据。这当前使用带有 WSE 的 asmx 服务,在 SOAP 标头中传递用户名和密码凭据。这些是通过未加密的。有人认为这提供了某种安全措施(互联网 DMZ 服务器上的攻击者无法访问从内部网 DMZ 服务器访问的服务的凭据)。

我们希望转向使用 WCF,但仍坚持使用 Web 服务。我们希望使用 wsHttpBinding 来实现与其他客户端的最佳互操作性并符合标准。继续使用用户名身份验证,这似乎要求使用 SSL 或消息加密,对于很多人来说,在我们控制两个端点的我们自己的数据中心内加密连接似乎有点矫枉过正。

我很想知道这是否是其他人所做的以及我们有哪些替代方案。我已经考虑过(并排除了以下几个)

  • SecurityMode = None - 不使用任何凭据。我们的安全人员对此并不满意,因为外部网络服务器上的攻击者可以访问他们喜欢的任何服务
  • 使用 BasicHttpBinding - 我认为这可以配置为使用 TransportCredentialOnly 传递未加密的用户凭据。但是,有点担心 BasicHttpBinding 是一种传统方法,与其他技术的互操作性较差
  • 使用Clear Username Binding - 但是,这是开源的,我的组织出于法律原因不想接近开源
  • 接受即使在数据中心内我们也必须转移到加密消息
  • 更改为使用不同的身份验证类型,例如Windows 凭据 - 担心这可能会对我们当前操作这些服务的方式以及我们是否可以从 DMZ 访问目录服务器产生重大变化。

任何关于其他人如何在具有安全区域的数据中心内使用 WCF 的想法将不胜感激

【问题讨论】:

  • 我对 WCF 安全性的了解还不够,无法回答您的所有问题,但我知道您可以在哪里找到!查看 Juval Lowy 的 Programming WCF 服务的第 10 章。这就是 WCF 的圣经,第 10 章涵盖了您想了解的有关 WCF 安全性的所有内容。
  • 感谢您的评论。有趣的是,我已经有了那本书。 IIRC Intranet 场景假设一个“平面”网络,客户端和服务器都在一个没有防火墙/网络分区等的网络上。因此,建议使用诸如 netTCP 之类的绑定,而不是我继承的防火墙友好 Web 服务方法。不过周一我会重读一遍(在我工作的办公桌抽屉里订书!)

标签: .net wcf security architecture wcf-security


【解决方案1】:

使用 BasicHttpBinding - 我认为这可以配置为通过用户 使用 TransportCredentialOnly 未加密的凭据。然而, 有点担心 BasicHttpBinding 旨在作为遗产 方法并且与其他技术的互操作性较差

基本 HTTP 身份验证是您可以使用的最具互操作性的内置身份验证机制,但它以纯文本形式发送密码。如果您在 IIS 中托管您的服务并且您不想使用 Windows 帐户进行身份验证,那么使用也会有一些小麻烦。

SecurityMode = None - 不使用任何凭据。我们的安全人员 对此不满意,因为外部网络服务器上的攻击者可能 访问他们喜欢的任何服务

在企业环境中保护服务是必须的。

更改为使用不同的身份验证类型,例如视窗 凭证 - 担心这可能对我们的方式产生重大变化 目前运营这些服务,以及我们是否可以访问 来自 DMZ 的目录服务器。

一旦您开始使用 Windows 凭据,您将不得不为两个网络使用相同或受信任的域。

在这种情况下,更好的选择是证书(CertificateOverTransport 自定义安全模式)。 WCF 中基本身份验证和 UserNameToken 身份验证的问题是用户名和密码以纯文本形式传输。这也是为什么 WCF 默认情况下(总是在 .NET 4 之前)要求通过 HTTPS 或通过消息安全进行加密的原因。任何攻击者(包括更危险的内部攻击者)都可以嗅探 DMZ 或内部网络中的通信,并获得访问您的服务所需的所有凭据。

一旦您开始使用证书,带有私钥的证书本身将安全地存储在 DMZ 中的服务器上 - 您甚至可以使证书不可导出。一旦 DMZ 应用程序调用您的内部服务,它会将有关使用的证书的信息添加到 SOAP 标头中并签署消息的时间戳。任何人都可以验证签名(并证明调用者的身份),但只有私钥的持有者才能创建一个 = 即使攻击者可以访问网络通信,他也无法窃取身份。还有其他与证书相关的安全机制。

UserNameToken(如您在 WSE 中使用的)支持加密密码,但 WCF 没有实现此功能。

为避免为UserNameOverTransportCertificateOverTransport 请求加密,您必须use custom binding(仅适用于 .NET 4 - 之前的版本需要一些来自 MS 的 KB)。

【讨论】:

  • 感谢您的详细回答 - 我还没有完全处理所有信息,但是关于 cmets 的初步问题“必须在企业环境中保护服务”和“任何攻击者(包括内部攻击者)危险得多)可以嗅探 DMZ 或内部网络中的通信,并获取他访问您的服务所需的所有凭据”。这似乎很明智,但我一直对数据中心内的加密感到有趣。有什么想法(在数据中心内加密)是正常做法还是有些不寻常?
  • 当您在未加密消息中以纯文本形式发送凭据时的目标情况。在这种情况下,攻击者可以简单地获取然后调用您的服务。我不确定在数据中心内加密消息有多普遍,但在银行甚至内部网络中也绝对普遍。
猜你喜欢
  • 1970-01-01
  • 1970-01-01
  • 1970-01-01
  • 2010-11-11
  • 1970-01-01
  • 1970-01-01
  • 1970-01-01
  • 2018-10-08
  • 1970-01-01
相关资源
最近更新 更多