An AI research team recently made a massive mistake when they published a bucket of open-source training data on GitHub that included terabytes of additional private data. This data contained a disk backup of employees’ workstations, containing all their secrets, private keys, passwords and thousands of internal messages!
The researchers shared the files using SAS tokens, a feature from Azure Storage accounts that allows data to be shared through the system. The unintentional breach could have been avoided by placing stricter access restrictions on the data shared through SAS tokens.
This blog post will explain the misconfiguration of SAS tokens and how to mitigate or prevent such breaches.
In Azure, a Shared Access Signature (SAS) token provides secure delegated access to resources in storage accounts. With a SAS, you have granular control over how a client can access your data, including:
A Shared Access Signature (SAS) is a powerful way to give fine-grained access to Azure Storage resources. It’s a token appended to the URI for an Azure Storage resource, containing a set of query parameters that indicate how the resource can be accessed. The signature is generated from the SAS parameters and secured with the key used to create the SAS. The signature is then used by Azure Storage to authorize access to the storage resource. With a SAS token, you can control access to resources, set expiration times and even allow access from specific IP addresses.
Figure 1 shows an example of a SAS URI, displaying the resource URI, the delimiter character ('?'), timestamps, token permissions, Type and the SAS token.
SAS tokens become a serious security risk when misconfigured, especially when sharing information with external entities. If compromised, a misconfigured SAS token can make the entire system vulnerable. To protect your organization, it's critical to understand the risks associated with SAS tokens.
First, control and monitor the permissions associated with the tokens. Ensure that access is limited to the absolutely necessary data and that no additional permissions are granted.
Second, closely monitor external identities, as they can be used for malicious purposes. Lastly, implement logging and monitoring for all SAS tokens to track access and changes to the data.
Using SAS tokens introduces two primary security risks:
To mitigate these risks, you need to ensure that you follow best security practices.
Always adhere to the principle of least privilege by providing the minimum required privileges to the fewest possible resources. For instance, if a user only needs read access to a single object, grant them that specific access only. This approach limits the damage if a SAS is compromised, as the user has fewer privileges.
Set expiration policies for your storage accounts to limit SAS access in the event of a compromise. Implement an upper expiration limit policy to govern any service SAS or account SAS created by a user. This policy protects your data and account from unauthorized access and prompts users to refresh their access keys regularly.
Manage SAS expiration effectively by setting a reasonable limit that aligns with your security and compliance needs. Additionally, establish alerts for when SAS tokens are created or updated to maintain security and to be alerted to any suspicious activity.
Employ short-term expiration for ad hoc service or account SAS to safeguard your data against unauthorized entities. This limits the time frame a compromised service or account SAS remains valid, reducing the risk of damage. This practice is particularly vital when you cannot reference a stored access policy, as it helps maintain control over the data written to a blob by limiting the upload time.
Develop a countermand plan to protect your business from a security breach involving a SAS. A comprehensive plan enables you to quickly identify and respond to potential threats.
An effective revocation plan should include immediate revocation of all access to the compromised SAS, assessment of the breach's source and scope, and establishment of a data backup to recover lost or destroyed data.
Always use HTTPS when creating or distributing a SAS. Transmitting a SAS over HTTP could allow an attacker to intercept it, compromising the data. Protecting your SAS with HTTPS is vital to prevent data corruption or exposure of sensitive information.
Opt for a user delegation SAS whenever possible for enhanced security. A user delegation SAS, secured by Microsoft Entra credentials, offers better security than a service SAS or an account SAS. It eliminates the need to store account keys in the code, reducing a significant security risk.
Implement a logging and monitoring service to gain visibility into user activities, which can help identify security or performance issues. A robust service can alert you to authorization failures, access policy removals, token expirations, billed usage and other potential threats. This visibility is crucial for protecting your system and data from malicious activities.
With a logging and monitoring service, you can receive immediate notifications of unauthorized activity, enabling quick identification and response to threats. Additionally, proper alerts can help you track consumption and utilization to prevent billing for unauthorized usage.
To learn about Prisma Cloud's latest innovations, tune in to our on-demand virtual event, CNAPP Supercharged: A Radically New Approach to Cloud Security, where we’ll show you how to streamline app lifecycle protection.
And don’t miss an opportunity to test drive best-in-class code-to-cloud security with a free 30-day Prisma Cloud trial.