Azure Storage Network Security

Network security settings in Azure Storage is an often misunderstood concept, so the goal of this post is to discuss it in a bit in detail. Lets start with the most basic of diagrams:

In this case, we have a client in some type of network boundary trying to reach out to Azure Storage, which is effectively a Platform-as-a-Service component. From the client perspective, for this scenario, we care mostly about outbound connections. In the ideal case, we limit outbound communication from our VM to only the required (uniquely identifiable) Azure storage account as opposed to the entire service, or worse, all of the internet. From a storage perspective, we ideally want to allow only authorized connections. This consists of properly authenticated connections originating from only allowed locations as opposed to only authorized connections “from the internet”.

Azure Storage Firewall

The basic component that supports network restrictions is the Azure Storage Firewall. This service, when enabled, governs all data connections to the storage account. The scenario that works out of the box is configuring the firewall to only allow specific IP addresses. From the storage perspective, this is the storage service protecting itself from traffic originating outside of it’s service.

At this point, we haven’t started talking about the client at all. It is assumed that the client has a direct route out to the internet, and can successfully make calls to the storage account. The storage account treats this as “internet traffic” and is expecting a static IP address to be added to it’s allow list.

Azure Service Endpoints

In the documentation for Azure storage firewalls, you’ll notice that it talks about creating rules for virtual networks. This is a special case that can only be used when the client is an Azure service deployed in a virtual network. It makes use of a service called Virtual Network Service Endpoints.

In this mode, traffic from an Azure virtual network is routed via the service endpoint directly to the Azure storage service, rather than via the internet. In addition to the special routing, the service endpoint attaches information about the source virtual network and subnet to the request. This way, the Azure storage firewall can inspect the traffic, not for originating IP address, but for these special tags. It can then make allow/deny decisions given the rules provided. Here is a visual.

So, from the Azure storage viewpoint, not much has changed. Traffic still arrives at the service, and is inspected by the firewall. The rules by which the inspection is done have changed, however. From the client viewpoint, internet traffic is no longer required for this particular communication flow. In fact, service endpoints typically takes control of the routing of this traffic away from the client and places it fully in the hands of Azure. So you can’t route this traffic to network virtual appliances for scanning, for example. The fun part of service endpoints is that there are no changes to the client application, it still addresses storage using the storage account name as normal.

Azure Private Endpoint

From the last section, you likely gleaned that Azure Service Endpoints is effectively just some routing trickery done by the virtual networking service. From the viewpoint of storage, traffic arrives at the public endpoint much the same way internet traffic would. Rules are consulted, and allowed traffic is approved.

Private Endpoints, as the name suggests, aims to improve on this by creating private endpoints for your Azure storage account. Here is a diagram to help explain.

Basically, one trades off the traditional approach of a firewall for a private endpoint that is controlled by the Azure fabric. The “firewall” in this case is the authorization flow that is followed when linking a network interface card (NIC) in a vnet/subnet to your private endpoint.

From the storage service viewpoint, a new private endpoint is created where it will listen to and accept traffic. From a client viewpoint, a NIC is created in the vnet/subnet that is tied specifically to that one private endpoint for your storage account. Applications must change their behaviour to address the private NIC, instead of the public endpoint as used in the previous two methods. The client also need not have access to all of the internet, or even all of Azure storage.

Conclusion

The purpose of this post was to go over the often misunderstood network security aspects of Azure storage. Network security is a dance between client and server, and different approaches offer different benefits based on your viewpoint. From a security perspective, I’d say that the ideal scenario would be to enable a storage account with only private endpoints to govern your traffic. This would allow you to deny all traffic via the storage firewall and only allow approved connections/flows from your controlled vnets.

 

About Shamir Charania

Share This Article

Comments