In my opinion, one of the most significant enablers for consumption of Platform as a Service (PaaS) in Azure has been the launch of Azure Private Link capability.
For years, the concept, and successful implementation, of a private network has been a cornerstone of IT security. This is still true, even with an ‘assume breach’ stance and with identity compromise frequently used as the primary attack vector.
With the advent of public cloud PaaS services, this concept was given some seriously grey and blurry edges. This is particularly true for hybrid deployments, where you typically have connections from on-premise applications traversing the public internet, at the mercy of ISP routing, before collecting and returning data from a database query. This is still the case even when your on-premise networking is extended into Azure via a VPN or ExpressRoute.
Of course, there are already many best practises and service features to make connectivity to your PaaS resources increasingly secure. Despite this, many people have remained apprehensive about adopting PaaS services.
For consumers of Microsoft Azure, enter Azure Private Link allowing the creation of Private Endpoints.
“Azure Private Endpoint is a network interface that connects you privately and securely to a service powered by Azure Private Link. Private Endpoint uses a private IP address from your VNet, effectively bringing the service into your VNet.”
Now we have the ability to connect to these PaaS services directly on our secure private network!
The basic implementation of Private Endpoints is extremely simple – just enable it for your compatible PaaS service. You can then connect to the service from all privately connected networks, firewalls allowing, enabling you to completely shut down any publicly exposed surface of the service.
Simple? Yes. But don’t forget DNS; you still need to address your PaaS service using the public DNS record but arrive at the newly assigned private IP within your VNet. For example, to access Azure SQL you still need your connection string to contain:
myazuresqlresource.database.windows.net
But now this name must resolve to your VNet private address IP, for instance 10.0.0.10.
Within Azure, if you are using native DNS functionality, this is taken care of with Private DNS zones. However, if you are accessing PaaS services as part of a hybrid infrastructure, ensure you have a suitable “network wide” DNS solution. The recommendation here is to enable DNS forwarders to the Azure infrastructure.
After deploying your Private Endpoint, don’t forget to review all the security features of the PaaS service, ensuring the service is locked down to only those areas of your private network that require access. Remember that you should always be aiming for micro-segmentation of your network.
As with any Azure deployment, Infrastructure as Code (for example, ARM templates or Terraform) should always be considered. In doing so, you can ensure that your code enforces all of the required lockdowns, offering insurance that this additional consideration is met for services updates and any future deployments.
Beyond allowing for the creation of Private Endpoints in your own tenancy, Azure Private Links can be securely provisioned between Azure tenants. By doing this, services can be securely injected into another Azure tenancy’s VNet. This facilitates the possibility of securely enabling data sharing (or system access) between partners without running the risk of internet exposure, extended attack surface or the need for large-scale network peering via VPN or similar.
Private Link functionality is not free. However, neither is it expensive and I would encourage you to factor in a private endpoint in all PaaS solution designs.
Remember that Jisc’s experienced cloud solution team can support and advise on all aspects of Azure, AWS and Google cloud design and deployment. Please get in touch if you want to know more.
Microsoft provides a full list of compatible PaaS services.