5 — Compute Security (AZ-500)

Durcir le plan compute d'Azure (VMs, AKS, ACI/ACA, ACR, APIM) : accès distant sans exposition, isolation réseau et identité des conteneurs, chiffrement des disques, et détection via Defender for Cloud.

A. Remote access aux VMs (angle sécurité)

Cross-ref AZ-700 : NSG/ASG, Azure Firewall, hub-spoke — déjà acquis. Ici l'angle = supprimer l'exposition RDP/SSH internet (3389/22 ouverts = surface d'attaque #1).

Deux mécanismes complémentaires (souvent combinés) :

Bastion — SKUs (sécurité)

🚨 Pièges

• Le sous-réseau doit s'appeler exactement AzureBastionSubnet, ≥ /26 (sauf Developer).
• Private-only et Developer se choisissent à la création ; impossible de downgrader un SKU après déploiement.
• Session recording = Premium uniquement.
• JIT ≠ Bastion : JIT contrôle quand les ports s'ouvrent ; Bastion supprime le besoin d'IP publique. On peut faire JIT sans Bastion (et inversement).
• JIT exige Defender for Servers (plan payant) activé.

📌 What is Azure Bastion? · Choose the right Bastion SKU · JIT — Protect VMs with Defender for Servers

B. AKS — Isolation réseau de l'API server

L'API server est la cible critique. Trois niveaux de durcissement réseau (du plus fort au plus souple) :

Network plane (CNI + Network Policy) : pods communiquent sans restriction par défaut → définir des NetworkPolicy. Moteurs : Cilium (recommandé, eBPF, L7 + FQDN filtering), Azure NPM (iptables/HNS), Calico.

🚨 Pièges

• On ne peut pas convertir un cluster public existant en private cluster → recréation. Mais authorized IP ranges s'active sur un cluster existant.
• Authorized IP ranges incompatible avec un endpoint API privé (s'applique au public seulement).
• Private cluster → ACR doit être joignable via Private Link ou peering, sinon les pulls échouent.
• Private cluster ne supporte pas les agents DevOps hébergés Microsoft → self-hosted.

📌 Enhance network access security to Kubernetes · Authorized IP ranges · Network policies (Cilium/NPM/Calico)

C. AKS — Authentification & identité

🚨 Pièges

• Après --disable-local-accounts sur un cluster existant, rotater les certificats (certificate rotation) pour révoquer ce qui a fuité.
• Avec intégration Entra, les membres du groupe aad-admin-group-object-ids gardent l'accès non-admin même local désactivé.
• Workload Identity remplace l'ancien AAD Pod Identity (déprécié) → utiliser Workload ID + OIDC issuer.

📌 Access and identity options for AKS · Manage local accounts · Workload ID deploy

D. AKS / ACI / ACA — Secure & monitor (Defender for Containers)

Defender for Containers (plan Defender for Cloud) = posture + threat detection conteneurs. Composants AKS (intégration native, outbound-only) :

Monitoring sécurité ACI (Azure Container Instances)

ACI n'a pas de sensor runtime comme AKS (pas de DaemonSet, pas de threat detection Kubernetes). Le monitoring sécurité repose sur Defender for Cloud / Defender for Containers côté posture + sur les bonnes pratiques de déploiement :

• Vulnerability assessment : Defender for Containers évalue les images vulnérables (scan registry ACR, CVE via MDVM) et les containers en cours d'exécution (agentless — snapshots de disque toutes les 24 h, indépendant du registre source). Findings remontés en recommandations Defender for Cloud.
• Secrets : ne jamais mettre de secret en clair dans les env vars (visibles dans les propriétés portail/CLI). Utiliser secure values (secureValue → valeur masquée, lisible seulement depuis le conteneur), des secret volumes, ou des références Key Vault (passées en paramètres sécurisés ARM). Pull ACR via Managed Identity (pas d'admin creds).
• Isolation réseau : déployer le container group dans un subnet délégué d'un VNet → IP privée, pas d'IP publique exposée ; communication privée avec les ressources du VNet. ⚠️ Sortie obligatoirement via NAT gateway (seule config supportée pour l'outbound en VNet) ; les network profiles sont retirés (API ≥ 2021-07-01).
• Données ACI chiffrées at rest (AES-256, PMK ou CMK via Key Vault).

💡 ACI = surveillance posture only (recommandations sur images/config) : pas de détection comportementale runtime comme AKS.

Monitoring sécurité ACA (Azure Container Apps)

ACA s'appuie sur la plateforme Container Apps Environment pour le monitoring et l'identité :

• Log Analytics : l'environment est lié à un workspace Log Analytics → centralise les logs (Console / System / HTTP). Configurer les diagnostic settings pour streamer logs + métriques vers Log Analytics / Storage / Event Hub. Azure Monitor alerts sur authentifications échouées, trafic anormal, taux d'erreur.
• Ingress auth (Easy Auth / Entra) : activer l'authentication intégrée au niveau ingress (Entra ID, etc.) pour exiger l'identité avant d'atteindre l'app ; restrictions ingress / IP (allowlist) pour limiter les sources.
• Secrets ACA + référence Key Vault : définir des secrets au niveau app, soit en clair (stockés chiffrés), soit en référence Key Vault (keyvaultref:<URI>,identityref:<MI>). La référence KV exige une managed identity + le rôle Key Vault Secrets User sur le vault. 🚨 Sans MI ou sans le rôle → erreur Authentication failed / Access denied à la résolution du secret.
• Managed identity : user-assigned préférée (réutilisable, persiste indépendamment du cycle de vie de l'app ; la system-assigned n'existe qu'après création, donc inutilisable au create avec référence KV). Sert au pull ACR et à l'accès Key Vault.

🚨 Pièges (AKS / ACI / ACA)

• L'Azure Policy add-on (AKS) est requis pour les recommandations de configuration ; sans lui, pas d'audit posture Gatekeeper.
• Le scan registry couvre ACR ; le runtime VA des conteneurs en exécution dépend du scan agentless (disk snapshots), pas d'un agent.
• Security gating ≠ Azure Policy : gating bloque sur vulnérabilités d'image ; Policy/Gatekeeper bloque sur config.
• ACA : firewall Key Vault actif peut bloquer la résolution de la référence → autoriser les IP sortantes de l'environment ou un Private Endpoint sur le vault.

📌 Defender for Containers — vulnerability assessment · ACI — secure environment variables · ACA — manage secrets / Key Vault reference · ACA — logging & monitoring

📌 Enable Defender for Containers · Architecture Defender for Containers · Container security recommendations

E. ACR — Access & durcissement

🚨 Pièges

• Private Endpoint, Content Trust, geo-replication = Premium SKU uniquement.
• L'admin account est encore requis par certains déploiements portail (ACI/ACA directs) → préférer MI.
• Latence connue : AcrPull accordé à un groupe Entra + kubelet identity → délai RBAC ; contourner avec bring your own kubelet identity.

📌 Authenticate with ACR (admin/MI) · MI to ACR · AKS↔ACR integration

F. Disk encryption (VMs)

🚨 Pièges

• CMK nécessite Disk Encryption Set (SSE/EaH/Confidential) ou KEK (ADE) ; le DES doit avoir les permissions Key Vault (access policy/RBAC).
• ADE incompatible avec EaH ou SSE+CMK sur la même VM (ne pas mélanger).
• EaH doit être activé VM désallouée pour désactiver ; CMK ne change pas le type d'un DES (recréer).
• SSE seul laisse Defender en Unhealthy (recommandation EaH).

📌 Overview of managed disk encryption options · Azure VM security overview — disk encryption

G. Recommandations sécurité APIM

🚨 Pièges

• Subscription key seule = faible ; ne pas publier d'open products (sans subscription).
• Defense in depth : valider le token aussi au backend (le gateway peut changer, replay possible).
• Toujours hériter <base> dans les policies ; pas de wildcard * en CORS ; désactiver l'API tracing en prod (fuite de données).

📌 API & APIM security recommendations · WAF service guide — APIM Security · Mitigate OWASP API Top 10 with APIM

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

Scénario 1 : Banque — Admin VMs sans exposition internet

Contexte business : un audit interdit toute IP publique ou port RDP/SSH ouvert sur les VMs de prod, et exige l'enregistrement des sessions admin.

Choix architectural : accès distant via Bastion Premium en private-only (avec enregistrement) ; ports 3389/22 fermés par défaut (NSG) et ouverts à la demande via JIT.

Architecture / pattern :

• Bastion Premium private-only → connexion RDP/SSH dans le navigateur, sans IP publique, sessions enregistrées.
• NSG : inbound 3389/22 en deny par défaut.
• JIT (Defender for Servers) pour les rares accès directs hors Bastion → règle NSG temporaire, auto-révoquée.

Trade-offs assumés :

• Gain : plus aucune surface RDP/SSH exposée (Zero Trust), accès tracés, ports fermés sauf besoin.
• Perte : coût du SKU Premium ; Bastion devient un point de passage obligé ; le JIT ajoute une étape de demande d'accès.

Pièges à éviter :

• Oublier de retirer l'IP publique de la VM une fois Bastion en place.
• Le private-only et l'enregistrement nécessitent le SKU Premium (pas Standard).

📐 Réf. CAF/WAF — Network security best practices (Zero Trust) : Bastion pour l'accès distant sécurisé sans IP publique + JIT pour permissions temporaires. Lien

Scénario 2 : SaaS régulé — Cluster AKS durci multi-équipes

Contexte business : une plateforme de conteneurs partagée entre équipes exige une segmentation, une identité centralisée, aucun secret en clair, et de la détection à l'exécution.

Choix architectural : cluster privé + isolation du trafic pod-à-pod (NetworkPolicy), identité via Entra ID + RBAC Kubernetes (comptes locaux désactivés), accès aux secrets via Workload Identity, et Defender for Containers.

Architecture / pattern :

• API server non exposé (private cluster ou VNet Integration) ; NetworkPolicy Cilium entre pods.
• Entra ID + Azure RBAC for Kubernetes ; local accounts disabled (pas de kubeconfig partagé).
• Workload Identity → les pods lisent Key Vault sans secret embarqué.
• Defender for Containers : sensor runtime + Azure Policy/Gatekeeper + scan du registre.

Trade-offs assumés :

• Gain : API et trafic interne isolés, identité/audit centralisés, plus de secrets, détection de menaces.
• Perte : un cluster privé complique l'accès des outils CI/CD ; Gatekeeper et le tuning des NetworkPolicy demandent de l'expertise.

Pièges à éviter :

• Désactiver les comptes locaux sans avoir configuré l'accès Entra → plus personne ne peut administrer.
• Croire que RBAC Kubernetes suffit sans NetworkPolicy → le trafic pod-à-pod reste ouvert.

📐 Réf. CAF/WAF — Service guide AKS (Security) : Entra ID + Kubernetes RBAC, disable local accounts, private cluster/authorized IP, Defender for Containers, Workload ID. Lien

Scénario 3 : E-commerce — Chaîne d'approvisionnement d'images de confiance

Contexte business : seules des images scannées et signées doivent atteindre la prod ; le registre ACR ne doit pas être exposé et aucun identifiant admin ne doit être partagé.

Choix architectural : ACR Premium fermé (Private Endpoint, admin user désactivé), pulls via identité managée (AcrPull), et Defender for Containers qui bloque les images vulnérables à l'admission.

Architecture / pattern :

• ACR Premium + Private Endpoint ; admin user désactivé (imposé par Azure Policy).
• Content Trust pour garantir provenance et intégrité des images.
• Pulls via Managed Identity (AcrPull) → pas de credentials partagés.
• Defender for Containers : scan du registre + gating à l'admission (bloque les images à CVE).

Trade-offs assumés :

• Gain : registre non exposé, provenance garantie, déploiement d'images vulnérables empêché.
• Perte : Private Endpoint et Content Trust ajoutent de la config ; le gating peut bloquer un déploiement si une image n'est pas conforme.

Pièges à éviter :

• Désactiver l'admin user sans avoir configuré l'identité managée → les pulls échouent.
• Oublier le Private Endpoint et laisser l'accès public actif sur le registre.

📐 Réf. MCSB — Container security recommendations : registry scanning, vulnérabilités résolues, Azure Policy/Gatekeeper, admin local désactivé. Lien

DEMO — chemins portail

1. Déployer Azure Bastion et supprimer l'IP publique d'une VM

1. Virtual Network cible → créer le subnet AzureBastionSubnet (≥ /26).
2. Portail → Bastions → + Create → choisir SKU (Standard/Premium ; Premium pour private-only/recording) → VNet + IP publique (sauf private-only).
3. Sur la VM → Connect → Bastion → saisir identifiants (RDP/SSH via 443).
4. VM → Networking → IP configuration → dissocier/supprimer la Public IP une fois Bastion validé.

2. Activer le JIT VM access (Defender for Cloud)

1. Microsoft Defender for Cloud → Workload protections → Just-in-time VM access.
2. Onglet Not Configured → sélectionner la VM → Enable JIT → définir ports (22/3389), protocole, IP source autorisée, durée max.
3. Pour se connecter : VM → Connect → Request access (ou via l'écran JIT) → règle NSG temporaire créée, auto-révoquée à expiration.

3. Durcir un cluster AKS (Entra + local accounts disabled)

1. Kubernetes services → cluster → Settings → Authentication and authorization.
2. Activer Microsoft Entra ID authentication with Azure RBAC → définir les admin groups.
3. Cluster configuration → Local accounts → Disabled → Save (rotater les certificats ensuite).
4. Settings → Microsoft Defender for Cloud (ou Defender → Environment settings) → activer Defender for Containers (sensor, Azure Policy, registry access).

4. Désactiver l'admin user ACR + Private Endpoint

1. Container registries → registre → Settings → Access keys → Admin user = Disabled.
2. Settings → Networking → Public access = Disabled (Premium).
3. Networking → Private endpoint → + Add → VNet/subnet du cluster/consommateur → valider Private DNS privatelink.azurecr.io.

5. Activer Encryption at Host avec CMK

1. Key Vaults → créer KV (avec Purge protection) + une clé.
2. Disk Encryption Sets → + Create → Encryption at-rest with a customer-managed key → sélectionner KV + clé → après déploiement, accepter l'alerte pour accorder l'accès KV au DES.
3. Create VM → Disks → Encryption at host = activé → Key management = customer-managed key → choisir le DES.
4. (VM existante) la désallouer avant d'activer/désactiver Encryption at Host (VM → Disks → Additional settings).