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