Configure Azure storage accounts for private network connections

Securing access to Storage accounts at network layer

You can limit access to your storage account to requests originating from specified IP addresses, IP ranges, subnets in an Azure Virtual Network (VNet), or resource instances of some Azure services. And thats what is the focus of this article.

Azure offers two similar but distinct services to allow virtual network (VNet) resources to privately connect to other Azure services. Azure VNet Service Endpoints and Azure Private Endpoints (powered by Azure Private Link) both promote network security by allowing VNet traffic to communicate with service resources without going over the internet, but there are some differences.

Point to note is that these two secure ways to connect to Azure services are not limited to Azure Storage accounts. We will focus on how to use these services to secure access to Storage accounts in different scenarios.

Lets begin with brief introduction to each way of securing network access to Storage accounts.

Service Endpoints

A service endpoint allows VNet resources to use private IP addresses to connect to an Azure service’s public endpoint, meaning traffic flows to the service resource over the Azure backbone network — instead of over the internet. In effect, you are extending the identity of the VNet to the service resource. You can then lock down the service resource so it only accepts traffic from the subnet associated with the service endpoint.

Optionally, you can lock down the VNet as well by adding a network security group (NSG) to deny all outbound traffic except to the desired Azure service. With the right configuration, service endpoints enable you to secure service resources to your VNet, providing an extra layer of security.

For example, say you have a virtual machine (VM) in a VNet that needs to communicate with an Azure storage account. You can combine a service endpoint, storage account, and NSG so that traffic from a VM in a private subnet reaches the storage account without hitting the internet, the storage account blocks all traffic unless it’s from that subnet, and the NSG restricts outbound traffic from the subnet to the internet.

Private Endpoints

Azure Private Link is a service that allows virtual network resources to privately connect to other resources as if they were part of the same network, carrying traffic across the Microsoft Azure backbone instead of the internet.

To take advantage of this service, you create a private endpoint. A private endpoint is a network interface that provides a private IP address to a service that would normally only be accessible to a VNet via public IP address.

For instance, every storage account has a public endpoint that by default is open to clients on any network. With a private endpoint, you can assign the storage account a private IP address from a VNet, and a virtual machine (VM) in that VNet can access the storage account without going over the internet. This is powerful because it means you don’t need to use public IP addresses, either at the traffic source or destination. It’s as if you’re bringing the storage account inside the VNet.

Few common use cases

There can be N number of scenarios and we have limited ourselves to discuss few common ones. Here are 4 use cases to see what is the best solution for which scenario.

For restricting Storage account access to Private network, make sure access over internet is turned off . This setting is under “networking” of Storage account. We can switch off the public IP access by selecting “Selected Networks” and saving.

1. Storage account is in Region A and you need to give access to resources in selective subnets.

Assume that you need to enable the network access to Storage account A for Private Subnet (deafult) in virtual Network vnet-spok1 only. In such a case, you can enable service endpoint for this particular subnet (deafult) and that would allow private connections to Storage account from resources in subnet deafult.

If required, we can add subnethub1 of vnet-hub1 to selected networks and private connection from resources in subnethub1 will also be allowed to Storage account A.

The subnets in virtual networks within same region (that of storage account) can be added to “Selected networks” under “Firewall and virtual networks”, so Service endpoints can be used with subnets within same region (with or without vnet peering).

2. Storage account is in Region A and you need to give access to resources in Region B

Assume that Virtual Network (vnet-hub1) in Region A has peering connection with Virtual Network in Region B (vnet-spoke3)

Hmmm…We see that we can add the subnet from Virtual Network in Region B (vnet-spoke3 ) as well in “Selected networks” under “Firewall and virtual networks”, that is because it has a peering connection with Virtual Network in Region A (vnet-hub1).

So that means we can add subnets in virtual networks in region same as that of Storage account to “Select networks” plus we can add subnets in virtual networks which have peering connection to virtual networks (even if this virtual network is not in “selected networks”) in region same as that of Storage account.

3. Storage account is in Region A and you need to give access to users using Point To Site VPN

Assume your users who connect to the azure virtual network need access to Storage account A. Users have privileges to connect using Point to Site VPN.

