Domain 2 β€” Module 4 of 6 67%
9 of 28 overall
Domain 2: Implement a Secure Environment Free ⏱ ~12 min read

Network Security: Firewalls, Private Links, and Endpoints

Configure server and database-level firewall rules, private endpoints, and service endpoints to control network access to Azure SQL resources.

Network security for Azure SQL

Simple explanation

Think of network security like layers of fences around a building.

Firewall rules are the outer fence β€” they check your IP address at the gate. Only IPs on the approved list get through.

Service endpoints are like a private underground tunnel from your office (VNet) to the building β€” traffic stays on Microsoft’s network, never touching the public internet.

Private endpoints go further β€” they put a private door to the building inside your office. The database gets a private IP address in your VNet. No public access at all.

Firewall rules

Azure SQL Database uses a two-level firewall:

Server-level firewall rules

  • Apply to ALL databases on the logical server
  • Configured via Azure Portal, PowerShell, CLI, or T-SQL
  • Allow specific IP addresses or ranges
-- Create a server-level firewall rule (T-SQL)
EXECUTE sp_set_firewall_rule
  @name = 'AllowOfficeIP',
  @start_ip_address = '203.0.113.10',
  @end_ip_address = '203.0.113.10';

Database-level firewall rules

  • Apply to a SPECIFIC database only
  • Configured via T-SQL only (not Azure Portal)
  • More granular β€” different databases can have different access
-- Create a database-level firewall rule
EXECUTE sp_set_database_firewall_rule
  @name = 'AllowAppServer',
  @start_ip_address = '10.0.1.50',
  @end_ip_address = '10.0.1.50';

The β€œAllow Azure services” setting

  • When enabled, any Azure service (from any subscription, any tenant) can reach your SQL server
  • Security risk β€” this is very broad. Priya disables this at ScaleWave and uses private endpoints instead.
Server-level vs Database-level Firewall Rules
AspectServer-levelDatabase-level
ScopeAll databases on the serverSingle database only
ConfigurationPortal, PowerShell, CLI, T-SQLT-SQL only
Stored inmaster databaseIndividual database
PortableNo (tied to server)Yes (travels with database)
Best forGeneral access controlPer-database isolation

Managed Instance firewall

MI lives inside a VNet, so it doesn’t use the same IP-based firewall model:

  • Access is controlled by Network Security Groups (NSGs) on the MI subnet
  • Public endpoint can be enabled (disabled by default) with NSG rules
  • Private endpoint is the recommended access method

Virtual network service endpoints

Service endpoints extend your VNet identity to Azure SQL:

  1. Enable the Microsoft.Sql service endpoint on a VNet subnet
  2. Create a VNet rule on the SQL server allowing that subnet
  3. Traffic from the subnet to Azure SQL stays on the Azure backbone β€” no public internet
-- Allow a VNet subnet (T-SQL)
EXECUTE sp_set_vnet_firewall_rule
  @name = 'AllowAppSubnet',
  @virtual_network_subnet_id = '/subscriptions/.../subnets/app-subnet';

Limitations:

  • Traffic source IP is still a public IP (the VNet IP, not a private IP)
  • Only works with Azure resources in the same region
  • The SQL server’s public endpoint is still active

Private Link is the gold standard for Azure SQL network security:

  1. Create a private endpoint in your VNet
  2. The SQL resource gets a private IP address from your VNet subnet
  3. Disable public access β€” only connections through the private endpoint are allowed
  4. All traffic stays entirely within your VNet β€” never touches the public internet
BenefitDetails
No public exposureThe SQL server’s public endpoint can be completely disabled
Private IPClients connect using a private IP (e.g., 10.0.2.5)
Cross-regionWorks across regions and even across tenants
DNS integrationPrivate DNS zone maps the server FQDN to the private IP

Amara’s setup at Harbour Health:

  1. Create private endpoint for the SQL server in the hospital VNet
  2. Create a private DNS zone (privatelink.database.windows.net)
  3. Link DNS zone to the VNet
  4. Disable public network access on the SQL server
  5. Applications connect using the same FQDN β€” DNS resolves to the private IP
Private Link DNS resolution

When you create a private endpoint, the FQDN resolution changes:

Before private endpoint: harbourhealth.database.windows.net β†’ public IP (e.g., 40.78.225.32)

After private endpoint + private DNS: harbourhealth.database.windows.net β†’ harbourhealth.privatelink.database.windows.net β†’ private IP (e.g., 10.0.2.5)

Applications don’t need to change connection strings β€” DNS handles the routing transparently.

Comparison: service endpoints vs private endpoints

Service Endpoints vs Private Endpoints
FeatureService EndpointsPrivate Endpoints
IP address typePublic IP (Azure backbone routing)Private IP in your VNet
Public endpointStill activeCan be disabled
Cross-regionSame region onlyAny region
Cross-tenantNoYes
DNS changesNone neededPrivate DNS zone required
CostFreePer-hour + data processing charges
Setup complexitySimple (enable + rule)Moderate (endpoint + DNS + disable public)
Security levelGoodBest
Exam tip: private endpoint is the recommended answer

When the exam asks about the most secure network configuration for Azure SQL:

  • Private endpoint + disable public access = most secure
  • Service endpoint = good but public endpoint stays active
  • Firewall rules only = least secure (relies on IP addresses)

If cost or simplicity isn’t mentioned in the scenario, choose private endpoint.

Question

What is the difference between server-level and database-level firewall rules?

Click or press Enter to reveal answer

Answer

Server-level rules apply to ALL databases on the logical server (configurable via Portal, CLI, T-SQL). Database-level rules apply to a single database only (T-SQL only) and travel with the database.

Click to flip back

Question

What does a private endpoint give you that a service endpoint doesn't?

Click or press Enter to reveal answer

Answer

A private IP address from your VNet. With private endpoints, you can disable the public endpoint entirely. Service endpoints still use public IPs and keep the public endpoint active.

Click to flip back

Question

Why is 'Allow Azure services' a security risk?

Click or press Enter to reveal answer

Answer

It allows any Azure service from any subscription and any tenant to access your SQL server. This is far too broad β€” use private endpoints or VNet rules for specific, controlled access.

Click to flip back

Knowledge Check

Amara needs to ensure Harbour Health's Azure SQL Database is accessible only from the hospital's Azure VNet. No traffic should traverse the public internet. What should she configure?

Knowledge Check

Priya needs to allow a specific application server (IP: 10.0.1.50) to access only the 'CustomerDB' database but not other databases on the same logical server. What should she configure?

Next up: Data Classification and Auditing β€” classify sensitive data, configure audits, and implement change data tracking.