Few days ago there have been some announcements for ignite 2017 (https://azure.microsoft.com/it-it/blog/azure-networking-announcements-for-ignite-2017/).
It’s exciting opportunity for Microsoft continue to grow in the cloud and it’s a fantastic momentum for consultants and architects to try new features that can simplify our life.
One specific announcement, took my attention. Azure Virtual Network Service Endpoints (Preview), then I decided to try it and report here some experience.
First of all, this is a feature preview on Azure Storage (the one I tried) and Azure SQL Database. It’s a way to protect Service Endpoint to allow private virtual network traffic and to deny Internet Facing IP traffic.
For many of our customers, data breaches remain a top concern. It’s very hard to convince some customers to move their business-critical data to the cloud. Storage Account (it values for other Azure Services too) have Internet-reachable IP addresses and potential can suffer of threats like leaked credentials. Most customers want limit access to this kind of resources to only their Azure Virtual Networks or on-premises.
Have you ever used Service Map solution in Log Analitycs to monitor VMs with public IP? You can see how many foreign public IP try to connect to SSH or to RDP port by Internet.
Azure Virtual Network Service Endpoints (Preview) feature, right now, it’s available only in these regions:
- Azure Storage: WestCentralUS, WestUS2, EastUS, WestUS, AustraliaEast, and AustraliaSouthEast
- Azure SQL Database: WestCentralUS, WestUS2, and EastUS.
VNET e Azure Service can be in different subscription but must be in the same AD tenant (it’s not clear yet if this limitation is only in preview)
Be carefull, If you still use VM with unmanaged disk, Backup of unamanged disk is not supported during the preview.
Good news, this feature is free, infact there is no additional charge for using service endpoints. The current pricing model for Azure services (Azure Storage, Azure SQL Database) applies as-is today.
There is no limit on the total number of service endpoints in a virtual network, but Azure Storage account services may enforce limits on the number of subnets used for securing the resource. Refer to the documentation for various services in Next steps for details.
I had pleasure to try it and I can tell it’s extremally simple.
I create an Azure Storage Account in WestUS2 region and configures Virtual Network during Storage Account creation.
This is an example.
After Storage Account creation, I could access to the settings by the tab Firewalls and virtual network of Storage Account blade.
After have clicked on this tab, I could find the Service Endpoint settings and I created more Service Endpoints.
In this case I enabled 2 VNETs and in the first VNET I enabled 3 subnets.
Remember, by enabling a Service Endpoint for Azure Storage within the Virtual Network, traffic is ensured an optimal route to the Azure Storage service. The identities of the virtual network and the subnet are also transmitted with each request. Administrators can subsequently configure network rules for the Storage account that allow requests to be received from specific subnets in the Virtual Network.
I tried a very interesting scenario.
Map network share from VM connected on VNET and denying access to share from internet.
The steps to follow for the lab are:
- Configure the Storage Account allowing access to only VNET and Subnet where VM is attested
- Connect the VM to the share with the NET USE command, as shown in the following figure.
- Verify with the NETSTAT Command that the connection is actually established and note that the storage account endpoint is always a public IP, but traffic runs only through the Microsoft backbone and not through the Internet.
- To verify that access to the share is blocked via the Internet, just try to connect the same share from a different VM that does not belong to the VNET with Service Endpoint enabled, in this case the test was done from my on-premises workstation. As shown in the picture, you get access denied.
Network rules are enforced on all network protocols to Azure storage, including REST and SMB. Access to your data from tools like the Azure portal, Storage Explorer, and AZCopy require explicit network rules granting access when network rules are in force.
Infact after disabled Internet Access to the Storage Account, I tryed to browse Blob Service or File Service and I got an unbelieveble Access Denied in the portal.
Don't worry, it's easy to get rid of this problem. You need to add your client IP address (the browser accesses to the storage account) in the Firewall and virtual networks.
Stay tuned for new announcements.