Traditionally, access to Azure Storage is granted using account access keys or Shared Access Signature (SAS) tokens. An account key grants full control over the entire storage account to anyone who has it, which is a major security risk if the key is leaked. SAS tokens are an improvement because they can be scoped to specific resources and have an expiration time, but they are not tied to a user's identity. This means if a SAS token is stolen, it can be used by anyone until it expires, and managing the creation and lifecycle of many SAS tokens adds operational complexity.
Azure RBAC solves these problems by tying permissions directly to an identity in Microsoft Entra ID (formerly Azure AD). Instead of handing out keys or tokens, you assign a user or group a built-in or custom role at a specific scope, such as the entire storage account, a single container, or even an individual blob. This enforces the principle of least privilege, as you can grant only the permissions needed for a task. For example, you can assign the Storage Blob Data Reader role to a user at the container level, allowing them only to read blobs in that container and nothing else. This model is centrally managed and easier to audit than distributing keys or tokens.
A comparison matrix evaluating Azure Storage authorization methods—Account Keys, SAS Tokens, Azure RBAC, and Azure ABAC—across identity binding, expiration, scope, and security risk.
To use RBAC, you must first enable Azure AD authentication for your storage account. Once enabled, you assign roles. Common built-in roles include Storage Blob Data Owner (full control), Storage Blob Data Contributor (read, write, delete), and Storage Blob Data Reader (read-only). You can assign these roles at the account, container, or blob scope. For more granular control, you can create custom roles or add attribute-based conditions. For instance, a condition could grant write access only to blobs in a container named "reports" or based on a user's department attribute in Microsoft Entra ID.
After configuring roles, you must verify they work correctly. Use the "Check access" feature in the Azure portal to simulate what a specific user can see and do. To monitor actual usage, configure diagnostic settings on the storage account to send logs to a Log Analytics workspace. These audit logs record every data plane operation, showing who accessed what resource, when, and from where. Regularly review these logs and your role assignments to ensure permissions remain correct and adhere to the least-privilege principle. Adjust roles or conditions promptly if audit findings show unnecessary access or if business requirements change.
Are you a guardian of your domain? Lean how to leverage your aptitude in security to protect Microsoft Azure technologies, with a goal of earning the Microsoft Certified: Azure Security Engineer Associate certification!
Prepare and test your skills

Prepare and test your skills

Account access keys grant full control over an entire storage account to anyone who possesses them, presenting a major security risk if a key is leaked. While Shared Access Signature (SAS) tokens can be limited by scope and expiration time, they are not tied to a user identity and can be used by anyone if stolen. Additionally, managing the creation and lifecycle of numerous SAS tokens introduces operational complexity.
The Storage Blob Data Owner role provides full control, Storage Blob Data Contributor provides read, write, and delete access, and Storage Blob Data Reader provides read-only access. These roles can be assigned at the storage account, container, or individual blob scope, and they can be customized further using custom roles or attribute-based conditions.
Administrators can validate permissions by using the Check access feature in the Azure portal to simulate what a specific user can see and do. Actual usage is audited by configuring diagnostic settings to send logs to a Log Analytics workspace, which records every data plane operation, including who accessed what resource, when, and from where. Regularly reviewing these logs and role assignments ensures access permissions remain correct and adhere to the principle of least privilege.