Azure acess models
Azure is primarily aimed at public facing services and web sites. You can see this in the way some Cloud Service features are only available at Azure's public edge. Azure provides the ability to interact machines remotely through the public ports and services. Sometimes you don't want everything exposed to the internet so you can get access to it. A VPN can be used in those cases provide secure no public machine-to-network or network-to-network connectivity
See this posting azure-point-to-site-vpn-private-access about how to set up Azure point-to-site connections.
Standard Access
Applications and services are deployed in the Azure environment as a kind of virtual data center. Individual machines and programs communicate with each other using the internal Azure network. Azure virtual machines can also communicate from Azure to other sites on the internet. Machines external to Azure normally communicate with Azure machines through their publicly defined service interface points.
Most services run on standard ports for Azure-to-Azure communications. They can be made public through the endpoint configuration screen. Notice that there is a public port accessible via the cloudapp.net address and a private port accessible internally to Azure via internal DNS or via direct IP access. I was unable to find a way of turning on private only endpoints through the Azure administrative portal.
Access Control and Security
Public ports, services and applications are reachable from anywhere on the internet. This can be a major security issue since Azure machines are probed almost as soon as they are created.
Azure supports Access control lists on a per endpoint basis. Each endpoint on a server can have its on ACLs. This example shows an endpoint that is visible from a specific external network, from two Azure VLANs internal to this Azure subscription. All other systems are blocked. The most restrictive policy should come last.
Point to Site VPN
A point to site VPN tunnel puts a non-Azure machine on a private network that is essentially inside Azure. You can think of it a as a virtual LAN card in the remote device that is connected to the Azure network. Machines connected via point to site have access to the back site (private) ports. Almost all MS Windows machines come with software to support this type of connectivity. Point to Site VPN connections happen through an Azure Gateway that is created as part of a VLAN. This is done via Powershell or via the Azure Management Portal.
See this posting azure-point-to-site-vpn-private-access about how to set up Azure point-to-site connections.
Site to Site VPN
Office to Data Center and Data Center to Data Center connections are made through site to site connections. This joins the two networks together and set up routes that give back side access to any Azure machine from any machine the remote site. This also removes the need for individual machine VPN configuration. Site to Site connections happen through an Azure side Gateway that is created as part of a VLAN. THis is done via Powershell or via the Azure Management Portal.
See this posting azure-site-to-site-vpn-with-netgear about how to set up an Azure site-to-site connection using a NetGear VPN capable router.
Site to Site Security Implications
The Azure site-to-site bridge adds a second public facing network to your network with a it's set of public ports and services. A corporation's internal network is only as secure as the least secure Azure machines.
The diagram at left shows a potential attack path from the internet through an Azure machine, over the site-to-site tunnel and into the office LAN.
All administrative ports and non-public services must be protected through Azure ACLs
Wrap Up
This discussion applies to both IaaS virtual machines and PaaS services.
grt
ReplyDelete