Microsoft AZ-305: Architecture de sécurité et Zero Trust — Guide d'étude

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

Fait partie du Microsoft Azure Solutions Architect Expert AZ-305 — 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.

Vue d’ensemble

L’architecture de sécurité sur Azure est ancrée dans le principe du Zero Trust : ne jamais faire confiance, toujours vérifier, autoriser explicitement et présumer la compromission. Les architectures doivent imposer un accès piloté par l’identité, une micro-segmentation, une protection renforcée des données, ainsi qu’une détection et une réponse continues aux menaces. Cette section relie les piliers — identité et secrets, protection des données, contrôles réseau et défense native contre les menaces cloud — en des conceptions cohérentes alignées sur les capacités de la plateforme Azure.

Identité, secrets et fondations du Zero Trust

Le Zero Trust commence par une vérification d’identité forte et le principe du moindre privilège. Chaque identité de charge de travail et humaine doit être évaluée au moment de l’accès, avec des contrôles conditionnels et des jetons à durée de vie limitée. Appliquez le moindre privilège en limitant les autorisations au plus petit ensemble d’actions sur le périmètre de ressource le plus restreint, et préférez l’élévation juste-à-temps (JIT) avec Privileged Identity Management (PIM) le cas échéant.

Azure Key Vault est central pour les secrets et les clés. Il existe deux modèles d’autorisation pour le plan de données :

Les stratégies d’accès (Access policies) sont l’ancien modèle ACL par coffre. Elles accordent des autorisations granulaires sur les secrets/clés/certificats aux principaux de sécurité, mais ne s’intègrent pas avec les affectations de refus (deny assignments) d’Azure RBAC ou PIM, et elles compliquent la gouvernance à grande échelle car leur portée est limitée au coffre.
Azure RBAC pour Key Vault est le modèle moderne. Lorsqu’il est activé sur le coffre, les autorisations du plan de données sont contrôlées par des rôles Azure RBAC (par exemple, Key Vault Secrets User, Key Vault Crypto Officer), héritent à travers les portées (groupe d’administration, abonnement, groupe de ressources), prennent en charge les affectations de refus et s’intègrent avec PIM et les Access Reviews. Choisissez RBAC pour la cohérence et la gouvernance centralisée ; ne mélangez pas les modèles sur le même coffre.

La suppression réversible (soft delete) et la protection contre le vidage (purge protection) préviennent la perte accidentelle ou malveillante. La suppression réversible conserve les objets supprimés pendant une période de rétention (configurable de 7 à 90 jours, 90 par défaut) permettant leur récupération. La protection contre le vidage, lorsqu’elle est activée, empêche la purge permanente des éléments supprimés de manière réversible jusqu’à l’expiration de la rétention, même par des utilisateurs hautement privilégiés. Pour les coffres de production, activez les deux. Managed HSM fournit des modules de sécurité matériels (HSM) dédiés, validés FIPS 140-2 Level 3, sous le contrôle d’Azure. Il ne prend en charge que les clés (pas de secrets/certificats), utilise Azure RBAC avec des rôles tels que Managed HSM Administrator, Crypto Officer et Crypto User, et la suppression réversible ainsi que la protection contre le vidage y sont toujours activées. Utilisez Managed HSM lorsque vous avez besoin d’une isolation des clés adossée au matériel, d’une administration basée sur le quorum ou d’une assurance réglementaire pour les contrôles de frontière cryptographique.

