Révision de la sécurité, de l’identité et de la gouvernance

Faits essentiels sur Entra ID pour l’examen : Entra ID (anciennement Azure AD) est le service d’identité cloud de Microsoft — il est différent d’Active Directory Domain Services (AD DS) local. Un locataire Entra ID représente l’instance d’identité cloud d’une organisation. Un locataire peut avoir plusieurs abonnements, mais chaque abonnement fait confiance à un seul locataire. Objets clés : Utilisateurs (comptes individuels), Groupes (ensembles d’utilisateurs ou d’appareils), principaux de service (identités d’applications) et identités managées (principaux de service gérés par Azure).

Une distinction AZ-900 souvent source de confusion : Azure RBAC contrôle l’accès aux ressources Azure (VM, comptes de stockage, groupes de ressources) et s’applique au niveau des abonnements, des groupes de ressources ou des ressources individuelles. Les rôles Entra ID contrôlent l’accès aux objets Entra ID (utilisateurs, groupes, applications, appareils) et s’appliquent au sein du locataire Entra ID. Un administrateur général dans Entra ID n’a pas automatiquement accès aux abonnements Azure. Un Contributor dans Azure RBAC ne peut pas gérer les utilisateurs Entra ID. Les deux systèmes de rôles sont distincts.

L’authentification multifacteur (MFA) exige que les utilisateurs vérifient leur identité à l’aide d’au moins deux facteurs : quelque chose qu’ils connaissent (mot de passe), qu’ils possèdent (application d’authentification, SMS) ou qu’ils sont (donnée biométrique). Dans Entra ID, la MFA est appliquée au moyen des stratégies d’accès conditionnel. Une stratégie d’accès conditionnel évalue des signaux (identité de l’utilisateur, conformité de l’appareil, emplacement, application à laquelle l’accès est demandé), puis applique des contrôles d’accès (exiger la MFA, bloquer l’accès, exiger un appareil conforme). L’examen vérifie notamment quel niveau de licence Entra ID inclut l’accès conditionnel : la réponse est Entra ID P1 ou une version supérieure.

Le modèle de sécurité Zero Trust de Microsoft repose sur trois principes : Vérifier explicitement — authentifier et autoriser chaque demande à l’aide de tous les points de données disponibles (identité, emplacement, appareil, service, classification des données). Utiliser un accès avec le moins de privilèges possible — limiter l’accès des utilisateurs au moyen d’un accès juste-à-temps et juste-suffisant, ainsi que de stratégies adaptatives fondées sur les risques. Partir du principe qu’une violation s’est produite — limiter l’étendue des dommages en segmentant les réseaux en microsegments, en chiffrant de bout en bout et en utilisant l’analytique pour obtenir une visibilité et favoriser la détection des menaces. L’examen AZ-900 attend de vous que vous sachiez reconnaître les principes Zero Trust dans les questions de mise en situation.

Points clés de Defender for Cloud pour l’examen : il fournit un Secure Score, un pourcentage indiquant dans quelle mesure votre environnement suit les recommandations de sécurité de Microsoft. Les recommandations sont regroupées en contrôles de sécurité (tels que « Remédier aux configurations de sécurité » et « Mettre en œuvre une sécurité avancée des données »). Defender for Cloud fonctionne sur Azure, dans les environnements locaux (via Azure Arc) et dans d’autres clouds. Il propose deux modes : Gratuit (CSPM de base et recommandations de sécurité uniquement) et les plans Defender (payants, ajoutant une protection avancée contre les menaces pour chaque type de charge de travail — VM, SQL, stockage, conteneurs, etc.).

Faits à retenir sur Azure Key Vault pour l’examen : Key Vault stocke trois types d’objets — secrets (mots de passe, chaînes de connexion), clés (clés RSA ou EC pour les opérations de chiffrement) et certificats (certificats X.509 avec gestion de leur cycle de vie). L’accès à Key Vault est contrôlé par RBAC (plus récent et recommandé) ou par l’ancien modèle de stratégie d’accès Key Vault. Key Vault s’intègre aux identités managées afin que les applications ne stockent jamais les identifiants. Key Vault propose deux niveaux : Standard (clés protégées par logiciel) et Premium (clés protégées par un HSM de niveau 2 conforme à FIPS 140-2).

