天蓝色架构 - 处理安全性
计划将我们现有的应用程序迁移到 Azure。 我们现有的安全流程架构如下
ASP MVC 3.0 UI 层，从用户处获取用户名密码 我们计划将 UI 层迁移到计算云上。 并且可以通过 uilayerdomainname.com 进行访问，该网站将具有 SSL 证书。
WCF REST Web 服务层还负责身份验证。目前位于 servicename.cloudapp.net 上。 （我们可以将其映射到 servicelayername.com 并获取该域名的 SSL）。
SQL Azure 数据库
UI 层将凭据发送到服务层，服务层根据 SQL Azure 数据库对其进行身份验证。
问题
WCF 计算云和 UI 层位于 Azure 中的同一区域。这两者之间的通信是否容易受到中间人攻击？我的 WCF 计算云也需要 SSL 吗？我们确实有两个带有 SSL 的域名，因此可以将服务映射到一个。
有什么方法可以限制 UI 层和 WCF 计算云之间的流量 - 仅允许 UI 层访问服务层吗？
如果我在同一个实例上发布 WCF 服务和 UI 层，性能会更好吗？它有点破坏了良好的分层架构，但如果它提高了性能，我可以接受它。我们不想跳过太多的障碍来将应用程序容纳到 Azure，以免从它迁移出来变得困难。
Planning to migrate our existing application to Azure.
Our existing architecture with security flow is as follows
ASP MVC 3.0 UI layer that takes user name password from the user
We are planning to migrate the UI layer onto a compute cloud.
and will be accessible at say uilayerdomainname.com which would have a SSL cert.WCF REST webservices layer that amongst other things does authentication as well. This is currently on say servicename.cloudapp.net. (We could map it to servicelayername.com and get a SSL for that domain name as well).
SQL Azure database
The UI layer sends the credentials to the service layer which authenticates it against the SQL azure database.
Question
Both the WCF compute cloud and UI Layer are on the same region in Azure. Would the communication between these two be prone to man in the middle attacks? Does my WCF compute cloud need SSL as well? We do have two domain names with SSLs and so could just map the services to one.
Is there any way I can restrict traffic between the UI layer and the WCF compute cloud - allow only the UI layer to access the services layer?
Would the performance be better if I publish both the WCF services and UI layer on the same instance? It sort of shoots down the nice layered architecture but if it improves performance I could go with it. We don't want to jump through too many hoops to accomodate the app to Azure lest it becomes difficult to migrate out of it.
如果你对这篇内容有疑问，欢迎到本站社区发帖提问 参与讨论，获取更多帮助，或者扫码二维码加入 Web 技术交流群。
绑定邮箱获取回复消息
由于您还没有绑定你的真实邮箱，如果其他用户或者作者回复了您的评论，将不能在第一时间通知您！
发布评论
评论（2）
如果您将服务托管在辅助角色中，则它们只能供您的 Web 角色使用。您还可以将其托管在其他地方并监视代码中的请求。同一部署中的 Azure 角色可以以一种非常特定的方式相互通信，而这种方式在部署外部不可用。
在 Azure 部署中，您需要非常具体地定义公共端点，因为角色托管在负载均衡器后面。如果您在辅助角色中托管 WCF 服务，则该服务将无法公开访问。
希望这有帮助
If you host your services in a Worker Role, then they can be available only to your Web Role. You can also host it elsewhere and monitor requests in code. Azure Roles in the same deployment can communicate with one another in a very specific way that is not available outside of the deployment.
In Azure deployments, you need to very specifically define your public endpoint because the roles are hosted behind a load-balancer. If you host your WCF service from within a worker-role it will not be accessible publicly.
Hope this helped
如果将 WCF 服务和 UI 层配置为仅通过内部终结点进行通信，则通信是私有的。除非公开，否则无需为 WCF 服务购买或配置 SSL 证书。
此外，这些内部端点之间的唯一流量将在您的实例之间 - 因此，您的 UI 层和 WCF 服务之间的流量已受到限制。
Web 角色和辅助角色都是这种情况：您可以将托管 WCF 服务的 Web 角色配置为具有私有内部终结点。
根据系统的体系结构，如果 UI 层和 WCF 层位于同一台计算机上，您可能会看到更好的性能。
如果您的界面“喋喋不休”并且为每个 UI 请求多次调用 WCF 服务，那么您肯定会看到性能改进。如果只有一两个调用，那么与数据库的延迟相比，改进可能很小。
If you configure the WCF service and UI layer to only communicate through internal endpoints then the communication is private. There is no need to purchase or configure an SSL certificate for the WCF service unless it is made public.
Further, the only traffic between these internal endpoints will be between your instances -- so, the traffic is already restricted between your UI layer and the WCF service.
This is the case for both Web roles and worker roles: you can configure a Web role hosting your WCF service to have a private internal endpoint.
Depending on the architecture of your system you may see better performance if you have the UI and WCF layer on the same machine.
If your interface is "chatty" and calls the WCF service several times for each UI request then you'll definitely see a performance improvement. If there's just one or two calls then the improvement is likely to be minimal compared to the latency of your database.