The responsibility of data ownership and stewardship is no longer centralized. Various departments, business units, and teams continuously handle data, utilizing it to meet their specific objectives. However, such a dispersed approach to data ownership can leave companies vulnerable.
One very probable cause of potential cybersecurity issues is when Azure Shared Access Signature (SAS) tokens are revealed in code repositories and other data sources or shared with third parties, which can then be accessed by the public and misused for malicious purposes. This can include cases such as leaking confidential information or accessing privileged files. In this blog, we will focus on the most popular type – Account SAS tokens (Azure).
What is an Azure SAS Token?
A Shared Access Signature (SAS) token is a unique string of encrypted text that encapsulates all the necessary details needed to authenticate a shared signature to access Azure Storage services. It also determines which service and resource can be accessed, the permissions granted, and the validity period of the signature.
If we look at the specifics of these tokens, there are 3 types of SAS tokens: Account SAS, Service SAS, and User Delegation SAS. This blog walks through Account SAS tokens specifically, as this is the type of token used to access storage, which is a critical (if not the most critical) point of failure in data security.
Account SAS Tokens
SAS tokens are encrypted codes in the form of URIs (Uniform Resource Identifier) that grant specific access rights to one or more Azure Storage resources, such as Azure Blob Storage, Azure File Storage, and Azure Queue Storage. Compared to other tokens, this extensive access means it's crucial to handle Account SAS carefully to prevent unauthorized data access.
Furthermore, the efficacy of a SAS token lies in its signature, a special parameter added to the storage resource's URI. This system ensures controlled access without revealing sensitive credentials, which is vital when users need access but shouldn't have overarching permissions. Azure Storage then verifies this signature to authorize access and allows clients direct access to specified resources for a predetermined time. Once it expires, a new token is required.
As observed in Microsoft’s documentation, here’s an example of a SAS token in a URI:
Once the token is generated, users may be granted permissions such as read and/or write. There are two notable use cases:
- Clients can upload and download data via a front-end proxy service that authenticates the signature.
- A specific service authenticates the user and then generates an Account SAS code to directly access storage account resources.
What are the Risks of Using SAS Tokens?
While Account SAS tokens are incredibly useful for accessing storage resources, there are a set of risks that businesses must consider.
Tracking generated tokens. One major challenge is the inherent lack of visibility into how many tokens are currently in circulation. Once tokens are generated, they can be accessed and utilized by any unauthorized entity.
Longer than intended timestamps. Secondly, there is the potential for users to set exceedingly long expiration dates when generating tokens, thus leaving data vulnerable for longer periods of time than originally intended. Service disruptions may also occur when tokens expire, impacting any services that rely upon them.
Once generated, a SAS token can't be revoked. To avoid such human errors, it is a best practice to specify a short lifespan on the signed key start and expiration date and time.
Mistaken permissions. To exacerbate these problems, SAS tokens might grant more access than originally intended. For instance, a user wanting to provide access to a specific file might inadvertently create a SAS token that allows access to the entire associated storage container including all the files in it. Also, a user wanting to provide "read" access to files might inadvertently create a SAS token that allows “write” or “manage” permissions instead of just “read,” so anyone who has the token at hand can write and manage the storage account.
Let’s look at a few best practices to avoid incorrect permissions and exposing unauthorized access.
Best Practices for Working with Azure SAS Tokens
We recommend a number of best practices when working with Azure SAS tokens:
Apply principle of least privilege:
- Limit SAS tokens to essential resources (e.g., one blob).
- Only grant necessary permissions (e.g., read-only).
Use short-lived SAS:
- Apply a shorter expiration time for SAS tokens and have clients request new SAS tokens when needed.
- Refresh SAS tokens as per Microsoft’s recommended time: 1 hour or less.
Handle SAS with care:
- Treat SAS tokens as confidential.
- Only share with clients who need access to a storage account.
Revocation strategy:
- Link SAS tokens to stored access policy to revoke them more easily.
- Be prepared to delete the stored access policy or change storage account keys if leaks occur.
Monitor and audit:
- Enable Azure Monitor and Storage Logs to oversee storage account access.
- Implement a SAS expiration policy to identify long-lived SAS use.
In addition to all these standard best practices, Cyera has specific actions that your organization can take today to ensure secure use of SAS tokens.
How Cyera can Help
As explained earlier, using SAS tokens to allow access to your data introduces potential data loss risks. Since revoking a specific SAS token is not possible, organizations can rotate the storage account’s access key, which invalidates all tokens and not only the SAS tokens associated with the storage account. Unfortunately, the main issue with this alternative solution is service degradation.
Alternatively, Cyera offers a multifaceted approach for businesses looking to manage and secure their SAS tokens, ensuring they are used appropriately and safely.
Visibility into SAS tokens. Cyera can scan a broad spectrum of IaaS, PaaS, and SaaS datastores and identifies Azure SAS tokens in both structured and unstructured data, such as databases and files within Microsoft 365 and various cloud storage services. This provides visibility of the presence and location of SAS tokens.
Audit access to SAS tokens. Cyera can provide insights into the users, groups, and other identities that can access datastores or files that contain SAS tokens, as well as the purpose for why these identities have access to the data.
Misplacement detection. Cyera can flag when tokens are found in less secure environments. For example, some companies may decide that SAS tokens should only reside in certain production environments. If the SAS tokens end up in a development environment with open access to many employees, it may violate company policies, triggering an alert.
Unauthorized token creation detection. Cyera can generate an alert when an Azure storage account has broad permissions that allow for unintended users to create SAS tokens. Security teams can set policies to monitor and limit these permissions and thus enforce a safer storage environment.
Unprotected token detection. Cyera can generate an alert when SAS tokens are found in a datastore with public access or if the SAS token itself is exposed as plaintext, allowing anyone with access to the datastore to utilize the token.
Conclusion
Improperly generating or exposing Azure Storage SAS tokens can be a major security risk to your sensitive data. Cyera helps mitigate these risks by enhancing the visibility, auditability, and detection of SAS token exposures.
Cyera takes a data-centric approach to security, assessing the exposure to your data at rest and in use and applying multiple layers of defense. Because Cyera applies deep data context holistically across your data landscape, we are the only solution that can empower security teams to know where their data is, what exposes it to risk, and take immediate action to remediate exposures and assure compliance without disrupting the business.
To learn more about how you can secure your data, schedule a demo today.
