Azure Storage Blobs Access Control

This document provides a comprehensive guide to understanding and implementing access control for Azure Storage Blobs. Securely managing access to your blob data is crucial for protecting sensitive information and ensuring data integrity.

Table of Contents

• Introduction to Blob Access Control
• Authentication Methods
• Authorization Models
• Role-Based Access Control (RBAC)
• Shared Access Signatures (SAS)
• Access Control Lists (ACLs) for Hierarchical Namespace
• Managed Identities
• Best Practices

Introduction to Blob Access Control

Azure Storage provides robust mechanisms to control who can access your data and what operations they can perform. This is achieved through a combination of authentication and authorization strategies.

Authentication Methods

Authentication verifies the identity of the user or service attempting to access your storage account. Azure Storage supports the following authentication methods:

• Azure Active Directory (Azure AD): The recommended method for securing access to your storage. Azure AD provides robust identity management and allows for granular permission control.
• Account Key: A primary and secondary key generated for each storage account. While simple to use, it grants full access to the storage account and should be managed securely.
• Shared Access Signatures (SAS): Time-limited tokens that grant specific permissions to blob containers or blobs. SAS tokens are ideal for delegating access to clients without sharing account keys.

Authorization Models

Once authenticated, authorization determines whether the identity is permitted to perform the requested operation on the specified resource.

Role-Based Access Control (RBAC)

Azure RBAC allows you to grant granular access to Azure resources. For Azure Storage, you can assign built-in roles or custom roles to users, groups, service principals, or managed identities. Common roles include:

• Storage Blob Data Reader: Grants read access to blob data.
• Storage Blob Data Contributor: Grants read, write, and delete access to blob data.
• Storage Blob Data Owner: Grants full control over blob data, including managing access control.

RBAC is applied at the subscription, resource group, or storage account level.

Shared Access Signatures (SAS)

A Shared Access Signature is a string that contains a security token, which can be appended to a URL to access a storage resource. SAS provides a delegated level of access to objects in your Azure Storage, allowing clients to modify and access storage resources without needing the account name and key.

There are two types of SAS:

• Service SAS: Signed with the storage account key.
• Account SAS: Signed with the storage account key, but can delegate access to all service types.

When creating a SAS, you can specify:

• Permissions (Read, Write, Delete, List, Create, Add, Process)
• Start and expiry times
• IP address restrictions
• Protocols (HTTPS only)

Creating a SAS Token

SAS tokens can be generated using:

• Azure Portal
• Azure CLI
• Azure PowerShell
• Azure Storage SDKs

Example of a SAS URI (conceptual):

https://myaccount.blob.core.windows.net/mycontainer/myblob.txt?sv=2020-08-04&ss=bfqt&srt=sco&sp=rwdlacupx&se=2023-12-31T12:00:00Z&st=2023-01-01T12:00:00Z&spr=https&sig=aBcDeFgHiJkLmNoPqRsTuVwXyZ1234567890abcDEF

Access Control Lists (ACLs) for Hierarchical Namespace

If you have enabled the hierarchical namespace feature on your Azure Data Lake Storage Gen2 account, you can use Access Control Lists (ACLs) for fine-grained control at the directory and file level.

ACLs extend RBAC by providing POSIX-like permissions for individual files and directories. Each entry in an ACL specifies a scope (user, group, or other) and a set of permissions (Read, Write, Execute).

ACL Types

• Access Control Entries (ACEs): Define permissions for specific users or groups.
• Default ACLs: Applied to new files and directories created within a directory.

Managed Identities

Managed identities provide Azure services with an automatically managed identity in Azure Active Directory. You can use managed identities to authenticate to Azure Storage without needing to store credentials in code or configuration files. This is highly recommended for applications and services running on Azure.

There are two types of managed identities:

• System-assigned: Enabled directly on an Azure resource.
• User-assigned: Created as a standalone Azure resource that can be assigned to one or more Azure resources.

Once a managed identity is created, you can grant it Azure RBAC roles on your storage account to control its access to blob data.

Best Practices

• Prefer Azure AD authentication with RBAC over account keys for most scenarios.
• Use the principle of least privilege: Grant only the necessary permissions to users and services.
• Utilize Managed Identities for applications running on Azure services.
• Use SAS tokens for delegated access with time limits and restricted permissions. Avoid long-lived SAS tokens.
• Securely store and manage account keys if they must be used. Rotate keys periodically.
• Enable HTTPS for all connections to Azure Storage.
• Regularly audit access logs and permissions.
• For Data Lake Storage Gen2, leverage ACLs for granular, file-level permissions.