4 — App Security

Concevoir l'identité et la sécurité applicative → secrets/clés/certificats (Key Vault), authn/authz (Entra ID, Managed Identity, RBAC) et gouvernance (Management Groups, tags, conformité).

A. Azure Key Vault

A.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.

A.2 Les 3 variantes de Key Vault

🚨 Précision FIPS (firmware Marvell mis à jour) : Premium ET Managed HSM sont désormais FIPS 140-3 Level 3. Le vrai critère de choix n'est donc plus le niveau FIPS mais : Managed HSM = single-tenant + key sovereignty + root of trust client + security domain + local RBAC (un Owner de sub ne voit pas les clés) + compliance PCI DSS/3DS. Premium = multitenant, root of trust Microsoft.

🎯 Mémo 305 :

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

A.3 Contenu d'un Key Vault — 3 types d'objets

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

A.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).

A.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.

A.6 Identité d'accès — Managed Identity

• Best practice : MI sur l'app (App Service, VM, Function, AKS) + rôle RBAC sur le KV → zero secret stocké.
• Auditing : Diagnostic Settings → Log Analytics → Sentinel.

A.7 Pièges KV 305

• 🚨 RBAC > Access Policies (recommandation MS moderne).
• 🚨 Purge protection IRRÉVERSIBLE : une fois activée, tu ne peux plus la désactiver. Le KV ne peut pas être purgé pendant la rétention.
• 🚨 Same region : pour CMK SQL/Storage, key vault dans même région que la ressource (sinon failover Geo-DR cassé).
• 🚨 Vault Standard ≠ HSM : pour HSM-backed → Vault Premium ou Managed HSM.
• 🚨 Managed HSM = cluster single-tenant dédié, pricing élevé, justifié uniquement pour compliance ultra.
• 🚨 Managed HSM stocke Keys only (pas de Secrets/Certificates).

B. Pattern : Push Container to ACR via KV Secret

[GitHub Actions / Azure DevOps]
   │ (Federated OIDC ou MI)
   ▼
[Key Vault] ─── secret = ACR password / SP creds
   │
   ▼
[ACR] ◄── docker push
   │
   ▼
[AKS/App Service/ACI] ─── docker pull (via MI + AcrPull)

Bonnes pratiques :

• MI sur cible (AKS/App Service) → pas besoin de stocker creds ACR.
• OIDC Federated Credentials côté CI/CD → zero secret stored.
• KV soft-delete + purge protection obligatoire prod.

C. 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.

C.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.

C.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

D. Protection des secrets

Pattern CI/CD moderne

GitHub Actions → Federated Credentials (OIDC) → token Entra court → Azure access. Aucun secret stocké.

E. Identity Design (Authentication + Identity Management)

E.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.

E.2 External Identities

E.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

F. Authorization Design

F.1 Authorize Azure resources — RBAC + PIM

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

F.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.

G. Identity Governance

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

H. Governance Design

H.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)

H.2 Subscription strategy

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

H.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).

H.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

H.5 Cost governance

I. 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

J. Scénarios 305 → solution

🏢 Scénarios d'entreprise (CAF/WAF)

Scénario 1 : Santé (Hôpital régional) — CMK HIPAA pour TDE SQL + Storage

Contexte business : Plateforme de dossiers patients sur Azure SQL + Storage. L'audit HIPAA exige des clés gérées par le client (CMK), récupérables, et non purgeables par un admin compromis. Le failover Geo-DR ne doit jamais casser à cause d'un problème de clé. Choix architectural : Key Vault Premium (HSM-backed) + soft-delete + purge protection + CMK pour TDE SQL et Storage, accès par Managed Identity + RBAC. → CMK conforme sans aller jusqu'au Managed HSM. Architecture / pattern :

