Microsoft AZ-500: Sécurité du calcul, des conteneurs et des points de terminaison — Guide d'étude

By Laurynas Brazys · 11 August 2026 · #microsoft #az-500 #certification #exam-prep #study-guide

Fait partie du Microsoft Azure Security Engineer Associate AZ-500 — Guide d’étude. Entraînez-vous avec des réponses vérifiées dans le centre d’examens Microsoft, ou passez des tests chronométrés sur ExamRoll.io.

Aperçu

Cette section fournit une référence opérationnelle pour la sécurisation des ressources de calcul, des conteneurs et des points de terminaison Azure sur IaaS et PaaS. Elle se concentre sur la manière de configurer les protections, leur importance et la façon de les appliquer de manière cohérente avec les contrôles natifs d’Azure.

Sécurité du calcul et des points de terminaison

Les protections de la plateforme de machines virtuelles Azure et les options de chiffrement sont fondamentales.

• Secure Boot, vTPM et Trusted Launch : Trusted Launch renforce les machines virtuelles de génération 2 en activant le démarrage sécurisé UEFI (UEFI Secure Boot) et un TPM virtuel (vTPM). Secure Boot empêche les chargeurs de démarrage/rootkits non signés. Le vTPM fournit un stockage inviolable pour les clés (par exemple BitLocker) et prend en charge le démarrage mesuré (measured boot) afin que la plateforme puisse attester de la chaîne de démarrage du système d’exploitation. Sur le plan opérationnel, activez Trusted Launch lors du déploiement et appliquez-le avec une stratégie pour garantir que toutes les nouvelles machines virtuelles bénéficient de vérifications d’intégrité ancrées dans le matériel, sans que les administrateurs aient à gérer les paramètres statiques du BIOS/UEFI.

• Machines virtuelles confidentielles : Utilisez les séries de machines virtuelles confidentielles basées sur AMD SEV-SNP ou Intel TDX (par exemple DCasv5/DCadsv5) pour chiffrer la mémoire des machines virtuelles et fournir une attestation. Cela protège les charges de travail contre un hôte/hyperviseur malveillant et les attaques par canal auxiliaire. Sur le plan opérationnel, sélectionnez des références (SKU) confidentielles pour les scénarios de données en cours d’utilisation très sensibles, intégrez l’attestation dans votre pipeline de déploiement et préférez les disques de système d’exploitation éphémères lorsque vous avez besoin de redéploiements rapides sans persistance des données.

• Options de chiffrement de disque :

  • Azure Disk Encryption (ADE) : BitLocker (Windows) ou DM-Crypt (Linux) à l’intérieur de l’invité, clés dans Key Vault (BEK/KEK). Utile lorsque vous avez besoin de domaines de chiffrement basés sur l’invité, de vérifications de conformité au sein du système d’exploitation ou pour tirer parti de BitLocker lié au vTPM. Nécessite un agent et des opérations de cycle de vie pour la santé de l’extension.
  • Chiffrement côté serveur (SSE) avec des clés gérées par le client (CMK) : Chiffrement au niveau du stockage pour les disques managés à l’aide de clés dans Key Vault ou Managed HSM. Aucun agent invité, couverture complète de la plateforme (disques, instantanés, images), surcharge opérationnelle minimale. Recommandé par défaut pour la plupart des cas d’utilisation ; à associer avec Trusted Launch ou les machines virtuelles confidentielles pour une défense en profondeur plus robuste.

• Microsoft Defender for Servers :

  • Plan 1 : Microsoft Defender for Endpoint (MDE) pour la protection EDR/des points de terminaison sur les serveurs. Choisissez ce plan si vous disposez déjà d’outils matures de gestion des vulnérabilités et de la configuration et que vous avez principalement besoin de l’EDR.
  • Plan 2 : Ajoute l’évaluation des vulnérabilités avec ou sans agent, l’accès juste-à-temps (JIT) aux machines virtuelles, les contrôles d’application adaptatifs, le renforcement adaptatif du réseau et la surveillance de l’intégrité des fichiers (FIM). Choisissez ce plan lorsque vous souhaitez une réduction de l’exposition pilotée par la plateforme et une gouvernance en action sans avoir à assembler plusieurs outils.
  • Protection des points de terminaison : Déployez MDE via des extensions de machine virtuelle ou Arc pour les serveurs non-Azure afin de standardiser la télémétrie, la protection anti-falsification et les playbooks de réponse sur l’ensemble des environnements hybrides.
  • Évaluation des vulnérabilités : Utilisez le signal de gestion des menaces et des vulnérabilités de MDE ou l’analyseur intégré (par ex., Qualys) pour inventorier les CVE, les prioriser par exploitabilité et orchestrer l’application des correctifs. Sur le plan opérationnel, établissez d’abord une base de référence pour les serveurs critiques exposés à Internet ; liez la remédiation aux fenêtres de maintenance.
  • Surveillance de l’intégrité des fichiers : Suivez les modifications apportées aux fichiers/clés de registre sensibles pour détecter les falsifications suspectes et répondre aux exigences de conformité. Configurez des chemins de surveillance délimités pour éviter le bruit et transférez les alertes vers votre SIEM.

