The Underground Tunnel: How I Locked Down Enterprise Storage Without Breaking the App

Many people think securing data in the cloud just means setting a strong password. But in enterprise cloud security, leaving a storage account accessible via the public internet—even with a strong password—is like putting a heavy steel bank vault right on a busy public street. Anyone walking by can try to pick the lock or scan it.

To solve this, I completely smashed that front public door shut and dug a private underground tunnel—known as an Azure Private Endpoint—connecting my application server directly to the vault.

🏰 The Analogy: Public Street Vault vs. Underground Tunnel

• The Public Endpoint (Vulnerable): Your bank vault sits on a busy highway. Even though it is locked, hackers worldwide can knock on the door, scan your firewall mechanisms, and bombard it with traffic.
• The Private Endpoint (Secured): You disable the public street door completely. Then, you dig a private access tunnel from the basement of your internal app building straight into the vault. No one on the public street can even see that the door exists.

[ Internet / Hackers ] ───► ❌ (Public Access Blocked at Edge)

[ App Subnet: 10.0.1.0/24 ] ──(Private IP: 10.0.1.4)──► [ Blob Storage Vault ]
                                      ▲
                                      │ (Resolved via Private DNS Zone)

🛠️ Step-by-Step Implementation

1. Locking the Vault (Disabling Public Access)

First, I created the storage account and explicitly revoked public network access from the outside world using the Azure CLI:

# Create the Storage Account
az storage account create -g Marathahalli_Lab_RG -n storevaultsea20949 -l southeastasia --sku Standard_LRS

# Block all public network access at the front gate
az storage account update -g Marathahalli_Lab_RG -n storevaultsea20949 --public-network-access Disabled

📸 Proof Point 1: Smashed Front Gate

This verification step in the Azure Portal shows that public network entry points are 100% disabled:

2. Digging the Underground Tunnel (Private Endpoint)

Next, I carved out a dedicated, internal private IP address on my virtual network subnet and wired it directly to the Blob storage service:

az network private-endpoint create \
  -g Marathahalli_Lab_RG \
  -n Storage_Private_Endpoint \
  --vnet-name Sec_Hub_SEA_VNet \
  --subnet Management_SEA_Subnet \
  --private-connection-resource-id $(az storage account show -g Marathahalli_Lab_RG -n storevaultsea20949 --query id -o tsv) \
  --group-id blob \
  --connection-name Blob_Private_Conn

📸 Proof Point 2: The Private Interface Allocation

By inspecting the network interface generated by the private link endpoint, we can see that it grabbed the internal IP 10.0.1.4 straight out of our virtual network subnet:

3. Overriding the Map (Private DNS Zone Integration)

Normally, when a computer looks up a storage URL, the internet returns a public IP address. To force traffic through our underground tunnel, I built an internal Private DNS zone to override that lookup map locally:

# Create the Private DNS Zone mandated for Azure Blobs
az network private-dns zone create -g Marathahalli_Lab_RG -n privatelink.blob.core.windows.net

# Link the Private DNS Zone to our Virtual Network
az network private-dns link vnet create \
  -g Marathahalli_Lab_RG \
  -z privatelink.blob.core.windows.net \
  -n Link_Hub_VNet \
  -v Sec_Hub_SEA_VNet \
  --registration-enabled false

# Bind the Private Endpoint configuration to register the internal A-record automatically
az network private-endpoint dns-zone-group create \
  -g Marathahalli_Lab_RG \
  --endpoint-name Storage_Private_Endpoint \
  --name Storage_DNS_Group \
  --private-dns-zone privatelink.blob.core.windows.net \
  --zone-name blob

📸 Proof Point 3: The Private Route Record Mapping

This is the ultimate verification. In the Private DNS Recordsets grid, our unique cloud storage endpoint URL maps perfectly onto our internal private IP address:

🛑 The Real-World Blocker: The 403 Forbidden Shock

During initial testing from inside an application server, trying to fetch a file threw a glaring error: AuthorizationFailure: This request is not authorized to perform this operation.

• The Root Cause: The server was still asking public internet DNS servers for the location, resolving the blocked public interface instead of using the private endpoint.
• The Fix: I properly linked the Private DNS zone configuration to the Private Endpoint. Azure automatically created an internal A Record pointing the storage link straight to our internal IP address (10.0.1.4). The request instantly traversed the private network backbone safely.

💡 Core AZ-104 Exam Takeaways

• Public Network Access Drop: Setting this to Disabled tells Azure's edge routing layer to drop incoming public packets immediately before they reach your data.
• Private Endpoints: This injects a Virtual Network Interface Card (vNIC) into a subnet, giving a multi-tenant platform service a dedicated private entry point.
• Conditional Forwarding Override: Azure uses the specific privatelink.blob.core.windows.net namespace internally to override standard internet routing routes cleanly.

⏱️ Sandbox Cleanup

To ensure compliance with strict cloud sandboxing constraints and avoid lingering costs on the tier, the resources were immediately deleted using:

az group delete --name Marathahalli_Lab_RG --yes --no-wait