Storage access keys and SAS tokens in Azure - Deep Dive

Overview - Storage access keys and SAS tokens

What is it?

Storage access keys and SAS tokens are two ways to control who can access data in Azure Storage. Access keys are like master keys that give full control to the storage account. SAS tokens are special, limited keys that allow specific actions for a set time. They help keep data safe while sharing access securely.

Why it matters

Without these controls, anyone could access or change your storage data, risking loss or theft. Access keys and SAS tokens let you share data safely without giving away full control. This protects your apps, users, and business from accidental or malicious damage.

Where it fits

You should understand basic Azure Storage concepts and identity management first. After this, you can learn about Azure role-based access control (RBAC) and managed identities for more advanced security.

Mental Model

Core Idea

Storage access keys are master keys giving full access, while SAS tokens are temporary, limited keys granting specific permissions.

Think of it like...

Think of access keys as the master key to your house, opening every door anytime. SAS tokens are like giving a guest a key that only opens the front door during their visit.

┌─────────────────────────────┐
│       Azure Storage         │
│ ┌───────────────┐           │
│ │ Access Keys   │◄── Full Access
│ └───────────────┘           │
│                             │
│ ┌───────────────┐           │
│ │  SAS Tokens   │◄── Limited Access
│ └───────────────┘           │
└─────────────────────────────┘

Build-Up - 7 Steps

1

Foundation

What are Storage Access Keys

Concept: Introduce storage access keys as the main way to access Azure Storage.

Azure Storage accounts have two access keys. These keys let you read, write, and manage everything in the storage account. They are like passwords for the whole storage account. You use them in your apps or tools to connect to storage.

Result

You can connect to and control all storage data using these keys.

Understanding access keys is crucial because they are the root of all access to your storage account.

2

Foundation

What are SAS Tokens

Concept: Explain SAS tokens as limited, temporary keys for specific access.

A Shared Access Signature (SAS) token is a special URL or token that grants limited access to storage resources. You can set what actions are allowed (like read or write), which files or containers it applies to, and how long it lasts. This lets you share data safely without giving full control.

Result

You can share storage access securely with limited permissions and time.

Knowing SAS tokens lets you share storage safely without risking your master keys.

3

Intermediate

Differences Between Keys and SAS Tokens

🤔Before reading on: do you think access keys and SAS tokens provide the same level of access? Commit to your answer.

Concept: Compare access keys and SAS tokens to understand their roles and risks.

Access keys give full control over the storage account and all its data. SAS tokens give limited access to specific resources for a set time. Access keys should be kept very secret. SAS tokens can be shared safely because they limit what others can do.

Result

You understand when to use keys (for full control) and when to use SAS (for limited sharing).

Knowing the difference helps you protect your storage by using the right access method for each situation.

4

Intermediate

How to Create and Use SAS Tokens

🤔Before reading on: do you think SAS tokens can be created to allow write access only? Commit to your answer.

Concept: Learn how to generate SAS tokens with specific permissions and expiry.

You create SAS tokens using Azure Portal, Azure CLI, or code. When creating, you choose permissions like read, write, delete, and set start and expiry times. You also specify which storage resource the token applies to, like a blob or container. Then you use the SAS token in URLs or connection strings to access storage.

Result

You can generate SAS tokens that safely share storage access with precise control.

Understanding SAS creation empowers you to share data securely and avoid over-permissioning.

5

Intermediate

Security Best Practices for Keys and SAS

🤔Before reading on: do you think it is safe to embed access keys directly in client apps? Commit to your answer.

Concept: Introduce security rules to protect keys and SAS tokens.

Never share access keys publicly or embed them in client apps. Rotate keys regularly to reduce risk. Use SAS tokens for client access instead of keys. Limit SAS token permissions and expiry time to the minimum needed. Monitor usage and revoke tokens if needed.

Result

You know how to keep your storage secure by managing keys and SAS tokens properly.

Following these practices prevents accidental leaks and reduces damage if keys or tokens are compromised.

6

Advanced

Using Stored Access Policies with SAS

🤔Before reading on: do you think stored access policies can change SAS token permissions after creation? Commit to your answer.

Concept: Explain stored access policies as a way to manage SAS tokens centrally.

Stored access policies are defined on containers or queues and let you group SAS token settings like permissions and expiry. SAS tokens linked to a policy inherit its settings. Changing or revoking the policy updates all linked SAS tokens instantly. This helps manage many SAS tokens easily and securely.

Result

You can centrally control SAS token permissions and revoke access quickly.

Knowing stored access policies helps you manage SAS tokens at scale and improve security.

7

Expert

Risks and Limitations of Access Keys and SAS

🤔Before reading on: do you think SAS tokens can be fully revoked once issued? Commit to your answer.

Concept: Explore security risks and limitations of keys and SAS tokens in production.

Access keys grant full control, so if leaked, attackers can do anything. SAS tokens cannot be revoked individually unless linked to stored access policies. Long-lived SAS tokens increase risk. Also, SAS tokens do not authenticate users, only grant access. For stronger security, combine SAS with Azure AD or use RBAC. Always monitor and rotate keys.

Result

You understand the security tradeoffs and how to mitigate risks in real systems.

Knowing these limits helps you design safer storage access strategies and avoid common security pitfalls.