• Réduction de l’exposition avec Defender for Cloud :

  • Accès juste-à-temps aux machines virtuelles : Ferme les ports RDP/SSH entrants. Les administrateurs demandent un accès limité dans le temps ; Defender ouvre la règle NSG ou Azure Firewall et journalise l’activité. Le résultat est une surface d’attaque considérablement réduite avec des exceptions auditables.
  • Contrôles d’application adaptatifs : Apprend les processus normaux et crée des listes d’autorisation (AppLocker sur Windows, règles d’audit pour Linux). Cela bloque les binaires et les scripts non approuvés, ce qui est particulièrement efficace contre les attaques sans fichier ou de type LOLBin.
  • Renforcement adaptatif du réseau : Utilise l’analyse du trafic et le renseignement sur les menaces pour proposer un durcissement des règles NSG. Adoptez une cadence de révision et d’application pour restreindre l’exposition de manière itérative tout en évitant les interruptions de service.
  • Configuration d’invité : Azure Policy pour l’audit/la remédiation au sein de l’invité (Windows et Linux) via un agent ou Azure Arc. Utilisez-le pour appliquer des bases de référence de système d’exploitation, des stratégies de mot de passe et des paramètres alignés sur CIS lorsque vous avez besoin d’un état de configuration prouvable, et pas seulement d’une posture de plateforme.

Calcul PaaS : App Service et Functions

Les modèles sécurisés par défaut réduisent la surface d’attaque du PaaS.

• Azure App Service :

  • Authentification/Autorisation : Activez l’authentification App Service pour déléguer l’authentification à Microsoft Entra ID ou à d’autres fournisseurs. Utilisez Easy Auth pour les flux OIDC/OAuth2 standards, puis imposez la connexion sur toutes les routes pour supprimer l’exposition non authentifiée.
  • Restrictions d’accès : Autorisez ou refusez le trafic par IP/CIDR, par service tags ou le trafic de réseau virtuel via des points de terminaison privés. Maintenez des règles distinctes pour le point de terminaison scm et le point de terminaison de l’application afin de protéger votre plan de déploiement de manière indépendante.
  • Points de terminaison privés : Exposez l’application via une adresse IP privée dans votre VNet et désactivez éventuellement l’accès public. Utilisez des zones DNS privées et restreignez les dépendances sortantes avec l’intégration VNet et un pare-feu de sortie (egress firewall) central.
  • Identités managées : Préférez les identités affectées par le système ou par l’utilisateur pour accéder à Key Vault, Storage et à d’autres services. Cela élimine les secrets intégrés et permet l’attribution centralisée des rôles et la rotation des clés.

• Azure Functions :

  • Gestion des clés : Les Functions utilisent des clés de fonction, des clés d’hôte et la clé maîtresse. Effectuez une rotation régulière des clés et stockez les clés consommées de l’extérieur dans Key Vault, ou remplacez les clés par des flux OAuth appropriés si possible.
  • Intégration réseau : Utilisez des points de terminaison privés pour l’accès entrant à l’application Function et l’intégration VNet régionale pour les contrôles sortants. Limitez le compte de stockage utilisé par les Functions aux seuls réseaux sélectionnés et ajoutez le point de terminaison privé de la Function aux réseaux autorisés.
  • Identités : Utilisez des identités managées pour l’authentification de service à service au lieu de clés ou de chaînes de connexion. Appliquez le principe du moindre privilège avec des attributions RBAC à portée limitée.
  • Contrôles de déploiement : Imposez le FTPS uniquement, désactivez l’authentification de base pour le site scm, restreignez les adresses IP du scm et utilisez Run From Package pour garantir des déploiements immuables. Intégrez la CI/CD avec la fédération d’identité de charge de travail pour éliminer les secrets à longue durée de vie.

Sécurité de Kubernetes et des conteneurs

Renforcez les clusters et les chaînes d’approvisionnement de bout en bout.

