Why “Just Give Them Access” Is the Most Dangerous Thing in Cloud Security
“It’s just temporary.” Those three words have caused more cloud security incidents than most people want to admit including me.
I still remember the moment it clicked for me. I was deep in an Azure lab, trying to figure out why a service account had access to an entire subscription when it only needed to read from one storage container. Nobody had done anything malicious. Nobody had even made a bad decision on purpose. The access had just… accumulated. Layer after layer. Project after project. Until one day, someone looked at the environment and realized they had no idea who could do what anymore.
That’s the quiet danger in cloud security. It rarely looks like a dramatic breach. It usually looks like a list of permissions nobody cleaned up.
As I continue studying Microsoft Azure and documenting that journey publicly, I keep coming back to two concepts that I believe every cloud engineer beginner or experienced must truly understand:
This guide is for you whether you just created your first Azure account or you’re already deploying infrastructure at scale. The fundamentals matter at every level.
Let’s be honest about how cloud environments get messy because it doesn’t happen the way you might expect.
It starts with a new team member joining mid-project. To avoid blocking them, a manager says, “Let’s just give them Contributor access to the whole resource group for now.” That “for now” never gets revisited.
Then a contractor joins for a three-month deployment. They need elevated access to push resources. Project ends. Permissions stay.
An engineer moves to a different team. Old access remains. Nobody notices because the account is still active and nobody’s looking.
Six months later, you have an Azure environment where dozens of identities carry permissions, they no longer need and no one has a clear picture of who can do what.
One compromised account with Reader permissions might leak sensitive configuration data. One compromised account with Owner permissions could destroy your entire infrastructure delete virtual machines, disable monitoring, exfiltrate data, and lock your team out.
The role you assign today is the blast radius you accept tomorrow.
The Principle of Least Privilege is a security concept with a simple rule:
In practice, this means you stop asking “what access might this person need?” and start asking “what access does this person actually need right now?”
The difference sounds small. The security impact is enormous.
Least Privilege reduces your attack surface. If a user account gets compromised, the attacker inherits only that user’s limited permissions not keys to the entire kingdom. It limits the damage from insider threats, both accidental and intentional. And it creates accountability, because every access grant has a clear purpose behind it.
In Azure, this principle is enforced through a system called Azure RBAC.
Azure Role-Based Access Control (Azure RBAC) is Microsoft Azure’s built-in authorization system. It lets you control who has access to Azure resources, what they can do with those resources, and at what scope those permissions apply.
Before RBAC, managing permissions was crude you either had access or you didn’t. Azure RBAC makes access granular and deliberate. Instead of handing someone the keys to your entire environment, you give them exactly what they need for their role and you scope it to exactly where they need it.
It works through three core concepts:
Security principal
The identity requesting access a user, a group, a service principal, or a managed identity.
Role definition
A collection of permissions. It defines what actions are allowed for example, “can read storage accounts” or “can delete virtual machines.”
Scope
Where the permissions apply at the level of a management group, subscription, resource group, or individual resource.
These three elements combine into a role assignment the actual record that grants access to a specific principal, at a specific scope, with a specific set of permissions.
Before going further, Entra ID helps to understand the identity system behind everything:
Microsoft Entra ID formerly known as Azure Active Directory is Microsoft’s cloud-based identity and access management platform. Every time a user signs into Azure, Microsoft 365, or a connected app, Entra ID is working in the background.
Entra ID answers the question “Who are you?” Azure RBAC answers the question “What are you allowed to do?”
These two systems work together. Entra ID authenticates the identity. RBAC authorizes what that identity can access. Neither one alone is enough you need both.
Entra ID also powers critical security features like Multi-Factor Authentication (MFA), Conditional Access policies, and identity protection all of which layer on top of RBAC to create a more complete security posture.
A critical point about custom roles: built-in roles are a great starting point, but they often grant more access than necessary for a specific task. If someone only needs to restart virtual machines not to delete or recreate them, a custom role lets you grant exactly that, nothing more.
If you’re new to Azure, here’s the actual process. Open your Azure portal and follow along.
Theory is useful. But it helps to see how this plays out in practice.
Scenario 1: The phished admin account
An attacker sends a convincing phishing email to an engineer. The engineer clicks. Their credentials are captured. Because that engineer had Owner-level access across three subscriptions “for convenience,” the attacker now has the ability to delete resources, disable security monitoring, export secrets, and deploy malicious workloads all before anyone notices.
Scenario 2: The forgotten contractor
A contractor completes a six-month deployment engagement and offboards. Their access isn’t revoked. an oversight in a busy team. Eight months later, their email account is compromised through an unrelated breach. The attacker finds active Azure credentials attached to that account. Because the contractor still has Contributor access to a production resource group, the attacker has everything they need.
Scenario 3: The accidental deletion
An intern runs a cleanup script one they genuinely thought was safe. Because they were given Contributor access to the entire subscription instead of just the test resource group, the script runs further than intended and deletes a production database. No malicious intent. Just too much access and not enough guardrails.
All three scenarios have one common thread: permissions that were broader than they needed to be.
Zero Trust is one of the most talked-about frameworks in modern cybersecurity. Its core principle is simple but has sweeping implications:
Zero Trust rejects the old assumption that anyone inside your network perimeter is safe. In modern cloud environments, where users connect from home, from personal devices, from anywhere in the world that assumption was never really valid anyway.
Azure RBAC is a foundational component of any Zero Trust implementation. It ensures that:
Pair RBAC with Conditional Access policies and MFA through Microsoft Entra ID, and you have a layered security model that doesn’t rely on trusting any single identity by default.
There’s a phrase you’ll hear often in cloud security circles: “identity is the new perimeter.” It sounds abstract until you understand what changed.
Traditional security was built around the network. You had a firewall, a corporate office, a physical boundary. If you were inside the network, you were assumed to be trustworthy. Security was focused on keeping threats out at the edge.
Cloud computing dismantled that model. Resources live outside corporate networks. Users access systems from anywhere. Applications communicate across the internet. There is no clear perimeter anymore not in the traditional sense.
What remains is identity. Every action in Azure is performed by an authenticated identity. That identity either has or doesn’t have permission to perform that action. If you control your identities and their permissions tightly, you retain meaningful security even in a borderless environment.
This is why Microsoft Entra ID, RBAC, Conditional Access, and MFA aren’t optional security add-ons. They are the security layer. They are the perimeter now.
I’m actively studying Azure, and I won’t pretend otherwise. I’m not writing this from a position of “I’ve solved this problem” I’m writing it from the position of someone who found it genuinely difficult to understand at first, and who knows that clear explanations are often the thing that’s missing.
What I’ve learned is that cloud security concepts like RBAC and Least Privilege aren’t reserved for senior architects. They are entry-level fundamentals that every cloud practitioner needs to internalize early because the habits you build when you’re learning are the ones you carry forward.
I’ve also learned that women in tech often feel like they need to wait until they “know enough” before they speak publicly about technical topics. I’m choosing not to wait. I’ll document the learning as it happens, in plain language, as honestly as I can.
If this post helped something click for you, that’s exactly why it exists.
Cloud security doesn’t fail all at once. It erodes slowly one unnecessary permission at a time, one unreviewed role assignment at a time, one forgotten contractor account at a time.
Azure RBAC and Least Privilege are not advanced security topics. They are foundational. They are where security maturity begins. And they are entirely within reach for anyone willing to learn them properly.
Take five minutes this week and look at your Azure environment. Ask the questions that matter:
The answers to those questions might be more important than any tool you configure.
Follow along with the journey
I share beginner-friendly Azure and cloud security breakdowns access management, identity, Zero Trust, and what I’m learning week by week.