4 — App Security (AZ-305)

0. Azure Key Vault ⭐⭐

0.1 C'est quoi

Service managé Azure pour stocker secrets, clés, et certificats avec accès auditable. Centralise la gestion des creds et évite le hardcoding dans le code/config.

0.2 Les 3 variantes de Key Vault

🎯 Mémo 305 :

• "Secrets app + CMK PaaS standard" → Vault Standard ou Premium
• "Compliance PCI DSS HSM / FedRAMP High / défense" → Managed HSM
• "BYOK ultra-strict avec contrôle physique HSM dédié" → Managed HSM

0.3 Contenu d'un Key Vault — 3 types d'objets

🚨 Managed HSM stocke Keys only (pas de Secrets/Certificates).

0.4 RBAC vs Access Policies (data plane) ⭐⭐

Le piège classique 305 : KV a 2 modèles d'autorisation pour le data plane (lecture/écriture des secrets/keys/certs).

🚨 Piège classique : "Access Policies vs RBAC" → RBAC est recommandé (sécurité renforcée, intégration PIM). Access Policies = legacy.

💡 Subtilité Managed HSM : utilise Azure RBAC pour control plane mais un Managed HSM local RBAC pour le data plane (isolation totale, même un sub admin ne peut pas accéder aux keys).

0.5 Soft-delete + Purge Protection — anti-bourde + anti-malveillant

🚨 Piège 305 : pour utiliser CMK sur Azure SQL TDE / Storage / Disk encryption, le KV doit avoir soft-delete + purge protection activés. Sinon, échec config.

B. Entra Permissions & Consent (Delegated vs Application)

🎯 Niveau AZ-305 = le concept de décision (delegated vs application, user vs admin consent). Flows OAuth détaillés, claims de token, code MSAL = AZ-204, hors scope.

Ici on parle de l'authentification d'une Application sur un service. Cette application est donc dans Entreprise Application. Soit c'est elle qui a des droits, soit l'utilisateur l'utilise et acquiere les droits de l'app.

B.1 Delegated vs Application — le concept

• Delegated = "Je suis ton avocat, j'agis en ton nom" → limité par les droits de l'user.
• Application = "Je suis un robot autonome, j'ai mes propres permissions" → aucun humain derrière.

B.2 Règle de décision

Y a-t-il un user qui se logge devant l'écran ?
├─ OUI → Delegated (web app, mobile, SPA)
└─ NON → Application (batch nocturne, webhook, MI sur VM)

🚨 Mots-clés exam :

• "service-to-service", "background job", "scheduled", "no user" → Application
• "user signs in", "on behalf of", "web app for users" → Delegated

C. Protection des secrets

D. Identity Design (Authentication + Identity Management)

D.1 Modèle hybride Entra

⭐ Entra Cloud Sync (vs Entra Connect Sync legacy) pour nouveaux déploiements.

🎯 "Réduire helpdesk reset mdp hybride" → SSPR + Password Writeback. 🎯 "Apps legacy exigent AD sans gérer DC" → Azure AD DS (Domain Services) dans VNet.

D.2 External Identities

D.3 Authentication design (prod)

• Conditional Access (P1) = pierre angulaire :
  • Exclure compte break-glass
  • Démarrer Report-only → tester What-if → Enable
  • Combine MFA + compliant device + named locations
• Passwordless ⭐ : FIDO2 / Windows Hello / Authenticator passwordless
• PIM (P2) : rôles privilégiés Eligible vs Active permanent

E. Authorization Design

E.1 Authorize Azure resources — RBAC + PIM

🎯 Mémo : RBAC pour qui peut quoi · PIM pour roles privilégiés JIT · Locks pour anti-bourde.

E.2 Authorize on-premises resources — App Proxy ⭐

Azure AD Application Proxy : reverse proxy managé qui publie une app on-prem vers Internet via Entra (sans VPN, sans ouvrir port entrant).

[User Internet] → Entra (auth + CA) → App Proxy Cloud → Connector on-prem (outbound 443) → App on-prem

Use cases :

• Publier une app on-prem (SharePoint, intranet web, RDP) via Entra SSO + Conditional Access.
• Authentification pre-auth Entra avant que la requête atteigne l'app.
• Modes : OIDC / SAML / Header-based / IWA-Kerberos KCD / Passthrough.

🚨 Piège classique 305 : "App SaaS cloud + SSO Entra + restriction compliant device" → App Registration + Conditional Access (pas App Proxy). App Proxy = pour apps on-prem, pas pour apps cloud SaaS déjà accessibles publiquement. 🎯 Mnémo : App on-prem → App Proxy / App cloud SaaS → App Reg + CA.

F. Identity Governance ⭐

Sous-objectif officiel : "Recommend a solution for identity governance".

🎯 "Gérer accès prestataires avec expiration auto + approbation" → Entitlement Management (Access Packages). 🎯 "Revue trimestrielle des guests" → Access Reviews. 🎯 "Roles admin JIT avec MFA + approbation" → PIM Eligible.

G. Governance Design

G.1 Hiérarchie management (Enterprise-Scale Landing Zones)

Tenant Root MG
  ├─ Platform MG          (équipe centrale)
  │   ├─ Management sub   (logs, monitoring)
  │   ├─ Identity sub     (DCs, Entra Connect)
  │   └─ Connectivity sub (hub VNet, vWAN, ER)
  ├─ Landing Zones MG     (workloads)
  │   ├─ Corp MG          (apps internes)
  │   └─ Online MG        (apps internet-facing)
  ├─ Sandbox MG           (POC, dev libre)
  └─ Decommissioned MG    (retraits)

