Azure Storage Account Networking and Network Security Features

all azure azure security azure storage Dec 07, 2024

Introduction

Azure Storage Accounts offer robust networking and network security features designed to help us connect to and access our data securely. By adopting a layered security approach, we can configure rules for virtual networks, IP addresses, and trusted Azure resources to protect our storage account. This guide explores the essential networking and network security features available in Azure Storage Accounts and provides practical insights on how to leverage them effectively. These features are accessible from the Security + Networking section in the storage account's left-hand menu.

Primary Networking and Network Security Features

Firewalls and virtual networks

Under the Firewalls and virtual networks tab, we can configure the following:

Allow public access from:
- All networks
- Specific virtual networks and subnets.
- Specific IP addresses or ranges.
Allow access to specific Azure resource instances based on their system-assigned managed identities to securely restrict storage account access to only our application's Azure resources. For example, we can grant access to one or more Logic App (Resource Type: Microsoft.Logic/workflows) instances.
Configure exceptions to:
- Allow Azure services on the trusted services list to access this storage account: Enable access for trusted Azure-managed services to bypass firewall rules securely.
- Allow read access to storage logging from any network: Permit retrieval of logging data from the storage account from any network.
- Allow read access to storage metrics from any network: Allow access to storage account metrics from any network for monitoring purposes.
Routing Preference: Choose how traffic is routed to your storage account, with Microsoft network routing for optimal performance and security or Internet routing for cost-effective solutions with potentially lower performance.

Private endpoint connections

Under the Private endpoint connections tab, we can create private endpoints to establish a secure, private connection to a service or resource. A private endpoint is a network interface within our virtual network (VNet) that connects privately to a service, ensuring all traffic remains on the Azure backbone network and is not exposed to the public internet.

The private endpoint must reside in the same Azure region as the virtual network where it is created. However, it can connect to a Private Link resource, such as a storage account or SQL database, located in a different Azure region. Private Link enables Azure services to be accessed privately over the Azure backbone network instead of the public internet.

This setup ensures that while the private endpoint aligns regionally with the VNet, it provides the flexibility to securely connect to resources in other regions. All traffic remains private and secure within the Azure backbone network, eliminating exposure to the public internet.

Custom domain

Under the Custom Domain tab, we can configure a custom domain like www.cloudericks.com to access blob data in our Azure storage account in one of the following ways:

Direct CNAME Validation: Point our domain (e.g., www.cloudericks.com) to cocan.blob.core.windows.net or cocan.z20.web.core.windows.net. This method is simple but causes brief downtime during verification.
Indirect CNAME Validation: Point a subdomain "asverify" (e.g., asverify.www.cloudericks.com) to asverify.cocan.blob.core.windows.net or asverify.cocan.z20.web.core.windows.net. Then, enter our domain without 'asverify.' This method avoids downtime and requires selecting the 'Use indirect CNAME validation' checkbox.

Azure Front Door and Azure CDN

Azure Front Door and Azure CDN are Content Delivery Network (CDN) services designed to accelerate the delivery of content stored in Azure Storage Accounts. For instance, if your application serves large files, such as videos or static assets, to a global audience, these services can significantly enhance load times and reliability by caching and routing traffic efficiently.

Azure recommends Azure Front Door over Azure CDN, particularly for scenarios requiring advanced traffic management and dynamic content delivery. Front Door offers intelligent traffic routing based on factors like latency, geography, and backend health, ensuring users are directed to the optimal backend. It supports both dynamic and static content delivery and includes application-layer features like URL-based routing, header rewrites, and caching. Additionally, Front Door integrates advanced security features, such as a Web Application Firewall (WAF), centralized SSL termination, and enhanced DDoS protection, making it the ideal solution for modern, secure web applications.

In contrast, Azure CDN is specifically optimized for delivering static content, such as images and videos, by caching data at edge locations to reduce latency. It provides basic HTTPS support and is a cost-effective solution for static content delivery. While Azure CDN excels at simple, static asset delivery, Azure Front Door is the preferred choice for complex, dynamic applications that require sophisticated routing, real-time performance optimization, and robust security features.

Access keys

The Access Keys tab in an Azure Storage Account provides access to the primary and secondary keys, along with their associated connection strings. These keys allow full access to the storage account, enabling operations such as reading, writing, and managing data.

The tab also facilitates key management, including key rotation, which is essential for maintaining security by regenerating keys periodically. Each key has a corresponding connection string for programmatic access, but it’s recommended to use Azure Active Directory (Azure AD) for more secure, role-based access control instead of relying on access keys. If access keys must be used, they should be securely stored in tools like Azure Key Vault to prevent exposure.

