Limiting Public Access and Protecting Sensitive Data in Azure Storage

#azure #azurefunctions #security

Challenge

An internal application in the US using Azure Storage had overly permissive default configurations, creating a risk of accidental data exposure through public access and long-lived SAS tokens.

Solution

Implemented a minimal yet robust security configuration with disabled public access, private endpoints, Azure AD authentication with RBAC, centralized secrets management via Key Vault, and comprehensive monitoring.

What I Built

I implemented a minimal yet robust security configuration that reduces the attack surface and prevents unauthorized access to sensitive data.

Implementation Details

1. Disabled Public Access

One of the most common cloud security mistakes is leaving blob storage publicly accessible. I disabled this at the storage account level by setting Allow Blob Public Access = Disabled.

2. Enabled Private Communication Only

Instead of allowing traffic from the public internet, I configured a Private Endpoint on a dedicated subnet within the Virtual Network. This ensures all storage traffic stays within Azure’s internal network.

3. Implemented Azure AD Authentication

SAS tokens are difficult to manage and rotate securely. I switched to Azure AD authentication with RBAC at the container level, using Storage Blob Data Contributor for the application service principal. This provides centralized identity management with granular control.

4. Enforced Least Privilege

To minimize the blast radius of any potential compromise, I applied strict permission boundaries:

Application service: Write permissions only
End users: Read-only access
No account-level keys distributed anywhere

5. Centralized Secrets Management

I eliminated hardcoded credentials by storing connection strings in Azure Key Vault and using Managed Identity for App Service authentication. Zero secrets live in the application code or repository.

6. Enabled Monitoring & Alerting

To detect suspicious activity in real-time, I configured Diagnostic Settings to send logs to a Log Analytics Workspace and created alert rules for:

Anonymous access attempts
Unusual data egress patterns
Failed authentication attempts

Complete Security Implementation Diagram

Step-by-Step Flow

User Request: End user initiates a request through the application interface
Authentication: App Service uses its Managed Identity to authenticate
Credential Retrieval: Managed Identity retrieves connection strings from Azure Key Vault (no hardcoded secrets)
Identity Verification: Azure AD verifies the identity of the requesting service
Permission Check: RBAC policies determine what actions are allowed (read/write)
Network Routing: Request is routed through the Virtual Network (no internet exposure)
Subnet Traversal: Traffic passes through the dedicated Private Endpoint subnet
Private Connection: Private Endpoint establishes secure connection to Storage Account
Storage Access: Storage Account receives the authenticated request
Write Operation: Application writes data to designated container (if authorized)
Read Operation: Users read data from container (read-only RBAC)
Logging: All access attempts are logged via Diagnostic Settings
Log Storage: Logs are sent to Log Analytics Workspace for analysis
Monitoring: Azure Monitor continuously analyzes access patterns
Alerting: Security alerts are triggered for suspicious activity (anonymous access, failed auth, unusual egress)