• Identité et autorisation AKS :

  • Intégration Microsoft Entra : Activez AAD managé pour AKS afin d’authentifier kubectl à l’aide de jetons et de groupes Entra. Cela centralise le cycle de vie des utilisateurs et l’accès conditionnel/MFA.
  • RBAC Kubernetes : Mappez les utilisateurs/groupes Entra à des rôles et des liaisons de rôles (role bindings) Kubernetes pour un moindre privilège à l’échelle du namespace.
  • Azure RBAC pour Kubernetes : Utilisez les rôles intégrés (par ex., Azure Kubernetes Service RBAC Viewer/Admin) lorsque vous souhaitez qu’Azure RBAC autorise directement les actions de l’API Kubernetes. Cela unifie l’autorisation et l’audit avec le plan de contrôle Azure.

• Réseautage et confidentialité AKS :

  • Stratégies réseau : Appliquez le trafic de pod à pod et de pod à service avec Azure NPM ou Calico. Refusez par défaut et autorisez explicitement la sortie (egress) requise ; la politique en tant que code (policy-as-code) empêche les mouvements latéraux.
  • Clusters privés : Rendez le serveur d’API privé, accessible uniquement via des points de terminaison privés. Associez-le à Azure Bastion/Private Link et à une stratégie de sortie par pare-feu (NAT Gateway + UDRs) pour maintenir le plan de gestion hors d’Internet.

• Sécurité de Container Registry (ACR) :

  • RBAC : Attribuez AcrPull aux charges de travail qui ont seulement besoin de tirer (pull) des images et AcrPush aux pipelines de build ; évitez le rôle surprivilégié de Propriétaire (Owner). AcrPull et AcrPush s’alignent sur le principe du moindre privilège.
  • Confiance et signature du contenu : Signez les images avec cosign et imposez la vérification avec un contrôle d’admission (Gatekeeper + Ratify) avant le démarrage des pods. Cela protège contre les images falsifiées.
  • Analyse d’images : Activez Microsoft Defender for Cloud pour analyser ACR lors d’un push/import et de manière planifiée. Bloquez le déploiement d’images contenant des CVE critiques non corrigées à l’aide de stratégies d’admission.
  • Modèle de quarantaine : Acheminez les nouvelles images vers un dépôt ou un tag de quarantaine, exécutez l’analyse et les vérifications de stratégie, puis promouvez-les en ré-étiquetant (retagging) après approbation.
  • Accès privé : Désactivez l’accès au réseau public et utilisez des points de terminaison privés et des règles de pare-feu de registre. Attachez AKS à ACR en utilisant une attribution de rôle au niveau de la ressource plutôt qu’un rôle d’annuaire.

Court exemple pour attacher ACR à AKS en utilisant l’identité managée du cluster :

az aks update -g rg-aks -n myAKS --attach-acr myAcrName

• Microsoft Defender for Containers : Déploie un capteur de plan de données sur AKS, surveille les journaux d’audit de Kubernetes et les signaux d’exécution, et les corrèle avec les résultats de l’analyse d’images. Il détecte les exécutions suspectes dans les pods (execs), le crypto-minage, les tableaux de bord exposés et les opérations risquées sur le plan de contrôle. Activez l’auto-approvisionnement et connectez les alertes à votre SIEM/SOAR pour le triage.

Gouvernance, politique et application

Un contrôle cohérent nécessite des politiques au déploiement et à l’exécution.

• Azure Policy pour le calcul et les disques :
  • Refuser la création de machines virtuelles sans trusted launch ou sans SSE avec une clé CMK.
  • Imposer les extensions de VM pour la protection des points de terminaison en utilisant DeployIfNotExists pour installer automatiquement les agents requis.
  • Auditer la conformité de la configuration des invités ; remédier à la dérive de manière planifiée.

Court extrait de politique pour déployer une extension de VM requise si elle est manquante :

"policyRule": {
  "if": { "field": "type", "equals": "Microsoft.Compute/virtualMachines" },
  "then": {
    "effect": "DeployIfNotExists",
    "details": {
      "type": "Microsoft.Compute/virtualMachines/extensions",
      "name": "MDE.Windows"
    }
  }
}

• Contrôles d’admission Kubernetes :
  • L’add-on Azure Policy pour AKS utilise Gatekeeper (OPA) pour évaluer les spécifications des pods lors de l’admission. Appliquer des règles telles que « extraire uniquement depuis ACR », « pas de conteneurs privilégiés » et « exiger les signatures d’images ».
  • Maintenir des initiatives distinctes pour la ligne de base (indispensable) et le renforcement (espaces de noms sensibles) afin de permettre un durcissement progressif.

