Securing and Optimizing Access to Azure Storage Accounts with Azure Endpoints
Securing and optimizing flows with Service and Private Endpoints
- Intro
- Service Endpoints and Firewalling the Azure Storage Account
- Service Endpoint Policies
- Private Endpoints
- Summary
Intro
When working with Azure files, it is important to ensure that traffic destined for your files shares is both secured and routed in an optimal fashion. There are several options for securing and changing network flows for services in Azure, with a focus on Azure files, below is a breakdown of the options and some considerations.
Service Endpoints and Firewalling the Azure Storage Account
By default, an Azure storage account is configured with a “public endpoint” and is open to traffic sourced from anywhere. The storage account is available and accessible over the public internet (this changes slightly within the Azure fabric, but for the purposes of this article, assume it’s the same).
A public endpoint is not necessarily a bad thing depending on your requirements, however, it is important to be aware that unless you lock the account down, it is open by default.
Storage accounts provide an inbuilt firewall, allowing you to restrict access to specific source IP addresses, and/or Azure virtual networks and subnets.
When securing a storage account and restricting to an Azure Virtual network, you will need to be leveraging Service Endpoints on virtual networks (VNets). VNet service endpoints provide secure and direct connectivity to Azure services via the Azure backbone network. Endpoints lockdown critical Azure service resources to only specific virtual networks.
When enabling Service Endpoints and accessing a Storage Account, traffic to the storage account is switched to use IPv4 rather than public addresses (NAT) as per the below image
This is typically perfect for say, FSLogix Containers that are accessed from Azure VM’s only. You can lock down the storage account to allow traffic only from specific subnets on your VNET whilst leveraging an optimal path to the Storage Account over the Azure fabric.
Be aware that when you lock down the storage accounts, you will lose access to view data on the shares from either the Azure Portal, or Azure Storage Explorer unless you allow the public IP you are coming from. Luckily, the Storage Account firewall detects what this is, and offers a nice easy “apply” option. If you have a dynamic IP address, don’t forget to remove your exemption once you have finished your tasks.
Service Endpoint Policies
Virtual Network (VNet) service endpoint policies effectively allow you to control specifically which Storage Accounts are accessed over the service endpoint, and which are not. This gives much more granular security control for protecting data exfiltration from your virtual network.
Private Endpoints
You may not want any form of public endpoint connection to Azure Storage accounts, this may be a security mandate, and can be addressed specifically with the use of Azure Private Endpoints.
Azure Private Endpoint is a network interface that connects privately (as in IPv4) to a service backed by Azure Private Link. Private Endpoint uses a private IPv4 address from an existing VNet, effectively bringing the service (in this context, storage account) into the VNet itself. If you have an ExpressRoute or IPSec VPN connection into Azure, you can also leverage the private endpoint, however DNS is king, and can be a little tricky to get working.
The image below is taken straight from the Microsoft documentation and outlines nicely how the Azure Private Link solution fits together.
In my demo account below, I have blocked any form of public endpoint connections to my storage account via the use of the Firewall (note that there is no need for firewall configurations when using private endpoints)
I have also configured and connected a private endpoint to my storage account:
This endpoint is configured with an IPv4 address in one of my existing subnets, which is also routable over my IPSec VPN tunnel:
The Private Link Center shows the connections are active:
When connecting to a private link resource using a fully qualified domain name (FQDN) it is critical to correctly configure DNS settings to resolve to the allocated private IP address. It is well worth reading through the detail from Microsoft.
An Azure Private link DNS zone has been configured to handle Azure DNS (this helps Azure switch the DNS response from the default public IP, back to a private IP owned by the endpoint, based on the source of the request – a private endpoint doesn’t mean you can’t use a public at the same time), to note, my VM’s in Azure leverage my existing Active Directory based DNS servers, so there were a few additional steps to achieve correct DNS lookups. Azure wants you to use a forwarder from a VM in Azure to it’s hosted DNS servers, however this didn’t suit me, so DNS being DNS, I manipulated it accordingly. Not posting the steps here as I don’t want to push potentially bad practices, but can share on request (and you can probably track through in the screenshots anyway).
The network interface associated with the private endpoint contains the information required to configure DNS, including FQDN and private IP addresses allocated for a given private link resource.
When using private endpoints for Azure services, traffic is secured to a specific private link resource. The platform performs an access control to validate network connections reaching only the specified private link resource.
Below shows my on-premises server, its name resolution when accessing the storage account, and the associated SMB connection to prove the point – all private.
Private endpoints aren’t always the best solution and need to be thought through. Potentially think about a use case where an isolated DR environment is brought online (via ASR), and accesses in read only mode, existing FSLogix Containers stored in an Azure Storage account. Given that the DR environment is 100% isolated, private endpoints are not suitable, however with Service Endpoints, we can securely provide access across the Azure fabric.
There is a cost associated with each private endpoint, so you will need to factor this into your decision making process.
Summary
Endpoints are a key component to securing and optimising traffic flow when dealing with Azure Storage Accounts. With the recent GA announcements associated with Azure Files and Active Directory Domain Join capability, Azure Files will become more and more prevalent for EUC based workloads such as FSLogix Containers, Citrix Profile Management and alternate file services, it will be important to ensure that this data is both secure, and accessible in an optimal fashion.
