Step 1: Identity (Prove who you are)
├── Show your employee badge (authentication)
├── Security guard checks photo matches your face
└── Badge has your name and employee ID

Step 2: Access (What can you do)
├── Badge gives access to certain floors only
├── Your floor: Marketing (5th floor) ✅
├── Other floors: Engineering (3rd floor) ❌
├── CEO's office: ❌ (even though you're on same floor)
└── Conference rooms: ✅ (shared access)

Result:
- You proved WHO you are (identity)
- System knows WHAT you can access (permissions)

Your Company Network (The Castle):
├── Firewall (The Moat) → Strong perimeter defense
├── Inside the network → Everyone trusted
└── Outside the network → Everyone blocked

Problem:
- Once attacker gets inside → They have access to everything
- Employees work from home → How do they get "inside"?
- SaaS apps (Office 365, Salesforce) → Outside your network!

Assume NOTHING is trusted:
├── Inside network ≠ Trusted
├── Every request requires authentication
├── Every action requires authorization
└── Identity is the new perimeter

Result:
- Attacker steals one password → Only accesses what that user can access
- Employee works from home → Uses identity to access (no VPN needed)
- SaaS apps → Use identity federation (single sign-on)

Question: "Are you really Alice?"
Methods:
- Password: Something you know
- Phone code: Something you have
- Fingerprint: Something you are

Result: Yes, you are Alice ✅

Question: "What can Alice do?"
Check permissions:
- Can Alice read this file? ✅
- Can Alice delete this database? ❌
- Can Alice create VMs? ✅

Result: Alice can do X, Y, Z but not A, B, C

You walk into a bank
Bank teller asks:
1. "What's your account number?" (something you know)
2. "Show me your driver's license" (something you have)
3. "Sign here" (something you are - handwriting)

You prove you ARE account holder #12345 ✅

Now that bank knows you're account holder #12345:
- Withdraw from YOUR account: ✅
- Withdraw from SOMEONE ELSE'S account: ❌
- Access YOUR safe deposit box: ✅
- Access the bank vault: ❌

Your identity determines your permissions

User: alice@company.com
Password: ********
MFA code from phone: 123456

Azure AD verifies: Yes, this is Alice ✅

Check what Alice can do:
- Read resources in resource group "dev": ✅
- Create VMs in resource group "dev": ✅
- Delete resources in resource group "prod": ❌
- Read billing information: ❌

Azure RBAC enforces these permissions

Problems:
1. Everyone shares one admin password
   - Password leaked → Everyone compromised
   - Someone leaves company → Must change password for everyone

2. No audit trail
   - Database deleted → Who did it? No idea
   - Compliance audit → Can't prove who accessed what

3. Too much access
   - Junior dev has same access as CTO
   - Intern can delete production database
   - Contractor can see payroll data

4. Manual management
   - New employee → Manually grant 20 permissions
   - Employee changes role → Manually update permissions
   - Employee leaves → Manually revoke access (if you remember!)

Result: Security nightmare, compliance failure, eventual data breach

Solutions:
1. Each person has unique identity
   - alice@company.com (Developer)
   - bob@company.com (DBA)
   - charlie@company.com (Intern)
   - Password leaked → Only one account compromised

2. Complete audit trail
   - Database deleted → Logs show: bob@company.com at 2:45 PM
   - Compliance audit → Full report of who accessed what and when

3. Principle of least privilege
   - Developers: Can deploy to dev environment ✅
   - Developers: Cannot access production ❌
   - DBAs: Can access databases ✅
   - DBAs: Cannot create VMs ❌
   - Interns: Read-only access to dev ✅

4. Automated management
   - New employee → Assign to "Developers" group → Auto-gets all permissions
   - Role change → Change group membership → Permissions auto-update
   - Employee leaves → Disable account → All access revoked instantly

Result: Secure, compliant, auditable, scalable

What Happened:
- Former employee had excessive permissions
- Used those permissions to access 100 million customer records
- Downloaded credit card applications, social security numbers

Root Cause:
- Overly permissive IAM policies
- No principle of least privilege
- Poor access review processes

Cost:
- $80 million fine from regulators
- $190 million settlement to customers
- Reputation damage (priceless)

Total: $270+ million

Prevention Cost:
- Proper IAM implementation: ~$100,000
- Regular access reviews: ~$20,000/year
- ROI: 2,700x return on investment (preventing $270M loss)

Methods:
- Username + Password (something you know)
- MFA code from phone (something you have)
- Biometric (something you are)
- Certificate (something you possess)

Result: Identity verified ✅

Permissions:
- Role: Developer
- Resources: resource-group-dev
- Actions: Can create, read, update (not delete)

Result: Permissions defined ✅

Checks:
- Is your device managed? ✅
- Are you in a trusted location? ✅
- Is it normal hours? ✅
- Is there suspicious activity? ❌ → Block

Result: Access granted or denied based on context

