Network Security: Firewalls, VNets, and Private Endpoints

Securing the front door

Marcus’s security requirements

⚙️ Marcus at FinSecure must meet SOC 2 security controls:

• Production databases accessible only from the application VNet (no public internet)
• Development databases accessible from the office IP range
• Azure portal access for emergency troubleshooting
• No direct browser access to production data

IP firewall rules

The simplest network restriction — allow specific IP addresses or ranges:

# Allow office IP range and Azure portal
az cosmosdb update --name finsecure-dev \
  --resource-group rg-finsecure \
  --ip-range-filter "203.0.113.0/24,104.42.195.92"

Setting	Description
Empty IP filter	All public IPs allowed (default)
Specific IPs/ranges	Only listed IPs can connect
104.42.195.92	Legacy Azure portal IP (use “Add Azure Portal Middleware IPs” instead)
0.0.0.0	Accept connections from within Azure datacentres

💡 Exam tip: Azure portal access exception

When you enable IP firewall rules, you may lose Azure portal access to your Cosmos DB account’s Data Explorer. To keep portal access, either:

1. Use the “Add Azure Portal Middleware IPs” option in the portal (recommended — adds the current required IPs automatically), or
2. Check the “Allow access from Azure portal” checkbox in the portal UI

Note: The old portal IP 104.42.195.92 is now legacy. The portal has transitioned to new Middleware IP addresses. The exam tests the concept — “after enabling IP firewall, the developer can no longer browse data in the portal” → add the portal exception.

VNet service endpoints

Restrict access to specific Azure Virtual Networks — traffic stays on Microsoft’s backbone:

# Enable service endpoint on the subnet
az network vnet subnet update \
  --resource-group rg-finsecure \
  --vnet-name vnet-production \
  --name subnet-apps \
  --service-endpoints "Microsoft.AzureCosmosDB"

# Configure Cosmos DB to accept from this subnet
az cosmosdb network-rule add \
  --name finsecure-cosmos \
  --resource-group rg-finsecure \
  --vnet-name vnet-production \
  --subnet subnet-apps

Key characteristics:

• Traffic stays on Microsoft’s backbone network (not the public internet)
• The Cosmos DB public endpoint is still used, but only from allowed subnets
• Quick to set up — no DNS changes needed
• Cannot extend to on-premises networks

Private endpoints (Private Link)

The most secure option — Cosmos DB gets a private IP address inside your VNet:

# Create a private endpoint
az network private-endpoint create \
  --name pe-cosmos-prod \
  --resource-group rg-finsecure \
  --vnet-name vnet-production \
  --subnet subnet-data \
  --private-connection-resource-id "/subscriptions/.../databaseAccounts/finsecure-cosmos" \
  --group-ids "Sql" \
  --connection-name "cosmos-connection"

Key characteristics:

• Cosmos DB accessible via a private IP (e.g., 10.0.1.5) inside your VNet
• Public endpoint can be disabled entirely
• Works with on-premises via VPN/ExpressRoute
• Requires DNS configuration (private DNS zone or custom DNS)

Network isolation comparison

Feature	IP Firewall	VNet Service Endpoints	Private Endpoints
Traffic path	Public internet (filtered)	Microsoft backbone	Private network only
Public endpoint	Used (filtered by IP)	Used (filtered by subnet)	Can be disabled entirely
On-premises access	✅ Via public IP	❌ Azure VNets only	✅ Via VPN/ExpressRoute
DNS changes	None	None	Required (private DNS zone)
Setup complexity	Low	Medium	High
Security level	Basic	Medium	Highest
Cost	Free	Free	Per-hour + data processing

CORS (Cross-Origin Resource Sharing)

CORS controls which web domains can make direct browser-to-Cosmos-DB API calls:

# Allow a specific web app to call Cosmos DB from the browser
az cosmosdb update --name finsecure-cosmos \
  --resource-group rg-finsecure \
  --cors "https://app.finsecure.com"

When CORS matters: Only for browser-based applications that call the Cosmos DB REST API directly. Server-side applications (APIs, Functions) don’t need CORS.

💡 Exam tip: combine multiple layers

In production, you typically combine multiple layers:

• Private endpoints for application access (highest security)
• IP firewall with portal exception for emergency admin access
• Disable public endpoint when private endpoints are the only access method

The exam may present a scenario requiring both private endpoint access for apps AND portal access for admins — the answer is private endpoints + IP firewall exception for the portal.

🎬 Video walkthrough

🎬 Video coming soon

Network Security — DP-420 Module 24

Network Security — DP-420 Module 24

~14 min

Flashcards

Question

What is the difference between VNet service endpoints and private endpoints?

Click or press Enter to reveal answer

Answer

Service endpoints: traffic stays on Microsoft backbone but uses the public endpoint (filtered by subnet). Private endpoints: Cosmos DB gets a private IP inside your VNet, public endpoint can be disabled entirely. Private endpoints are more secure and work with on-premises via VPN/ExpressRoute.

Click to flip back

💡 Show hint

Question

What happens to Azure portal Data Explorer access when you enable IP firewall?

Click or press Enter to reveal answer

Answer

Portal access may be blocked unless you add the portal Middleware IPs (use the 'Add Azure Portal Middleware IPs' button) or enable 'Allow access from Azure portal'. The legacy IP 104.42.195.92 has been replaced by new Middleware addresses.

Click to flip back

💡 Show hint

Question

Can private endpoints work with on-premises networks?

Click or press Enter to reveal answer

Answer

Yes — private endpoints assign a private IP inside your VNet. On-premises networks can reach this IP via VPN or ExpressRoute. VNet service endpoints cannot reach on-premises — they only work within Azure VNets.

Click to flip back

💡 Show hint

Knowledge Check

Knowledge Check

Marcus needs to ensure FinSecure's production Cosmos DB is only accessible from the application VNet with no public internet exposure. Which approach should he use?

AIP firewall rules allowing the application's public IPBVNet service endpoints on the application subnetCPrivate endpoints with the public endpoint disabledDCORS configuration allowing the application domain

Check Answer

Knowledge Check

After enabling IP firewall on the dev Cosmos DB account, a developer can no longer access Data Explorer in the Azure portal. What's the fix?

ADisable the IP firewall entirelyBAdd the Azure portal Middleware IPs to the allowed IP list (or use the 'Add Azure Portal Middleware IPs' button)CSwitch to a private endpointDEnable CORS for the Azure portal domain

Check Answer

---

Next up: Data Security — encryption at rest, customer-managed keys, RBAC, resource tokens, and Always Encrypted for protecting your data.