Additionally, disabling shared key authentication is advised if all applications support Azure AD. The Access Keys tab is particularly useful for legacy applications or as an emergency fallback for access. To enhance security, rotate keys regularly and minimize their use to reduce potential risks.

Shared access signature

In the Shared access signature tab, we can generate secure, temporary tokens to grant access to resources in our Azure Storage Account without sharing the access keys. Account-level SAS provides access to all services within the storage account, including blobs, files, queues, and tables, based on the permissions and scope defined during token creation. We can specify granular permissions such as read, write, delete, and list, along with time-bound access, IP address restrictions, and protocol enforcement (e.g., HTTPS only) to enhance security.

While this tab focuses on account-level SAS, there are other SAS types available for more specific needs. Service-level SAS restricts access to individual resources like a blob container or queue, making it ideal for sharing specific data securely. User-Delegation SAS, created using Azure Active Directory (Azure AD) credentials, provides enhanced security by delegating access based on Azure AD roles and identities. Additionally, modern applications can use OAuth 2.0 access tokens via Azure AD for short-lived, role-based, and highly secure access, eliminating the reliance on shared keys.

Account-level SAS tokens are best suited for broad operational needs but should be used with caution, as they provide extensive access. For more secure and granular control, consider using Service SAS or Azure AD-based methods wherever possible.

Azure Storage Authorization Mechanisms

Azure Storage supports several mechanisms for controlling access securely:

Microsoft Entra Credentials (formerly Azure Active Directory): Leverages role-based access control (RBAC) to provide fine-grained, secure permissions based on Azure AD roles and identities, ensuring minimal privilege is granted.
Account Keys: These provide full administrative access to the storage account and should be used sparingly due to their extensive permissions. Regular key rotation is essential to mitigate security risks.
Shared Access Signatures (SAS): SAS tokens delegate temporary, scoped access to specific resources, with options to limit by time, permissions, and IP ranges. This approach ensures secure interactions without exposing account keys and adheres to the principle of least privilege.

By choosing the appropriate mechanism, you can tailor access to meet your security and operational needs effectively. SAS tokens are ideal for temporary and granular access, while Azure AD-based authentication offers robust, role-based control for modern applications.

Encryption

Encryption Tab

The Encryption tab in an Azure Storage Account provides options to manage the encryption of data at rest. By default, Azure encrypts all data stored in the storage account using Microsoft-managed keys. This ensures data security without requiring additional configuration. However, the Encryption tab also offers advanced options, including the use of Customer-Managed Keys (CMKs).

Key Features of the Encryption Tab

Microsoft-Managed Keys:
- Default encryption method where Azure manages the encryption keys.
- Suitable for most workloads requiring secure and compliant encryption.
Customer-Managed Keys (CMKs):
- Allows you to use your own keys stored in Azure Key Vault or Key Vault Managed HSMs.
- Provides full control over key rotation and lifecycle management.
- Useful for meeting regulatory or compliance requirements.
Infrastructure Encryption:
- Azure Storage automatically encrypts all data at rest using 256-bit AES encryption in GCM mode, one of the strongest block ciphers available. This encryption is FIPS 140-2 compliant, ensuring robust data protection at the service level. For customers requiring higher assurance, Infrastructure Encryption adds a second layer of encryption using 256-bit AES encryption in CBC mode. This double encryption provides an additional safeguard, ensuring that even if one encryption algorithm or key is compromised, the second layer continues to protect the data.
- This option must be enabled during the storage account creation and cannot be changed later.
- Particularly useful for highly sensitive workloads that require double encryption.
Key Rotation:
- With CMKs, we can configure automatic key rotation or rotate keys manually using Azure Key Vault policies.

Encryption Scopes Tab

The Encryption Scopes tab provides granular control over encryption by allowing us to define encryption settings at the container level. This is ideal for scenarios where different containers or datasets require varying encryption configurations. Multiple encryption scopes allow us to configure different encryption settings for individual containers within a single storage account thus ensuring that each container’s encryption aligns with specific security, compliance, or operational requirements, offering flexibility and enhanced control.

Key Features of the Encryption Scopes Tab

Granular Encryption Control: Assign unique encryption settings, such as customer-managed keys, to specific containers within the storage account.
Scoped Customer-Managed Keys: Use CMKs stored in Azure Key Vault for selected encryption scopes, ensuring sensitive datasets have dedicated encryption keys.
Infrastructure Encryption: While Infrastructure Encryption must be enabled at the storage account level during its creation, it can still be applied selectively to specific containers by configuring it through the Encryption Scopes Tab, ensuring double encryption for sensitive datasets. However, this setting cannot be changed once the encryption scope is created, making it essential to decide upfront based on security and compliance requirements.
Multi-Tenant or Multi-Workload Scenarios: Perfect for environments where different containers serve multiple tenants or workloads, each with distinct encryption requirements.
Default Encryption Scope: Define a default encryption scope for newly created containers, simplifying management.

