Access and protection: Azure RBAC, Zero Trust, defense in depth and Microsoft Defender for Cloud

Why this matters

Signing in proves who someone is. It says nothing about what they may then do. A new Azure subscription makes this painfully clear: the person who created it is the Owner of everything in it, and the quickest way to unblock a colleague is to make them an Owner too. Repeat that a few times and every engineer can delete production, grant themselves more rights and read data they never needed. When one of those accounts is compromised, the attacker inherits all of it.

This lesson covers the tools and ideas that stop that drift. A manager needs to know why "give them Reader on that resource group" is a better answer than "give them access". A salesperson needs to explain how a layered design and a posture tool protect a customer's workloads, without claiming that any one control is enough. A junior administrator needs to assign roles at the right scope, recognise which defensive layer a control belongs to, and read a secure score. Without these ideas, security becomes one firewall and a hope.

The lesson

Azure role-based access control (RBAC)

Azure role-based access control (RBAC) decides who can do what with Azure resources. Every grant is a role assignment, and a role assignment always brings together three things.

• A security principal: who gets the access. That can be a user, a group in Microsoft Entra ID, a service principal (an identity an application uses), or a managed identity (an identity Azure creates and manages for a resource such as a web app).
• A role definition: what they may do. A role is a list of allowed actions, such as reading resources, restarting a virtual machine, or deleting a storage account.
• A scope: where the access applies. Scopes are a management group, a subscription, a resource group or a single resource (lesson 6 explains the hierarchy).

Scopes and principals are different things. A resource group or management group is a place where a role is assigned; it never receives a role itself.

Azure has many built-in roles, and four are worth knowing by name.

There are also narrower built-in roles for particular services, and organisations can write custom roles when none fits. If a group of operators must start and restart virtual machines and change nothing else, the answer is a role assignment whose role contains exactly those actions, given to that group at the right scope.

Two rules make RBAC predictable.

• Inheritance flows down. An assignment at a parent scope applies to every child. Contributor on a subscription means Contributor in every resource group and on every resource inside it, not just on resources the user created.
• It is an allow model. A user can perform an action only if some role assignment, at that scope or above it, grants that action. With no matching assignment the request is refused. Nothing asks the subscription owner to approve it, and nothing lets it through because it came from the office.

Least privilege in RBAC means the smallest role at the narrowest scope. A team lead who must view every resource in one resource group, change nothing and see no other groups needs Reader on that resource group. Reader on the subscription shows too much; Contributor or Owner allows too much.

RBAC is not Azure Policy (lesson 13). RBAC controls what people and applications are allowed to do. Policy controls what resources are allowed to look like, such as permitted regions or sizes. RBAC is also not Conditional Access (lesson 10), which judges a sign-in rather than an action on a resource.

Zero Trust

The traditional perimeter model treated the corporate network like a castle: anything inside the firewall was trusted, and the effort went into the walls. Once staff, devices and applications spread across homes, phones and clouds, that model stopped making sense. One stolen laptop on the VPN had the run of the place.

Zero Trust starts from the opposite assumption. No request is trusted because of where it comes from. Every request is checked as if it arrived from an open network. Microsoft describes three guiding principles.

1. Verify explicitly. Always authenticate and authorise using all available signals: identity, location, device health, the service being reached, and anything unusual about the request. This applies inside the corporate network too. Conditional Access and MFA (lesson 10) are how Azure does it at sign-in.
2. Use least privilege access. Give each identity only the access it needs, and only for as long as it needs it. Techniques include just-in-time and just-enough access, risk-based policies, and data protection. An engineer who receives time-limited access to production for one task, with only the permissions that task needs, is least privilege in action.
3. Assume breach. Design as if an attacker is already inside. Segment access so one foothold reaches little, encrypt traffic end to end, and use analytics to spot threats and limit the blast radius.

The second and third principles are easy to blur. Least privilege is about how much access each identity holds. Assume breach is about containing an intruder who already has some, through segmentation, encryption and monitoring.

Defense in depth