Under the Hood

Access keys are symmetric keys stored securely in Azure. When used, they authenticate requests by proving possession of the key. SAS tokens are generated by signing a string with an access key, encoding permissions, resource, and expiry. Azure validates SAS tokens by checking the signature and permissions before allowing access.

Why designed this way?

Access keys provide a simple, powerful way to authenticate all storage operations. SAS tokens were designed to allow fine-grained, temporary access without sharing full keys. This balances security with flexibility for sharing data.

┌───────────────┐        ┌───────────────┐
│ Access Key 1  │───────▶│ Sign SAS Data │
│ Access Key 2  │        └───────────────┘
└───────────────┘                │
                                ▼
                      ┌───────────────────┐
                      │   SAS Token       │
                      │ Permissions, Expiry│
                      └───────────────────┘
                                │
                                ▼
                      ┌───────────────────┐
                      │ Azure Storage     │
                      │ Validates Signature│
                      └───────────────────┘

Myth Busters - 4 Common Misconceptions

Quick: Do you think SAS tokens can be revoked individually after creation? Commit to yes or no.

Common Belief: SAS tokens can be revoked anytime individually once issued.

Reality: SAS tokens cannot be revoked individually unless they are linked to a stored access policy, which can be revoked or changed.

Why it matters: Believing SAS tokens can be revoked individually may lead to long-lived tokens remaining active and vulnerable if leaked.

Quick: Do you think embedding access keys in client apps is safe if the app is private? Commit to yes or no.

Common Belief: Embedding access keys in client apps is safe as long as the app is not public.

Reality: Embedding access keys in client apps is unsafe because keys can be extracted, exposing full storage control to attackers.

Why it matters: This mistake can lead to full data compromise if the app is reverse-engineered or leaked.

Quick: Do you think SAS tokens authenticate the user accessing storage? Commit to yes or no.

Common Belief: SAS tokens authenticate the user accessing the storage resource.

Reality: SAS tokens do not authenticate users; they only grant access based on possession of the token.

Why it matters: Misunderstanding this can cause over-trusting SAS tokens and ignoring user identity, weakening security.

Quick: Do you think rotating access keys is optional if SAS tokens are used? Commit to yes or no.

Common Belief: If SAS tokens are used, rotating access keys is not necessary.

Reality: Access keys should be rotated regularly even if SAS tokens are used, because SAS tokens are generated from these keys.

Why it matters: Neglecting key rotation increases risk if keys are compromised, affecting all SAS tokens.

Expert Zone

1

SAS tokens can be scoped to very specific resources and permissions, but overly broad tokens are a common security risk.

2

Stored access policies allow revoking or updating multiple SAS tokens at once, but they add complexity and must be managed carefully.

3

Access keys are symmetric and cannot be limited by IP or protocol, unlike SAS tokens which support such restrictions.

When NOT to use

Avoid using access keys directly in client-side apps or public environments; use Azure AD authentication or managed identities instead. SAS tokens are not suitable for long-term access or strong user authentication; use RBAC and Azure AD for those cases.

Production Patterns

In production, access keys are kept in secure vaults and rotated regularly. SAS tokens are generated dynamically with minimal permissions and short expiry. Stored access policies are used to manage groups of SAS tokens. Monitoring and alerting on key usage and SAS token activity is standard practice.

Connections

Azure Role-Based Access Control (RBAC)

Builds-on

Understanding keys and SAS tokens helps grasp RBAC, which provides user-based, fine-grained access control beyond shared keys.

Public Key Infrastructure (PKI)

Contrast

Unlike symmetric access keys, PKI uses asymmetric keys for authentication, highlighting different security models in access control.

Physical Key and Lock Systems

Analogy in security design

Knowing how physical master keys and guest keys work helps understand the balance between full and limited access in digital storage.

Common Pitfalls

#1 Embedding access keys directly in client-side code.

Wrong approach:

const storageKey = "";
// Used directly in frontend JavaScript

Correct approach:

Use SAS tokens generated by a secure backend service and pass them to the client.

Root cause:

Misunderstanding that access keys are sensitive secrets that must not be exposed publicly.

#2 Creating SAS tokens with overly broad permissions and long expiry.

Wrong approach:

Generate SAS token with read, write, delete permissions valid for 1 year.

Correct approach:

Generate SAS token with only needed permissions (e.g., read) and short expiry (e.g., 1 hour).

Root cause:

Lack of understanding of the principle of least privilege and security risks of long-lived tokens.

#3 Not rotating access keys regularly.

Wrong approach:

// Access keys never rotated after initial setup

Correct approach:

Rotate access keys every 30 days or per organizational policy using Azure Portal or CLI.

Root cause:

Underestimating the risk of key compromise and the importance of key lifecycle management.

Key Takeaways

Storage access keys are powerful master keys that grant full control over your Azure Storage account and must be protected carefully.

SAS tokens provide a safer way to share storage access by limiting permissions and time, reducing security risks.

Always prefer SAS tokens over access keys for client or external access, and follow best practices like least privilege and short expiry.

Use stored access policies to centrally manage and revoke SAS tokens when needed.

Understand the limits of keys and SAS tokens and combine them with Azure AD and RBAC for stronger security in production.