• KV dans la même région que SQL et Storage (sinon le failover Geo-DR casse).
• CMK avec auto-rotation (rotation policy KV).
• Logs KV → Log Analytics → alertes sur restauration/suppression de clé.
• 1 Key Vault par app + environnement (dev/prod séparés) pour limiter le blast radius. Trade-offs assumés :
• Gain : conformité HIPAA, contrôle du cycle de vie des clés, anti-purge même contre un insider.
• Perte : purge protection irréversible (pas de recréation d'un vault homonyme avant fin de rétention) ; clé même région = contrainte multi-région. Pièges à éviter :
• Oublier la purge protection → la config CMK SQL/Storage échoue (prérequis).
• Stocker le cert TLS « comme un secret » → utiliser le type Certificate (auto-rotation).
• KV dans une autre région que la ressource → failover impossible. 📐 Réf. WAF — Security pillar, service guide Azure Key Vault : appliquer soft-delete + purge protection, une instance KV par application/région/environnement, et l'auto-rotation des clés/secrets/certs comme baseline de protection des données. Lien

Scénario 2 : Services financiers (Banque) — Souveraineté des clés PCI DSS avec Managed HSM

Contexte business : Émetteur de cartes soumis PCI DSS / 3DS. Exigence : matériel single-tenant, souveraineté des clés (root of trust contrôlé par la banque), et isolation telle qu'aucun admin Azure ne puisse voir les clés. Choix architectural : Key Vault Managed HSM (single-tenant) avec security domain détenu par la banque, local RBAC pour le data plane, BYOK depuis un HSM on-prem. Architecture / pattern :

• Security domain téléchargé hors-bande au provisioning, avec quorum (≥ 3 key holders).
• Séparation stricte : Azure RBAC (control plane) ≠ local RBAC (data plane) → un Owner de sub ne voit pas les clés.
• Private endpoints sur le Managed HSM (accès VNet only) + purge protection + backups géo-redondants. Trade-offs assumés :
• Gain : single-tenant, souveraineté des clés, conformité PCI DSS/3DS, isolation totale.
• Perte : coût élevé (à l'heure), complexité (gestion du security domain et du quorum ; le perdre = perdre les clés). Pièges à éviter :
• Choisir entre Premium et Managed HSM sur le FIPS : les deux sont 140-3 L3. Le vrai critère = single-tenant + souveraineté des clés.
• Vouloir y stocker secrets/certs → Managed HSM = Keys only.
• Perdre le security domain → récupération impossible (DR cassé). 📐 Réf. — How to choose the right Azure key management solution : Managed HSM se justifie quand single tenancy, key sovereignty et root of trust client sont requis (PCI DSS/3DS), là où AKV Premium suffit pour CMK standard sans souveraineté. Lien

Scénario 3 : Industrie (manufacturier hybride) — Identité hybride + accès on-prem sans VPN

Contexte business : Industriel avec AD on-prem et apps intranet legacy, en migration cloud-first. Besoin : sync d'identité résiliente, et exposer les apps on-prem aux employés distants via Entra SSO + MFA, sans port entrant ni VPN. Choix architectural : Entra Cloud Sync (PHS + SSO) pour l'identité + Application Proxy pour publier les apps on-prem + Conditional Access (MFA + compliant device). Architecture / pattern :

• Cloud Sync (agents légers, multi-actifs, failover auto) plutôt que Connect Sync legacy ; PHS avec fallback si AD down.
• App Proxy connector on-prem en outbound 443 only → aucun port entrant ouvert.
• Pre-auth Entra + CA appliqués avant que la requête atteigne l'app.
• Compte break-glass exclu des policies CA ; démarrage en Report-only. Trade-offs assumés :
• Gain : zéro port entrant, SSO + MFA centralisés sur apps legacy, sync résiliente (multi-agents).
• Perte : Cloud Sync a des limites (150K objets/domaine, pas de Hybrid Azure AD Join) ; certaines topologies complexes exigent encore Connect Sync. Pièges à éviter :
• App Proxy pour une app cloud SaaS déjà publique → c'est App Registration + CA qu'il faut (App Proxy = on-prem only).
• « Require MFA » sur All users sans exclure le break-glass → lock-out total possible.
• Choisir Connect Sync par habitude alors que Cloud Sync suffit → migration future évitable. 📐 Réf. CAF — Identity and access management : migration Connect→Cloud Sync : pour les nouveaux déploiements hybrides, Cloud Sync est la direction stratégique (cloud-managed, multi-agents, failover) ; vérifier le comparatif de capacités avant de retenir Connect Sync. Lien

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 tenant
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 tenant (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