Azure SC-900: Access Governance — Conditional Access, RBAC, and PIM
Entering a company building is different from entering a specific room inside it. And even within the same room, different rules can apply depending on whether it is a weekday or weekend, or whether it is a full-time employee or an intern. Modern cloud security demands precisely this kind of sophisticated, fine-grained access control. This post examines the core access governance tools in Azure.
Conditional Access: Smart, Context-Aware Security
Imagine a security guard deciding who can enter a building — not just by checking a badge, but by considering multiple conditions: "Is this person entering through the main entrance during working hours? Or are they trying to come in through a back door at 3 AM? Does facial recognition match? Did they arrive in a registered vehicle?" All of these conditions are evaluated together.
That is exactly the role Microsoft Entra ID's Conditional Access plays. Rather than simply checking "is the password correct?", it collects multiple signals and uses them to allow access, block access, or require additional authentication.
Signals: What Information Is Collected?
User-related: Who is trying to log in? (An administrator? A regular employee?) Location-related: Where is the login coming from? (A company office in Seoul? Overseas? A known malicious location?) Device-related: What device is being used? (A company-managed device? A personal device?) App-related: Which application is being accessed? (A sensitive financial system? A regular email account?) Risk-related: A risk score for the login attempt, detected by Microsoft AI. (Does it follow an abnormal pattern?)
Decisions: What Action Is Taken?
Based on the collected signals, one of three decisions can be made:
Allow: If conditions are normal, access is granted.
Block: If the situation is deemed risky, access is completely blocked.
Conditional Allow: Access is granted subject to conditions — such as requiring MFA, requesting a password change, or allowing access only from a compliant device.
Real-World Examples
Scenario 1: An employee accesses email from the company's Seoul office during business hours on a weekday. Normal conditions — access is granted immediately.
Scenario 2: The same employee attempts to access the Azure management portal at 2 AM from a Nigerian IP address. Risk signals detected — blocked or MFA required.
Scenario 3: A personal smartphone is used to access company files. The device does not comply with company policies — MFA required and read-only access granted.
Entra Roles vs. Azure RBAC: Two Separate Systems
Think of a school: the principal manages the entire school's operations but does not manage Seoul city education administration. A city government official handles administration but does not decide the school curriculum. Different roles for different purposes.
Azure also has two distinct role systems with different purposes.
Microsoft Entra ID Roles
These roles govern the management of Microsoft Entra ID itself. They determine who can manage identity-related things: user accounts, groups, licenses, app registrations, and so on.
Representative roles: Global Administrator: Manages everything in Entra ID. Highest level of privilege. User Administrator: Manages only users and groups. Helpdesk Administrator: Limited to actions like password resets.
Azure RBAC (Role-Based Access Control)
These roles determine who can manage Azure resources — VMs, storage, databases, and so on. This is an entirely separate system from Entra ID roles.
Representative roles: Owner: Full access to all resources and the ability to delegate permissions to others. Contributor: Can create, modify, and delete resources, but cannot delegate permissions. Reader: Can only view resources.
An Important Distinction
Becoming a Global Administrator in Entra ID does not automatically grant access to all resources in an Azure subscription. Conversely, being a subscription Owner in Azure does not grant the ability to manage Entra ID. These two systems operate independently.
Azure RBAC is applied according to scope: Management Group → Subscription → Resource Group → Individual Resource. A role assigned at a higher scope is inherited by lower scopes.
!Entra ID Roles versus Azure RBAC
PIM: Elevated Privileges Only When Needed
Imagine a security company managing keys. When a safe needs to be opened, the key is borrowed for that task and returned when the job is done. Walking around with the safe key at all times is risky — it could be lost or stolen.
PIM (Privileged Identity Management) applies this principle to IT security.
The Problem PIM Solves
The old approach: A person who needs admin privileges is given an admin account with those privileges maintained around the clock. If that account is compromised, an attacker gains unlimited access.
The PIM approach: Privileges are activated temporarily only when needed. A user normally has standard user privileges and submits a "privilege activation" request when administrative work is required.
Core Features of PIM
Just-in-Time Access: Privileges are activated only for the time they are needed. If administrative work is planned for two hours, privileges are granted for two hours.
Approval Workflow: High-level privilege activation can be configured to require manager approval. The user must submit a justification for why the privilege is needed.
Time Limit: Privileges expire automatically. Even if no one manually revokes them, they disappear after the designated time.
Notifications and Auditing: Every instance of who activated which privilege and when is logged, and notifications are sent.
MFA Requirement: MFA is required at privilege activation to add an extra layer of security.
Access Reviews: Regularly Auditing Permissions
Think about subscription services. If you never check "am I still using this?", you end up paying for services you no longer use. Organizational access permissions work the same way.
An employee has moved to a different department. Their access to the previous department's systems does not disappear automatically. You need to confirm that accounts of departed employees have been fully deactivated.
Access Reviews is a tool for performing this "permission cleanup" systematically.
How It Works
A regular review schedule is set. For example: review all admin accounts every quarter.
Reviewers (managers, resource owners, or the users themselves) approve or deny whether each permission is still needed.
Automation: Reviews can be configured to automatically remove permissions based on the outcome.
Who Conducts the Review?
Manager reviews: A team lead reviews their team members' access permissions. Resource owner reviews: The person responsible for a specific system reviews access to that system. Self-review: Users are asked "do you still need this access?"
Entitlement Management: Simplified Access with Access Packages
What systems should a new employee access when they join? Send an email to IT, make a separate request, wait for approval... it is complicated, and more so in large organizations.
Entitlement Management simplifies this. Access permissions needed for each role are bundled into "access packages."
Example: A "New Marketing Team Employee" package = SharePoint Marketing Site + Teams Marketing Channel + CRM System read access.
A new marketing employee simply requests this one package, and all the access they need is granted at once. An expiration date can be set so that access for contract employees is automatically removed at the end of their contract.