09 · Implémenter la sécurité pour les services de plateforme d'applications

Version : 1.2 · Date : 2026-10-21 · Domaine 3 de l'examen : Calcul sécurisé (20 à 25 %)

En une phrase : on bloque les attaques web en bordure (WAF), on fait d'API Management le point de contrôle des API, on retire l'exposition publique des back-ends (Access restrictions, private endpoints, environnements internes), on remplace tous les secrets par des managed identities, et on surveille les conteneurs du registre jusqu'au pod avec Defender.

Ce que l'examen demande#

Intitulés officiels, en anglais, du guide d'étude SC-500 :

Les compléments de l'ancienne AZ-500 et de culture générale sont regroupés en 11.

Conseil de lecture : AKS est la plus grosse partie du chapitre (section 3), vue sous l'angle sécurité et examen. Pour l'architecture et le réseau AKS en profondeur, voir le parcours AKS voisin (dossier ..\AKS).

1. Les bases à maîtriser avant tout#

1.1 Quel service pour quel besoin ?#

1.2 Trois réflexes qui reviennent dans tout le chapitre#

1. Aucun secret dans le code ni dans la configuration : managed identity (voir chapitre 01) ou fédération des identités de charge de travail, et secrets restants dans Key Vault (chapitre 02).
2. Aucune exposition publique inutile : Access restrictions, private endpoints, environnements internes, puis un WAF devant ce qui doit rester public (chapitre 06 pour Private Link et Azure Firewall).
3. Gouverner à l'échelle : Azure Policy pour imposer les bons paramètres (chapitre 03), Defender for Cloud pour mesurer la posture et détecter les menaces (chapitre 10).

2. Defender for Containers#

2.1 Les cinq domaines couverts#

Defender for Containers est un plan de Defender for Cloud qui protège les clusters Kubernetes, les nœuds, les charges, les registres et les images, dans Azure, AWS, GCP et sur site.

2.2 Les composants à activer#

Dans Defender for Cloud > Environment settings > abonnement (ou connecteur AWS, GCP) > plan Containers > Settings :

Pour EKS et GKE, on connecte d'abord le compte AWS ou le projet GCP à Defender for Cloud ; les composants (Defender sensor, Azure Policy) s'y déploient comme extensions Azure Arc. Les clusters sur site passent par Kubernetes avec Azure Arc. La protection contre les menaces des journaux d'audit est sans agent (Agentless threat protection).

Piège : les alertes ne concernent que les actions et déploiements postérieurs à l'activation du plan.

2.3 Ce que détecte la protection à l'exécution#

• Plus de 60 analyses spécifiques à Kubernetes, IA et détection d'anomalies.
• Exemples : tableau de bord Kubernetes exposé, service LoadBalancer qui expose publiquement une charge, création de rôles à privilèges élevés, montages sensibles.
• Avec le Defender sensor : logiciels malveillants (détection, et blocage en option), dérive binaire (un processus qui ne vient pas de l'image : détection ou blocage selon des stratégies de dérive), activité DNS suspecte.

2.4 Le gated deployment#

Disponible en GA depuis novembre 2025. Un contrôleur d'admission évalue chaque image avant son entrée dans le cluster, à partir des résultats d'analyse du registre :

Bon réflexe : commencer en Audit, avec une portée étroite (un namespace), avant de passer en Deny (qui ajoute une à deux secondes au déploiement).

2.5 Répondre depuis Defender XDR#

Dans le portail Microsoft Defender, sur un pod compromis : Isolate, Restrict access (préversion) ou Terminate le pod, puis Release from isolation après l'enquête. Les actions sont tracées dans le Action center. La chasse se fait dans les tables CloudProcessEvents et CloudAuditEvents.

3. Azure Kubernetes Service (AKS)#

3.1 Le modèle : ce que Microsoft gère, ce que vous configurez#

• Chaque cluster a son plan de contrôle dédié, monolocataire, géré par Microsoft (API server, planificateur, etcd).
• Les nœuds sont des VM Azure dans un sous-réseau privé, sans IP publique. SSH est activé par défaut mais seulement depuis l'IP interne ; sa désactivation et la connexion SSH par Entra ID sont en préversion.
• L'autorisation de nœud (requêtes kubelet) est activée par défaut à partir de Kubernetes 1.24.
• Les disques des nœuds sont des disques managés chiffrés au repos par la plateforme.

AKS Automatic ou Standard : les deux modes partagent les mêmes concepts, mais AKS Automatic applique une base de référence renforcée par défaut :

Piège d'entretien : « les environnements Kubernetes ne sont pas sûrs pour une utilisation multilocataire hostile ». Le domaine de sécurité est le cluster, pas le nœud : pour des locataires hostiles, il faut des clusters séparés.

3.2 Les cinq scénarios d'identité#

A. Authentification Entra ID et local accounts#

• Le locataire Entra de l'authentification doit être celui de l'abonnement du cluster.
• Avec Entra ID, l'accès hérite de l'Conditional Access, de la MFA et de PIM. kubelogin sert aux connexions non interactives.
• Les local accounts utilisent un certificat d'administrateur du cluster qui contourne Entra ID : pas d'audit centralisé, pas Conditional Access. Même avec Entra, l'accès --admin reste une porte dérobée tant qu'ils sont actifs.

# Nouveau cluster : Entra ID, Azure RBAC for Kubernetes Authorization, sans local accounts
az aks create --resource-group rg-aks-prd --name aks-prd \
  --enable-aad --aad-admin-group-object-ids <id-groupe-admins> \
  --enable-azure-rbac --disable-local-accounts --generate-ssh-keys

# Cluster existant
az aks update --resource-group rg-aks-prd --name aks-prd --disable-local-accounts

Après avoir désactivé les local accounts sur un cluster existant, faire tourner les certificats du cluster pour révoquer ceux qui auraient été récupérés. À l'échelle, la stratégie intégrée Azure Kubernetes Service Clusters should have local authentication methods disabled audite ou refuse les clusters non conformes.

B. RBAC Kubernetes ou Azure RBAC for Kubernetes Authorization#

Les quatre rôles intégrés de données :

C. Le kubeconfig, une opération Azure#

Télécharger le kubeconfig (az aks get-credentials) est une opération ARM, contrôlée par Azure RBAC, distincte des droits dans l'API Kubernetes. Pour un pipeline : le rôle Azure Kubernetes Service Cluster User Role (récupère le kubeconfig, ne donne aucun droit dans l'API), puis un rôle de données au plus petit périmètre (par exemple RBAC Writer sur un namespace). Éviter les identifiants d'administrateur (Azure Kubernetes Service Cluster Admin Role).