Defense in depth is a layered strategy. Several layers of protection surround the data, so if one layer fails, the next still slows or stops the attacker. Its purpose is to remove any single point of failure. Relying on one very strong firewall is exactly what the model avoids.

Microsoft's version has seven layers, from the outside in.

1. Physical security: controlling entry to the datacenter buildings and the hardware inside. In Azure, Microsoft does this.
2. Identity and access: controlling who can reach infrastructure and what they can change. Examples are single sign-on, multifactor authentication and auditing of sign-in events.
3. Perimeter: protecting the boundary between your network and the internet. Azure DDoS Protection filters large-scale floods, and perimeter firewalls block unwanted traffic before it reaches resources.
4. Network: limiting communication between resources. Splitting a virtual network into subnets and using network security groups (lesson 8) so each application tier reaches only the tiers it needs means an attacker in one tier cannot move freely to the next.
5. Compute: securing the virtual machines themselves. Keep them patched, run endpoint protection, and restrict who can reach them, for example by keeping management ports closed.
6. Application: keeping applications free of vulnerabilities. Scan code before release and keep secrets such as connection strings in a secure store like Azure Key Vault, not in source code.
7. Data: at the centre, because data is what attackers are usually after. Encrypting stored records and controlling access to databases belong here.

When a question names a control and asks for its layer, look at what the control touches. A building door: physical. A sign-in: identity and access. The internet edge: perimeter. Traffic between internal subnets: network. The VM: compute. Code and its secrets: application. The records themselves: data.

Microsoft Defender for Cloud

Microsoft Defender for Cloud is Azure's tool for security posture and threat protection. It does two jobs.

• Posture management: it continuously assesses how resources are configured against security best practice and produces security recommendations, such as enabling encryption or closing an exposed port. It summarises progress as a secure score, which measures how fully its recommendations have been met. A higher score means less identified risk.
• Workload protection: optional Defender plans (for example Defender for Servers, Defender for Storage, Defender for SQL) watch particular kinds of workload and raise security alerts when they detect threats.

Other capabilities worth knowing:

• Just-in-time VM access keeps remote desktop and other management ports on virtual machines closed by default and opens them only on an approved request, for chosen source addresses and a limited time. It is least privilege applied to network access.
• Regulatory compliance views show how the environment measures up against common security standards.

Its reach is wide. Defender for Cloud is natively integrated with Azure, so many Azure services are assessed with nothing to deploy. It also extends to other public clouds and to on-premises machines, which it can reach through Azure Arc (lesson 14). A company running workloads in Azure, in another provider's cloud and in its own datacenter can use one service to assess all of them.

Know what Defender for Cloud is not:

• Not Azure Monitor (lesson 16), which collects performance metrics and logs.
• Not Azure Service Health, which reports Azure outages.
• Not Azure Policy or Azure RBAC. It recommends and alerts; it does not replace access control.
• Not a SIEM. Collecting and correlating logs from every source is Microsoft Sentinel, a separate product.

What the exam is really asking

• Role assignment parts. Principal (user, group, service principal, managed identity), role definition, scope. Groups and managed identities are principals; resource groups and management groups are scopes.
• Which role. View only: Reader. Manage but not grant: Contributor. Manage and grant: Owner. Grant only: User Access Administrator. Pick the narrowest scope that does the job, and remember assignments are inherited downward.
• No assignment means no access. RBAC allows; it does not ask.
• Which Zero Trust principle. Checking every request against signals: verify explicitly. Just-in-time, just-enough access: least privilege. Segmenting and encrypting to contain an intruder: assume breach.
• Which defense-in-depth layer. Match the control to what it protects, and remember data sits at the centre.
• Defender for Cloud versus its neighbours. Posture, secure score, recommendations, threat alerts and JIT VM access: Defender for Cloud. Performance data: Azure Monitor. Outages: Service Health. Resource rules: Azure Policy. Log correlation: Microsoft Sentinel.

The traps are RBAC versus Azure Policy (who may act versus what resources may look like), RBAC versus Conditional Access (an action on a resource versus a sign-in), and Zero Trust versus the perimeter model, which trusted anything on the corporate network.