Microsoft Defender for Storage

Microsoft Defender for Storage enhances security by detecting threats such as malicious access, data exfiltration, and malware uploads. It provides:

Threat Detection: Activity monitoring via log analysis and sensitive data threat detection at no additional cost.
Malware Scanning: On-upload malware scanning using Microsoft Defender Antivirus with cloud protection ($0.15/GB scanned).
Pricing: $10 per storage account per month (additional charges for scanning).

Defender for Cloud continuously monitors storage configurations, providing recommendations to mitigate vulnerabilities. Enable Defender at the account or subscription level for proactive protection of Azure Storage workloads.

Best Practices for Secure Configuration

Block All by Default: Start by denying all traffic to your storage account. Only allow access from trusted networks, specific IP ranges, or authorized Azure resource instances.
Use Private Endpoints: Use private endpoints to route traffic securely through our virtual network, eliminating exposure to the public internet. If using private endpoints, disable public access entirely for maximum security.
Restrict Public Network Access: For scenarios requiring public access, limit traffic to specific, trusted IP addresses or ranges. Configure virtual network subnets to secure access further. Regularly review and update firewall rules to reflect changes in our network or application needs.
Enable Logging and Metrics Thoughtfully: Enable logging and metrics services selectively, ensuring only essential operations are logged. Allow exceptions for logging and metrics read access but restrict other public network access.
Disaster Recovery Planning: Use cross-region service endpoints to ensure seamless access to storage accounts in paired regions during outages. Configure alternative virtual networks in paired regions for redundancy and recovery purposes.
Use Managed Access: Grant access to specific Azure resource instances using system-assigned managed identities when virtual networks or IP rules are not feasible. Configure granular, operation-specific rules to minimize unnecessary access.
Enable Infrastructure Encryption if Needed: For sensitive workloads, enable double encryption via Infrastructure Encryption during storage account creation or through Encryption Scopes at the container level.
Regularly Review and Rotate Keys: Avoid relying on account keys; use Azure AD authentication where possible. If using account keys, rotate them regularly and store them securely using Azure Key Vault.
Leverage Threat Detection: Enable Microsoft Defender for Storage to monitor and detect threats such as data exfiltration, malware uploads, and unauthorized access. Use Defender’s recommendations to address vulnerabilities proactively.
Hierarchical Namespace: Combine Azure roles and ACLs for granular access control in Data Lake Storage-enabled accounts.
Network Security Perimeter (Preview): Define logical isolation for PaaS resources to restrict public access while allowing explicit exceptions. Ideal for scenarios where additional isolation is required.
Programmatic Tools: Use tools like Azure PowerShell or CLI for automating configurations, especially for advanced scenarios.

Practical Limitations

Private Network Rules: Cannot use private IP ranges (e.g., 10.x.x.x) in IP rules.
Same-Region Traffic: Virtual network rules (e.g., allowing access only from a specific subnet) must be used for same-region access, as IP rules are ineffective for traffic within the same Azure region. This is because Azure routes same-region traffic directly through its backbone network, bypassing public IPs, which makes IP-based restrictions inapplicable.
Changing Subnets: If a subnet in a rule is deleted, it must be re-authorized after recreation to restore access. This is because the recreated subnet is treated as a new resource with a different identifier, requiring explicit reauthorization to ensure continued access control.
DNS Considerations: Avoid caching IP addresses or overriding DNS TTL, as this can lead to issues such as failed access due to outdated IPs in caches. This happens because Azure storage endpoints are dynamic and may change, requiring real-time DNS resolution to ensure accurate connectivity.
Firewall Rules Scope: Firewall rules apply only to data operations (e.g., accessing blobs). Control operations (e.g., creating or deleting a storage account) are unrestricted by firewall rules and are typically governed by Azure Role-Based Access Control (RBAC).

Conclusion

Azure Storage Accounts provide a comprehensive suite of networking and security features that enable secure and efficient data management in the cloud. By leveraging tools such as Firewalls and Virtual Networks, Private Endpoints, and Routing Preferences, organizations can control access and ensure secure communication. Capabilities like Custom Domains, Encryption Scopes, and Microsoft Defender for Storage offer additional layers of security, flexibility, and threat detection.

Stay connected with news and updates!

Join our mailing list to receive the latest news and updates from our team.
Don't worry, your information will not be shared.

We hate SPAM. We will never sell your information, for any reason.