Points d’examen sur Azure Policy : une définition de stratégie indique ce qui doit être évalué et l’action à effectuer (Audit, Deny, DeployIfNotExists, Modify). Une attribution de stratégie applique une définition à une étendue (groupe d’administration, abonnement ou groupe de ressources). Une initiative de stratégie (également appelée ensemble de stratégies) regroupe plusieurs définitions. L’effet DeployIfNotExists est particulier : il déploie automatiquement une ressource de correction si la condition est remplie (par exemple, déployer un agent Log Analytics sur les VM qui n’en possèdent pas). Les résultats de conformité s’affichent sous forme de pourcentages dans le tableau de bord de conformité.

Faits sur les groupes d’administration : vous pouvez imbriquer des groupes d’administration jusqu’à 6 niveaux de profondeur sous la racine. Le groupe racine du locataire est le groupe d’administration de niveau supérieur, créé automatiquement. Les stratégies et les attributions RBAC effectuées au niveau d’un groupe d’administration sont héritées par tous les groupes d’administration enfants et les abonnements situés en dessous. Conception d’entreprise courante : racine → Plateforme (abonnements de connectivité, d’identité et de gestion) → zones d’atterrissage (production, hors production) → abonnements propres à chaque produit. Cette hiérarchie permet une gouvernance centralisée à grande échelle.

Faits sur les verrous de ressources : le verrou CanNotDelete autorise la lecture et la modification, mais empêche la suppression. Le verrou ReadOnly autorise uniquement les opérations de lecture — aucune modification ni suppression. Les verrous peuvent être appliqués au niveau de l’abonnement, du groupe de ressources ou de la ressource, et sont hérités par les ressources enfants. Seuls les rôles Owner et User Access Administrator peuvent créer ou supprimer des verrous. Les balises de ressources sont des paires de métadonnées clé-valeur ; elles ne sont PAS héritées (contrairement aux verrous et aux stratégies). Vous pouvez utiliser jusqu’à 50 balises par ressource, avec un nom de balise de 512 caractères maximum et une valeur de 256 caractères maximum.

Services de sécurité réseau AZ-900 : Azure DDoS Protection Basic est gratuit et protège automatiquement toutes les ressources Azure contre les attaques DDoS courantes des couches 3 et 4. Azure DDoS Protection Standard est payant (environ 2 944 $ par mois et par réseau virtuel protégé), et ajoute un ajustement adaptatif, des métriques d’attaque en temps réel et une analyse après attaque. Azure Firewall est un pare-feu avec état managé, doté d’une haute disponibilité intégrée et d’une mise à l’échelle automatique — ce n’est pas un NSG. Azure Firewall fonctionne au niveau de la couche 7 (règles applicatives avec filtrage FQDN), tandis que les NSG fonctionnent au niveau de la couche 4 (règles de port et d’adresse IP).

Scénarios de sécurité AZ-900 courants :

• Empêcher la suppression accidentelle d’une VM → verrou de ressource (CanNotDelete)
• Obliger toutes les ressources à posséder une balise CostCentre → Azure Policy (effet Deny)
• Déclencher une alerte lorsqu’un utilisateur se connecte depuis un emplacement inhabituel → Protection de l’identité Entra ID / accès conditionnel
• Stocker de manière sécurisée le mot de passe de la base de données d’une application → secret Azure Key Vault
• Afficher les recommandations de sécurité et le score de conformité → Secure Score de Microsoft Defender for Cloud
• Détecter les menaces dans les journaux d’audit des abonnements → Microsoft Sentinel

Testez votre compréhension des concepts de Microsoft Azure Fundamentals (AZ-900) présentés dans cette leçon.

Dans cette leçon, vous avez révisé : Entra ID et Azure RBAC (deux systèmes distincts de contrôle d’accès, respectivement pour l’identité cloud et les ressources Azure), le Secure Score de Defender for Cloud (mesure la posture de sécurité et met en évidence les recommandations) et le fait que les verrous ReadOnly prévalent sur RBAC (même les propriétaires ne peuvent pas écrire sur des ressources verrouillées avec ReadOnly). Nous allons maintenant aborder la stratégie d’examen et la gestion du temps pour l’AZ-900.