Azure Best Practice - Securing Your File Shares

Hello team. I've got some quick best practices to share for using and securing an Azure File Share. By now, you should hopefully know about one of my favorite Azure Platform-as-a-Service options, using the Azure Files service inside of your Azure Storage account.

Azure Files

Azure Files is a fully-managed file share service that you can use in the cloud and connect to from anywhere. Using the SMB protocol, you can mount a file share you create in your Azure Storage account to Azure Virtual Machines, a server on your network, or any Windows, Linux, or macOS client. Azure Files can completely replace a traditional, on-premises Windows file server or NAS device, and completely removes your need to manage RAID sets, disk replication, and server patching. It's an awesome tool, but there are some features you should be aware of.

Securing Network Access

Being able to mount an SMB share from anywhere in the world is convenient, but most organizations won't want to make corporate data available on the web, even if the data is encrypted and secured with access keys that you rotate. For security purposes, you'll want to use a feature Azure released last year - Service Endpoints.

Azure Service Endpoints are like little portals from Azure platform services, like Azure Storage, Azure SQL Database, and Azure Service Bus, into your private Azure Virtual Network (VNet). Azure platform services need to be managed by Azure, which means they normally exist outside your VNet, and resources on your VNet normally need to communicate over public IP addresses to reach these services. By attaching a Service Endpoint to a subnet in your VNet, you can present these platform services as local resources on your network, giving you:

• Improved security for your Azure resources
• Optimal routing for service traffic
• Less management overhead (no reserved public IP addresses in your VNet)

By attaching a Service Endpoint for Azure Storage on your subnet, you can restrict traffic to your Azure Storage account to only addresses on your Azure VNet or IP addresses you specifically whitelist. However, this has a few drawbacks of its own.

Azure Snapshots

Last year, Microsoft announced the integration of Azure Snapshots to Azure Files within Azure Backup. Share Snapshots take incremental backups of your file shares in Azure, and can give you convenient, point-in-time recovery for lost or corrupted files. The catch? Once you turn on a Service Endpoint for your Azure Storage account, other Azure managed services, like Azure Backup, can't access your storage account. It would appear that customers would have to choose between the security of restricting access to the storage account or the convenience of having scheduled, managed snapshots taken to protect their data.

A Secure Solution

I recently ran into this exact issue for a client of ours. We had hoped that using Azure Backup on a virtual machine that the Azure Files file share was mounted to would protect our data in the file share, but Azure Backup will not back up a volume that has been mounted as a network drive. We can initiate a manual snapshot of the file share from the Azure Portal, but this is far from ideal.

We also tried using Azure Automation (which is a fantastic service for automating tasks like server patching and configuration management) to schedule a snapshot. Unfortunately, this is another service that exists outside the range of whitelisted IP addresses for the Azure Storage Account, so it looked like we were stuck.

What to do?

In this situation, we found the best way to manage repeating snapshots for an Azure Files file share was to schedule the process from within PowerShell on a virtual machine running in the customer's VNet. We knew this would work, since the virtual machine was automatically whitelisted for access by virtue of being on VNet, but we still needed to figure out how to script this. Here's what we did.

First, I wrote a small PowerShell script that would initiate the snapshot:

$context = New-AzureStorageContext -StorageAccountName [storageaccountname] -StorageAccountKey [storageaccountkey]

$share = Get-AzureStorageShare -Context $context -Name [fileshare]

$snapshot = $share.Snapshot()

I saved this locally to the virtual machine as C:\PS\filesharesnapshot.ps1

Then, I used a feature in Windows PowerShell called Task Scheduler to write a script that would execute daily at 1:00 AM:

$Trigger= New-ScheduledTaskTrigger -At 1:00am –Daily

$User= "NT AUTHORITY\SYSTEM"

$Action= New-ScheduledTaskAction -Execute "PowerShell.exe" -Argument "C:\PS\filesharesnapshot.ps1"

Register-ScheduledTask -TaskName "filesharesnap" -Trigger $Trigger -User $User -Action $Action -RunLevel Highest –Force

Summary

Voila! Now we don't have to choose between having secure access to our Azure Storage account and scheduled snapshots to protect our data. If we ever need to restore a specific version of a file, or if our files get corrupted via ransomware or something less nefarious, we can instantly revert back to previous versions of the entire file share, a folder, or a specific file.

If you have questions about how we put this solution together, or would like to see some more tips and tricks for managing a public or hybrid cloud deployment, please let me know in the comments. If you are interested to know how iT1 can help you secure your and manage your Azure environment, please reach out to us at [email protected].