Débutant

Fondamentaux Azure

Identités Entra ID, gouvernance RBAC, réseaux virtuels et machines virtuelles : cliquez sur chaque module pour déplier le cours complet.

▶

Module 1 — Identités avec Microsoft Entra ID

Identités 25 %

1. Concepts essentiels

Microsoft Entra ID (anciennement Azure AD) est le service d’identité cloud de Microsoft. Il stocke les utilisateurs, les groupes, les appareils et les applications d’un locataire (tenant). Chaque utilisateur possède un nom d’utilisateur principal (UPN) de la forme prenom.nom@contoso.com, unique dans le locataire.

Les groupes de sécurité regroupent des utilisateurs pour leur attribuer des accès en une seule opération. Les groupes à appartenance dynamique mettent à jour leurs membres automatiquement selon des règles d’attributs, par exemple user.department égal à « IT ». Le libre-service de réinitialisation de mot de passe (SSPR) permet aux utilisateurs de réinitialiser eux-mêmes leur mot de passe après une vérification d’identité.

Pourquoi c'est important : sans identités propres, aucun accès applicatif ni aucune attribution RBAC ne tient : un nouvel arrivant sans compte reste bloqué le premier jour, un départ non révoqué conserve ses accès au locataire. L'examen AZ-104 teste directement la création d'utilisateurs, les groupes dynamiques et le SSPR.
L'analogie qui aide : Entra ID est le registre du personnel d'un immeuble : chaque occupant reçoit un badge nominatif unique (l'UPN), les groupes de sécurité sont des trousseaux qui ouvrent plusieurs portes d'un coup, et le SSPR est la borne qui refait un badge perdu après un contrôle d'identité.

2. Créer un utilisateur et un groupe (Azure CLI)

# Se connecter et vérifier le contexte
az login
az account show
az account set --subscription "Production"

# Créer un utilisateur Entra ID
az ad user create --display-name "Léa Martin" --user-principal-name lea.martin@contoso.com --password "P@ssw0rd!"

# Créer un groupe de sécurité puis y ajouter l'utilisatrice
az ad group create --display-name "Équipe-Réseau" --mail-nickname "equipe-reseau"
az ad group member add --group "Équipe-Réseau" --member-id lea.martin@contoso.com

3. Équivalent PowerShell (module Az)

Connect-AzAccount
$pwd = ConvertTo-SecureString "P@ssw0rd!" -AsPlainText -Force
New-AzADUser -DisplayName "Léa Martin" -UserPrincipalName "lea.martin@contoso.com" -Password $pwd
New-AzADGroup -DisplayName "Équipe-Réseau" -MailNickname "equipe-reseau" -SecurityEnabled
Démonstration pas à pas : az login fixe le locataire et az account set verrouille l'abonnement de travail ; az ad user create crée Léa Martin avec son UPN unique ; az ad group create crée le groupe Équipe-Réseau ; az ad group member add rattache l'utilisatrice au groupe. Le flux est clair : identité d'abord, groupe ensuite, attribution RBAC enfin — une seule attribution sur le groupe couvrira tous les futurs membres.

4. Synthèse : types d’identités

TypeUsageExemple
Utilisateur membreEmployé du locatairelea.martin@contoso.com
Utilisateur invité (B2B)Partenaire externeCompte invité avec MFA
Principal de serviceIdentité d’une applicationPipeline de déploiement
Identité managéeRessource Azure sans secret géréVM accédant au coffre de clés
Point d’examen : l’identité managée supprime les secrets du code ; la ressource obtient un jeton Entra ID et reçoit des autorisations RBAC. L’accès conditionnel impose la MFA selon des signaux (utilisateur, appareil, localisation, risque).
Pièges classiques : confondre utilisateur membre et invité B2B ; utiliser un groupe de distribution au lieu d'un groupe de sécurité pour les accès ; croire que la suppression d'un utilisateur révoque aussitôt ses jetons actifs ; oublier que l'identité managée doit quand même recevoir une attribution RBAC explicite.
À vous de jouer : quinze techniciens arrivent, avec des mouvements fréquents. Créez-vous quinze attributions RBAC individuelles ou un seul groupe de sécurité ?
Voir la réponse

Créez un seul groupe de sécurité, idéalement dynamique sur user.department égal à IT, puis une seule attribution RBAC sur ce groupe : chaque arrivée ou départ se gère par l'appartenance au groupe, sans toucher aux attributions.

▶

Module 2 — Gouvernance : RBAC, verrous et stratégies

Gouvernance 10 %

1. Le contrôle d’accès RBAC

Le contrôle d’accès en fonction du rôle (RBAC) attribue un rôle à un principal de sécurité (utilisateur, groupe, principal de service) sur une étendue : groupe d’administration, abonnement, groupe de ressources ou ressource. Les autorisations s’héritent du parent vers l’enfant. Le principe du moindre privilège impose de donner le rôle le plus faible suffisant.

Pourquoi c'est important : en production, une attribution trop large expose la suppression de ressources critiques, une attribution trop étroite bloque les déploiements. RBAC est le premier point contrôlé après un refus d'accès : rôle, étendue et héritage expliquent quatre-vingts pour cent des incidents d'autorisation.
L'analogie qui aide : RBAC fonctionne comme un trousseau d'immeuble : l'étendue est le bâtiment ou l'étage concerné, le rôle est le type de clé (passe-partout du propriétaire, clé d'usage du contributeur, badge visiteur du lecteur). Donner le rôle Contributeur sur tout l'abonnement quand seul un groupe de ressources est concerné, c'est confier le passe-partout alors qu'une clé d'étage suffit.

2. Attribuer un rôle (Azure CLI)

# Créer le groupe de ressources puis attribuer le rôle Contributeur
az group create --name RG-App --location francecentral
az role assignment create --assignee lea.martin@contoso.com --role Contributor --resource-group RG-App

# Auditer les attributions existantes
az role assignment list --assignee lea.martin@contoso.com --all -o table
Démonstration pas à pas : az group create isole le périmètre RG-App ; az role assignment create lie Lea Martin au rôle Contributeur sur cette seule étendue, donc toutes les ressources héritent de ce droit ; az role assignment list audite le résultat effectif. Le flux RBAC se lit ainsi : qui (principal) reçoit quoi (rôle) sur où (étendue), puis vérification systématique avant de transmettre l'information à l'utilisateur.

3. Verrous et stratégies

Un verrou CanNotDelete empêche la suppression tout en autorisant les modifications ; un verrou ReadOnly bloque suppression et modification. Azure Policy applique des règles à grande échelle (exiger une balise, interdire les IP publiques, imposer certains SKU) avec des effets audit, deny, append ou deployIfNotExists.

# Affecter une stratégie intégrée à un groupe de ressources
az policy assignment create --name "exiger-balise-env" --policy "Require a tag on resources" --resource-group RG-App

# Protéger un groupe critique contre la suppression
az lock create --name Verrou-Prod --lock-type CanNotDelete --resource-group RG-App

4. Synthèse : rôles intégrés courants

RôlePeut gérer les ressourcesPeut gérer les accès
Propriétaire (Owner)OuiOui
Contributeur (Contributor)OuiNon
Lecteur (Reader)Non (lecture)Non
Administrateur de l’accès utilisateurNonOui
Point d’examen : Contributeur gère tout sauf les accès ; Propriétaire ajoute la gestion RBAC. En cas de refus d’accès, vérifier l’étendue, le rôle et le délai de propagation, puis utiliser « Vérifier l’accès » et le journal d’activité.
Pièges classiques : donner Contributeur en espérant déléguer la gestion des accès, alors que seul Propriétaire ou Administrateur de l'accès utilisateur le permet ; attribuer au niveau abonnement au lieu du groupe de ressources ; oublier le délai de propagation RBAC ; confondre verrou CanNotDelete (modifications autorisées) et ReadOnly (tout est bloqué).
À vous de jouer : Léa peut créer des machines virtuelles dans RG-App mais ne peut pas ajouter un collègue au groupe de ressources. Quel rôle lui manque et que vérifiez-vous en premier ?
Voir la réponse

Contributeur ne gère pas les accès : il faut Propriétaire ou Administrateur de l'accès utilisateur sur RG-App. Vérifiez d'abord l'étendue exacte de son attribution avec az role assignment list, puis le délai de propagation et le journal d'activité.

▶

Module 3 — Réseaux virtuels, sous-réseaux et NSG

Réseau 20 %

1. VNet et sous-réseaux

Un réseau virtuel (VNet) isole vos ressources dans une plage d’adresses privées (10.0.0.0/8, 172.16.0.0/12 ou 192.168.0.0/16). On le découpe en sous-réseaux (applicatif, base de données, passerelle). Azure réserve les 4 premières adresses de chaque sous-réseau. Le sous-réseau GatewaySubnet (nom imposé, /27 minimum) accueille la passerelle VPN ou ExpressRoute.

Pourquoi c'est important : un plan d'adressage raté bloque les extensions futures et les appairages : chevauchement de plages, sous-réseau trop petit, GatewaySubnet mal nommé. En audit réel, la première question porte toujours sur l'isolement applicatif et base de données et sur l'exposition SSH et RDP vers Internet.
L'analogie qui aide : le VNet est un campus privé avec sa propre numérotation de rues, les sous-réseaux sont les bâtiments (cours, laboratoires, local technique de la passerelle), et le NSG est le vigile à chaque entrée qui vérifie la liste des visiteurs par ordre de priorité, du numéro le plus petit au plus grand.

2. Créer un VNet et ses sous-réseaux (Azure CLI)

az group create --name RG-Net --location francecentral

# VNet 10.1.0.0/16 avec un premier sous-réseau applicatif
az network vnet create --resource-group RG-Net --name VNet-Hub --address-prefix 10.1.0.0/16 --subnet-name Subnet-App --subnet-prefix 10.1.1.0/24

# Sous-réseau base de données + sous-réseau de passerelle
az network vnet subnet create --resource-group RG-Net --vnet-name VNet-Hub --name Subnet-DB --address-prefix 10.1.2.0/24
az network vnet subnet create --resource-group RG-Net --vnet-name VNet-Hub --name GatewaySubnet --address-prefix 10.1.255.0/27

3. Filtrer avec un NSG

Le groupe de sécurité réseau (NSG) filtre le trafic au niveau du sous-réseau ou de la carte réseau. Les règles sont évaluées par priorité croissante (100 à 4096) et la première correspondance décide (autoriser ou refuser).

Démonstration pas à pas : az network vnet create pose le plan 10.1.0.0/16 avec Subnet-App ; les deux az network vnet subnet create ajoutent Subnet-DB puis GatewaySubnet en /27 ; az network nsg create fabrique le filtre NSG-Web ; chaque az network nsg rule create ouvre un flux précis (80 et 443 vers tous, 22 restreint à 10.1.0.0/16). Le trafic suit ce chemin : Internet vers NSG, NSG vers sous-réseau, sous-réseau vers carte réseau de la VM.
az network nsg create --resource-group RG-Net --name NSG-Web

# Autoriser HTTP/HTTPS depuis Internet, SSH depuis le réseau interne uniquement
az network nsg rule create --resource-group RG-Net --nsg-name NSG-Web --name Allow-HTTP --priority 100 --destination-port-ranges 80 --protocol Tcp --access Allow --direction Inbound
az network nsg rule create --resource-group RG-Net --nsg-name NSG-Web --name Allow-HTTPS --priority 110 --destination-port-ranges 443 --protocol Tcp --access Allow --direction Inbound
az network nsg rule create --resource-group RG-Net --nsg-name NSG-Web --name Allow-SSH-Interne --priority 120 --source-address-prefixes 10.1.0.0/16 --destination-port-ranges 22 --protocol Tcp --access Allow --direction Inbound

4. Synthèse : ports à connaître

ServicePortProtocole
SSH22TCP
RDP3389TCP
HTTP / HTTPS80 / 443TCP
DNS53TCP/UDP
SMB (Azure Files)445TCP
Point d’examen : un NSG trop permissif (source « * » vers 3389/22) est un classique des QCM : restreindre la source au réseau interne ou à une adresse de rebond (Bastion). Associer le NSG au sous-réseau pour couvrir toutes ses VM.
Pièges classiques : ouvrir SSH ou RDP vers source étoile ; oublier que la première règle correspondante gagne, donc une règle de refus à priorité 100 bloque tout le reste ; nommer approximativement GatewaySubnet ; oublier les quatre adresses réservées par sous-réseau dans le dimensionnement.
À vous de jouer : le port 22 est ouvert vers Internet avec priorité 100 et vous voulez le restreindre au réseau interne sans casser le HTTPS. Quelle règle modifiez-vous et comment ?
Voir la réponse

Modifiez uniquement la règle Allow-SSH-Interne : source-address-prefixes à 10.1.0.0/16 au lieu de l'étoile, priorité 120 inchangée, et laissez les règles 100 et 110 pour HTTP et HTTPS. Associez ensuite le NSG au sous-réseau pour couvrir toutes les VM.

▶

Module 4 — Machines virtuelles : création et cycle de vie

Compute 15 %

1. Créer une VM

La commande az vm create provisionne la VM, son disque managé, sa carte réseau et un NSG par défaut. On choisit une image (Ubuntu2204, Win2022AzureEdition), une taille (B pour les charges variables, D pour un usage général, E pour la mémoire) et une méthode d’authentification (clé SSH sous Linux).

Pourquoi c'est important : la VM reste la brique de calcul la plus facturée et la plus piégée à l'examen : un arrêt simple continue de facturer le calcul, un mauvais choix de taille dégrade les performances ou double la facture, une image non généralisée bloque la duplication propre.
L'analogie qui aide : louer une VM, c'est louer un bureau meublé : l'image est le mobilier standard posé à l'entrée, la taille est la surface louée, stop garde le loyer du bureau vide, deallocate rend les clés et ne laisse que le box du stockage à payer, run-command glisse un mot sous la porte sans demander la clé SSH.
az group create --name RG-Compute --location francecentral

az vm create --resource-group RG-Compute --name VM-Web01 --image Ubuntu2204 --size Standard_B2s --admin-username azureuser --generate-ssh-keys

# Vérifier l'état et les adresses
az vm list -o table
az vm show --resource-group RG-Compute --name VM-Web01

2. Arrêter sans payer : deallocate

az vm stop arrête le système mais conserve l’allocation matérielle : la facturation du calcul continue. az vm deallocate libère le matériel et stoppe la facturation (seul le stockage reste facturé). Pour changer de taille, la VM doit être désallouée.

Démonstration pas à pas : az vm create provisionne VM-Web01 avec son disque, sa carte réseau et ses clés SSH ; az vm list et az vm show contrôlent l'état et les adresses ; az vm deallocate libère le matériel avant az vm resize vers Standard_D4s_v5, puis az vm start relance la machine ; az vm run-command invoke exécute hostname via l'agent Azure, preuve que le diagnostic passe même sans flux SSH ouvert.
# Arrêt économique puis redimensionnement
az vm deallocate --resource-group RG-Compute --name VM-Web01
az vm resize --resource-group RG-Compute --name VM-Web01 --size Standard_D4s_v5
az vm start --resource-group RG-Compute --name VM-Web01

# Exécuter un diagnostic sans ouvrir SSH (agent Azure)
az vm run-command invoke --resource-group RG-Compute --name VM-Web01 --command-id RunShellScript --scripts "hostname"

3. Synthèse : tailles et états

SérieProfilUsage typique
B (burstable)Crédits CPU, faible coûtMaquettes, petits sites
D / Ddsv5Usage général équilibréServeurs web et applicatifs
E / Edsv5Mémoire élevéeBases de données
FCalcul intensifTraitement par lots
Point d’examen : « stop » n’arrête pas la facturation, seul « deallocate » le fait. Les disques Premium SSD v2 et Ultra Disk offrent IOPS et débit configurables pour les bases exigeantes. Généraliser (sysprep) avant de créer une image.
Pièges classiques : arrêter depuis le système invité en croyant stopper la facturation ; tenter un resize sans deallocate ; créer une image depuis une VM non généralisée ; choisir une série B burstable pour une charge soutenue puis accuser le réseau.
À vous de jouer : la facture du calcul continue malgré l'arrêt de VM-Web01 depuis Ubuntu, et vous devez passer en Standard_D4s_v5. Quelle séquence tapez-vous ?
Voir la réponse

az vm deallocate puis az vm resize vers Standard_D4s_v5 puis az vm start : seul deallocate libère l'allocation matérielle et autorise le changement de taille, et seul lui stoppe la facturation du calcul.

Niveau suivant : Intermédiaire Pratiquer dans le terminal