Courte contrainte Gatekeeper pour restreindre les registres :

apiVersion: constraints.gatekeeper.sh/v1beta1
kind: K8sAllowedRepos
metadata:
  name: allowed-acr-only
spec:
  parameters:
    repos:
    - myacr.azurecr.io/

• Cadence opérationnelle :
  • Détecter : Utiliser les recommandations de Defender for Cloud et les alertes de charge de travail comme signaux de dérive et de menace.
  • Décider : Trier par impact métier et exploitabilité ; assigner des propriétaires via des balises (tags).
  • Appliquer : Convertir les pilotes réussis en politiques de refus/contraintes d’admission ; mesurer les tentatives bloquées pour détecter le shadow IT.

Scénario de problème pratique

Adobe Inc. migre un microservice de paiement vers Azure. Les exigences de sécurité imposent une exposition publique nulle, uniquement des images signées et un accès administrateur limité dans le temps aux machines virtuelles héritées pendant la transition.

1. Rendre le plan de contrôle AKS privé et verrouiller le trafic sortant (egress).

• Justification : Un serveur d’API AKS privé supprime le plan de gestion d’Internet. Une NAT Gateway associée à un Azure Firewall avec des règles de sortie explicites garantit que les charges de travail n’atteignent que les points de terminaison approuvés (ACR, Key Vault, dépôts de paquets Microsoft).

2. Imposer les images signées et restreindre les registres.

• Justification : Configurer Gatekeeper avec des contraintes qui n’autorisent que les images provenant de myacr.azurecr.io et exigent des signatures cosign validées par Ratify. Cela empêche l’exécution d’images altérées ou non fiables, comblant ainsi un risque majeur pour la chaîne d’approvisionnement.

3. Sécuriser ACR avec des points de terminaison privés et des rôles à privilèges minimum.

• Justification : Désactiver l’accès réseau public et exposer ACR via un point de terminaison privé dans le VNet d’AKS. Accorder uniquement le rôle AcrPull à l’identité managée d’AKS ; accorder le rôle AcrPush au pipeline de build. Cela respecte le principe du moindre privilège et élimine la dépendance à Internet.

4. Activer Defender for Containers et l’analyse d’images ACR.

• Justification : L’analyse continue des images lors du push et la détection des menaces à l’exécution fournissent une couverture à plusieurs niveaux. Les alertes unifient les erreurs de configuration, les vulnérabilités connues et les comportements suspects pour une réponse rapide.

5. Protéger les outils d’administration basés sur App Service avec une authentification et un accès privé.

• Justification : Utiliser App Service Authentication avec Microsoft Entra ID pour exiger l’authentification multifacteur (MFA) et l’accès conditionnel. Créer un point de terminaison privé pour l’application d’administration et restreindre l’accès scm séparément. Les identités managées suppriment les secrets pour l’accès à Key Vault.

6. Utiliser l’accès Just-in-Time (JIT) aux VM pour les hôtes hérités pendant la transition.

• Justification : L’accès JIT ferme les ports RDP/SSH par défaut et ne les ouvre que sur des demandes approuvées pour des durées limitées. Cela limite strictement les fenêtres d’exposition tout en préservant l’accès d’urgence.

7. Standardiser les choix de chiffrement : SSE avec CMK pour les disques ; Trusted Launch pour les VM.

• Justification : Le SSE avec CMK minimise la charge opérationnelle et centralise le cycle de vie des clés dans Key Vault, tandis que Trusted Launch/vTPM ajoute l’intégrité du démarrage et la protection des clés. ADE est réservé uniquement aux cas où une preuve de domaine de chiffrement basée sur l’invité est contractuellement requise.

8. Appliquer Azure Policy et le contrôle d’admission comme garde-fous.

• Justification : Les initiatives Azure Policy imposent le trusted launch, les extensions de VM requises et refusent l’accès public à ACR/Function. Les contraintes Gatekeeper mettent en œuvre des contrôles d’admission à l’exécution pour AKS. Ensemble, elles garantissent que les configurations restent conformes au fur et à mesure que les équipes itèrent.

9. Valider et opérer avec une gouvernance continue.

• Justification : Intégrer les alertes de Defender for Cloud et de MDE dans le SIEM d’Adobe, mesurer l’effet des politiques (refus vs audit) et examiner les exceptions mensuellement. Cela transforme les contrôles ponctuels en un modèle opérationnel de sécurité durable.

← Architecture de sécurité réseau · Tous les domaines · Sécurité des données →

Entraînez-vous sur ces questions → · Tests chronométrés sur ExamRoll.io →

Parcourir Microsoft →