Identity-Access-and Security in Microsoft Azure
1. Introduction
Cloud computing has become a central part of modern business. As organizations move their
data and services to the cloud, one question becomes more important than ever:
Who should have access to what, and how do we secure it?
In Microsoft Azure, managing identity, access, and security is crucial to protect data, maintain
compliance, and avoid unauthorized activity.
This guide is designed for people new to Azure and cloud security, and it will help you
understand:
• What identities are in Azure
• How users are authenticated and authorized
• What tools exist to protect access
• And how to build a strong security foundation
We’ll keep everything simple and explain each topic step-by-step
Key Concepts (Before We Begin)
Concept Description
Identity A user, app, or device that can be authenticated in Azure
Authentication Proving who you are (e.g. with a password or MFA)
Authorization Defining what you can do (e.g. read-only vs. admin access)
Access control The rules and tools to manage who can do what in your environment
Security Protecting systems and data from threats and breache
Example Scenario:
Let’s say you work at a company that has several cloud apps hosted in Azure.
You want to make sure that:
• Only employees can access those apps
• Admins have higher privileges than regular users
• Access from unknown locations is blocked
• Passwords alone aren’t enough to sign in
Azure gives you tools to do all of this, securely and at scale. In the next section, we’ll start by
introducing Microsoft’s identity platform: Microsoft EntraID.
2. Microsoft Entra ID: Identity Types Explained
Microsoft Entra ID (previously Azure AD) is the cloud-based identity service used to manage
who can access your resources and how. One of its core functions is to handle different types of
identities.
🧑💼 1. Human (User) Identities
These are real people who sign in and use services.
• Internal users: Employees inside your organization
• External users: Guests, partners, consultants, vendors, and other collaborators
Example: Jane from your HR department is an internal user. Ahmed from a partner company
is an external user.
⚙️ 2. Workload Identities (Applications & Services)
These are non-human identities, used by apps, scripts, or services.
• Service Principals: Think of this as an "identity for your app"; it lets your application
authenticate and access resources securely.
• Managed Identities: Microsoft manages the credentials for you, so you don’t have to
store secrets in code.
Example: A web app that needs to connect to a database in Azure can use a Managed
Identity instead of saving a password.
📱 3. Device Identities
These identities are tied to devices like laptops, phones, or IoT equipment.
• Microsoft Entra ID registered: Devices brought by users (BYOD) that are registered
for authentication.
• Microsoft Entra ID joined: Devices fully managed by your organization and joined to
Entra ID.
• Hybrid joined: Devices that are connected to both on-prem Active Directory and Entra
ID.
Example: Your work laptop joined to Entra ID = Azure AD Joined
Your personal phone used for work apps = Registered device.
Point: Microsoft Entra + Microsoft Security Copilot
Enhanced Identity Protection through AI and Risk Analysis
Microsoft Entra is more than just an identity service; it’s also part of Microsoft’s broader
security ecosystem. When integrated with Microsoft Security Copilot, it enables powerful AI-
driven insights and response options.
Two Key Experiences:
1. Standalone experience
o Built-in prompts for exploring user activity, risks, and logs
o You can ask questions in natural language (e.g., “Show risky users this week”)
2. Embedded experience
o Directly integrated in the Risky Users report
o Summarizes user risk, suggests insights, and recommends fast mitigation steps
Example Use Cases (see image):
• View a user’s activity related to Entra ID Protection
• Explore sign-in logs and group details
• Get audit logs of changes to licenses and roles
• Use plain language to investigate identity-related incidents
3. Microsoft Entra Domain Services (Microsoft Entra DS)
Overview
Microsoft Entra Domain Services is a managed domain service that provides traditional Active
Directory features in the cloud, without the need to deploy, manage, or patch domain
controllers (DCs).
It allows virtual machines and legacy applications in Azure to use domain join, LDAP, Kerberos,
NTLM authentication, and group policy—just like a traditional on-premises Active Directory
environment.
Key Features
Description Feature
Join Azure VMs to a domain without deploying your
Domain Join
own domain controllers
LDAP Authentication Applications can authenticate using LDAP protocol
NTLM & Kerberos Support Support for classic Windows authentication methods
Group Policy Apply GPOs to manage VM settings and policies
Microsoft handles updates, patching, replication, and
Fully Managed
high availability
Common Use Cases
• Applications that require legacy authentication protocols and cannot integrate with
Entra ID directly
• Migrating legacy on-premises apps to Azure without redesign
• Providing domain services to non-Windows or hybrid environments
4. Authentication vs Authorization
Overview
Authentication and authorization are two fundamental concepts in identity and access
management. They are often confused, but they serve very different purposes.
Think of authentication as "Who are you?", and authorization as "What can you do?"
Key Differences
Feature Authentication Authorization
Verifies the identity of the Determines what actions the user or
Definition
user or system system is allowed to perform
To ensure the person/system To grant or deny access to specific
Purpose
is who they claim to be resources
Occurs When Before authorization After successful authentication
Password, biometrics, smart Read/write access to files, Admin vs
Examples
card, MFA User roles
Entra ID login, MFA, device RBAC, Conditional Access, Privileged
Tools in Azure
identity Identity Management (PIM)
Real-Life Analogy
Imagine you're entering an office building:
• Authentication is when the security guard checks your ID badge to confirm your
identity.
• Authorization is when they check whether you're allowed to access the 5th floor.
Important Notes
• Authentication always comes before authorization.
• Azure uses services like Microsoft Entra ID for authentication and RBAC /
Conditional Access / PIM for fine-grained authorization.
• You can be authenticated but not authorized to perform certain actions.
5. Azure Multi-Factor Authentication (MFA)
Overview
Azure Multi-Factor Authentication (MFA) is a security feature that helps protect your
accounts by requiring more than one method of identity verification.
Instead of relying solely on a password, users must also provide an additional verification
method, making it much harder for attackers to gain access—even if the password is
compromised.
Supported Verification Methods
Method Description
Receive a call and press a key to
Phone Call
authenticate
Text Message (SMS) Enter a code sent to your mobile phone
Approve a push notification via the
Mobile App Notification
Authenticator app
Mobile App Verification Code Enter a time-based code from the app
Hardware Token (FIDO2, OATH) Use a physical security key
Face ID or fingerprint on supported
Biometrics
devices
Why Use MFA?
• Over 99% of identity attacks can be blocked by MFA.
• Passwords are often weak or reused — MFA adds a layer of protection.
• MFA is a critical component of Zero Trust architecture.
Use Cases
• Accessing the Azure portal
• Signing into Microsoft 365 apps
• Connecting remotely to company resources
• Conditional Access policies requiring MFA for risky logins or external access
Notes
• MFA can be enforced via Conditional Access policies.
• Admin accounts should always have MFA enabled.
• You can require MFA only when conditions apply, such as sign-ins from unfamiliar
locations or devices.
6. Conditional Access
Overview
Conditional Access is a powerful feature in Azure that allows you to enforce automated access
control decisions based on conditions like user identity, location, device status, and risk level.
It works like a "security guard at the gate"; deciding whether to allow access, require MFA,
block access, or apply other controls based on predefined rules.
How It Works
Conditional Access evaluates signals during the sign-in process, such as:
• User or group trying to access
• App or resource being accessed
• Device state (e.g., compliant, hybrid joined)
• Location (IP address, country)
• Sign-in risk level (based on Microsoft threat intelligence)
Based on these, it enforces controls, like:
• Require Multi-Factor Authentication
• Block access
• Require compliant device
• Require password change
Example Policies
Access Control Condition
Require MFA Sign-in from outside trusted location
Block access High-risk user detected
Access to sensitive app from unmanaged
Require compliant device or block
device
Require MFA + device compliance Admin accessing Azure Portal
Use Cases
• Protecting high-value applications like SharePoint, Exchange, Azure portal
• Preventing risky sign-ins from unfamiliar locations
• Requiring stronger authentication in specific scenarios
• Enforcing device compliance for mobile and desktop access
Notes
• Conditional Access works best when combined with Microsoft Entra ID, MFA, Intune,
and Defender for Identity.
• Policies can be tested in report-only mode before enforcing them.
• It's a core pillar of Zero Trust security in Azure.
7. Role-Based Access Control (RBAC)
Overview
Role-Based Access Control (RBAC) is a system in Azure that allows you to grant users the
precise permissions they need to perform tasks; nothing more, nothing less.
RBAC helps you manage who can access Azure resources, what they can do with them, and
what areas they can access.
RBAC Components
Component Description
Security Principal A user, group, service principal, or managed identity
Role Definition A collection of permissions like read, write, delete, etc.
The level at which access is granted: Subscription,
Scope
Resource Group, or Resource
The act of linking a role definition to a user/group at a
Assignment
specific scop
Common Built-in Roles
Role Name Description
Owner Full access to everything, including assigning roles
Can create and manage resources, but not assign
Contributor
roles
Reader Can view resources, but not make changes
User Access Administrator Can manage access permissions (RBAC)
Notes
• RBAC is not the same as Active Directory permissions; it’s specific to Azure
resources.
• You can also define custom roles if built-in ones don't meet your needs.
• Use "least privilege" principle: only give users what they absolutely need.
8. Defense in Depth
Overview
Defense in Depth is a security strategy that uses multiple layers of defense to protect data and
systems. If one layer fails, the next provides another opportunity to stop an attack.
Think of it like a castle with multiple walls, gates, guards, and traps; each layer helps defend
the crown jewels (your data).
Key Layers in Azure’s Defense in Depth
Layer Description
Physical Security Microsoft data centers with restricted access and 24/7 monitoring
Firewalls, network security groups (NSGs), DDoS protection, private
Network Security
endpoints
Perimeter Security Azure Front Door, Web Application Firewall (WAF), VPN, ExpressRoute
Identity & Access Microsoft Entra ID, MFA, Conditional Access, RBAC
Endpoint Protection Defender for Endpoint, antivirus, patch management
Application Security Secure code practices, API security, app gateway, threat detection
Data Security Encryption at rest/in transit, Azure Key Vault, backup and recovery
Monitoring & Microsoft Defender for Cloud, Sentinel, logging, alerting, and incident
Response response
Best Practices
• Don’t rely on a single control like passwords or firewalls.
• Use MFA + RBAC + NSGs + Defender in combination.
• Make sure monitoring and alerting are enabled across all layers.
9. Zero Trust
Overview
Zero Trust is a security model that operates under the principle of “never trust, always
verify.” It assumes that no user, device, or app should be trusted by default, even if it’s inside
the network.
In Zero Trust, everything must prove its identity and trustworthiness before being granted
access; every single time.
Core Principles
1. Verify Explicitly
Always authenticate and authorize based on all available data points: identity, location,
device health, service, data sensitivity, etc.
2. Use Least Privilege Access
Grant users the minimum access necessary to perform their tasks, using Just-In-Time
(JIT) and Just-Enough-Access (JEA) models.
3. Assume Breach
Design systems with the expectation that a breach could happen, and ensure monitoring,
segmentation, and containment mechanisms are in place.
Key Technologies Supporting Zero Trust in Azure
Technology Role in Zero Trust
Microsoft Entra ID Identity and access control (authN/authZ)
Conditional Access Enforce context-based policies
Multi-Factor Authentication Strong identity verification
Privileged Identity Management Just-in-time role elevation for admins
Continuous threat monitoring and security
Microsoft Defender for Cloud
recommendations
SIEM for detecting, investigating, and responding to
Microsoft Sentinel
threats
Microsoft Entra Verified ID Decentralized identity verification
10. Microsoft Defender for Cloud
Overview
Microsoft Defender for Cloud is a cloud-native security posture management (CSPM) and
threat protection solution for your Azure, hybrid, and multi-cloud environments.
It helps you harden your resources, detect threats, and respond to attacks—all from a single
dashboard.
Key Capabilities
Feature Description
A numeric summary of your current security posture with
Secure Score
recommended actions
Security Recommendations Prioritized steps to improve the configuration of your resources
Threat Protection Real-time alerts and analysis for suspicious activities
Advanced protections for services like VMs, SQL, Storage,
Defender Plans
AKS, Key Vault
Regulatory Compliance Maps your setup against standards like ISO 27001, NIST, SOC2,
Dashboard etc.
Integration with Sentinel Sends alerts for centralized SIEM and SOAR analysis
Supported Environments
• Azure-native services
• Hybrid workloads (via Azure Arc)
• Multi-cloud (AWS, GCP)
Use Cases
• Enforcing secure baseline configurations for all VMs
• Monitoring for unusual login patterns to storage accounts
• Ensuring Key Vaults are not publicly accessible
• Gaining visibility into misconfigured NSGs or firewall
✅ Best Practices
• Enable Defender plans for critical resources.
• Fix high-impact recommendations with automation where possible.
• Use Secure Score as a guide for your remediation strategy.
• Integrate with Microsoft Sentinel for full security operations.
11. Privileged Identity Management (PIM)
Overview
Privileged Identity Management (PIM) is a feature of Microsoft Entra ID that helps you
manage, control, and monitor access to important resources in Azure. It’s especially focused
on high-privilege roles like Global Administrator or Contributor.
Instead of giving permanent admin access, PIM lets you assign temporary, just-in-time (JIT)
permissions; only when needed and with full auditing.
Key Features
Feature Description
Just-In-Time Access (JIT) Grant users time-limited access to privileged roles
Approval Workflow Require manual approval before role activation
MFA Enforcement Enforce Multi-Factor Authentication before activating a role
Audit Logs View detailed logs of who activated what role, when, and why
Access Reviews Periodically check if users still need elevated access
Notification Alerts Get email alerts for role activations or suspicious behavior
Common Use Case
• Instead of assigning a user as permanent Owner of a subscription, you assign them as
eligible, and they activate that access only when needed.
Benefits
• Minimize standing privileges: reduces risk of misuse or attack
• Enhance visibility: detailed audit trails and alerts
• Improve compliance: supports least-privilege and access governance
• Boost security posture: attackers have fewer targets
✅ Best Practices
• Assign sensitive roles (like Global Admin) as eligible, not active
• Enable notifications and approval workflows
• Schedule regular access reviews
• Combine with Conditional Access policies for tighter control
12. Azure Key Vault
Overview
Azure Key Vault is a cloud service for securely storing and accessing secrets, such as API
keys, passwords, certificates, and encryption keys. It's designed to help developers and IT
teams safeguard sensitive data without having to manage hardware security modules (HSMs)
on-premises.
It centralizes secrets management, simplifies key lifecycle operations, and enhances security
with access controls and logging.
Core Capabilities
Feature Description
Secure storage Uses FIPS 140-2 validated HSMs to store keys securely
Access control (RBAC) Grant access to apps, users, and services based on roles
Integrates with Azure Monitor and Microsoft Sentinel for full
Logging and auditing
visibility
Automatically renew certificates from supported Certificate
Automated rotation
Authorities
Key lifecycle
Import, generate, disable, or delete keys with versioning support
management
What You Can Store in Key Vault
Type Examples
Secrets Database connection strings, passwords
Keys RSA keys, encryption/decryption keys
Certificates TLS/SSL certificates
Integration Scenarios
• Azure Functions reading secrets to connect to external APIs
• Web apps pulling database passwords from Key Vault at runtime
• Disk encryption using Key Vault-stored keys for BitLocker
• DevOps pipelines securely injecting secrets during deployments
Security Highlights
• All access is logged
• Secrets are never exposed in plain text after storage
• Supports integration with Managed Identities
• Uses network isolation options like Private Endpoints
✅ Best Practices
• Use Managed Identity instead of embedding credentials in code
• Enable Soft Delete and Purge Protection
• Regularly rotate secrets and keys
• Apply RBAC and Key Vault Access Policies for precise control
