Overview
In the Azure ecosystem, Shared Access Signature (SAS) tokens are a common method for granting temporary, granular access to storage resources without exposing account keys. They are essential for many application workflows, from allowing user uploads to sharing data with partners. However, their convenience can introduce significant risk if they are not configured securely.
A critical, yet often overlooked, security setting is the enforcement of HTTPS for all SAS token traffic. When a SAS token is generated, it can be configured to allow access over both HTTP and HTTPS. Allowing unencrypted HTTP traffic exposes the token—and the data it protects—to interception. This misconfiguration is not just a security vulnerability; it’s a source of potential financial waste, creating risks that can lead to costly data breaches, regulatory fines, and operational disruption.
Why It Matters for FinOps
From a FinOps perspective, a security vulnerability is a financial liability waiting to happen. Allowing SAS tokens over HTTP creates direct and indirect costs that impact the business. A data breach resulting from an intercepted token can trigger millions of dollars in regulatory fines under frameworks like GDPR, HIPAA, and PCI-DSS. The operational cost of responding to such an incident—including forensic analysis, key rotation, and service downtime—can halt development and drain engineering resources.
Furthermore, non-compliance can jeopardize business relationships and customer trust, leading to churn and revenue loss. Effective cloud financial management requires proactive governance that eliminates these unforced errors. Treating secure configuration as a non-negotiable aspect of cloud operations prevents the realization of these avoidable costs and protects the organization’s bottom line.
What Counts as “Idle” in This Article
For the purposes of this article, we aren’t looking at "idle" resources in the traditional sense of CPU or memory. Instead, we are focused on identifying vulnerable configurations that represent a form of governance waste. A SAS token is considered insecurely configured if it meets the following criteria:
- It is generated without a parameter that explicitly restricts its use to the HTTPS protocol only.
- It is generated to allow both HTTPS and HTTP, creating an insecure fallback option.
The primary signal of this vulnerability is found in the token’s generation logic within application code or automation scripts. While the Azure Storage account may have a global "Secure transfer required" setting, a token configured to allow HTTP represents a latent risk that could be exploited if the global setting is ever misconfigured or disabled.
Common Scenarios
Scenario 1
A mobile application allows users to upload profile pictures directly to an Azure Storage Account. The backend API generates a short-lived SAS token and provides it to the client. If this token allows HTTP, a user on an insecure public Wi-Fi network could have their token intercepted, allowing an attacker to access the upload container.
Scenario 2
An organization shares a large dataset with a third-party partner by providing them with a SAS token. If the token permits HTTP and the partner uses a legacy script or tool that defaults to unencrypted connections, the sensitive dataset could be transmitted in cleartext across the internet, exposing it to eavesdropping.
Scenario 3
A CI/CD pipeline uses automation scripts to generate SAS tokens for moving build artifacts and application logs between storage accounts. A developer, focused on speed, uses a default command that doesn’t enforce HTTPS, inadvertently introducing a security flaw into the production deployment process.
Risks and Trade-offs
The primary risk of not enforcing HTTPS is a Man-in-the-Middle (MitM) attack. An attacker on the same network as the client can intercept the unencrypted HTTP request, steal the SAS token, and gain the same permissions it grants. This could lead to data theft, malicious data injection, or service disruption.
Some teams might argue for allowing HTTP to support legacy applications that lack modern TLS capabilities. This is a dangerous trade-off. The perceived benefit of maintaining compatibility with an outdated system is far outweighed by the risk of a data breach. The correct approach is to update the legacy system or isolate it behind a modern, secure proxy rather than weakening the security posture of your cloud environment. Sacrificing data-in-transit encryption is never an acceptable cost-saving measure.
Recommended Guardrails
Effective governance prevents insecure SAS tokens from ever being created. This requires a multi-layered approach that combines policy, automation, and clear ownership.
- Policy as Code: Implement Azure Policy to enforce the "Secure transfer required" setting on all Azure Storage Accounts. While this doesn’t fix the token generation logic itself, it provides a critical safety net that blocks insecure connections at the service level.
- Secure Defaults: Establish secure-by-default libraries and templates for developers generating SAS tokens. Ensure that all internal SDKs and scripts explicitly set the protocol to HTTPS only.
- Tagging and Ownership: Maintain a clear tagging strategy for storage accounts to identify data owners and the applications that access them. This simplifies auditing and speeds up remediation when a misconfiguration is found.
- Education: Train development and DevOps teams on the security implications of SAS token parameters and promote the use of more secure alternatives, like Managed Identities.
Provider Notes
Azure
Azure provides several mechanisms to secure access to Storage Accounts. When working with Shared Access Signatures, the most important guardrail is enabling the "Secure transfer required" option on the storage account. This setting acts as a global control, rejecting any incoming requests over unencrypted HTTP, regardless of how a specific SAS token was configured.
For a more robust and modern approach to delegated access, organizations should prioritize using User Delegation SAS. These tokens are secured with Microsoft Entra ID credentials instead of the storage account key, which allows for better auditing and management. Even better is to eliminate tokens entirely where possible by using Managed Identities for Azure resources like VMs and Functions that need to access storage, relying on RBAC for permissions.
Binadox Operational Playbook
Binadox Insight: A single insecure parameter in a SAS token generation script can invalidate millions of dollars spent on other security controls. This vulnerability highlights how small, technical configuration errors can create massive financial and reputational risk, turning a useful cloud feature into a liability.
Binadox Checklist:
- Audit all Azure Storage Accounts to ensure "Secure transfer required" is enabled.
- Implement an Azure Policy to deny the creation of new storage accounts without this setting.
- Review application code and CI/CD scripts for SAS token generation logic and enforce HTTPS-only protocols.
- Prioritize the adoption of Managed Identities for services running within Azure.
- Establish a clear and rapid process for rotating storage account keys if a compromised token is suspected.
- Educate engineering teams on the risks of insecure token generation and promote secure coding practices.
Binadox KPIs to Track:
- Percentage of Azure Storage Accounts with "Secure transfer required" enabled.
- Number of Azure Policy violations for storage account configurations.
- Mean Time to Remediate (MTTR) for identified security misconfigurations.
- Reduction in the use of account key-based SAS tokens in favor of User Delegation SAS or Managed Identities.
Binadox Common Pitfalls:
- Assuming the account-level "Secure transfer required" setting is a substitute for secure token generation practices.
- Creating long-lived SAS tokens that increase the window of opportunity for an attacker if compromised.
- Lacking a documented and practiced key rotation plan, leading to operational chaos during a security incident.
- Forgetting to audit and remediate automation scripts in CI/CD pipelines, which can continuously create insecure tokens.
Conclusion
Securing Shared Access Signature tokens in Azure is a foundational element of cloud governance and financial risk management. Enforcing HTTPS is not an optional best practice; it is a mandatory control required to protect data, meet compliance obligations, and prevent costly security incidents.
By implementing robust guardrails through Azure Policy, establishing secure coding standards, and shifting towards modern authentication mechanisms like Managed Identities, you can eliminate this unnecessary risk. Proactive governance ensures that the convenience of SAS tokens does not come at the cost of your organization’s security and financial stability.
7-day free trial