D. Les managed identities du cluster#

• Par défaut, l'identité du plan de contrôle est affectée par le système. Préférer une identité affectée par l'utilisateur quand le VNet, les disques, la table de routage ou l'kubelet identity sont hors du groupe MC_ et qu'on ne déploie pas avec Azure CLI (attributions de rôles à faire soi-même).
• Une kubelet identity précréée doit être affectée par l'utilisateur ; si elle est hors du groupe MC_, l'identité du plan de contrôle a besoin du rôle Managed Identity Operator sur elle.
• Les service principals restent possibles mais sont déconseillés : leurs identifiants expirent par défaut au bout d'un an. Un cluster passé aux managed identities ne peut pas revenir à un service principal.

E. Microsoft Entra Workload ID#

Le cluster devient émetteur de jetons OIDC. Un pod reçoit un jeton de compte de service projeté qu'il échange contre un jeton Entra grâce à un federated credential posé sur une user-assigned managed identity (ou une inscription d'application). Entra vérifie la signature avec les clés publiques publiées par l'émetteur (/.well-known/openid-configuration, /openid/v1/jwks).

sequenceDiagram
    participant P as Pod étiqueté
    participant W as Webhook d'admission
    participant E as Microsoft Entra ID
    participant K as Key Vault
    W->>P: Injecte le jeton projeté et les variables AZURE_*
    P->>E: Jeton de compte de service (audience api://AzureADTokenExchange)
    E->>E: Vérifie issuer, subject, audience et la signature (JWKS)
    E-->>P: Jeton d'accès Entra
    P->>K: Lecture du secret avec le jeton Entra
    K-->>P: Secret (rôle Key Vault Secrets User)

# 1. Activer l'OIDC issuer et Workload ID
az aks update --resource-group rg-aks-prd --name aks-prd --enable-oidc-issuer --enable-workload-identity
ISSUER=$(az aks show --resource-group rg-aks-prd --name aks-prd --query oidcIssuerProfile.issuerUrl -o tsv)

# 2. Managed identity et federated credential lié au compte de service app/sa-app
az identity create --resource-group rg-aks-prd --name id-app-prd
az identity federated-credential create --name fic-sa-app --identity-name id-app-prd --resource-group rg-aks-prd \
  --issuer "$ISSUER" --subject system:serviceaccount:app:sa-app --audience api://AzureADTokenExchange

apiVersion: v1
kind: ServiceAccount
metadata:
  name: sa-app
  namespace: app
  annotations:
    azure.workload.identity/client-id: "<client-id-de-id-app-prd>"
---
# Dans le modèle de pod du Deployment :
#   metadata.labels: azure.workload.identity/use: "true"   (obligatoire, sinon le pod n'est pas muté)
#   spec.serviceAccountName: sa-app

Points d'examen et d'entretien :

• l'étiquette azure.workload.identity/use: "true" est obligatoire dans le modèle de pod ;
• lire le chemin du jeton dans AZURE_FEDERATED_TOKEN_FILE, ne jamais le coder en dur ; relire le fichier à chaque échange ;
• 20 federated credentials au plus par managed identity ; propagation de quelques secondes ;
• après un changement d'annotation du compte de service, redémarrer le pod ;
• demander des portées v2 de la forme <ressource>/.default ;
• la pod-managed identity (aad-pod-identity) est dépréciée : migrer vers Workload ID (un sidecar de migration existe, temporairement) ;
• non pris en charge sur les nœuds virtuels.

3.3 Protéger l'accès réseau à l'API server#

# Authorized IP ranges (la valeur remplace la liste : y remettre toutes les plages)
az aks update --resource-group rg-aks-prd --name aks-prd --api-server-authorized-ip-ranges 73.140.245.0/24,203.0.113.10/32

# Private cluster sans nom DNS public
az aks create --resource-group rg-aks-prd --name aks-prd --load-balancer-sku standard \
  --enable-private-cluster --private-dns-zone system --disable-public-fqdn \
  --assign-identity <id-ressource-identité> --generate-ssh-keys

Équivalent Terraform (arguments repris de l'exemple Microsoft Learn) :

resource "azurerm_kubernetes_cluster" "aks" {
  name                                = "aks-prd"
  location                            = azurerm_resource_group.aks.location
  resource_group_name                 = azurerm_resource_group.aks.name
  dns_prefix                          = "aksprd"
  private_cluster_enabled             = true
  private_cluster_public_fqdn_enabled = false # pas de nom DNS public
  private_dns_zone_id                 = "System"

  default_node_pool {
    name           = "system"
    node_count     = 3
    vm_size        = "Standard_DS2_v2"
    vnet_subnet_id = azurerm_subnet.aks.id
  }

  identity {
    type         = "UserAssigned"
    identity_ids = [azurerm_user_assigned_identity.aks.id]
  }

  network_profile {
    network_plugin    = "azure"
    load_balancer_sku = "standard"
  }
}

Options de la zone DNS privée (--private-dns-zone) : system (par défaut, zone créée dans le groupe des nœuds), none (pas de zone privée, nom public uniquement), ou l'ID d'une zone existante (identité affectée par l'utilisateur avec Private DNS Zone Contributor et Network Contributor). none et --disable-public-fqdn ensemble ne sont pas pris en charge. Sans connectivité réseau au private cluster, az aks command invoke exécute une commande à travers l'API Azure.

3.4 Le réseau des pods et la sortie#

Network policies : par défaut, tous les pods peuvent se parler. Les network policies Kubernetes restreignent ce trafic par namespace et étiquettes.

# Seuls les pods app: frontend peuvent joindre les pods app: backend
kind: NetworkPolicy
apiVersion: networking.k8s.io/v1
metadata:
  name: backend-policy
spec:
  podSelector:
    matchLabels:
      app: backend
  ingress:
  - from:
    - podSelector:
        matchLabels:
          app: frontend

NSG : AKS gère le NSG de la carte réseau des nœuds ; ne pas le modifier. Ajouter des NSG au niveau du sous-réseau, sans bloquer le trafic de gestion (équilibreur, plan de contrôle, sortie).

CNI : kubenet n'est plus pris en charge à partir du 31/03/2028 ; migrer vers Azure CNI Overlay.

Sortie contrôlée par Azure Firewall :

• type de sortie userDefinedRouting : aucune IP publique d'équilibreur n'est créée pour la sortie, tout passe par la route ;
• table de routage sur le sous-réseau AKS : 0.0.0.0/0 → appliance virtuelle (IP privée du pare-feu) ;
• règle d'application avec la balise FQDN AzureKubernetesService (FQDN requis, mise à jour automatique), plus les règles réseau nécessaires ;
• prévoir au moins une vingtaine d'IP frontales sur le pare-feu en production (épuisement SNAT) ;
• avec des authorized IP ranges, ajouter l'IP publique du pare-feu dans la liste.

az aks create --resource-group rg-aks-prd --name aks-prd --network-plugin azure \
  --outbound-type userDefinedRouting --vnet-subnet-id "$SUBNET_ID" \
  --api-server-authorized-ip-ranges "$FW_PUBLIC_IP" --generate-ssh-keys

3.5 Gouverner les charges de travail#

Une requête passe par trois étapes avant d'être écrite dans etcd :

flowchart LR
    A["kubectl apply"] --> B["Authentification<br/>Entra ID"]
    B --> C["Autorisation<br/>Azure RBAC ou RBAC K8s"]
    C --> D["Admission<br/>Pod Security Admission"]
    D --> E["Admission<br/>Azure Policy / Gatekeeper"]
    E --> F["Admission<br/>gated deployment Defender"]
    F --> G["Objet enregistré<br/>dans etcd"]

# PSA : bloquer et avertir en restricted sur un namespace
kubectl label --overwrite ns app pod-security.kubernetes.io/enforce=restricted pod-security.kubernetes.io/warn=restricted

# Azure Policy pour Kubernetes
az aks enable-addons --resource-group rg-aks-prd --name aks-prd --addons azure-policy

Le modul'Azure Policy installé, une stratégie de l'initiative baseline en effet deny refuse par exemple un pod avec securityContext.privileged: true. Les installations de Gatekeeper hors module ne sont pas prises en charge. Côté conteneur : pas de root ni d'escalade de privilèges, profils AppArmor et seccomp.

3.6 Nœuds, versions et mises à niveau#

az aks update --resource-group rg-aks-prd --name aks-prd --auto-upgrade-channel stable --node-os-upgrade-channel SecurityPatch
az aks update --resource-group rg-aks-prd --name aks-prd --enable-image-cleaner --image-cleaner-interval-hours 48

Pièges : le canal SecurityPatch n'existe pas pour Windows, et il échoue avec une stratégie Azure Policy en deny qui exige une CMK sur les disques OS (AKS crée temporairement un Virtual Machine Scale Set copy-…). Azure Linux 2.0 n'a plus de correctifs depuis le 30/11/2025 et ses images disparaissent le 31/10/2026 : migrer vers Azure Linux 3.

3.7 Les secrets du cluster#

Rappels : un Secret Kubernetes n'est qu'encodé en base64 (jamais dans le contrôle de code source) ; il est stocké sur le nœud en tmpfs et seulement là où un pod en a besoin ; il est limité à son namespace.

az aks addon update --resource-group rg-aks-prd --name aks-prd --addon azure-keyvault-secrets-provider \
  --enable-secret-rotation --rotation-poll-interval 5m

3.8 Isoler davantage#

Pour des exigences de conformité : tailles de VM isolées (dédiées à un client), conteneurs confidentiels (préversion, mémoire chiffrée par le matériel AMD SEV-SNP) et Pod Sandboxing (préversion, frontière d'isolation entre le conteneur et le noyau de l'hôte).

4. Azure Container Registry (ACR)#

4.1 S'authentifier#

az acr update --name acrprd --admin-enabled false

4.2 Autoriser : mode RBAC ou mode ABAC#

Le paramètre Mode d'autorisation des attributions de rôles change les rôles reconnus :

az acr update --name acrprd --resource-group rg-acr --role-assignment-mode 'rbac-abac'

Pièges : en mode ABAC, AcrPull, AcrPush et AcrDelete sont ignorés, et az aks --attach-acr ne fonctionne plus (il faut attribuer Container Registry Repository Reader à l'kubelet identity). Le basculement invalide les identifiants déjà émis (erreurs 401 jusqu'au rafraîchissement des clients).

4.3 Réseau#

4.4 Protéger le contenu#

• Chiffrement : au repos par défaut ; customer-managed key en Premium, uniquement à la création, impossible à désactiver ensuite, avec une identité affectée par l'utilisateur, clés RSA seulement.
• Signature : Docker Content Trust est en dépréciation depuis le 31/03/2025, ne peut plus être activé sur un nouveau registre depuis le 31/05/2026 et disparaît le 31/03/2028. On signe avec Notation (Notary Project), clé et certificat dans Key Vault, en signant le digest (les étiquettes sont modifiables) ; vérification dans le pipeline ou dans AKS (Ratify + Azure Policy).
• Verrou d'image : deleteEnabled et writeEnabled à false sur les étiquettes de production.
• Analyse : Defender for Containers analyse les images poussées (voir 2).

4.5 Intégrer ACR à AKS#

# Mode RBAC : attribue AcrPull à l'kubelet identity
az aks update --resource-group rg-aks-prd --name aks-prd --attach-acr <id-ressource-acr>
# Diagnostic DNS, routage et authentification entre le cluster et le registre
az aks check-acr --resource-group rg-aks-prd --name aks-prd --acr acrprd.azurecr.io

Un private cluster avec un registre doit avoir un private endpoint du registre dans son VNet (ou un peering vers celui du registre).

5. Container Instances et Container Apps#

5.1 Azure Container Instances (ACI)#

5.2 Azure Container Apps#

Environnement : il porte le réseau. Un environnement interne n'a aucun point de terminaison public ; ce choix se fait à la création et ne peut pas être changé.

az containerapp env create --name cae-prd --resource-group rg-app --infrastructure-subnet-resource-id <id-sous-réseau> \
  --internal-only true

Autres contrôles :

• Ingress : allowInsecure à false par défaut (HTTP redirigé vers HTTPS), restrictions d'IP (autoriser ou refuser), certificats clients (clientCertificateMode : Require, Accept, Ignore par défaut) ;
• chiffrement pair à pair au niveau de l'environnement pour le trafic entre apps ;
• built-in authentication (Easy Auth), le même système qu'App Service ;
• managed identities (système ou utilisateur) et tirage d'image par managed identity (rôle de tirage sur ACR) ;
• private endpoint, désactivation de l'accès public, UDR vers Azure Firewall et NSG pour la sortie.

Secrets : stockés au niveau de l'app, exposés en variables d'environnement (secretref:) ou en volumes. En production, les référencer depuis Key Vault : managed identity avec Key Vault Secrets User.

az containerapp create --resource-group rg-app --name queuereader --environment cae-prd --image <image> \
  --user-assigned "<id-identité>" \
  --secrets "queue-cs=keyvaultref:<uri-secret>,identityref:<id-identité>"

Pièges : avec create, il faut une identité affectée par l'utilisateur (l'identité système n'existe pas encore). Modifier ou supprimer un secret n'affecte pas les révisions existantes : créer une nouvelle révision ou redémarrer. Plusieurs rôles intégrés contiennent l'action listSecrets, qui renvoie les valeurs en clair : vérifier un rôle avant de l'attribuer.

6. Azure Functions#

6.1 Clés d'accès et authorization levels#

• Authorization levels d'un déclencheur HTTP : anonymous (aucune clé), function, admin. Sans valeur explicite : function (sauf modèle Node.js v4 : anonymous).
• La clé passe dans ?code= ou l'en-tête x-functions-key. Une clé de fonction l'emporte sur une clé d'hôte de même nom.
• Une clé n'est pas une authentification : Microsoft rappelle que la seule vraie protection est d'authentifier le client (Entra ID) et d'isoler l'application dans un réseau.
• Désactiver les points de terminaison /admin : propriété de site functionsRuntimeAdminIsolationEnabled à true.
• Stocker les clés dans Key Vault : AzureWebJobsSecretStorageKeyVaultUri, un coffre par app (sinon collisions).
• Faire tourner une clé quand elle a fuité : supprimer et recréer une fonction ne change pas ses clés.

6.2 Authentification et identités#

• Authentification App Service (Easy Auth) : Entra ID vérifie l'appelant avant le code.
• Connexions basées sur l'identité au lieu des chaînes de connexion, y compris pour le stockage de l'hôte :

AzureWebJobsStorage__accountName = ststorageprd
AzureWebJobsStorage__credential  = managedidentity
AzureWebJobsStorage__clientId    = <client-id de l'identité affectée par l'utilisateur>

• Key Vault references dans les paramètres d'application (fonctionnent avec un coffre restreint au réseau si l'app est intégrée au VNet).

6.3 Réseau#

Avec un private endpoint, tester depuis le VNet ; pour le portail, ajouter la balise de service AzureCloud aux règles autorisées. Le storage account de l'app peut lui-même être restreint au VNet (private endpoints ou service endpoints).

7. Azure Logic Apps#

7.1 Consumption ou Standard#

L'environnement de service d'intégration (ISE) est retiré depuis le 31 août 2024 : Logic Apps Standard le remplace.

7.2 Protéger le déclencheur Request#

1. SAS (par défaut) : l'URL contient une signature (sp, sv, sig). Régénérer les clés d'accès, créer des URL de rappel qui expirent. En Consumption, on peut désactiver la SAS :

"properties": {
  "accessControl": {
    "triggers": {
      "sasAuthenticationPolicy": { "state": "Disabled" }
    }
  }
}

2. OAuth 2.0 avec Entra ID (Consumption) : une authorization policy de type AAD liste au moins les revendications iss (commence par https://sts.windows.net/ ou https://login.microsoftonline.com/) et aud. Jetons Bearer ou PoP. Un seul schéma par appel : SAS et OAuth ensemble provoquent une erreur.
3. Restreindre les IP entrantes, par exemple aux seules IP d'API Management, qui expose le workflow avec ses propres contrôles (OAuth, certificat client).

7.3 Protéger l'historique et les paramètres#

• Restreindre par plage IP l'accès aux entrées et sorties de l'historique ; 0.0.0.0-0.0.0.0 bloque tout le monde (seul un administrateur peut lever la restriction : accès « juste-à-temps » aux données).
• Secure inputs et Secure outputs (obfuscation) sur les actions qui manipulent des secrets :

"runtimeConfiguration": {
  "secureData": { "properties": [ "inputs", "outputs" ] }
}

• Paramètres de déploiement en securestring ou secureobject : ils ne sont pas renvoyés avec la définition.
• Les en-têtes Authorization ne sont pas visibles dans les entrées et sorties.

7.4 Appels sortants#

Préférer la managed identity (connecteurs intégrés HTTP, Blob, Service Bus, Key Vault…) à la basic authentication, au certificat ou au secret OAuth. Le paramètre Audience doit correspondre exactement à l'ID de ressource attendu par Entra (par défaut https://management.azure.com/, pour Key Vault https://vault.azure.net), sinon erreur 400 ou 401.

8. Azure App Service#

8.1 Les paramètres de base#

az webapp update --resource-group rg-web --name app-web-prd --https-only true
az webapp config set --resource-group rg-web --name app-web-prd --min-tls-version 1.2
# Désactiver la basic authentication FTP et SCM
az resource update --resource-group rg-web --name ftp --namespace Microsoft.Web \
  --resource-type basicPublishingCredentialsPolicies --parent sites/app-web-prd --set properties.allow=false
az resource update --resource-group rg-web --name scm --namespace Microsoft.Web \
  --resource-type basicPublishingCredentialsPolicies --parent sites/app-web-prd --set properties.allow=false

8.2 Les Access restrictions#

• Un pare-feu entrant : liste de règles autoriser / refuser évaluées par priorité (le plus petit nombre d'abord).
• Types de règles : IPv4/IPv6, réseau virtuel (service endpoints Microsoft.Web), balise de service (par exemple AzureFrontDoor.Backend), filtres d'en-têtes HTTP (X-Forwarded-For, X-Forwarded-Host, X-Azure-FDID, X-FD-HealthProbe), règles multisources (8 plages au plus), 512 règles au plus.
• Règle non correspondante : sans règle, tout est autorisé ; dès qu'une règle existe, refus implicite final (sauf si on configure explicitement l'action par défaut).
• Le site SCM (outils avancés, déploiement) a ses propres règles, ou réutilise celles du site principal (Use main site rules).
• Le trafic qui arrive par un private endpoint n'est pas soumis aux Access restrictions (on le filtre par NSG).

az webapp config access-restriction add --resource-group rg-web --name app-web-prd \
  --rule-name 'Admins' --action Allow --ip-address 122.133.144.0/24 --priority 100 --scm-site true

Front Door seul : règle de balise de service AzureFrontDoor.Backend et filtre d'en-tête X-Azure-FDID avec l'ID de votre instance (la balise seule laisserait passer n'importe quelle instance Front Door).

8.3 Réseau, isolation et détection#

• Entrée privée : private endpoint avec accès public désactivé, ou App Service Environment v3 interne (ILB).
• Sortie : intégration VNet (mêmes principes que Functions).
• App Service Environment v3 : calcul isolé et dédié dans votre VNet (niveaux Isolated v2 et v4), entrée par équilibreur interne (ILB) souvent derrière un Application Gateway WAF ; les ASE v1 et v2 sont retirés depuis le 31/08/2024.
• Defender for App Service : tous les niveaux de plan, facturé par instance ; détecte scanners, IP malveillantes, commandes suspectes, et les entrées DNS pendantes au décommissionnement d'un site (risque de prise de contrôle de sous-domaine). Autre protection : l'enregistrement TXT asuid.<sous-domaine> de vérification de domaine.

9. Azure Web Application Firewall (WAF)#

9.1 Où le déployer#

Le WAF existe aussi sur Application Gateway for Containers (entrée des clusters AKS) et sur Azure CDN ; ce dernier est une préversion qui n'accepte plus de nouveaux clients (Microsoft oriente vers le WAF sur Front Door). Sur Front Door Standard, seules les custom rules sont disponibles.

Calendrier : la configuration WAF (ancien mode) d'Application Gateway v2 est retirée le 15/03/2027 (passer aux stratégies WAF, que seul WAF_v2 accepte) ; Front Door (classic) est retiré le 31/03/2027 et Azure CDN Standard from Microsoft (classic) le 30/09/2027 : migrer vers Front Door Standard ou Premium.

9.2 Modes, rule sets et anomaly score#

• Detection : journalise sans bloquer. Prevention : bloque (réponse 403) et journalise. Les ensembles managés sont activés en Detection par défaut ; démarrer ainsi, analyser les journaux, ajouter des exclusions, puis passer en Prevention.
• DRS 2.2 (OWASP CRS 3.3.4 + Microsoft Threat Intelligence) est recommandé pour les nouveaux déploiements.
• Anomaly score : chaque règle correspondante ajoute selon sa gravité ; 5 ou plus déclenche le blocage (en Prevention).

• Niveaux de paranoïa : DRS 2.2 en PL1 par défaut (règles PL2 désactivées) ; PL3 et PL4 non pris en charge.

flowchart TD
    A["Requête HTTP"] --> B{"Custom rules<br/>par priorité"}
    B -- "Bloquer" --> X["403, journalisé"]
    B -- "Autoriser" --> OK["Back-end"]
    B -- "Aucune correspondance" --> C["Règles managées DRS<br/>somme des scores"]
    C --> D{"Score supérieur ou égal à 5 ?"}
    D -- "Non" --> OK
    D -- "Oui, mode Detection" --> L["Journalisé, transmis"] --> OK
    D -- "Oui, mode Prevention" --> X

9.3 Custom rules et protections avancées#

• Les custom rules passent avant les règles managées ; une correspondance applique l'action et arrête l'évaluation.
• Conditions : listes d'IP, géofiltrage (inclure le code inconnu ZZ), paramètres HTTP, méthode, taille.
• Rate limiting : par IP de socket (Front Door), seuil sur 1 ou 5 minutes, combinable avec d'autres conditions.
• Bot Manager : bons, mauvais et bots inconnus avec une action par catégorie.
• Gestion centralisée des stratégies avec Azure Firewall Manager.

10. Protéger les API back-end avec API Management#

10.1 Le principe#

La passerelle applique des stratégies XML par portée (globale, produit, API, opération) dans quatre sections : inbound, backend, outbound, on-error. Elle devient le point de contrôle unique : les back-ends n'acceptent que l'APIM (IP, réseau privé, jeton de la managed identity de l'APIM).

Piège : une subscription key identifie un consommateur et sert aux quotas ; ce n'est pas une authentification forte.

10.2 Authentifier l'appelant#

<inbound>
    <base />
    <!-- 1. Filtrer les appelants -->
    <ip-filter action="allow">
        <address-range from="10.10.0.0" to="10.10.255.255" />
    </ip-filter>
    <!-- 2. Jeton Entra obligatoire, application cliente connue -->
    <validate-azure-ad-token tenant-id="{{aad-tenant-id}}">
        <client-application-ids>
            <application-id>{{aad-client-application-id}}</application-id>
        </client-application-ids>
    </validate-azure-ad-token>
    <!-- 3. 10 appels par minute par adresse IP -->
    <rate-limit-by-key calls="10" renewal-period="60" counter-key="@(context.Request.IpAddress)" />
    <!-- 4. L'APIM s'authentifie auprès du back-end avec son managed identity -->
    <authentication-managed-identity resource="api://<id-application-du-back-end>" />
</inbound>

Pour recevoir les certificats clients : Negotiate client certificate sur le nom d'hôte (Developer, Basic, Standard, Premium) ou Request client certificate (Consumption et niveaux v2, où la renégociation TLS n'existe pas).

10.3 S'authentifier auprès du back-end#

• authentication-managed-identity : recommandé, aucun secret.
• authentication-certificate : mTLS vers le back-end ; certificat dans Key Vault (rotation reprise sous 4 heures), référencé par certificate-id et non par empreinte (l'empreinte change à la rotation).
• Valeurs sensibles en named values adossées à Key Vault.

10.4 Limiter le débit et les volumes#

Les compteurs de rate limiting sont par passerelle régionale ; les quotas sont globaux à l'instance.

10.5 Réseau#

La connectivité de service approuvé de la passerelle vers Stockage, Key Vault, Service Bus, Event Hubs et ACR est retirée depuis le 15/03/2026 : utiliser d'autres options réseau.

10.6 Defender for APIs#

Plan de Defender for Cloud pour les API publiées dans API Management : inventaire, API externes, inutilisées ou non authentifiées, classification des données sensibles, recommandations, détection des menaces à l'exécution (OWASP API Top 10), intégration SIEM et Defender CSPM. Limites : API REST seulement ; pas les passerelles auto-hébergées ni les workspaces.

11. Compléments AZ-500 et culture#

• Front Door Premium + Private Link : l'origine (App Service, stockage, équilibreur interne…) n'est plus exposée sur Internet.
• App Service Environment v3 : voir 8.3 ; isolation complète, ILB, forçage de TLS 1.2 sur toutes les apps.
• Azure Spring Apps : en période de retrait depuis le 17/03/2025, retiré le 31/03/2028 ; migrer vers Container Apps ou AKS.
• Grille de lecture « 4C » (Cloud, Cluster, Conteneur, Code), issue de la communauté Kubernetes : chaque couche protège la suivante. Cloud = abonnement, réseau, identité (chapitres 01, 03, 06) ; Cluster = section 3 ; Conteneur = images, ACR, Defender ; Code = pipeline sécurisé, dépendances, secrets hors du code.
• Chaîne d'approvisionnement des conteneurs : Microsoft décrit le cadre Containers Secure Supply Chain (CSSC) que Defender pour les conteneurs met en œuvre (analyse en CI avec le CLI Defender for Cloud, résultats signés, gated deployment).

12. Labs conseillés#

À faire dans un abonnement de test (un petit cluster AKS de 1 à 2 nœuds, niveau Free, supprimé à la fin ; l'essai de Defender pour les conteneurs suffit).

Lab 1 : AKS avec Entra ID, sans local accounts.

1. Créer le cluster avec --enable-aad --enable-azure-rbac --disable-local-accounts (3.2).
2. Vous attribuer Azure Kubernetes Service RBAC Reader sur un namespace, puis tenter kubectl get secrets.
3. Tenter az aks get-credentials --admin.
4. Résultat attendu : lecture des pods possible, Secrets refusés ; --admin refusé car les local accounts sont désactivés.

Lab 2 : Workload ID vers Key Vault.

1. Activer l'OIDC issuer et Workload ID, créer une managed identity avec Key Vault Secrets User sur un coffre de test et l'federated credential du compte de service (3.2 E).
2. Déployer un pod azure-cli avec le compte de service annoté et l'étiquette azure.workload.identity/use: "true".
3. Dans le pod : az login --federated-token "$(cat $AZURE_FEDERATED_TOKEN_FILE)" --service-principal -u $AZURE_CLIENT_ID -t $AZURE_TENANT_ID, puis lire le secret.
4. Résultat attendu : le secret est lu sans aucun mot de passe ; retirer l'étiquette du pod et constater l'échec.

Lab 3 : admission et Defender for Containers.

1. Étiqueter un namespace en PSA enforce=restricted, puis déployer un pod privileged: true.
2. Activer le module Azure Policy et l'initiative pod security baseline en deny sur le cluster.
3. Activer Defender for Containers (Defender sensor, Registry access), pousser une image ancienne dans ACR.
4. Résultat attendu : le pod privilégié est refusé ; les vulnérabilités de l'image apparaissent dans les recommandations.

Lab 4 : App Service derrière Front Door, avec Easy Auth.

1. Créer une app web, activer HTTPS Only, TLS 1.2 et désactiver la basic authentication FTP et SCM.
2. Activer l'authentification Entra ID et vérifier la redirection vers la connexion.
3. Ajouter un Front Door Standard, puis les Access restrictions AzureFrontDoor.Backend + X-Azure-FDID.
4. Résultat attendu : l'appel direct à *.azurewebsites.net renvoie 403, l'appel par Front Door passe.

Lab 5 : APIM devant une Function.

1. Créer une Function HTTP (niveau function) et une instance APIM Developer ; importer la Function dans APIM.
2. Ajouter validate-azure-ad-token, rate-limit-by-key (5 appels par minute) et ip-filter dans inbound.
3. Appeler sans jeton, puis avec un jeton, puis en boucle.
4. Résultat attendu : 401 sans jeton, 200 avec jeton, 429 au-delà de la limite.

13. Les pièges d'examen#

14. Scénarios d'entraînement#

1. Contoso veut qu'aucune image contenant une vulnérabilité critique ne puisse être déployée sur ses clusters AKS de production, tout en commençant sans casser les déploiements. Que configurer ?

Defender for Containers avec le Defender sensor (Security Gating), le Registry access et Security findings, l'émetteur OIDC sur les clusters ; une règle de gated deployment d'abord en Audit sur un namespace, puis en Deny sur le périmètre de production, avec des exemptions documentées. Droits : Security Admin.

2. Une équipe se connecte à AKS avec az aks get-credentials --admin. Le RSSI exige que tout accès passe par Entra ID avec MFA et PIM. Que faire ?

Activer l'intégration Entra et Azure RBAC for Kubernetes Authorization, attribuer les rôles RBAC Reader/Writer/Admin par espace de noms via des groupes gérés dans PIM, puis désactiver les local accounts et faire tourner les certificats du cluster. Assigner la stratégie « méthodes d'authentification locales désactivées » à l'échelle.

3. Une API dans AKS doit lire une chaîne de connexion dans Key Vault. Le développeur propose un Secret Kubernetes créé à la main. Meilleure solution ?

Workload ID : user-assigned managed identity avec Key Vault Secrets User, federated credential (issuer du cluster, subject system:serviceaccount:<ns>:<sa>, audience api://AzureADTokenExchange), compte de service annoté et pod étiqueté. Ou le pilote CSI Secrets Store avec cette même identité pour monter le secret et sa rotation.

4. Le cluster doit être privé, administré depuis le réseau de l'entreprise, et sa sortie Internet limitée aux FQDN nécessaires. Architecture ?

Private cluster (private endpoint + zone DNS privée, --disable-public-fqdn), administration par VPN ou ExpressRoute et agents auto-hébergés ; sous-réseau AKS avec une UDR 0.0.0.0/0 vers le Azure Firewall et --outbound-type userDefinedRouting ; règle d'application avec la balise FQDN AzureKubernetesService.

5. Après le passage du registre en mode « RBAC Registry + ABAC Repository Permissions », les pods passent en ImagePullBackOff. Pourquoi et que faire ?

En mode ABAC, AcrPull (attribué par --attach-acr) n'est plus reconnu, et les anciens identifiants sont invalidés. Attribuer Container Registry Repository Reader (éventuellement limité au dépôt par condition ABAC) à l'kubelet identity, puis laisser les nœuds rafraîchir leurs identifiants.

6. Le registre ne doit être joignable que depuis le VNet de production, avec des images signées. Que mettre en place ?

Niveau Premium, private endpoint (zone privatelink.azurecr.io, points de données dédiés automatiques), accès public désactivé, admin user désactivé, signature avec Notation et un certificat dans Key Vault, vérification au déploiement ; Defender pour l'analyse continue.

7. Une API sur Container Apps ne doit jamais être exposée sur Internet mais doit être appelable depuis des VM du VNet et le site local par VPN. Configuration ?

Environnement interne (--internal-only true, décidé à la création) et ingress de l'app sur « depuis n'importe où », ce qui la publie sur l'équilibreur interne de l'environnement. « Limité à l'environnement » la cacherait aussi au VNet (404).

8. Une Function HTTP en plan Consumption utilise une clé d'hôte partagée avec trois partenaires, et une chaîne de connexion de stockage dans ses paramètres. Comment l'améliorer ?

Built-in authentication (Easy Auth) avec Entra ID (une application cliente par partenaire), function keys distinctes si des clés restent nécessaires, jamais la clé maître ; connexions par identité (AzureWebJobsStorage__accountName, __credential=managedidentity) ; pour un private endpoint, passer en Flex Consumption ou Elastic Premium.

9. Une Logic App Consumption est déclenchée par une URL SAS qui circule dans des e-mails. Le RSSI veut une authentification par jeton et que les mots de passe manipulés n'apparaissent pas dans l'historique. Que faire ?

Ajouter une stratégie d'autorisation Entra (revendications iss et aud), désactiver la SAS (sasAuthenticationPolicy: Disabled), régénérer les clés d'accès ; activer les Secure inputs / Secure outputs sur les actions sensibles et restreindre par IP l'accès au contenu de l'historique.

10. Une application App Service est derrière Front Door Premium. Des requêtes arrivent directement sur *.azurewebsites.net. Comment l'empêcher ?

Idéalement Private Link de Front Door Premium vers l'origine et accès public désactivé. Sinon, Access restrictions : balise de service AzureFrontDoor.Backend avec filtre d'en-tête X-Azure-FDID égal à l'ID de l'instance ; règles aussi sur le site SCM ; HTTPS Only et TLS 1.2.

11. Après l'activation du WAF d'Application Gateway en Prevention, les formulaires de connexion renvoient des 403. Démarche ?

Repasser en Detection, lire les journaux du pare-feu (règles déclenchées, souvent le blocage par anomaly score), ajouter des exclusions ciblées (par exemple un cookie ou un en-tête de jeton) ou une stratégie par URI pour le chemin concerné, puis revenir en Prevention.

12. Des API exposées par APIM appellent un back-end App Service protégé par Entra ID. On veut : jeton Entra obligatoire pour les clients, 100 appels par minute par utilisateur, et aucun secret entre l'APIM et le back-end.

Dans inbound : validate-azure-ad-token (locataire, applications clientes), rate-limit-by-key avec la revendication sub du JWT comme clé, puis authentication-managed-identity avec l'ID d'application du back-end comme ressource. Côté back-end : Easy Auth qui n'accepte que l'audience attendue, et restriction d'accès aux IP (ou au réseau privé) de l'APIM. Activer Defender for APIs.

15. Pour aller plus loin#

• AKS en profondeur (architecture, réseau, exploitation, IA) : parcours AKS voisin (dossier ..\AKS).
• Fédération d'identités à grande échelle : les identity bindings d'AKS permettent à plusieurs clusters de partager une identité managée via un seul federated credential.
• Ratify + Azure Policy pour vérifier les signatures Notation à l'admission dans AKS.
• Défense L7 et L3-L4 combinées : Front Door WAF devant, DDoS Protection sur le VNet d'origine (chapitre 06).
• AI gateway : les mêmes stratégies APIM, plus llm-token-limit et la sécurité du contenu (chapitre 07).
• Supervision : envoyer les journaux d'audit Kubernetes, du WAF et de l'APIM vers Microsoft Sentinel (chapitre 11).

16. Fiche à retenir#

• Defender for Containers : posture, vulnérabilités (signées), exécution (MITRE, Defender XDR), chaîne d'approvisionnement, déploiement du Defender sensor.
• Gated deployment : Audit / Deny, règle par défaut en audit (élevé, critique), Defender sensor + Security Gating, Registry access + Security findings, OIDC, K8s 1.31+.
• Defender XDR : Isolate, Restrict access, Terminate un pod ; isolement = moteur de network policies, K8s 1.27+.
• AKS : Entra ID + Azure RBAC for Kubernetes Authorization, local accounts désactivés (puis rotation des certificats).
• Rôles : RBAC Reader (pas de Secrets) · Writer (escalade possible) · Admin (namespace) · Cluster Admin ; kubeconfig = Cluster User Role.
• Identités : plan de contrôle (Contributor sur MC_), kubelet (AcrPull), modules ; service principal déconseillé.
• Workload ID : OIDC issuer, federated credential, use: "true", AZURE_FEDERATED_TOKEN_FILE, 20 identifiants au plus ; pod identity dépréciée.
• API server : authorized IP ranges (public seulement) ou private cluster (Private Link, DNS privé, agents auto-hébergés).
• Network policies : Cilium recommandé ; Azure NPM fin 30/09/2028 (Linux) ; ne pas toucher au NSG de la carte gérée.
• Sortie : userDefinedRouting + UDR vers le pare-feu + balise FQDN AzureKubernetesService.
• Admission : PSA (enforce, warn ; privileged, baseline, restricted) · Azure Policy (Gatekeeper, initiatives, deny) · Deployment Safeguards.
• Mises à niveau : N-2, LTS en Premium, canal cluster stable, canal OS SecurityPatch ou NodeImage, fenêtre ≥ 4 h, Image Cleaner.
• Secrets : KMS pour etcd, CSI Secrets Store (rotation 2 min par défaut).
• ACR : admin désactivé ; AcrPull/AcrPush (RBAC) ou Repository Reader/Writer (ABAC) ; Premium pour point privé, IP, CMK (à la création) ; Notation (DCT retiré le 31/03/2028).
• ACI : VNet + passerelle NAT, managed identity, conteneurs confidentiels (SEV-SNP, attestation).
• Container Apps : environnement interne (définitif), restrictions d'IP, mTLS, Easy Auth, références Key Vault (Key Vault Secrets User).
• Functions : clés fonction / hôte / maître (admin) / système ; une clé ≠ authentification ; functionsRuntimeAdminIsolationEnabled ; connexions par identité ; point privé hors Consumption.
• Logic Apps : SAS ou OAuth Entra (iss, aud), désactivation de la SAS, restriction d'IP, secureData, managed identity ; ISE retiré.
• App Service : HTTPS seul (à activer), TLS 1.2, basic auth FTP/SCM désactivée, Access restrictions (SCM séparé, refus implicite, pas sur le point privé), X-Azure-FDID.
• Defender for App Service : DNS pendants ; ASE v3 = isolation et ILB.
• WAF : App Gateway WAF_v2 (global, site, URI) ou Front Door (Premium pour DRS et bots) ; Detection → Prevention ; score ≥ 5 ; custom rules d'abord.
• APIM : validate-azure-ad-token / validate-jwt / validate-client-certificate, rate-limit-by-key (429), quota-by-key (403), ip-filter, authentication-managed-identity, named values Key Vault, Defender for APIs.

Références#

Toutes lues le 21/10/2026 sur Microsoft Learn :

• Guide d'étude de l'examen SC-500
• Présentation de Microsoft Defender for Containers
• Activer Defender for Containers
• Gated deployment pour les images de conteneur Kubernetes
• Configurer les règles de gated deployment
• Enquêter sur les menaces de conteneur dans le portail Microsoft Defender
• Concepts de sécurité pour les applications et les clusters AKS
• Options d'accès et d'identité pour AKS
• Concepts d'authentification de cluster AKS
• Concepts d'autorisation de cluster AKS
• Utiliser l'autorisation Microsoft Entra ID pour l'API Kubernetes
• Gérer les local accounts
• Managed identities dans AKS
• Workload ID Microsoft Entra avec AKS
• Créer un cluster AKS privé
• Plages d'adresses IP autorisées de l'API server
• Sécuriser le trafic entre pods avec des stratégies réseau
• Limiter le trafic réseau avec Azure Firewall dans AKS
• Utiliser Pod Security Admission dans AKS
• Comprendre Azure Policy pour les clusters Kubernetes
• Deployment Safeguards dans AKS
• Mise à niveau automatique des images OS des nœuds
• Versions de Kubernetes prises en charge dans AKS
• Support à long terme (LTS) des versions AKS
• Image Cleaner dans AKS
• Chiffrement des données KMS dans AKS
• Fournisseur Azure Key Vault pour le pilote CSI Secrets Store
• S'authentifier auprès d'Azure Container Registry
• Autorisations de dépôt ABAC dans Azure Container Registry
• Sécuriser votre déploiement Azure Container Registry
• Points de terminaison de données dédiés ACR
• Transition de Docker Content Trust vers Notary Project
• Customer-managed keys pour ACR
• S'authentifier auprès d'ACR depuis AKS
• Considérations de sécurité pour Azure Container Instances
• Conteneurs confidentiels sur Azure Container Instances
• Ingress dans Azure Container Apps
• Gérer les secrets dans Azure Container Apps
• Sécuriser votre déploiement Azure Container Apps
• Utiliser les clés d'accès dans Azure Functions
• Sécuriser Azure Functions
• Options réseau d'Azure Functions
• Connexions aux services dans Azure Functions
• Sécuriser l'accès et les données dans Azure Logic Apps
• Authentifier avec des managed identities dans Azure Logic Apps
• Logic Apps Standard et Consumption
• Sécuriser votre déploiement Azure App Service
• Access restrictions Azure App Service
• Désactiver la basic authentication dans App Service
• Versions TLS minimales pour App Service
• App Service Environment v3 et App Service multilocataire
• Vue d'ensemble de Defender for App Service
• WAF sur Azure Application Gateway
• Stratégies WAF d'Application Gateway
• Groupes de règles CRS et DRS d'Application Gateway
• WAF sur Azure Front Door
• Rate limiting sur Azure Front Door
• Comparaison d'Azure Front Door et d'Azure CDN
• Référence des stratégies API Management
• Stratégie validate-azure-ad-token
• Authentification par certificat client dans API Management
• Limitation avancée des requêtes avec API Management
• Réseau virtuel et API Management
• Retrait de la connectivité de service approuvé d'API Management
• À propos de Microsoft Defender for APIs
• Annonce du retrait d'Azure Spring Apps
• Stratégie ip-filter d'API Management
• Contrôler l'accès au kubeconfig d'AKS avec Azure RBAC
• WAF sur Azure Content Delivery Network (préversion fermée)
• Rôles intégrés Azure pour les conteneurs