What’s new?
For the security-minded among us, data exfiltration is a constant concern. From external threats to misconfigured workflows to bad actors, the need to minimize the risk of customer data leaving the safety of Azure and customer’s own premises is as big as the need to process that data.
Azure SQL Managed Instance meshes the latest security features of SQL Server with Azure’s multi-level cloud security controls. A broad range of features – private connectivity, row-level security, encryption in transit and at rest, threat protection, vulnerability assessment, and more – provide Azure SQL Managed Instance with a layered, defense-in-depth security for our applications.
In this article we will focus on a new capability within this security framework: the preview of Azure SQL’s Managed Instance’s support for Azure virtual network service endpoint policies.
Introduction
There are times when we may want to use an Azure Storage account to orchestrate a specific workflow. For example, we may want to set up Data Migration Service or Log Replay Service to mirror an on-premises database to Azure SQL Managed Instance. To do that, we need to set up an Azure Storage account in which to store logs. This storage account now figures as a part in the data flow. Each new part means broader attack surface and more chances for a misclick or a rogue automation to expose data. This is the classical “a chain is as strong as its weakest link” metaphor, or as I to call it, the Toddler Stack Model:
So, how do we reduce the chance of a bad configuration or an “inside job” tipping the tower over and exposing our data? Well, for one thing, we can configure our Azure Storage accounts for private or limited public connectivity. However, we can also set things up the other way round and prohibit services inside our Azure SQL Managed Instance subnet from connecting to dubious accounts in Azure Storage. Ideally, we will double our security by doing both, which also makes it harder for a bad actor to disable our security controls or go around them.
How service endpoint policies help prevent data exfiltration
Azure provides us with multiple mechanisms to secure traffic to and from virtual networks. One way we can up the security is by attaching service endpoints to our subnet. Service endpoints do several useful things: they route our traffic through fast and secure Azure backbone; apply filtering rules before traffic leaves our subnet; and allow the Azure service being contacted to recognize where the traffic is coming from. More than a dozen Azure services support service endpoints. Importantly, Azure Storage is one of those.
In other words, with an Azure Storage service endpoint in place on our Azure SQL Managed Instance subnet, we can establish three security mechanisms:
- Traffic between our databases and Azure Storage is now guaranteed to traverse Azure’s backbone, regardless of routes set in the route rable.
- Our storage accounts can reject connections that don’t originate from our subnets.
- Our Azure SQL Managed Instance subnet can stop services from reaching out to unsafe storage accounts.
Mechanism 1 becomes automatically active once a service endpoint is in place. Mechanism 2 takes effect when we configure our storage account for limited public connectivity. For the third mechanism, we need service endpoint policies.
Service endpoint policies
Service endpoint policies tell service endpoints what traffic is allowed to leave our subnet and reach out to other services in Azure. We configure policies to allow specific storage accounts and deny all others. Doing so will prevent resources in that subnet – that is, Azure SQL Managed Instance – from accessing any Azure Storage accounts other than the ones we’ve explicitly allowed! This helps guard against misconfigured logging, auditing, migration, and replication workflows, as well as hinder malicious actors determined to exfiltrate data on a large scale.
Service endpoints default to denying connections to Azure Storage
We need to be careful when configuring service endpoint policies because they introduce a major change in how a subnet behaves. When you associate your first service endpoint policy with a subnet, all outbound connections to storage accounts will be rejected by default unless the policies allow them. We recommend that you take a cautious approach by first allowing your subnet to access all storage accounts in your subscriptions. Then, narrow that down to resource groups where your storage accounts are. Finally, update your policies one last time to only allow the individual storage accounts. Keep verifying that your workflows work as intended as you go.
If you’ve been following Azure SQL Managed Instance, you may ask: well, what about the remote storage that it uses for regular operation and backups? Should I worry about cutting them off with my own policies? The answer is, thankfully, no. Managed Instance will take care to automatically allow all built-in storage accounts with a set of special exceptions that cannot be disabled. This way, you can be confident that your databases remain operational and backed up regardless of policies on the Managed Instance’s subnet.
When to use service endpoint policies in Azure SQL Managed Instance?
Obviously as often as possible, especially because there are no extra costs associated with them. Still, there are a couple of common scenarios that involve data flows between Azure SQL Managed Instance and Azure Storage accounts:
- We mentioned Azure DMS offline migration and Log Replay Service migration earlier.
- When you import data with BULK INSERT or OPENROWSET(BULK ...), do a copy-only backup with TO URL=, or restore a database from Azure Storage.
- If you log extended events to an Event File target, or have your database fire off auditing events to a storage account.
- When you synchronize tables using transactional replication, which requires a storage account share.
If you use, or plan to use, such and other workflows where Azure Storage is contacted from inside the Azure SQL Managed Instance subnet, consider adding service endpoints to your subnets and securing both ends.
Next steps
Try it out on your own Azure SQL Managed Instance and storage account. You can find a step-by-step guide here: Configure service endpoint policies for Azure SQL Managed Instance.
Note that this feature is not available in all regions while in review. It will be made available Azure-wide once it enters general availability. The regions in which is not available during preview are listed in the limitations section of the documentation page. If you are in a supported region but still unable to associate a service endpoint policy with your subnet, you may have resource locks or Azure policies blocking this feature. Please refer to Azure SQL Managed Instance's network requirements for more information on how to unblock it.
Make sure to check out the latest updates to Azure SQL Managed Instance which expand its ability to drive the modernization of mission-critical applications through improvements in security, flexibility, performance, and scale.
We hope that you find service endpoint policies for Azure SQL Managed Instance easy to manage and helpful in securing your workflows. Now, try them out and share your thoughts in the comments!