Curriculum Overview: Azure Role-Based Access Control (RBAC)

This curriculum provides a structured path to understanding how Microsoft Azure manages access to resources. Azure RBAC is a critical security system that provides fine-grained access management, ensuring that users have only the permissions they need to perform their jobs.

Prerequisites

Before diving into Azure RBAC, learners should have a foundational understanding of the following:

• Cloud Concepts: Familiarity with Shared Responsibility and Defense-in-Depth models.
• Identity Basics: Understanding of authentication (who you are) versus authorization (what you can do).
• Azure Hierarchy: Knowledge of Azure Management Groups, Subscriptions, and Resource Groups.
• Microsoft Entra ID (formerly Azure AD): Basic understanding of users, groups, and service principals.

Module Breakdown

Learning Objectives per Module

Module 1: Identity Fundamentals

• Explain the role of authorization within the Azure ecosystem.
• Describe how RBAC fits into the Zero Trust security framework (Verify explicitly, use least privileged access, assume breach).

Module 2: RBAC Core Components

• Define a Security Principal (User, Group, Service Principal, or Managed Identity).
• Distinguish between different Role Definitions (Owner, Contributor, Reader, and User Access Administrator).
• Understand the structure of a Role Assignment.

Module 3: Scope Hierarchy

• Describe the Scope levels: Management Group, Subscription, Resource Group, and Individual Resource.
• Explain how Inheritance works (permissions applied at a higher level flow down to lower levels).

\begin{tikzpicture} % Scope Hierarchy Visualization \draw[thick, fill=blue!10] (0,0) rectangle (6,4); \node at (3,3.6) {\textbf{Management Group}};

\draw[thick, fill=blue!20] (0.5,0.5) rectangle (5.5,3.2); \node at (3,2.8) {Subscription};

\draw[thick, fill=blue!30] (1,1) rectangle (5,2.4); \node at (3,2) {Resource Group};

\draw[thick, fill=blue!40] (1.5,1.2) rectangle (4.5,1.7); \node at (3,1.45) {Resource};

% Inheritance Arrow \draw[->, ultra thick, red] (6.5,4) -- (6.5,0); \node[rotate=-90] at (6.8,2) {\textbf{Permission Inheritance}}; \end{tikzpicture}

Module 4: Implementing RBAC

• Demonstrate how to assign roles via the Azure Portal.
• Compare and contrast built-in roles versus custom roles.

Module 5: Governance & Auditing

• Apply the Principle of Least Privilege to real-world scenarios.
• Describe how to use Access Reviews to maintain a secure environment.

Success Metrics

To demonstrate mastery of Azure RBAC, the learner must be able to:

• Explain the difference between a Role Definition and a Role Assignment.
• Identify the correct scope for a specific administrative task to minimize security risks.
• Determine why a user has a specific permission based on inheritance rules.
• Select the appropriate built-in role (Reader vs. Contributor) for a developer vs. an auditor.
• Configure a role assignment that limits access to a single resource group rather than an entire subscription.

Real-World Application

[!IMPORTANT] The Principle of Least Privilege (PoLP) In a production environment, you should never grant "Owner" permissions if "Contributor" is enough. If a user only needs to view logs, they should only be a "Reader". This limits the "blast radius" if an account is ever compromised.

Case Study: The "Cloud Admin" Dilemma

Imagine a company where every developer has "Owner" access to the production subscription. One developer accidentally deletes the primary production database while trying to run a test.

Solution using RBAC:

1. Move the Database to a separate Resource Group.
2. Assign the developers the Reader role at the Subscription level.
3. Assign the developers the Contributor role only on the Development Resource Group.
4. Restrict Owner access to a small set of highly-vetted Cloud Infrastructure Admins.

This structure ensures developers can still work without having the power to accidentally destroy critical production infrastructure.