{"id":1868,"date":"2020-09-11T01:00:00","date_gmt":"2020-09-11T01:00:00","guid":{"rendered":"http:\/\/inswwdev.azurewebsites.net\/au\/insights\/uncategorized\/securing-and-optimising-access-to-azure-storage-accounts-with-azure-endpoints\/"},"modified":"2024-10-10T08:25:55","modified_gmt":"2024-10-10T08:25:55","slug":"securing-and-optimising-access-to-azure-storage-accounts-with-azure-endpoints","status":"publish","type":"post","link":"https:\/\/www.insentragroup.com\/gb\/insights\/geek-speak\/cloud-and-modern-data-center\/securing-and-optimising-access-to-azure-storage-accounts-with-azure-endpoints\/","title":{"rendered":"Securing and Optimising Access to Azure Storage Accounts with Azure Endpoints"},"content":{"rendered":"

\"\"<\/p>\n

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.<\/p>\n

SERVICE ENDPOINTS AND FIREWALLING THE AZURE STORAGE ACCOUNT<\/h3>\n

By default, an Azure storage account is configured with a \u201cpublic endpoint\u201d 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\u2019s the same).<\/p>\n

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.<\/p>\n

\"\"<\/p>\n

Storage Account Firewall<\/p>\n

Storage accounts provide an inbuilt firewall, allowing you to restrict access to specific source IP addresses, and\/or Azure virtual networks and subnets.<\/p>\n

\"\"<\/p>\n

Allowed Subnets via Firewall<\/p>\n

When securing a storage account and restricting to an Azure Virtual network, you will need to be leveraging\u00a0Service Endpoints<\/a>\u00a0on 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.<\/p>\n

\"\"<\/p>\n

Service Endpoints on the VNET<\/p>\n

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.<\/p>\n

\"\"<\/p>\n

Microsoft Image on Service endpoint IP changes<\/p>\n

This is typically perfect for say, FSLogix Containers that are accessed from Azure VM\u2019s 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.<\/p>\n

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 \u201capply\u201d option. If you have a dynamic IP address, don\u2019t forget to remove your exemption once you have finished your tasks.<\/p>\n

\"\"<\/p>\n

Locked out of Azure file shares in the portal<\/p>\n

SERVICE ENDPOINT POLICIES<\/h3>\n

Virtual Network (VNet) service endpoint policies<\/a>\u00a0effectively 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.<\/p>\n

\"\"<\/p>\n

Service Endpoint Policy<\/p>\n

PRIVATE ENDPOINTS<\/h3>\n

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.<\/p>\n

Azure Private Endpoint is a network interface that connects privately (as in IPv4) to a service backed by\u00a0Azure Private Link.<\/a>\u00a0Private 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.<\/p>\n

The image below is taken straight from the\u00a0Microsoft documentation<\/a>\u00a0and outlines nicely how the Azure Private Link solution fits together.<\/p>\n

\"\"<\/p>\n

Microsoft Image on Private Link<\/p>\n

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).<\/p>\n

\"\"<\/p>\n

Azure Storage Account Firewall<\/p>\n

I have also configured and connected a private endpoint to my storage account:<\/p>\n

\"\"<\/p>\n

Private Endpoint on the Storage Account<\/p>\n

This endpoint is configured with an IPv4 address in one of my existing subnets, which is also routable over my IPSec VPN tunnel:<\/p>\n

\"\"<\/p>\n

Endpoint IPv4 detail<\/p>\n

The Private Link Center shows the connections are active:<\/p>\n

\"\"<\/p>\n

Azure Private Link Center<\/p>\n

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\u00a0detail from Microsoft<\/a>.<\/p>\n

An\u00a0Azure Private link DNS zone<\/a>\u00a0has 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 \u2013 a private endpoint doesn\u2019t mean you can\u2019t use a public at the same time), to note, my VM\u2019s in Azure leverage my existing Active Directory based DNS servers, so there were a few additional steps to achieve correct DNS lookups.\u00a0Azure wants you to use a forwarder from a VM in Azure to its hosted DNS servers<\/a>, however this didn\u2019t suit me, so DNS being DNS, I manipulated it accordingly. Not posting the steps here as I don\u2019t want to push potentially bad practices but can share on request (and you can probably track through in the screenshots anyway).<\/p>\n