Logs:
- alice@company.com
- Created VM "web-server-01"
- In resource group "production"
- At 2024-01-22 14:32:05 UTC
- From IP: 203.0.113.42

Result: Complete audit trail ✅

Your Identity Journey in Azure:

Step 1: Identity Provider (Azure AD)
├── Stores all identities (users, groups, service principals)
├── Handles authentication (username/password, MFA)
└── Issues security tokens (proof of who you are)

Step 2: Access Control (Azure RBAC)
├── Defines roles (Reader, Contributor, Owner)
├── Assigns roles to identities
└── Enforces permissions (can you do this action?)

Step 3: Conditional Access (Azure AD Premium)
├── Evaluates context (location, device, risk)
├── Applies policies (allow, block, require MFA)
└── Adapts to threats (if risky login, require MFA)

Step 4: Auditing (Azure Monitor)
├── Logs all authentication attempts
├── Logs all actions taken
└── Provides compliance reports

Bad:
- Team shares "admin@company.com" account
- Everyone knows the password

Why bad:
- No accountability (who made that change?)
- One compromise = everyone compromised
- Can't revoke access for one person

Bad:
- "Making someone admin is easier than figuring out exact permissions"
- Everyone is Owner on everything

Why bad:
- Intern can delete production
- Contractor can see payroll
- Huge blast radius when account compromised

Bad:
- Grant permissions when needed
- Never remove them
- People accumulate permissions over years

Result:
- Former employee still has access (left 2 years ago!)
- Person changed roles but kept old permissions
- Service accounts no longer used but still active

Bad:
- "Passwords are enough"
- "MFA is annoying"

Reality:
- 99.9% of account compromises use stolen passwords
- MFA blocks these attacks

Question 1: What type of identity?
├─ Human user → Continue to Question 2
└─ Application/Service → Use Managed Identity or Service Principal

Question 2: How sensitive is the access?
├─ Admin access → Require MFA + Conditional Access
├─ Regular access → Require MFA
└─ Read-only public data → Password only (acceptable)

Question 3: What authentication method?
├─ Passwordless options:
│   ├─ Windows Hello for Business (biometric)
│   ├─ FIDO2 security keys (hardware token)
│   └─ Microsoft Authenticator (push notification)
│
└─ Password + MFA:
    ├─ Authenticator app (best)
    ├─ SMS/Phone call (better than nothing)
    └─ Hardware token (most secure)

Question 4: Do you need conditional access?
├─ Require managed devices? → Azure AD Premium P1
├─ Require specific locations? → Azure AD Premium P1
├─ Block risky sign-ins? → Azure AD Premium P2
└─ Basic MFA only → Azure AD Free

Policy: Smart MFA
Conditions:
  - User is NOT on corporate network
  - User accessing from unknown device
  - Sign-in risk: Medium or High

Actions:
  - Require MFA
  - Require compliant device

Scenario 1: Office Network
User: alice@company.com
Location: Corporate network (trusted IP)
Device: Company laptop (Intune-managed)
Action: ✅ No MFA required (trusted environment)

Scenario 2: Home Network
User: alice@company.com
Location: Home (untrusted)
Device: Personal laptop
Action: ⚠️  Require MFA

Scenario 3: Coffee Shop
User: alice@company.com
Location: Public WiFi (untrusted)
Device: Personal phone
Risk: High (Azure AD detects anomaly)
Action: ❌ Block access OR require re-authentication + MFA

Who (Security Principal) + What (Role) + Where (Scope) = Permission

Management Group (org-wide policies)
    ↓ inherits
Subscription (billing boundary)
    ↓ inherits
Resource Group (lifecycle boundary)
    ↓ inherits
Resource (individual service)

# Alice has these assignments:
# 1. Reader at Subscription level
# 2. Contributor at "Dev" Resource Group

# Effective permissions:
Subscription scope:
  ✅ Can view all resources
  ❌ Cannot modify anything

Dev Resource Group:
  ✅ Can view AND modify resources
  ✅ Can create new resources
  ❌ Cannot assign roles (not Owner)

✅ Can view resources (inherited from Subscription)
  ❌ Cannot modify (no Contributor role)

{
  "Name": "SQL Database Administrator",
  "Description": "Manage SQL databases but not delete them",
  "Actions": [
    "Microsoft.Sql/servers/databases/read",
    "Microsoft.Sql/servers/databases/write",
    "Microsoft.Sql/servers/databases/backups/*",
    "Microsoft.Sql/servers/databases/auditingSettings/*",
    "Microsoft.Sql/servers/databases/securityAlertPolicies/*"
  ],
  "NotActions": [
    "Microsoft.Sql/servers/databases/delete"
  ],
  "AssignableScopes": [
    "/subscriptions/{subscription-id}"
  ]
}

az role definition create --role-definition @custom-role.json

az vm identity assign \
  --name MyVM \
  --resource-group MyRG

