Cloud-based SQL Server security isn't simpler. It's different — and the learning curve is brutal if you grew up on-prem.
If you've spent years working Windows authentication, SQL logins, role memberships, and the occasional certificate, you may assume cloud security is more of that, just with a portal. Not. The SQL Server/Cloud permission models are layered differently, the terminology shifts depending on the platform, and the people who 'own' security are spread across teams that don't always speak the same language.
The Problem: Two Permission Systems, One Confusing Experience
The core issue exists across all major cloud platforms: There is a split between management plane permissions (who can see and configure resources in the portal) and data plane permissions (who can actually read/write the data).
| Platform | Mgmt Plane | Data Plane |
|---|---|---|
| Azure | ARM roles | Storage Data roles |
| AWS | IAM policies | Resource/bucket policies |
| GCP | Cloud IAM | Data access scopes |
The result is the same everywhere: A user can have 'Contributor' access to a resource and still get 'Access Denied' when they try to use it. The terminology varies, the confusion is universal.
And it gets worse. Identity sync delays can mean waiting hours for permission changes to take effect. Role inheritance doesn't behave like on-prem Active Directory. Informal titles like 'tenant admin' or 'cloud admin' mean different things to different organizations. And sometimes even different things to different people in the same organization.
Microsoft's own documentation acknowledges that 'Achieving Separation of Duties (SoD) is challenging for security-related or troubleshooting tasks'. That's not a criticism. It's an honest admission that the model is complex, even for the people who built it.
A Real-World Example
A customer reached out with what seemed a simple ask: "We have a new Blob Storage account and we can't assign permissions so I can add documents to it."
Their security admin had created the storage account and container. He tried to grant the requesting user access, but it didn't work. The user couldn't see it in the portal, let alone add documents. They had a tight timeline — this was for a proof-of-concept analytics portal and they needed it sorted fast.
My first question: "When you say he 'was not able to grant access' does that mean he tried and it failed, or he granted it and you still can't see anything?"
The answer: "It was more the former. He was trying to add the role assignments and it didn't work as we expected."
Then my customer said: "John (name change) has tenant admin to Azure, so I don't think it will be a limitation on his side."
Here's the problem with that assumption.
What 'Tenant Admin' Actually Means
If by 'tenant admin' they meant Global Administrator in Entra ID (formerly Azure AD), that role gives full control over users in the directory. It does not automatically grant permission to manage Azure resources like a storage account. To do that, the Global Admin would need to perform an 'elevation' step to get User Access Administrator at the root scope, or someone would need to explicitly assign them Owner on the resource.
More likely, though, is that they just hadn't assigned the right combination of roles.
To successfully access a blob container in the Azure portal, a user needs permissions in two distinct systems:
| Role Type | What It Does |
|---|---|
| ARM Role (ie., Reader) | Lets you see the storage account in the portal and navigate to its resources |
| Storage Data Role (ie., Storage Blob Data Contributor) | Lets you read/write/delete data within the blob container |
If you only assign Reader, they can see it but can't touch the data. If you only assign Storage Blob Data Contributor, the user can't see the storage account in the portal. You need both.
We got on a call with the customer, their cloud admin, and our cloud expert. Within minutes, our cloud guy found the hole — a missing role assignment — applied it in the portal, and the problem resolved immediately.
Cause? They just didn't know about the dual-permission model. And why would they? It's not very intuitive. The terminology is inconsistent. And 'Contributor' sure sounds like it would let you contribute.
Even the Experts Draw a Line
Here's something worth noting: some of the most respected SQL Server voices in the industry explicitly exclude security and permissions work from their practice contractually. Not because they can't learn it or don't know it -- but because the complexity and risk warrant specialization. When top-tier SQL Server experts are steering clear of security questions entirely, that tells you something about the depth of this space.
The idea that 'the cloud handles security for you' is a widespread, largely misleading myth. Cloud platforms remove some infrastructure tasks — automated backups, patching, failover — but they don't validate that your permission model makes sense. They don't catch the gap between what you think a role grants and what it actually grants. And they certainly don't ensure your DBA and cloud teams are aligned on who can do what.
Where Does the DBA Fit?
Cloud security is most definitely not DBA-only territory, but DBAs should understand it well enough to:
• Recognize when something is a permission issue vs a configuration issue
• Speak the same language as their cloud teams
• Catch issues that slip through the DBA to Cloud Team handoff
The most effective DBAs I've worked with aren't the ones who know everything about cloud IAM. They're the ones who know enough to ask the right questions — and have good communications with their cloud counterparts so the questions get answered.
Coming Next
This post is just a primer. An acknowledgment that the problem exists and that you're not alone if you've been frustrated by it. In my follow-up, I'll provide actionable guidance for DBAs navigating cloud security alongside their cloud teams, including:
• Understanding the management plane vs. data plane split in practical terms
• Minimum permission combinations for common DBA tasks
• Necessary permission combinations for common user tasks at the frontend
• How to diagnose 'Access Denied' when the portal says you have access
• A checklist for DBAs before handing off to cloud teams (and vice versa)
What's Tripped You Up?
I'd love to hear from you. What cloud security issues have caught you off guard? What did you learn in your first SQL Server+Cloud 'Access Denied' surprise? Drop a comment if you can. Your pain points will help shape the follow-up.
More to Read:
Microsoft: Azure SQL Database Security Best Practices
Microsoft: Assign an Azure role for access to blob data
Azure SQL and Entra ID authentication, tips from the field
No comments:
Post a Comment