Since Users` end devices have private IPs which are part of the VPN address space and are not part of any Virtual Network address space, its not possible to avail the service endpoint feature in this case.

Users` P2S VPN connection goes through VPN Gateway subnet, we can create a private endpoint in a subnet (subnethub1) which is part of the virtual network having Gateway subnet. So Storage account will be assigned a Private IP in subnet subnethub1 of Virtual network vnet-hub1. Default routes allow the traffic to flow freely within Azure Virtual network and we can use that in conjunction with private endpoint to provide storage account access to P2S VPN users.

Any subnet in a virtual network peered with the Virtual network having private endpoint, can use that private endpoint to connect to the storage account.

What if the storage account was in Region B as per diagram above (private endpoint diag1)?

• Then we could create a private endpoint of Storage account in subnethub1 of vnet-hub1 and all peered VNets (both spokes) and P2S VPN users would have access to that.
• We could create a private endpoint of Storage account in default subnet of vnet-spoke3 and all peered VNets (vnet-hub1) and P2S VPN users would have access to that (given that there is UDR defined for traffic leaving the gateway subnet with prefix address same as default subnet of vnet-spoke3). Resources in vnet-spoke1 wouldn’t have access to this private endpoint unless there is peering between vnet-spoke1 and vnet-spoke3 or There is a UDR defined for traffic leaving the deafult subnet of vnet-spoke1 with prefix address same as default subnet of vnet-spoke3
• We could create a private endpoint of Storage account in deafult subnet of vnet-spoke1 and all peered vnets (vnet-hub1) and P2S VPN users would have access to that (given that there is UDR defined for traffic leaving the gateway subnet with prefix address same as default subnet of vnet-spoke1). Resources in vnet-spoke2 wouldn’t have access to this private endpoint unless there is peering between vnet-spoke1 and vnet-spoke3 or There is a UDR defined for traffic leaving the default subnet of vnet-spoke3 with prefix address same as default subnet of vnet-spoke1.

4. Storage account is in Region A and you need to give access to resource in on premise network

On premise network and Virtual network vnet-hub1 are connected via site to site VPN, and we need to make sure the resources in virtual network vnet-spoke2 can access Storage account A.

We can leverage the same Private endpoint we created in last example to make this work. Reason being that private endpoint is in vnet-hub1 and VPN traffic, whether that is Point to Site VPN or Site to Site VPN is flowing through Gateway Subnet of Virtual network vnet-hub1 and that allows us to provide access to on-premise resources.

Things to know before you use service endpoints

A few tips to keep in mind about service endpoints:

• There’s no cost for service endpoints. You’re charged for the VNet resources and service resources you use, as always, but you pay nothing extra for service endpoints.
• A service endpoint is implemented for an entire service (and, depending on the service, it doesn’t even need to be the same AD tenant). However, if your service resource is a storage account, you can use a service endpoint policy to narrow the scope to all storage accounts in a subscription or resource group, or to a single storage account.
• When you enable a service endpoint, VMs in the associated subnet switch from public IP addresses to private IP addresses. Keep this in mind, as existing firewall rules set to public IP addresses can fail. Additionally, traffic from the subnet to the service resource might be temporarily interrupted during the switch.
• Service resources can only be secured to virtual networks, so on-premises traffic can’t use service endpoints to connect to an Azure service.

Things to know before you use private endpoints

• Private endpoints cost money. You pay for private endpoint resource hours as well as inbound and outbound data processed. However, if you’re running your own service powered by Private Link, there’s no added charge for the private link service — just the private endpoint.
• It’s critical to correctly configure your DNS settings when using private endpoints, particularly when using the fully qualified domain name (FQDN) to connect to the private endpoint resource, since the FQDN of Azure services resolves to their public IP addresses.
• Private endpoints don’t support network policies such as Network Security Groups (NSGs) or Azure Firewall, so security rules won’t apply to them. But don’t worry — other resources in the subnet are still governed by NSG security rules as usual.

When should you use which?

Whether you use a service endpoint or private endpoint depends largely on the particulars of your use case.

• If you want to be able to block all internet traffic to a target resource, use a private endpoint.
• If you’re dealing with traffic from on-premises, use a private endpoint.
• If you want to secure a specific sub-resource to your VNet resources, use a private endpoint.
• If you want to secure a specific storage account to your VNet resources, you can use a private endpoint, or a service endpoint with a service endpoint policy.
• If you don’t need a private IP address at the destination, service endpoints are considerably easier to create and maintain, and they don’t require special DNS configuration.
• And if cost is a concern, note that service endpoints are free.

Ultimately, as with all things network security, the endpoint type you choose is up to you and your specific use case.