# Get VM's identity
IDENTITY=$(az vm identity show \
  --name MyVM \
  --resource-group MyRG \
  --query principalId \
  --output tsv)

# Grant access to Key Vault
az keyvault set-policy \
  --name MyVault \
  --object-id $IDENTITY \
  --secret-permissions get list

from azure.identity import DefaultAzureCredential
from azure.keyvault.secrets import SecretClient

# No credentials in code!
credential = DefaultAzureCredential()
client = SecretClient(
    vault_url="https://myvault.vault.azure.net",
    credential=credential
)

# Get secret
secret = client.get_secret("DatabasePassword")
print(secret.value)

IF (Condition)
THEN (Control)

# Instead of assigning role permanently:
az role assignment create \
  --assignee alice@company.com \
  --role Owner \
  --scope /subscriptions/{sub-id}

# Make them ELIGIBLE via PIM:
# (Done via Azure Portal: Azure AD > PIM > Azure Resources)

Role: Owner
Activation:
  - Maximum duration: 4 hours
  - Require justification: Yes
  - Require approval: Yes (for Owner role)
  - Approvers: Security team
  - Require MFA: Yes

Assignment:
  - Maximum eligible duration: 180 days (then re-justify)
  - Require justification on assignment: Yes

User: Alice
Role: Owner
Duration: 4 hours
Justification: "Deploy emergency hotfix for incident INC-12345"
Approval: Required
Approver: Bob (Security Lead)

Workflow:
1. Alice requests activation (Portal or API)
2. Bob receives notification
3. Bob approves (or denies)
4. Alice elevated for 4 hours
5. After 4 hours: Auto-demotion
6. All logged in Azure AD audit logs

Review: Owner role eligibility
Scope: All users eligible for Owner
Frequency: Quarterly
Reviewers: Resource owners

Questions:
1. Does this user still need this role?
2. Should we reduce their maximum duration?
3. Should we add more approvers?

Actions:
- Remove access (no longer needed)
- Reduce duration (4 hours → 2 hours)
- Add approval requirement

# Export PIM assignments
az rest --method GET \
  --url "https://management.azure.com/subscriptions/{sub-id}/providers/Microsoft.Authorization/roleEligibilityScheduleInstances?api-version=2020-10-01" \
  --query "value[?roleDefinitionId contains 'Owner']"

# Alert on long-running activations
# (via Log Analytics query)

# Security Defaults enables:
# - MFA for all users
# - Blocks legacy authentication
# - Requires MFA for Azure portal

# Enable via Azure AD Portal:
# Azure AD > Properties > Manage Security Defaults > Enable

# Via Portal: Azure AD > Security > Conditional Access > New Policy

Name: Require MFA for Azure Portal
Assignments:
  Users: All users
  Cloud apps: Microsoft Azure Management
Access controls:
  Grant: Require MFA
Enable policy: On

Name: Block Legacy Authentication
Assignments:
  Users: All users
  Cloud apps: All
  Conditions:
    Client apps: Exchange ActiveSync, Other clients
Access controls:
  Block access
Enable policy: Report-only (test first)

# Enable PIM (requires Azure AD Premium P2)

# 1. Make user eligible for role (not active)
# Portal: Azure AD > PIM > Azure AD Roles > Add assignments
User: alice@company.com
Role: Global Administrator
Assignment type: Eligible
Duration: 180 days

# 2. Configure role settings
Role: Global Administrator
Activation:
  - Max duration: 4 hours
  - Require justification: Yes
  - Require MFA: Yes
  - Require approval: Yes

# Create web app with managed identity
az webapp create \
  --name webapp-demo-$RANDOM \
  --resource-group rg-demo \
  --plan plan-demo \
  --runtime "DOTNETCORE|6.0"

# Enable system-assigned managed identity
az webapp identity assign \
  --name webapp-demo-$RANDOM \
  --resource-group rg-demo

# Create Key Vault
az keyvault create \
  --name kv-demo-$RANDOM \
  --resource-group rg-demo \
  --location eastus

# Grant webapp access to Key Vault
IDENTITY=$(az webapp identity show \
  --name webapp-demo-$RANDOM \
  --resource-group rg-demo \
  --query principalId -o tsv)

az keyvault set-policy \
  --name kv-demo-$RANDOM \
  --object-id $IDENTITY \
  --secret-permissions get list

using Azure.Identity;
using Azure.Security.KeyVault.Secrets;

var builder = WebApplication.CreateBuilder(args);

// No credentials in code!
var credential = new DefaultAzureCredential();
var keyVaultUri = "https://kv-demo-12345.vault.azure.net";
var secretClient = new SecretClient(new Uri(keyVaultUri), credential);

builder.Services.AddSingleton(secretClient);

var app = builder.Build();

app.MapGet("/secret", async (SecretClient client) =>
{
    var secret = await client.GetSecretAsync("DatabasePassword");
    return $"Secret retrieved at {DateTime.UtcNow}";
});

app.Run();