Azure SQL Network Security (Vnets, Service Endpoints & Private Link)
| Post applies to: | ||||
|---|---|---|---|---|
| SQL DB Singleton | SQL DB Managed Instance |
Having been a database engineer/DBA/architect for many years one of the biggest learning curves moving to Azure was that to do with securing Azure SQL databases. Sure SQL Server logins, database users, roles and permissions behave in the same way but I suddenly found myself in the alien world of network design meetings talking to infrastructure engineers about how to physically isolate and secure PaaS database services like Azure SQL.
The first thing that needs to happen – and this is very much an infrastructure/network team task – is to set-up secure connectivity between your network and Azure. There are 2 basic options to do this:
- VPN connection – Point-to-Site or Site-to-Site VPN
- ExpressRoute – dedicated private connection
Once secure connectivity is in place we can think about securing the SQL database services. How we secure them depends upon the flavour of Azure SQL you’re deploying.
Azure SQL Managed Instance
Let’s talk about Azure SQL Managed Instance first as it’s more aligned to the traditional world we’re used to. Managed Instance has to be inside a Vnet in Azure which is a private network just like your corporate network therefore the only way to access the SQL MI is by being allowed inside the Vnet. Often this means “peering” (as far as I can tell that’s network jargon for connecting) your corporate net with the private Vnet so they trust each other. Network access to the Azure Vnet is then controlled by a Gateway just as access to your private corporate net is. Once inside the Vnet usual SQL security applies with Logins, DB Users and permissions – just like you’re used to
So the SQL Managed Instance network security model is the same as what you’re used to but in-order for it to work there obviously needs to be some network plumbing in place first.
Azure SQL Database
Azure SQL Database is a little different. It sits outside your private Vnet with a Public Endpoint meaning traffic doesn’t need access to a private network in order to connect to the SQL Database service.
For SQL DB then the security parameter is not a network parameter but rather SQL Server/Database level firewalls and strong User Authentication (using techniques such as Multi Factor Authentication and Role Based Access Controls) all of which are employed to prevent unauthorised access. So all’s we’ve really done is move the firewall back from the network edge to inside the service (in this case a SQL Server/database).
NOTE – IT’S SECURE BY DEFAULT: Although the Public Endpoint allows access to the database service from anywhere it relies on SQL Server/DB firewall rules to allow connections through to the SQL server/database. By default no firewalls rules exist so no access is allowed.
The problem is though that for many years people like me had it drummed into us that network security for something as important as a critical database server is based on the “layers of an onion” approach where even exposing to the internet that a database server exists – even if it’s can’t be accessed – is a very significant risk except in specific well-planned circumstances. So this new-fangled concept of there not being a defined, hard network parameter encompassing and shielding critical services is too alien a concept for many traditional IT teams.
So Azure SQL Database supports 2 network endpoint security services:
Service Endpoint
- Defined in a subnet inside our Vnet, once created the Service Endpoint is added to the SQL Database server firewall
- The result is that only traffic from the Vnet where the Service Endpoint exists, can connect directly to the SQL Database (if no other SQL server/database firewalls have been created allowing access from other sources)
- This means traffic logically bypasses the Public Endpoint effectively disabling it although not removing it
- Traffic from the specified Vnet is allowed to connect to the SQL Database as if the SQL database was inside the same Vnet
- And because this is trusted traffic from a trusted source, the usual SQL Server security measures then ensure only authorised users can login and access databases – just like tour traditional on-prem set-up
Private Link & Private Endpoints
Just one problem remains: even though the Public Endpoint is effectively switched off it still exists with a public endpoint/IP address even though the SQL Server firewall blocks traffic from everything but the Service Endpoint. The risk here is that someone could add a new rule to the SQL server/database firewall that allows access from the public network and this is potentially beyond the control of the network security team.
The lingering public endpoint is therefore still unacceptable for some security teams so in this scenario a private endpoint can be implemented using the Private Link service.
- Private Link is used to define a private endpoint (that is a private IP address) inside the VNet which maps to a specific Service – in this case the logical SQL Server hosting our Azure SQL Database
- Traffic from inside the Vnet can connect to the database via the Private Link endpoint effectively bypassing the Public Endpoint
- So far this doesn’t seem that different from a Service Endpoint but the Private Link goes one step further – it effectively removes the target SQL server/database from the Azure SQL service Public Endpoint thereby removing the Public Endpoint altogether for that logical SQL server and the databases it hosts
And hey presto! There it is! A public cloud PaaS database service sitting outside your private network but only accessible from within a trusted Vnet and no public endpoint being exposed to potentially compromise security!
After 20 years in data... 