Storage Firewall
π― Lab Objective
In this hands-on lab, you will learn how to:
- Understand Azure Storage Account network security and firewall capabilities
- Configure storage account firewall rules to restrict network access
- Implement virtual network service endpoints for secure storage access
- Test connectivity scenarios from different network locations
- Troubleshoot storage access issues caused by network restrictions
- Implement defense-in-depth security for Azure Storage accounts
Scenario: Your organization requires that the companyβs sensitive data stored in Azure Storage accounts should only be accessible from specific networks and IP ranges. You need to configure storage firewall rules and test various access scenarios to ensure proper security controls.
π Please sign in to launch lab.
ποΈ Pre-Provisioned Environment
The following Azure resources have been pre-deployed in your environment:
Resource Overview
Resource Type | Resource Name | Configuration | Purpose |
---|---|---|---|
Resource Group | StorageFirewall-Lab-RG | Contains all lab resources | Logical container |
Virtual Network | Corp-VNet | Address space: 10.0.0.0/16 | Corporate network |
Trusted Subnet | TrustedSubnet | Range: 10.0.1.0/24 | Approved network segment |
Untrusted Subnet | UntrustedSubnet | Range: 10.0.2.0/24 | Restricted network segment |
Trusted VM | TrustedVM | Windows Server 2019 | Authorized client |
Untrusted VM | UntrustedVM | Ubuntu 20.04 LTS | Unauthorized client |
Storage Account | labstorage[unique] | General Purpose v2 | Target storage resource |
Blob Container | testdata | Private access level | Test data container |
Network Architecture
Corp-VNet (10.0.0.0/16)βββ TrustedSubnet (10.0.1.0/24)β βββ TrustedVM (Windows Server)β βββ Should have storage accessβββ UntrustedSubnet (10.0.2.0/24) βββ UntrustedVM (Ubuntu Linux) βββ Should be blocked from storage
Internetβββ Storage Account (labstorage[unique]) βββ Firewall Rules (to be configured) βββ Blob Container: testdata
VM Details
VM | Private IP | Operating System | Purpose |
---|---|---|---|
TrustedVM | 10.0.1.4 | Windows Server 2019 | Test authorized access |
UntrustedVM | 10.0.2.4 | Ubuntu 20.04 LTS | Test blocked access |
π Lab Exercises
Part 1: Verify Current Storage Access
Step 1: Get Storage Account Details
- Navigate to StorageFirewall-Lab-RG resource group
- Click on the Storage Account (labstorage[unique])
- In the left menu, click Access keys
- Copy the following information:
- Storage account name:
labstorage[unique]
- Key1: Copy the entire key value
- Blob service endpoint:
https://labstorage[unique].blob.core.windows.net/
- Storage account name:
Step 2: Test Access from Trusted VM
- Navigate to TrustedVM
- Click Connect β RDP
- Use credentials:
- Username:
azureuser
- Password:
LabPassword123!
- Username:
Step 3: Test Storage Connectivity from Trusted VM
From TrustedVM, open PowerShell and run:
# Test basic connectivity to storage endpoint$storageEndpoint = "https://labstorage[unique].blob.core.windows.net/"try { Invoke-WebRequest -Uri $storageEndpoint -Method HEAD -TimeoutSec 10 Write-Host "β
Storage endpoint accessible"} catch { Write-Host "β Storage endpoint blocked: $($_.Exception.Message)"}
# Test blob listing (should work initially)$storageAccount = "labstorage[unique]"$storageKey = "[your-storage-key]"$ctx = New-AzStorageContext -StorageAccountName $storageAccount -StorageAccountKey $storageKeyGet-AzStorageContainer -Context $ctx
Step 4: Test Access from Untrusted VM
- Navigate to UntrustedVM
- Click Connect β SSH
- Use Azure Cloud Shell or SSH client:
ssh azureuser@[UntrustedVM-Public-IP]# Password: LabPassword123!
Step 5: Test Storage Connectivity from Untrusted VM
From UntrustedVM, run:
# Test storage endpoint connectivitycurl -I --connect-timeout 10 https://labstorage[unique].blob.core.windows.net/
# Install Azure CLI for storage testingcurl -sL https://aka.ms/InstallAzureCLIDeb | sudo bash
# Test storage accessaz storage container list --account-name labstorage[unique] --account-key "[your-storage-key]"
Initial Expected Results:
- β Both VMs should have unrestricted access to the storage account
- β Storage endpoints should be reachable from both locations
Part 2: Configure Storage Account Firewall
Step 1: Navigate to Storage Networking Settings
- Go to your Storage Account in the portal
- In the left menu, click Networking
- You should see βFirewalls and virtual networksβ tab selected
Step 2: Enable Network Restrictions
- Current setting: Should show βAllow access from all networksβ
- Change to: Select βEnabled from selected virtual networks and IP addressesβ
- This will block all access by default
Step 3: Add Virtual Network Exception
- Under Virtual networks, click + Add existing virtual network
- Configure the network rule:
Setting | Value | Purpose |
---|---|---|
Subscription | Your subscription | Target subscription |
Virtual networks | Corp-VNet | Corporate network |
Subnets | TrustedSubnet | Only trusted subnet |
- Click Add
Step 4: Add Your Public IP (Optional)
- Under Firewall, click + Add your client IP address
- This adds your current public IP to the allowed list
- Purpose: Allows you to manage the storage account from Azure Portal
Step 5: Configure Additional Settings
Setting | Value | Purpose |
---|---|---|
Allow trusted Microsoft services | Checked | Azure services access |
Resource instances | Leave empty | No specific resource rules |
- Save the configuration
β±οΈ Propagation Time: Firewall changes can take 2-5 minutes to take effect.
Part 3: Test Firewall Effectiveness
Step 1: Test from Trusted VM (Should Work)
Return to TrustedVM PowerShell session:
# Wait for firewall rules to propagateStart-Sleep -Seconds 120
# Test storage endpoint access$storageEndpoint = "https://labstorage[unique].blob.core.windows.net/"try { $response = Invoke-WebRequest -Uri $storageEndpoint -Method HEAD -TimeoutSec 15 Write-Host "β
TrustedVM: Storage accessible - Status: $($response.StatusCode)"} catch { Write-Host "β TrustedVM: Storage blocked - Error: $($_.Exception.Message)"}
# Test blob operations$storageAccount = "labstorage[unique]"$storageKey = "[your-storage-key]"$ctx = New-AzStorageContext -StorageAccountName $storageAccount -StorageAccountKey $storageKey
try { $containers = Get-AzStorageContainer -Context $ctx Write-Host "β
TrustedVM: Can list containers ($($containers.Count) found)"} catch { Write-Host "β TrustedVM: Cannot access storage: $($_.Exception.Message)"}
Expected Result: β Access should succeed from TrustedVM
Step 2: Test from Untrusted VM (Should Fail)
From UntrustedVM SSH session:
# Test storage endpoint accessecho "Testing from UntrustedVM..."curl -I --connect-timeout 15 https://labstorage[unique].blob.core.windows.net/
# Test with Azure CLIaz storage container list --account-name labstorage[unique] --account-key "[your-storage-key]" --timeout 15
Expected Result: β Access should fail from UntrustedVM
Step 3: Test from Your Local Machine
From your local machine (if outside Azure):
# This should fail unless your IP is in the firewall rulescurl -I https://labstorage[unique].blob.core.windows.net/
Expected Result: Depends on whether your public IP was added to firewall rules
Part 4: Advanced Firewall Configuration
Step 1: Add Specific IP Address Rules
- In Storage Account Networking settings
- Under Firewall, click + Add IP range
- Add a specific IP range:
Setting | Value | Purpose |
---|---|---|
Address range | 203.0.113.0/24 | Example external network |
Name | External-Office | Descriptive label |
- Click Save
Step 2: Test Exception Rules
Create a more complex scenario by adding the UntrustedVMβs public IP:
-
Get UntrustedVMβs public IP:
- Go to UntrustedVM β Networking
- Copy the Public IP address
-
Add this IP to firewall rules:
- Go to Storage Account β Networking
- Click + Add IP range
- Enter the UntrustedVMβs public IP
- Click Save
-
Test again from UntrustedVM (should now work via public IP)
Step 3: Configure Resource-Specific Access
- Under Resource instances, click + Add
- Configure access for specific Azure resources:
Setting | Value | Purpose |
---|---|---|
Resource type | Microsoft.Compute/virtualMachines | VM access |
Resource instance | TrustedVM | Specific VM |
Tenant ID | Your tenant ID | Security boundary |
Part 5: Service Endpoint Integration
Step 1: Enable Service Endpoint on Trusted Subnet
- Navigate to Corp-VNet β Subnets
- Click on TrustedSubnet
- Under Service endpoints, click + Add
- Select service:
Microsoft.Storage
- Click Save
β±οΈ Configuration Time: Service endpoint enablement takes 1-2 minutes.
Step 2: Update Storage Firewall for Service Endpoint
- Go to Storage Account β Networking
- Verify that
TrustedSubnet
appears in the virtual networks list - Confirm service endpoint is being used (should show endpoint status)
Step 3: Test Service Endpoint Performance
From TrustedVM, test routing:
# Check route to storage account$storageIP = (Resolve-DnsName labstorage[unique].blob.core.windows.net).IPAddressWrite-Host "Storage resolves to: $storageIP"
# Test traceroute to storagetracert $storageIP
# Performance testMeasure-Command { Invoke-WebRequest -Uri "https://labstorage[unique].blob.core.windows.net/" -Method HEAD}
π§ Troubleshooting Guide
Common Storage Firewall Issues
Issue | Symptoms | Possible Cause | Solution |
---|---|---|---|
All access blocked | 403 Forbidden errors | No firewall exceptions | Add VNet or IP exceptions |
Partial access only | Some operations fail | Insufficient permissions | Check storage account permissions |
Slow propagation | Rules not taking effect | Network changes propagating | Wait 2-5 minutes, retry |
Portal access blocked | Canβt manage storage account | Client IP not allowed | Add your public IP to firewall |
Service endpoint not working | Still using public routing | Service endpoint not enabled | Enable on subnet and verify |
Firewall Rule Validation
Access Type | Expected Behavior | Verification Method |
---|---|---|
Allowed VNet | Full access from subnet | Test from VM in subnet |
Blocked VNet | 403 Forbidden errors | Test from blocked subnet |
Allowed IP | Access from specific IP | Test from that IP address |
Public Access | Blocked by default | Test from random internet IP |
Part 6: Monitoring and Logging
Step 1: Enable Storage Analytics
- In Storage Account, go to Monitoring β Diagnostic settings
- Click + Add diagnostic setting
- Configure logging:
Setting | Value | Purpose |
---|---|---|
Name | StorageFirewallLogs | Log configuration name |
Blob | Checked | Enable blob logging |
StorageRead | Checked | Log read operations |
StorageWrite | Checked | Log write operations |
StorageDelete | Checked | Log delete operations |
- Destination: Choose Log Analytics workspace or Storage account
Step 2: Monitor Failed Access Attempts
- Go to Monitoring β Logs
- Run this query to see blocked requests:
StorageBlobLogs| where StatusCode == 403| where TimeGenerated > ago(1h)| project TimeGenerated, CallerIpAddress, Uri, StatusText| order by TimeGenerated desc
π§ͺ Additional Experiments
Try these optional exercises to deepen your understanding:
- Private Endpoints: Compare storage firewall with private endpoints
- Cross-Region Access: Test firewall rules across different Azure regions
- Application Integration: Test how applications handle storage firewall blocks
- Backup and Recovery: Understand how firewall affects backup services
- CDN Integration: Test how Azure CDN works with storage firewalls
π Key Takeaways
After completing this lab, you should understand:
- Storage account firewalls provide network-level access control
- Virtual network integration enables secure subnet-based access
- Service endpoints improve performance and security for VNet access
- IP-based rules complement network-based restrictions
- Firewall changes require time to propagate across Azureβs network
- Monitoring and logging are essential for troubleshooting access issues
- Defense-in-depth combines multiple security layers
π Storage Security Best Practices
Firewall Configuration
- Principle of Least Privilege: Only allow necessary networks and IPs
- Regular Review: Audit firewall rules periodically
- Monitor Access: Enable logging for security monitoring
- Test Changes: Validate firewall rules in non-production first
Access Patterns
- Service Endpoints: Use for Azure VNet access
- Private Endpoints: Use for highest security requirements
- Public Access: Avoid when possible, restrict with firewalls
- Shared Access Signatures: Combine with network restrictions