\"\"<\/p>\n

Azure Private Link Center<\/p>\n

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\u00a0detail from Microsoft<\/a>.<\/p>\n

An\u00a0Azure Private link DNS zone<\/a>\u00a0has 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 \u2013 a private endpoint doesn\u2019t mean you can\u2019t use a public at the same time), to note, my VM\u2019s in Azure leverage my existing Active Directory based DNS servers, so there were a few additional steps to achieve correct DNS lookups.\u00a0Azure wants you to use a forwarder from a VM in Azure to its hosted DNS servers<\/a>, however this didn\u2019t suit me, so DNS being DNS, I manipulated it accordingly. Not posting the steps here as I don\u2019t want to push potentially bad practices but can share on request (and you can probably track through in the screenshots anyway).<\/p>\n

\"\"<\/p>\n

DNS Details for the endpoint<\/p>\n

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.<\/p>\n

Below shows my on-premises server, its name resolution when accessing the storage account, and the associated SMB connection to prove the point \u2013 all private.<\/p>\n

\"\"<\/p>\n

Private endpoints aren\u2019t 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.<\/p>\n

There is a cost associated with each private endpoint, so you will need to factor this into your decision-making process.<\/p>\n

SUMMARY<\/h3>\n

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.<\/p>\n

This blog was originally published on jkindon.com<\/a> on 16\/06\/20 and reproduced with permission.<\/p>\n","protected":false},"excerpt":{"rendered":"

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… Continue reading Securing and Optimising Access to Azure Storage Accounts with Azure Endpoints<\/span><\/a><\/p>\n","protected":false},"author":86,"featured_media":1869,"comment_status":"open","ping_status":"open","sticky":false,"template":"","format":"standard","meta":{"content-type":"","footnotes":""},"categories":[21],"tags":[],"class_list":["post-1868","post","type-post","status-publish","format-standard","has-post-thumbnail","hentry","category-cloud-and-modern-data-center","entry"],"_links":{"self":[{"href":"https:\/\/www.insentragroup.com\/gb\/wp-json\/wp\/v2\/posts\/1868","targetHints":{"allow":["GET"]}}],"collection":[{"href":"https:\/\/www.insentragroup.com\/gb\/wp-json\/wp\/v2\/posts"}],"about":[{"href":"https:\/\/www.insentragroup.com\/gb\/wp-json\/wp\/v2\/types\/post"}],"author":[{"embeddable":true,"href":"https:\/\/www.insentragroup.com\/gb\/wp-json\/wp\/v2\/users\/86"}],"replies":[{"embeddable":true,"href":"https:\/\/www.insentragroup.com\/gb\/wp-json\/wp\/v2\/comments?post=1868"}],"version-history":[{"count":1,"href":"https:\/\/www.insentragroup.com\/gb\/wp-json\/wp\/v2\/posts\/1868\/revisions"}],"predecessor-version":[{"id":22210,"href":"https:\/\/www.insentragroup.com\/gb\/wp-json\/wp\/v2\/posts\/1868\/revisions\/22210"}],"wp:featuredmedia":[{"embeddable":true,"href":"https:\/\/www.insentragroup.com\/gb\/wp-json\/wp\/v2\/media\/1869"}],"wp:attachment":[{"href":"https:\/\/www.insentragroup.com\/gb\/wp-json\/wp\/v2\/media?parent=1868"}],"wp:term":[{"taxonomy":"category","embeddable":true,"href":"https:\/\/www.insentragroup.com\/gb\/wp-json\/wp\/v2\/categories?post=1868"},{"taxonomy":"post_tag","embeddable":true,"href":"https:\/\/www.insentragroup.com\/gb\/wp-json\/wp\/v2\/tags?post=1868"}],"curies":[{"name":"wp","href":"https:\/\/api.w.org\/{rel}","templated":true}]}}