Securing Azure SQL (Part 2): Azure SQL Database Private Endpoint
In the first part of my Securing Azure SQL Database blog series, I discussed using Azure SQL firewall rules to secure your databases. The firewall rules help restrict which addresses can make it into your databases to perform requests, but it still means there is a public endpoint for your data.
There's another option for securing your Azure SQL Database—Azure Private Endpoints, which allow you to remove the public endpoint and instead force all access through Virtual Networks (VNets) you control. Let's take a closer look at what Private Endpoints are, how they work, and what you need to keep in mind when using them.
Azure Private Link is an Azure Networking feature for several Azure services, including Azure SQL Database. (You can also use Private Link with Azure Storage, Azure Synapse Analytics, Azure Key Vault, Azure Event Hubs, Azure Cosmos DB, and more.) Private Link allows you to set up Private Endpoint on your VNet that effectively attach an Azure service directly to your Virtual Network with its own private IP address. The resources within your VNet, such as a website or VM, then access the Azure service through this connection rather than having to go through a public endpoint.
Imagine you're renting multiple rooms at a hotel for a big family gathering. If each room was separate, then everyone, both family and other visitors, would need to go in and out of the same main doors to access the rooms. If you only wanted your family members to visit the rooms, you'd need to have people posted at each door to ensure only family can enter. Although this approach can work, it means there could be a lot of doors to watch and keep track of.
Now, what if the rooms were all interconnected behind a single external door? In this case, you've reduced the number of doors you're covering to one, which would make it much easier to ensure only your family is part of the party.
If you think of each of the rooms you've rented at this imaginary hotel as part of your deployed VNet, then Private Endpoint is a door connecting your family's rooms to another room, which leads to a service the hotel offers. For example, what if there were a private indoor swimming pool your rooms were linked to? Or a private dining room? Only your family would be able to access those services. Similarly, using a Private Endpoint for Azure SQL means only resources on your Virtual Network can access your databases.
To set up a Private Endpoint, you must already have a Virtual Network deployed with a subnet you're attaching the Azure service to. Each Private Endpoint needs three things to work:
- The definition of the endpoint, which includes what type of Azure service you're connecting to and the IP address it will live behind
- A Network Interface Card (NIC), which is connected to the subnet
- A way of mapping the public Fully Qualified Domain Name (FQDN) of your Azure resource to the private IP address
When you create the Public Endpoint via the Azure Portal, all three of these will be deployed for you. By default, the Azure Portal will create a private DNS zone to handle the FQDN mapping. (Note that this is the recommended way of handling the mapping, but there are other options. If you're using ARM, or other automation, everything will have to be defined as separate resources to deploy.)
Clients that live within the VNet, or connected to the VNet, will then still use the FQDN of your Azure resource in their configuration. So, if your Azure SQL Server lives at example.database.windows.net, all your clients would continue to use that FQDN in their connection string. However, the magic of the private DNS zone will cause traffic to that service to route through the private IP address instead. This means you can set up the Private Endpoint and not change your connection strings for any of your existing applications or consumers.
By the nature of being a cloud offering, Azure SQL Database is connected to the internet and by default has a public endpoint to reach your data. Now we know Private Endpoint provides you private access to the service by mapping an internal private IP address on your Virtual Network to an Azure service, which means you can turn off the public endpoint altogether! This is like all those private hotel service rooms no longer having a door to anything but rooms you have rented.
Once you create a Private Endpoint for your Azure SQL Server, there is an option to turn off the public network access on the Firewalls and virtual networks tab in the Azure Portal. If you choose to do so, then the only access to the attached databases would be via the Private Endpoint, meaning the clients would have to be attached to your VNet. This can be done a variety of ways and is really based on how you want to do your networking design. You can also connect clients from other VNets, or even from on-premises networks, using Virtual Network peering, VNet-to-VNet connections, and VPN gateways. This allows you to control access to your data across regions, clouds, and on-premises.
It's important to note that if you're connecting via a Private Endpoint, the Azure SQL Database firewall rules I covered in the previous posts in this series aren't used. They're skipped completely, as that's all part of the public endpoint access pathway. If you leave public access to the Azure SQL Server on, then any connections not going through the Private Endpoint will go through the normal Azure SQL firewall rules workflow.
One of the benefits of Private Endpoint feature is that since all connections are being sent directly to your logical Azure SQL Server via the private IP address, they no longer need to flow through the Azure SQL Database gateways. In the public endpoint flow, connections are first sent to one of the Azure SQL gateways to then get redirected back to the node hosting the database.
By using Private Endpoint, the Azure SQL Database gateways are bypassed completely and always use port 1433. This reduces your security risk footprint by ensuring communication to your database is never going through the Azure SQL gateway and is locked to one address on a single port and from your Virtual Network. If you aren't familiar with the Azure SQL Database connectivity architecture, there's a great Microsoft Docs article on it.
Just like anything, there are benefits, limitations, and trade-offs to every feature. Here are some things to keep in mind when using Private Endpoints with Azure SQL Database:
- Private Link is one way only. This allows clients on your VNet to connect to the Azure SQL resource but doesn't allow Azure services to reach into your Virtual Network. This makes sense when dealing with databases but remember that Private Link is a networking feature for many Azure services, not just Azure SQL Database.
- The Azure Private Endpoint is at the logical SQL Server level. So, you have access to everything on that server via the private IP address, not to only a single database. This could be both good or bad, depending on your needs.
- When removing the public endpoint, make sure to also think about turning off the Allow Azure Services option, so it also blocks anything else running in an Azure data center from getting in.
- If you're turning off the public endpoint, you might think about running a job to routinely check to ensure no Azure SQL Database firewall rules exist and the public endpoint remains off. That way, if someone does turn it on, there aren't firewall rules defined that would instantly become valid.
- Private Link doesn't apply to Azure SQL Database Managed Instance. Managed Instances are deployed into your Virtual Network already.
- The Azure Private Endpoint must be created in the same region as the VNet it's being attached to, but the Azure SQL Server can be in another region. The same Azure SQL Server can also support multiple Private Endpoint connections.
Prior to Private Link, there were also Service Endpoints, which are still available as an option to secure access to your Azure SQL. In the next blog post in this series, I will cover Service Endpoints and how they differ from Private Link.
- Securing Azure SQL (Part 1): Azure SQL Database Firewall
- Securing Azure SQL (Part 1.1): Azure SQL Firewall and Authentication
- Securing Azure SQL (Part 1.2): Check Firewall Rules
- Securing Azure SQL (Part 2): Azure SQL Database Private Endpoint ← [This post]
- Securing Azure SQL (Part 3): Azure SQL Database Service Endpoint