Azure Blob Storage

The Corma and Azure Blob Storage integration keeps access to your storage accounts in line with who should reach them. Microsoft describes Azure Blob Storage as its object storage solution for the cloud, optimized for storing massive amounts of unstructured data. Blob Storage is billed on data volume, operations, data transfer and redundancy rather than seats, so the question is who holds a role or a key that can read your data.

Key takeaways

• Anyone who holds an Azure storage account access key can authorize requests against the account and effectively has access to all of its data.
• Azure storage accounts permit Shared Key authorization by default, and Microsoft recommends disallowing it in favor of Microsoft Entra ID.
• Rotating or regenerating an Azure storage access key revokes the SAS tokens generated from that key, while user delegation SAS tokens are not affected.
• Any Azure role that includes the listKeys action lets its holder read blob data through Shared Key, even without a blob data role.

Which Azure Blob Storage credentials need an owner?

Account keys are shared secrets. Microsoft recommends Microsoft Entra ID with managed identities whenever possible, and recommends disallowing Shared Key authorization, after which clients must use Entra ID or a user delegation SAS. A service SAS and an account SAS are secured with the account key, while a user delegation SAS is secured with Microsoft Entra credentials and lasts 7 days at most.

Microsoft does not document that an account key or a key-based SAS stops working when the person who copied it leaves. The documented fixes are to rotate or regenerate the key and update every client still using it, or, for a service SAS, to revoke it through a stored access policy. Microsoft recommends managing access keys in Azure Key Vault and rotating them regularly. A user delegation SAS, by contrast, can be revoked by revoking the user delegation key or by removing the RBAC role assignments of the security principal that created it.

How Corma governs Azure Blob Storage

• Data roles under review: Storage Blob Data Owner, Contributor and Reader assignments, and any role that can list account keys, go into automated access reviews.
• Leavers with a key check: a leaver workflow in the IT Workflow Builder asks the storage account owner whether the person held access keys or key-based SAS tokens, so keys can be regenerated.
• Keys and identities with an owner: account keys, SAS tokens, service principals and managed identities are non-human identities, so each one needs a named owner.
• Spend in view: your Azure costs, Blob Storage included, sit in SaaS subscription management.

Frequently asked questions

Does Azure Blob Storage support SSO and SCIM?

Blob Storage has no user directory of its own. People and applications can reach blob data through Microsoft Entra ID with Azure RBAC, but account keys and key-based SAS tokens also reach it, and Conditional Access applies only once Shared Key authorization is disallowed. See also how Corma covers Microsoft Entra ID.

How does Corma connect to Azure Blob Storage?

Corma connects through API or through its browser-based agents, which run in an isolated browser session with credentials from your password vault. For Blob Storage, what to review is role assignments and account keys. See also how Corma covers cloud platforms such as AWS.

Where is Corma data hosted?

Corma runs on AWS, with web servers and databases in data centers inside the European Union. Data is encrypted in transit and at rest, and Corma is ISO/IEC 27001:2022 certified.

Want to see who holds Blob data roles and key-listing rights? Book a Corma demo.