Windows Azure VPN 和 IP 限制
我们与第三方服务集成，可以在其中运行目前使用 HTTPS 加密和用户名/密码保护的查询。我们从 Windows Azure 云上运行的服务发送查询。
第三方提供商希望迁移到更好的安全性，他们要求我们
- 设置 VPN - 这是有问题的，因为我们需要使用 Azure Connect，他们必须在上安装客户端端点服务 设置 VPN -这
提供一些查询来源的 IP 地址，以便它们可以在防火墙级别过滤掉任何其他人 - 这是有问题的，因为据我所知，您无法修复 Windows Azure 计算节点的 IP 地址。
建议另一种安全的替代方案 - 我唯一能想到的就是在非 Azure 服务器上设置 VPN，然后通过使用 Azure Connect 隧道传输请求 - 这对我们来说显然是额外的工作，也破坏了如果服务依赖于非云服务，则将其托管在云上。
有什么想法吗？
- 他们可以在 DMZ 网络上的另一台服务器上安装 Azure Connect 终结点吗？即不是托管其服务的实际服务器？
- 我们能否以某种方式为他们提供用于传入查询的静态 IP？
- 还有其他可扩展的解决方案吗？
谢谢
We integrate with a third-party service where we can run queries which is right now secured using HTTPS encryption and username/password. We send our queries from a service running on the Windows Azure cloud.
The third-party provider wants to migrate towards better security and they have asked us to either
Setup a VPN - which is problematic because for we'd need to use Azure Connect and they'd have to install the client endpoint service on their part.
Provide some IP address where the queries will come from so they can filter out anyone else at the firewall level - which is problematic because AFAIK you cannot fix the IP addresses of the Windows Azure Compute nodes.
Suggest another secure alternative - the only thing I could think of is to set up the VPN with them on a non-Azure server and then tunnel the requests through using Azure Connect - which is obviously extra work for us and also defeats the point of hosting the service on a cloud if it depends on a non-cloud service.
Any ideas?
- Can they install the Azure Connect endpoint on another server on their DMZ network? i.e. not the actual server which hosts their service?
- Can we somehow provide them with static IPs for incoming queries?
- Any other solution that is scalable?
Thanks
如果你对这篇内容有疑问，欢迎到本站社区发帖提问 参与讨论，获取更多帮助，或者扫码二维码加入 Web 技术交流群。
绑定邮箱获取回复消息
由于您还没有绑定你的真实邮箱，如果其他用户或者作者回复了您的评论，将不能在第一时间通知您！
发布评论
评论（2）
如果我正确理解了该场景，您的 Azure 服务是第三方服务的客户端。这种情况可以通过使用 Windows Azure AppFabric 服务总线来解决。您需要在第三方数据中心安装代理应用程序，负责建立与服务总线的连接。连接来自第三方数据中心内部，因此防火墙中没有新的传入漏洞。该连接可以利用其所有安全优势处理 WCF 连接，并且可以使用 ACS 对用户进行身份验证。
这是一个起点： http://msdn.microsoft.com/en-us /library/ee732537.aspx
Windows Azure 平台培训工具包中有一个实践实验室，它解释了您需要的大部分详细信息。
If I understand the scenario correctly, your Azure service is a client to a 3rd party service. This scenario may be solved through the use of the Windows Azure AppFabric Service Bus. You would need to install a proxy app in the 3rd party's datacenter that would be responsible for establishing the connection to the service bus. The connection comes from inside the 3rd party's datacenter, so no new incoming holes in the firewall. The connection can handle WCF connections with all its security strengths, and users can be authenticated with ACS.
Here is a starting point: http://msdn.microsoft.com/en-us/library/ee732537.aspx
There is a hands on lab in the Windows Azure Platform Training Kit that explains most of the details that you'll need.
恕我直言，HTTPS 已经非常好；而且我不太明白 VPN 如何使系统更加安全。特别是，VPN 并不是灵丹妙药，如果您的虚拟机受到威胁，那么 VPN 连接也会受到威胁（对于 HTTPS 也是如此）。另一方面，IP限制确实会减少攻击面。
那么，使用云之外的服务器确实是一个糟糕的主意。它不仅破坏了云的大部分好处（曾经在那里，做过这些，并遭受了很多痛苦），而且还使整个事情变得不那么安全，变得更加复杂，受到更多的攻击。
Windows Azure 目前不提供任何看起来像静态 IP 的东西。根据我们的经验，即使服务仅升级（且从未删除），给定服务的 IP 地址也会偶尔更改。长期以来，静态 IP 地址一直是一项重要的功能请求，微软可能会在某个时候提供它，但可能仍需要几个月的时间。
IMHO, HTTPS is already very good; and I don't exactly see how a VPN would make the system any more secure. In particular, VPN is no silver bullet, if your VM is compromised then the VPN connection is compromised too (same for HTTPS). On the other hand, the IP restriction would indeed reduce the attack surface.
Then, using a server outside the cloud is a poor idea indeed. Not only it defeats most of the benefits of the cloud (been there, done that and suffered a lot), but also it also makes the whole thing less secure with more complexity and more attack surface.
Windows Azure does not provide anything that look like a static IP at this point. In our experience, IP addresses for a given service change once in a while even if the service is only upgraded (and never deleted). Static IP addresses have been an important feature request for a long time, Microsoft will probably provide it at some point, but it might still take many months.