Les identités managées Azure (Azure Managed Identities) éliminent les informations d’identification pour les charges de travail hébergées sur Azure. Les identités affectées par le système sont liées au cycle de vie d’une seule ressource ; la suppression de la ressource supprime l’identité. Elles sont idéales pour les ressources uniques (une Function App ou une VM) qui nécessitent des périmètres d’autorisation indépendants. Les identités affectées par l’utilisateur sont autonomes et peuvent être attachées à plusieurs ressources ; elles persistent lorsque les ressources de calcul sont remplacées ou mises à l’échelle, ce qui les rend adaptées aux flottes, aux déploiements bleu/vert, ou lorsqu’une identité cohérente est requise entre les instances. Les charges de travail obtiennent des jetons sans secrets en appelant le service de métadonnées d’instance (IMDS) à l’adresse 169.254.169.254 ou le point de terminaison d’identité managée de la plateforme, demandant un jeton d’accès pour une ressource (par exemple, https://vault.azure.net pour Key Vault). Utilisez Azure RBAC pour accorder à l’identité les rôles de moindre privilège sur les ressources cibles ; la plateforme effectue la rotation des informations d’identification automatiquement.

Azure AD Workload Identity Federation élimine le besoin de stocker des informations d’identification cloud dans des systèmes CI/CD externes et Kubernetes. Avec GitHub Actions, créez une information d’identification fédérée sur l’application Azure AD en utilisant l’émetteur OIDC de GitHub (token.actions.githubusercontent.com) et limitez-la par dépôt, branche ou environnement. GitHub échange son jeton OIDC contre un jeton Azure AD à l’exécution ; assignez des rôles Azure à cette application et appliquez le moindre privilège par workflow. Pour Kubernetes (AKS), activez OIDC sur le cluster et configurez l’identité de charge de travail Azure AD. Mappez le jeton OIDC d’un ServiceAccount à une application Azure AD ou à une identité managée affectée par l’utilisateur via une information d’identification fédérée, puis liez des rôles Azure à cette identité. Les pods échangent leur jeton OIDC projeté contre des jetons Azure pour appeler des services comme Key Vault ou Storage — aucun secret ni agent au niveau du nœud n’est requis, et l’isolation est meilleure qu’avec l’ancienne solution aad-pod-identity.

Protection contre les menaces, SIEM/SOAR et gouvernance des applications cloud

Microsoft Defender for Cloud fournit la gestion de la posture de sécurité du cloud et la protection des charges de travail. Le Secure Score quantifie le risque en évaluant les mauvaises configurations et en recommandant des paramètres renforcés (par exemple, l’activation de l’authentification multifacteur (MFA), l’application du chiffrement de disque ou la restriction des points de terminaison publics). Améliorez le Secure Score grâce à des attributions de stratégies au niveau du groupe d’administration pour standardiser les bases de référence. Les protections des charges de travail s’étendent aux serveurs, conteneurs, bases de données, stockage, Key Vault et App Service pour fournir des détections de menaces, des évaluations de vulnérabilité et des fonctionnalités telles que l’accès juste-à-temps aux machines virtuelles, les contrôles d’application adaptatifs et la surveillance de l’intégrité des fichiers. La conformité réglementaire met en correspondance votre environnement avec des normes (Azure Security Benchmark, CIS, PCI-DSS, ISO 27001) et indique la réussite/l’échec par rapport aux contrôles de stratégie ; utilisez cette fonction pour suivre et corriger les écarts avec les parties prenantes de la gouvernance.

Microsoft Sentinel est le SIEM et le SOAR natif du cloud. Les connecteurs de données intègrent la télémétrie d’Azure Activity, des connexions et audits Azure AD, de Microsoft 365, de la suite Microsoft Defender, des ressources Azure et des sources non-Azure via Syslog/CEF ou les agents AMA/Log Analytics. Les règles d’analyse détectent les menaces à l’aide de KQL : règles planifiées pour la corrélation périodique, règles en quasi-temps réel pour la détection à faible latence, et modèles d’apprentissage automatique/d’anomalie pour les informations comportementales. Ajustez les seuils des règles, la suppression et les mappages d’entités pour réduire le bruit et enrichir les incidents. Automatisez les réponses avec les playbooks SOAR créés dans Logic Apps ; déclenchez l’isolement des hôtes compromis via Defender for Endpoint, désactivez les comptes suspects dans Azure AD, révoquez les sessions, purgez les e-mails malveillants, ou notifiez et ouvrez des tickets. Utilisez les règles d’automatisation pour router les incidents, les étiqueter par gravité et invoquer des playbooks en fonction des propriétés de l’incident.

Microsoft Defender for Cloud Apps régit l’utilisation des applications SaaS. La découverte du Shadow IT ingère les journaux de pare-feu/proxy et la télémétrie des points de terminaison pour identifier les applications non approuvées, les classer par risque et vous permettre de les approuver/désapprouver. Intégrez avec Defender for Endpoint pour une découverte continue. Les contrôles de session appliquent le Conditional Access App Control en temps réel via un proxy inverse pour faire respecter des stratégies telles que le blocage du téléchargement pour les appareils non gérés, l’exigence d’étiquetage des documents avant le téléchargement, l’application de filigranes ou la restriction du couper/copier/coller, sans modifier l’application SaaS.

Protection des données et Confidential Computing

Azure Information Protection opérationnalise la classification et la protection des données grâce à des étiquettes de confidentialité. Les étiquettes définissent la classification, les marquages visuels, le chiffrement (Azure Rights Management) et les droits d’utilisation (afficher, imprimer, transférer, accès hors ligne). Publiez les étiquettes via des stratégies d’étiquetage pour des utilisateurs sélectionnés et exigez un étiquetage obligatoire le cas échéant. Les stratégies d’étiquetage automatique peuvent appliquer des étiquettes dans les applications Office sur les points de terminaison en se basant sur l’inspection du contenu (par exemple, des modèles de PII, des mots-clés) et au repos/en transit dans les services via des outils de gouvernance des données, réduisant ainsi les erreurs des utilisateurs et renforçant la protection de base. Utilisez des invites de justification pour les déclassements et auditez les changements d’étiquettes pour soutenir la gouvernance.

Azure Confidential Computing protège les données en cours d’utilisation en exécutant des charges de travail à l’intérieur d’environnements d’exécution de confiance (Trusted Execution Environments) basés sur le matériel. Les machines virtuelles confidentielles (par exemple, AMD SEV-SNP ou Intel TDX) chiffrent la mémoire de la VM et en assurent l’intégrité, protégeant les charges de travail invitées de l’hôte cloud et des autres locataires. Utilisez-les pour les scénarios de type lift-and-shift nécessitant des protections de niveau enclave sans modification des applications. Les conteneurs confidentiels sur AKS exécutent des charges de travail conteneurisées sur des pools de nœuds confidentiels ; combinez-les avec des images de conteneurs chiffrées et l’attestation pour garantir que seules les charges de travail attestées s’exécutent. L’attestation est effectuée à l’aide d’Azure Attestation pour vérifier les mesures de la plateforme et de la charge de travail (quotes) avant de libérer les secrets. Intégrez les vérifications d’attestation dans votre plan de contrôle ou votre pipeline de déploiement ; ce n’est qu’après une attestation réussie que Key Vault ou un KMS externe doit libérer les clés de déchiffrement à la charge de travail, complétant ainsi la protection des données en cours d’utilisation.

Segmentation du réseau, périmètre et défense DDoS en profondeur

La micro-segmentation du réseau limite le mouvement latéral et s’associe à la vérification de l’identité pour appliquer le Zero Trust. Les Network Security Groups sont des filtres de paquets à état (stateful) appliqués aux sous-réseaux ou aux cartes réseau (NIC) ; utilisez des service tags et des refus explicites pour restreindre les flux est-ouest et nord-sud, refusez par défaut les ports non nécessaires et journalisez avec les journaux de flux NSG. Les Application Security Groups abstraient des groupes de charges de travail dynamiques afin que vous puissiez écrire des règles NSG par rôle d’application plutôt que par adresses IP, permettant une segmentation basée sur l’intention qui s’adapte à la mise à l’échelle automatique et aux adresses éphémères.

Azure Firewall fournit un contrôle centralisé et entièrement stateful des couches L3 à L7 avec des règles d’application et de réseau, le filtrage FQDN, le DNAT/SNAT, le filtrage basé sur le renseignement sur les menaces (threat intelligence) et des fonctionnalités Premium comme l’inspection TLS et l’IDPS pour une inspection approfondie du trafic sortant et entrant. Utilisez Firewall Policy pour une configuration basée sur l’intention et l’héritage entre les régions. Acheminez le trafic sortant (egress) via Azure Firewall avec des routes définies par l’utilisateur (user-defined routes), et associez-le à des Private Endpoints pour maintenir le trafic PaaS hors de l’internet public.

Les applications exposées sur le web devraient être protégées en amont par un Web Application Firewall. Déployez un WAF sur Application Gateway pour un équilibrage de charge de couche 7 régional et intégré au VNet, ou sur Azure Front Door pour un point d’entrée anycast mondial et une intégration CDN. Activez les règles gérées par l’OWASP et ajoutez des règles personnalisées pour le filtrage par chemin/géographie/IP et les défenses contre les bots, et intégrez-le aux stratégies DDoS au niveau du périmètre (edge).

DDoS Protection Standard ajoute une atténuation adaptative en temps réel pour les points de terminaison publics dans les VNets, de la télémétrie et une protection des coûts en cas de montée en charge (scale-out) lors d’une attaque. Appliquez les plans de protection DDoS au niveau du VNet pour toutes les ressources d’adresses IP publiques associées, testez avec du trafic simulé et examinez les métriques et les alertes. Superposez vos couches de défense : DDoS au périmètre, WAF à la couche L7, Azure Firewall pour la politique L3-L7, NSG/ASG pour la micro-segmentation, et l’accès conditionnel (Conditional Access) plus la conformité des appareils pour une application des politiques pilotée par l’identité.

Scénario de problème pratique

Starbucks modernise une plateforme de commande multi-régions sur Azure avec AKS, Azure SQL Database et Event Hubs. L’architecture doit adopter le Zero Trust : éliminer les secrets intégrés, segmenter les réseaux, protéger les données en cours d’utilisation, et mettre en œuvre une détection unifiée des menaces et une réponse automatisée à travers le cloud et le SaaS.

Appliquer l’accès basé sur l’identité pour les charges de travail

Mettre en œuvre des identités managées affectées par l’utilisateur pour les charges de travail AKS nécessitant un accès à Key Vault et Storage. Attribuer des rôles RBAC du moindre privilège (Key Vault Secrets User, Storage Blob Data Reader) au niveau du groupe de ressources. Choisi parce que les identités managées suppriment les secrets, supportent les pods en montée en charge (scale-out) partageant une identité stable, et s’intègrent avec PIM/Access Reviews via Azure RBAC.

Fédérer le CI/CD sans informations d’identification stockées

Configurer la fédération d’identité de charge de travail Azure AD pour GitHub Actions en utilisant l’émetteur OIDC de GitHub et des contraintes de dépôt/environnement. Les workflows obtiennent des jetons Azure à l’exécution pour déployer Bicep et Helm. Choisi pour éliminer les PAT/secrets, réduire le rayon d’impact (blast radius) à des dépôts/branches spécifiques, et permettre des revendications conditionnelles.

Protéger les clés et les secrets avec des garanties de récupération

Utiliser Azure Key Vault avec le modèle de permission RBAC, la suppression réversible (soft delete) et la protection contre la purge activées. Stocker les chaînes de connexion et les secrets d’application ; stocker les clés de protection TDE pour Azure SQL dans un Managed HSM pour une assurance FIPS de niveau 3. Choisi pour l’audit centralisé, la récupérabilité et l’isolation des clés sur support matériel pour le matériel cryptographique critique.

Segmenter les réseaux et centraliser le trafic sortant

Appliquer des NSG avec un refus par défaut et des ASG pour les niveaux (web, api, données). Forcer tout le trafic sortant (egress) à passer par Azure Firewall Premium avec IDPS et inspection TLS ; utiliser des Private Endpoints pour Azure SQL et Key Vault. Choisi pour mettre en œuvre la micro-segmentation au niveau du sous-réseau/NIC, l’inspection approfondie des paquets pour le contrôle de l’exfiltration et l’accès privé aux services PaaS.

Protéger le périmètre public

Placer en amont du niveau web Azure Front Door avec des politiques WAF utilisant l’OWASP CRS et des règles personnalisées pour la limitation géographique/IP et les signatures de bots. Activer DDoS Protection Standard sur le VNet hub hébergeant Application Gateway pour le basculement régional. Choisi pour absorber les attaques volumétriques à l’échelle mondiale et bloquer les exploits de couche 7 avant qu’ils n’atteignent AKS.

Gouverner l’accès SaaS et les appareils non gérés

Intégrer Microsoft Defender for Cloud Apps avec Conditional Access App Control pour appliquer des contrôles de session sur M365 et les SaaS tiers autorisés : bloquer les téléchargements sur les appareils non gérés, exiger des étiquettes de sensibilité au téléchargement et appliquer un filigrane. Choisi pour des contrôles en temps réel sans modification des applications et une application cohérente à travers le SaaS.

Classifier et protéger les données sensibles

Définir des étiquettes de sensibilité Azure Information Protection (Public, Confidentiel, Hautement Confidentiel – Données Client) avec chiffrement et droits d’utilisation. Activer les politiques d’étiquetage automatique pour les modèles de PII dans Office et au repos dans SharePoint/OneDrive. Choisi pour standardiser le traitement des données, réduire les erreurs des utilisateurs et maintenir une protection persistante.

Sécuriser les données en cours d’utilisation pour le traitement des paiements

Exécuter les microservices de paiement sur des pools de nœuds confidentiels AKS et les modèles de risque par lots sur des VM confidentielles (AMD SEV-SNP). Contrôler l’accès aux clés de déchiffrement via Azure Attestation ; seuls les nœuds/pods attestés reçoivent les secrets de Key Vault. Choisi pour protéger la mémoire de l’accès de l’hôte/locataire et établir un démarrage mesuré (measured boot) et l’intégrité de la charge de travail.

Établir la gestion de la posture et la conformité

Activer Microsoft Defender for Cloud au niveau du groupe d’administration avec les standards Azure Security Benchmark et PCI-DSS. Activer les plans Defender pertinents (conteneurs, serveurs, SQL, Key Vault) et l’accès JIT aux VM. Choisi pour un Score de sécurité centralisé, des mappages réglementaires et des protections natives des charges de travail.

Centraliser la détection et orchestrer la réponse

Intégrer la télémétrie à Microsoft Sentinel via des connecteurs de données (Azure AD, Azure Activity, M365, Defender, journaux AKS, Firewall). Déployer des règles d’analyse pour le vol d’informations d’identification, le trafic sortant suspect, les évasions de conteneurs et l’activité d’administration anormale. Automatiser avec des playbooks Logic Apps pour désactiver les comptes compromis, isoler les nœuds AKS, bloquer le trafic sortant dans Azure Firewall et ouvrir des tickets. Choisi pour un SIEM/SOAR natif du cloud, un déploiement rapide de règles et une intégration étroite avec les signaux de sécurité Microsoft.

Cette conception applique le Zero Trust de bout en bout : les identités sont vérifiées en continu, les privilèges sont minimaux et juste-à-temps, les réseaux sont micro-segmentés avec une inspection centralisée, les données sont classifiées et protégées, aussi bien au repos qu’en cours d’utilisation, et la détection continue des menaces avec une réponse automatisée réduit le temps moyen de confinement.

← Haute disponibilité · Tous les domaines · Architecture d’intégration et de messagerie →

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