G.2 Subscription strategy

💡 Limites soft par sub : cores VM/famille, public IPs, role assignments (~4000), VNets (1000), SAs (250). Multi-subs pour scale.

G.3 Resource organization + Tagging

• Resource Groups : 1 RG = 1 lifecycle (créé/supprimé ensemble).
• Tagging strategy : enforced via Azure Policy
  • Owner / CostCenter / Environment / Project / Compliance
• Tag inheritance via Policy : propage tags MG → sub → RG → ressource (réduit oubli).

G.4 Azure Policy compliance at scale

Initiatives built-in à appliquer racine MG :

• Azure Security Benchmark v3 (baseline)
• CIS / ISO 27001 / NIST SP 800-53 / PCI DSS v4 / HIPAA HITRUST

Effects à privilégier :

• Audit au démarrage (mesurer baseline 1-2 semaines)
• Deny quand prêt (enforcement)
• DeployIfNotExists pour auto-remediation (ex : AMA + DCRs sur toutes VMs)
• Exemptions avec date d'expiration obligatoire

G.5 Cost governance

H. Decision trees AZ-305

Hybride identité

AD on-prem ?
├─ Greenfield                           → Cloud-only Entra
├─ Hybride simple                       → PHS + SSO + Entra Cloud Sync ⭐
├─ "No password in cloud"               → PTA
└─ Existant ADFS                        → Migrer vers PHS + SSO

Authorize on-prem vs cloud

App à exposer ?
├─ App on-prem → vers Internet          → App Proxy + Entra CA
├─ App cloud SaaS existante             → App Registration + Conditional Access
└─ App custom Azure native              → MI + RBAC

Identity governance

Besoin governance ?
├─ Revue périodique accès               → Access Reviews
├─ Onboarding prestataires self-service → Entitlement Management (Access Packages)
├─ Rôles privilégiés JIT                → PIM Eligible
├─ Automate joiner/leaver               → Lifecycle Workflows
└─ Détecter sign-in risks               → Identity Protection

Governance hiérarchique

Organisation taille ?
├─ Petite (1-5 subs)                    → 1 sub par env
├─ Moyenne                              → 1 sub par BU + env + MG hierarchy basique
└─ Grande / >5 subs / multi-BU          → Enterprise-Scale Landing Zones (ALZ Bicep/TF)

Policy enforcement

Scope policy ?
├─ Baseline                             → Azure Security Benchmark v3
├─ Régulé (PCI/HIPAA/ISO/NIST)          → Initiatives MS built-in correspondantes
└─ Standards internes                   → Custom initiative

DEMO

Demo Portail — App Registration (Delegated permissions, web app)

1. Microsoft Entra ID > App registrations > + New registration
2. Name : myapp-web, Single tenant (ou Multitenant si SaaS)
3. Redirect URI : Web → https://myapp.com/auth/callback
4. Register → noter Application (client) ID + Directory (tenant) ID
5. App Reg > API permissions > + Add a permission > Microsoft Graph > Delegated permissions
6. Cocher User.Read, Mail.Send → Add permissions
7. (Si admin consent requis) Bouton Grant admin consent for
8. Code app (MSAL) = AZ-204 territory, pas couvert ici

Demo Portail — App Registration (Application permissions, daemon)

1. App registrations > + New registration → Name myapp-daemon → Register
2. API permissions > + Add a permission > Microsoft Graph > Application permissions
3. Cocher User.Read.All (ou autre)
4. Grant admin consent for (OBLIGATOIRE pour Application)
5. Auth : MI ⭐ (préférée) ou Certificate (KV) ou Client Secret (KV)

Demo Portail — Federated Credentials OIDC GitHub

1. Microsoft Entra ID > App registrations > + New registration → Name github-cicd → Register (noter client ID + tenant ID)
2. App Reg → Certificates & secrets > Federated credentials > + Add credential
3. Scenario : GitHub Actions deploying Azure resources :
   • Organization : myorg
   • Repository : myrepo
   • Entity type : Branch → main
   • Name : github-main
4. Resource groups > rg > IAM > + Add role assignment → Role Contributor → Member github-cicd
5. Côté GitHub Actions : azure/login@v2 avec client-id + tenant-id + subscription-id (zero password)

CLI équivalent (pour IaC) :

az ad app federated-credential create --id $APP_ID --parameters '{
  "name":"github-main","issuer":"https://token.actions.githubusercontent.com",
  "subject":"repo:myorg/myrepo:ref:refs/heads/main",
  "audiences":["api://AzureADTokenExchange"]}'

Demo Portail — Conditional Access policy

1. Microsoft Entra ID > Security > Conditional Access > + New policy
2. Name : Require MFA for All Users
3. Users : All users (exclure compte break-glass)
4. Cloud apps : All cloud apps
5. Conditions : configurer si besoin (named locations, device platforms)
6. Grant : Require multi-factor authentication + Require compliant device
7. Enable policy : démarrer en Report-only 1-2 semaines → analyser dans Sign-in logs → puis On

Demo Portail — PIM activation rôle Eligible

1. Microsoft Entra ID > Identity Governance > Privileged Identity Management > Azure resources (ou Microsoft Entra roles)
2. Sélectionner sub / rôle → Assignments > + Add assignments
3. Selected role : Contributor / Members : user / Assignment type : Eligible (pas Active)
4. Settings (sur le rôle) : durée max activation, MFA required, approbation workflow, justification obligatoire, notification email
5. Côté user : My roles > Eligible assignments > Activate → MFA + justification → JIT