1. Hiérarchie des ressources et gouvernance

1.1 Les quatre niveaux de portée

Tout dans Azure s'inscrit dans une hiérarchie de portées (scopes). RBAC, Azure Policy, budgets et verrous s'héritent du haut vers le bas : une affectation au niveau d'un management group s'applique à toutes les subscriptions et ressources en dessous.

Niveau	Rôle	Limites / remarques
Tenant Microsoft Entra ID	Annuaire d'identités, frontière d'authentification	Une subscription fait confiance à un seul tenant. Le changement de tenant d'une subscription supprime les affectations RBAC.
Root management group	Racine implicite (Tenant Root Group)	Non supprimable. Ne rien affecter directement dessus sauf les policies vraiment universelles.
Management groups	Regroupement logique de subscriptions pour la gouvernance	Jusqu'à 6 niveaux de profondeur (hors racine et subscription). Un parent unique par groupe.
Subscription	Unité de facturation, de quotas et frontière d'échelle	Quotas par région (vCPU par famille, IP publiques...). Frontière naturelle d'isolation entre environnements.
Resource group	Conteneur de cycle de vie	Une ressource appartient à un seul RG. Le RG a une région (métadonnées) mais peut contenir des ressources d'autres régions.

1.2 Regrouper par cycle de vie

Un resource group doit regrouper des ressources qui naissent, évoluent et meurent ensemble. Mauvais découpage typique : un RG « réseau » partagé entre plusieurs applications qui finit par contenir des NIC orphelines. Bon découpage : rg-app1-prod-frc (application), rg-network-hub-frc (connectivité partagée, gérée par l'équipe plateforme).

1.3 Convention de nommage

Le CAF propose un modèle <type>-<charge>-<env>-<région>-<instance>. Certaines ressources ont des contraintes fortes : les comptes de stockage (3-24 caractères, minuscules et chiffres, unicité globale), les Key Vault (3-24 caractères, unicité globale), les VM Windows (nom d'hôte limité à 15 caractères).

Ressource	Préfixe CAF	Exemple
Resource group	rg	rg-erp-prod-frc-001
Virtual network	vnet	vnet-hub-frc-001
Subnet	snet	snet-app-prod
NSG	nsg	nsg-snet-app-prod
Machine virtuelle	vm	vmerpapp01
Compte de stockage	st	sterpprodfrc001
Key Vault	kv	kv-erp-prod-frc
Log Analytics	log	log-platform-frc

1.4 Verrous de ressources

Les verrous CanNotDelete et ReadOnly s'appliquent au plan de contrôle (ARM), y compris pour les Owners. À poser sur les ressources critiques : hub réseau, Log Analytics central, coffres Recovery Services.

az lock create --name lock-hub-nodelete \
  --resource-group rg-network-hub-frc \
  --lock-type CanNotDelete \
  --notes "Hub de connectivite - suppression interdite"

2. Landing zone CAF

2.1 Ce qu'est une landing zone

Le Cloud Adoption Framework (CAF) définit l'Azure landing zone comme un environnement pré-configuré (identité, réseau, gouvernance, sécurité, supervision) dans lequel on dépose les charges de travail. On distingue les platform landing zones (services partagés) des application landing zones (une subscription par application/environnement).

2.2 Hiérarchie de management groups de référence

Tenant Root Group
 └── contoso (intermediate root)
      ├── Platform
      │    ├── Identity        (DC Azure, Entra Domain Services eventuel)
      │    ├── Management      (Log Analytics, Automation, Backup central)
      │    └── Connectivity    (hub, firewall, gateways, DNS)
      ├── Landing Zones
      │    ├── Corp            (charges internes, connectees au hub, pas d'IP publique)
      │    └── Online          (charges exposees Internet)
      ├── Sandbox              (experimentation, deconnecte du reseau corp)
      └── Decommissioned       (subscriptions en attente de suppression)

2.3 Options de déploiement

Option	Points forts	Points d'attention
Accélérateur portail (ALZ)	Rapide, assistant guidé	Peu reproductible, dérive difficile à suivre
ALZ Bicep (modules AVM)	Natif Azure, pas de state externe	Gestion du cycle de vie via deployment stacks / what-if
ALZ Terraform (modules AVM)	Multi-cloud, écosystème large, plan déterministe	State à protéger (compte de stockage verrouillé)

Les implémentations de référence ont évolué vers les Azure Verified Modules (AVM) ; vérifier le dépôt officiel en vigueur avant de partir sur un ancien module (ex. l'ancien module Terraform « caf-enterprise-scale »). Pour Terraform voir Terraform.

2.4 Subscription vending

À l'échelle, la création d'une subscription applicative doit être automatisée : création (alias EA/MCA), rattachement au bon management group, VNet spoke pré-peeré au hub, budget, groupes RBAC, tags obligatoires. Un pipeline (voir CI/CD) alimente par une demande déclarative garantit l'homogénéité.

# Rattacher une subscription a un management group
az account management-group subscription add \
  --name mg-corp \
  --subscription <SUBSCRIPTION_ID>

3. Réseau : hub-spoke, Virtual WAN, peering

3.1 Plan d'adressage

Le plan d'adressage est la décision la plus coûteuse à corriger. Règles :

• Allouer un super-bloc par région (ex. 10.40.0.0/14) sans chevauchement avec le on-premises, les autres clouds et les partenaires VPN.
• Azure réserve 5 adresses par subnet (réseau, passerelle .1, DNS .2 et .3, broadcast). Un /29 n'offre que 3 IP utilisables.
• Tailles minimales recommandées : GatewaySubnet /27, AzureFirewallSubnet /26, AzureBastionSubnet /26, RouteServerSubnet /27.
• Prévoir des subnets dédiés aux Private Endpoints et aux délégations (App Service VNet integration, Container Apps, SQL MI...), qui ne peuvent pas cohabiter avec autre chose.

3.2 Hub-spoke vs Virtual WAN

Critère	Hub-spoke (VNet classique)	Virtual WAN (hub managé)
Contrôle	Total : UDR, NVA tierces, tables de routage	Routage managé ; personnalisation via route tables vWAN et routing intent
Transit spoke-to-spoke	Via firewall/NVA + UDR (le peering n'est pas transitif)	Natif via le hub, inspection via routing intent
Nombre de sites/branches	Adapté à quelques sites	Conçu pour des dizaines/centaines de branches SD-WAN
Multi-région	Hubs peerés + routage manuel	Maillage hub-to-hub automatique
Coût	Paye ce qu'on déploie	Coût fixe du hub + unités de traitement
Cas typique	PME/ETI, 1-2 régions, besoin de NVA	Grand compte, réseau mondial, SD-WAN

3.3 VNet peering : ce qu'il faut savoir

• Le peering est non transitif : spoke A ↔ hub ↔ spoke B ne permet pas A → B sans un routeur (Azure Firewall/NVA) et des UDR.
• Il se configure des deux côtés ; un côté seul reste en état Initiated.
• allowGatewayTransit côté hub + useRemoteGateways côté spoke pour que le spoke utilise la VPN/ER Gateway du hub.
• allowForwardedTraffic nécessaire pour accepter du trafic relayé par une NVA.
• Global peering (inter-région) : facturé en entrée et en sortie, latence de la distance.
• Modifier l'espace d'adressage d'un VNet peeré est possible, mais il faut ensuite resynchroniser le peering (az network vnet peering sync).

# Peering hub -> spoke (cote hub)
az network vnet peering create -g rg-network-hub-frc \
  --name peer-hub-to-erp --vnet-name vnet-hub-frc-001 \
  --remote-vnet /subscriptions/<SUBSCRIPTION_ID>/resourceGroups/rg-erp-prod-frc/providers/Microsoft.Network/virtualNetworks/vnet-erp-prod-frc \
  --allow-vnet-access --allow-forwarded-traffic --allow-gateway-transit

# Peering spoke -> hub (cote spoke)
az network vnet peering create -g rg-erp-prod-frc \
  --name peer-erp-to-hub --vnet-name vnet-erp-prod-frc \
  --remote-vnet /subscriptions/<SUBSCRIPTION_ID>/resourceGroups/rg-network-hub-frc/providers/Microsoft.Network/virtualNetworks/vnet-hub-frc-001 \
  --allow-vnet-access --allow-forwarded-traffic --use-remote-gateways

3.4 Routage : UDR et propagation

Pour forcer le trafic d'un spoke à passer par le firewall du hub, on associe au subnet une route table :

az network route-table create -g rg-erp-prod-frc -n rt-erp-prod \
  --disable-bgp-route-propagation true

az network route-table route create -g rg-erp-prod-frc --route-table-name rt-erp-prod \
  -n default-to-fw --address-prefix 0.0.0.0/0 \
  --next-hop-type VirtualAppliance --next-hop-ip-address 10.40.0.4

az network vnet subnet update -g rg-erp-prod-frc --vnet-name vnet-erp-prod-frc \
  -n snet-app-prod --route-table rt-erp-prod

4. Filtrage : NSG, ASG, Azure Firewall

4.1 Network Security Groups

Le NSG est un filtre L4 stateful, associé à un subnet et/ou une NIC. Les deux sont évalués : en entrée subnet puis NIC, en sortie NIC puis subnet. Priorité de 100 à 4096, la plus petite gagne.

Règle par défaut	Effet	Conséquence
AllowVnetInBound (65000)	Autorise tout le tag VirtualNetwork	Le tag inclut les VNets peerés et les préfixes on-prem appris : le mouvement latéral est ouvert par défaut
AllowAzureLoadBalancerInBound (65001)	Sondes du LB (168.63.129.16)	Ne jamais bloquer : les sondes de santé échoueraient
DenyAllInBound (65500)	Refus implicite	-
AllowInternetOutBound (65001)	Sortie Internet libre	À surcharger si sortie imposée par le firewall

4.2 Application Security Groups

Les ASG permettent d'écrire des règles par rôle applicatif plutôt que par IP : les NIC sont membres d'ASG, les règles NSG référencent les ASG. Contrainte : tous les membres d'un ASG et le NSG doivent être dans le même VNet.

az network asg create -g rg-erp-prod-frc -n asg-erp-web
az network asg create -g rg-erp-prod-frc -n asg-erp-db

az network nsg rule create -g rg-erp-prod-frc --nsg-name nsg-snet-app-prod \
  -n allow-web-to-db --priority 200 --direction Inbound --access Allow \
  --protocol Tcp --destination-port-ranges 1433 \
  --source-asgs asg-erp-web --destination-asgs asg-erp-db

az network nic ip-config update -g rg-erp-prod-frc --nic-name vmerpweb01-nic \
  -n ipconfig1 --application-security-groups asg-erp-web

4.3 Azure Firewall

SKU	Fonctions	Usage
Basic	Filtrage L3-L7, débit limité	PME, faible trafic
Standard	Règles réseau/application, FQDN, threat intelligence, proxy DNS	Cas général
Premium	+ IDPS, inspection TLS, filtrage URL, catégories web	Secteurs réglementés, inspection de la sortie

Les règles sont portées par une Firewall Policy (héritable : policy parente globale + policy enfant régionale), organisée en rule collection groups traités par priorité. Ordre d'évaluation : DNAT, puis réseau, puis application. Une règle réseau qui matche court-circuite les règles application.

az network firewall policy rule-collection-group collection add-filter-collection \
  -g rg-network-hub-frc --policy-name afwp-hub-frc \
  --rule-collection-group-name rcg-spokes --name app-allow-updates \
  --collection-priority 300 --action Allow --rule-type ApplicationRule \
  --rule-name windows-update --source-addresses 10.40.16.0/20 \
  --protocols Https=443 --fqdn-tags WindowsUpdate

5. Private Endpoints et DNS privé hybride

5.1 Service Endpoint vs Private Endpoint

Critère	Service Endpoint	Private Endpoint (Private Link)
Adresse du service	Reste publique	IP privée dans votre subnet
Accès depuis on-prem	Non	Oui (via VPN/ER)
Exfiltration	Ouvre tout le service pour le subnet (sauf policies)	Limité à l'instance ciblée
DNS	Aucun changement	Zone Private DNS obligatoire
Coût	Gratuit	Horaire + volumétrie

5.2 Mécanique DNS d'un Private Endpoint

Pour un compte de stockage sterpprodfrc001 avec Private Endpoint blob, la résolution publique devient :

sterpprodfrc001.blob.core.windows.net
  CNAME sterpprodfrc001.privatelink.blob.core.windows.net
  (puis, sans zone privee : CNAME vers l'IP publique du service)

La zone Private DNS privatelink.blob.core.windows.net, liée au VNet, contient l'enregistrement A sterpprodfrc001 -> 10.40.20.5. Le client garde l'URL publique (le certificat TLS reste valide) et résout l'IP privée.

• Une zone Private DNS par type de sous-ressource (privatelink.blob..., privatelink.file..., privatelink.vaultcore.azure.net, privatelink.database.windows.net...).
• Centraliser les zones dans la subscription Connectivity et les lier au hub (et aux spokes si les spokes utilisent le DNS Azure).
• Utiliser le DNS zone group du Private Endpoint pour que l'enregistrement A soit créé/supprimé automatiquement. Une Azure Policy DeployIfNotExists peut l'imposer.

5.3 Le piège de la résolution DNS hybride

L'adresse 168.63.129.16 (résolveur Azure) n'est joignable que depuis l'intérieur d'Azure. Il faut donc un relais : Azure DNS Private Resolver.

• Inbound endpoint (subnet dédié, /28 minimum, délégué à Microsoft.Network/dnsResolvers) : IP privée vers laquelle les DNS on-prem font un redirecteur conditionnel.
• Outbound endpoint + forwarding ruleset : pour que les VNets Azure résolvent les zones on-prem (corp.contoso.com vers les DC).

# Sur les DNS Windows on-prem : redirecteur conditionnel vers l'inbound endpoint
Add-DnsServerConditionalForwarderZone -Name "blob.core.windows.net" `
  -MasterServers 10.40.4.4 -ReplicationScope Forest
Add-DnsServerConditionalForwarderZone -Name "vaultcore.azure.net" `
  -MasterServers 10.40.4.4 -ReplicationScope Forest

5.4 Création complète en CLI

az network private-dns zone create -g rg-dns-frc -n privatelink.blob.core.windows.net
az network private-dns link vnet create -g rg-dns-frc \
  -z privatelink.blob.core.windows.net -n link-hub \
  -v /subscriptions/<SUBSCRIPTION_ID>/resourceGroups/rg-network-hub-frc/providers/Microsoft.Network/virtualNetworks/vnet-hub-frc-001 \
  --registration-enabled false

az network private-endpoint create -g rg-erp-prod-frc -n pe-sterpprod-blob \
  --vnet-name vnet-erp-prod-frc --subnet snet-pe \
  --private-connection-resource-id $(az storage account show -n sterpprodfrc001 --query id -o tsv) \
  --group-id blob --connection-name pec-sterpprod-blob

az network private-endpoint dns-zone-group create -g rg-erp-prod-frc \
  --endpoint-name pe-sterpprod-blob -n default \
  --private-dns-zone /subscriptions/<SUBSCRIPTION_ID>/resourceGroups/rg-dns-frc/providers/Microsoft.Network/privateDnsZones/privatelink.blob.core.windows.net \
  --zone-name blob

az storage account update -n sterpprodfrc001 --public-network-access Disabled

6. Connectivité hybride : VPN Gateway et ExpressRoute

6.1 Comparatif

Critère	VPN Gateway (S2S IPsec)	ExpressRoute
Transport	Internet chiffré IPsec/IKEv2	Circuit privé opérateur (non chiffré par défaut)
Débit	Selon SKU (VpnGw1AZ à VpnGw5AZ)	50 Mb/s à 10 Gb/s (100 Gb/s en ExpressRoute Direct)
Latence	Variable (Internet)	Prévisible, SLA
Délai de mise en œuvre	Heures	Semaines (opérateur)
Chiffrement	Natif	MACsec (Direct) ou IPsec par-dessus
Usage	Sites secondaires, secours d'ER	Liaison principale datacenter

6.2 VPN Gateway : choix de conception

• Choisir les SKU AZ (zone-redundant). Microsoft a engagé la migration des SKU non-AZ et du SKU Basic legacy : vérifier le calendrier dans la doc éditeur.
• Active-active : deux instances, deux IP publiques, deux tunnels par site. Indispensable pour supporter une maintenance sans coupure.
• BGP plutôt que des réseaux statiques (local network gateway) dès qu'il y a plusieurs sites ou un secours ER.
• Politique IPsec personnalisée pour s'aligner avec le pare-feu on-prem (voir Pare-feu).

az network vpn-connection ipsec-policy add -g rg-network-hub-frc \
  --connection-name cn-paris-dc \
  --ike-encryption GCMAES256 --ike-integrity SHA384 --dh-group ECP384 \
  --ipsec-encryption GCMAES256 --ipsec-integrity GCMAES256 --pfs-group ECP384 \
  --sa-lifetime 27000 --sa-max-size 102400000

6.3 ExpressRoute : points clés

• Private peering pour les VNets ; Microsoft peering pour les services publics Microsoft (rarement nécessaire aujourd'hui, à justifier).
• Le circuit a deux liens (primaire/secondaire) : les deux sessions BGP doivent être UP, sinon pas de redondance.
• Gateway ER en SKU zone-redundant (ErGw1AZ et supérieurs) ; FastPath pour contourner la gateway sur le plan de données (gros débits).
• Préférence de chemin ER/VPN : l'ER est préférée pour un même préfixe ; pour un VPN de secours, annoncer des préfixes identiques et contrôler avec AS-path prepend côté on-prem.
• Limite de préfixes annoncés en private peering (selon SKU) : au-delà, la session BGP tombe. Agréger.

7. RBAC, Azure Policy et tags

7.1 Azure RBAC vs rôles Entra

Deux systèmes distincts : les rôles Entra (Global Administrator, User Administrator...) gèrent l'annuaire ; Azure RBAC (Owner, Contributor, Reader...) gère les ressources. Un Global Administrator n'a aucun droit Azure par défaut, mais peut s'élever (Access management for Azure resources) et obtenir User Access Administrator sur la racine : à surveiller dans les journaux. Voir Microsoft Entra ID.

Rôle intégré	Peut	Ne peut pas
Owner	Tout, y compris déléguer	-
Contributor	Créer/modifier/supprimer les ressources	Affecter des rôles, gérer les blueprints/policies d'affectation
Reader	Lire le plan de contrôle	Lire les secrets / clés (listKeys)
User Access Administrator	Gérer les affectations RBAC	Modifier les ressources
Role Based Access Control Administrator	Affecter des rôles avec conditions (restreindre les rôles délégables)	-

7.2 Bonnes pratiques RBAC

• Affecter à des groupes Entra, jamais à des utilisateurs nominatifs.
• Owner et User Access Administrator en PIM (éligible, activation justifiée et limitée dans le temps).
• Rôles personnalisés : partir d'un rôle intégré, retirer, ne jamais mettre * en actions avec des notActions (les nouvelles actions publiées par Microsoft seraient automatiquement accordées).
• Limite d'affectations RBAC par subscription (plusieurs milliers) : à surveiller dans les grandes organisations.

# Affectations directes a des utilisateurs (a eliminer)
az role assignment list --all --query "[?principalType=='User'].{who:principalName, role:roleDefinitionName, scope:scope}" -o table

# Affecter un role a un groupe sur un RG
az role assignment create --assignee-object-id <GROUP_OBJECT_ID> \
  --assignee-principal-type Group --role "Contributor" \
  --scope /subscriptions/<SUBSCRIPTION_ID>/resourceGroups/rg-erp-prod-frc

7.3 Azure Policy

Effet	Comportement	Exemple
Deny	Bloque la création/modification non conforme	Régions autorisées, SKU VM autorisés
Audit	Signale sans bloquer	Phase d'observation
Modify	Ajoute/modifie des propriétés (tags, flags)	Hériter le tag CostCenter du RG
DeployIfNotExists	Déploie une ressource associée (identité managée requise)	Diagnostic settings, DNS zone group, agent AMA
DenyAction	Bloque une action (ex. suppression)	Interdire la suppression des Log Analytics
Disabled	Désactive la règle	Paramétrage d'initiative

# Affecter la policy "Allowed locations" au management group Landing Zones
az policy assignment create --name pa-allowed-locations \
  --scope /providers/Microsoft.Management/managementGroups/mg-landingzones \
  --policy e56962a6-4747-49cd-b67b-bf8b01975c4c \
  --params '{ "listOfAllowedLocations": { "value": ["francecentral","westeurope"] } }'

# Etat de conformite
az policy state summarize --management-group mg-landingzones

# Lancer la remediation d'une policy DeployIfNotExists
az policy remediation create -n rem-diag --policy-assignment pa-diag-settings \
  --management-group mg-landingzones

7.4 Tags

• Tags obligatoires typiques : Environment, Owner, CostCenter, Application, DataClassification.
• Les tags ne s'héritent pas nativement : utiliser la policy intégrée « Inherit a tag from the resource group » (effet Modify).
• Cost Management permet aussi l'héritage des tags pour la facturation (paramètre au niveau de la facturation), sans modifier les ressources.
• Les tags sont des métadonnées en clair, visibles par tout Reader : n'y mettre aucune donnée sensible.

8. Identités managées et Key Vault

8.1 System-assigned vs user-assigned

Critère	System-assigned	User-assigned
Cycle de vie	Lié à la ressource (supprimé avec elle)	Indépendant
Partage	Une ressource	Plusieurs ressources
Pré-provisionnement des droits	Impossible avant création	Possible (RBAC posé avant le déploiement)
Cas typique	Une VM qui lit un Key Vault	Pool de VMSS, AKS, déploiements IaC, workload identity federation

Depuis une VM, le jeton s'obtient via l'endpoint IMDS (non routable, interne à l'hôte) :

curl -s -H "Metadata: true" \
  "http://169.254.169.254/metadata/identity/oauth2/token?api-version=2018-02-01&resource=https://vault.azure.net"

8.2 Key Vault : conception

• Modèle d'autorisation RBAC (et non les access policies legacy) : granularité par secret possible, gestion via PIM, cohérent avec le reste d'Azure.
• Un coffre par application et par environnement : la frontière de sécurité et de throttling est le coffre.
• Soft delete (obligatoire, 7 à 90 jours) + purge protection (irréversible une fois activée) en production.
• Accès public désactivé + Private Endpoint (privatelink.vaultcore.azure.net).
• Managed HSM si exigence FIPS 140-3 niveau 3 ou contrôle exclusif des clés.

az keyvault create -g rg-erp-prod-frc -n kv-erp-prod-frc -l francecentral \
  --enable-rbac-authorization true --enable-purge-protection true \
  --retention-days 90 --public-network-access Disabled

# Donner a l'identite managee de la VM la lecture des secrets
az role assignment create --assignee-object-id <MI_PRINCIPAL_ID> \
  --assignee-principal-type ServicePrincipal --role "Key Vault Secrets User" \
  --scope $(az keyvault show -n kv-erp-prod-frc --query id -o tsv)

# Rotation : date d'expiration explicite
az keyvault secret set --vault-name kv-erp-prod-frc -n db-password \
  --file ./secret.txt --expires "2027-04-01T00:00:00Z"

9. Machines virtuelles : tailles, disques, zones

9.1 Lire un nom de taille

Format : [Famille][Sous-famille][vCPU][Fonctionnalités]_[Version]. Exemple Standard_D4as_v5 : famille D (usage général), 4 vCPU, a = AMD, s = support Premium SSD, v5.

Famille	Profil	Usage
B	Burstable (crédits CPU)	Jump hosts, faible charge ; piège si charge soutenue (crédits épuisés = CPU bridé)
D	Usage général, ratio 4 Go/vCPU	Serveurs applicatifs, AD
E	Mémoire, 8 Go/vCPU	SQL Server, caches
F	Calcul, 2 Go/vCPU	Batch, frontaux
L	Stockage local NVMe	Bases distribuées, big data
M	Très grande mémoire	SAP HANA
N	GPU	IA, VDI graphique

9.2 Disques managés

Type	Caractéristiques	Usage
Standard HDD	Faible coût, latence élevée	Archives, non-prod
Standard SSD	Latence correcte, IOPS limitées	Serveurs peu sollicités
Premium SSD	IOPS/débit liés à la taille (palier P), bursting	Production générale
Premium SSD v2	IOPS, débit et taille réglables indépendamment	Bases de données ; restrictions (pas de disque OS, cache hôte non supporté) à vérifier
Ultra Disk	Latence sub-milliseconde, très hautes IOPS	Bases transactionnelles critiques

• Cache hôte : ReadOnly pour les disques de données SQL, None pour les journaux de transactions, ReadWrite uniquement disque OS.
• Le disque temporaire (D: sous Windows, /mnt ou /dev/sdb sous Linux) est perdu au redéploiement/redimensionnement : jamais de données persistantes.
• Chiffrement : SSE avec clé plateforme par défaut ; CMK via Disk Encryption Set ; encryption at host pour chiffrer aussi cache et disque temporaire. Azure Disk Encryption (BitLocker/dm-crypt) est en voie de retrait au profit d'encryption at host : vérifier le calendrier.

9.3 Disponibilité

Option	Protection contre	SLA indicatif (doc éditeur fait foi)
VM unique Premium SSD	-	99,9 %
Availability Set	Panne de rack / maintenance (fault & update domains)	99,95 %
Availability Zones (2+ VM réparties)	Perte d'un datacenter de la région	99,99 %
VMSS Flexible multi-zones	Idem + élasticité	99,99 %

Les zones n'apportent rien sans répartition applicative : Load Balancer Standard zone-redundant, IP publiques Standard zone-redundant, réplication de données (Always On AG, cluster). Ne pas oublier que les IP publiques Basic ont été retirées.

az vm create -g rg-erp-prod-frc -n vmerpapp01 \
  --image Win2025Datacenter --size Standard_D4as_v5 --zone 1 \
  --vnet-name vnet-erp-prod-frc --subnet snet-app-prod --public-ip-address "" \
  --nsg "" --admin-username azadmin --admin-password "$ADMIN_PWD" \
  --security-type TrustedLaunch --enable-secure-boot true --enable-vtpm true \
  --encryption-at-host true --assign-identity \
  --os-disk-delete-option Delete --nic-delete-option Delete

10. Azure Backup et Site Recovery

10.1 Coffres et politiques

Coffre	Protège
Recovery Services vault	VM Azure, SQL/SAP HANA dans VM, Azure Files, agent MARS, ASR
Backup vault	Disques managés, blobs, PostgreSQL flexible, AKS

• Politique VM Enhanced : plusieurs sauvegardes par jour, nécessaire pour Trusted Launch et Premium SSD v2/Ultra.
• Instant restore : snapshots conservés localement 1 à 5 jours (restauration rapide) avant transfert dans le coffre.
• Redondance du coffre : LRS/ZRS/GRS, à fixer avant la première sauvegarde (non modifiable ensuite). Cross Region Restore nécessite GRS.

10.2 Protection contre le ransomware

• Soft delete (14 jours par défaut, extensible) et soft delete « always-on ».
• Immutable vault : empêche la réduction de rétention et la suppression des points de restauration ; une fois verrouillé, c'est irréversible.
• Multi-user authorization (MUA) via Resource Guard dans un autre tenant/subscription : les opérations critiques (désactiver soft delete, réduire la rétention) exigent l'approbation d'un second administrateur.
• Copie hors Azure ou dans un autre tenant pour les données vitales (stratégie 3-2-1-1-0, voir Stratégie de sauvegarde).

az backup vault create -g rg-backup-frc -n rsv-prod-frc -l francecentral
az backup vault backup-properties set -g rg-backup-frc -n rsv-prod-frc \
  --backup-storage-redundancy GeoRedundant --cross-region-restore-flag true

az backup protection enable-for-vm -g rg-backup-frc --vault-name rsv-prod-frc \
  --vm $(az vm show -g rg-erp-prod-frc -n vmerpapp01 --query id -o tsv) \
  --policy-name EnhancedPolicy-Daily

# Declencher une sauvegarde a la demande (retention 30 jours)
az backup protection backup-now -g rg-backup-frc --vault-name rsv-prod-frc \
  --container-name vmerpapp01 --item-name vmerpapp01 \
  --backup-management-type AzureIaasVM --retain-until 19-11-2026

10.3 Azure Site Recovery

ASR réplique en continu les VM vers une région (ou zone) secondaire. RPO de l'ordre de quelques secondes à minutes ; RTO dépendant de l'orchestration (recovery plans).

• Préparer le réseau cible (VNet, NSG, DNS, gateway) avant : ASR crée les VM, pas l'environnement.
• Recovery plans : groupes de démarrage (AD/DNS, puis bases, puis applicatif), scripts Automation pour les changements DNS/LB.
• Test failover trimestriel dans un VNet isolé : il ne perturbe pas la réplication.
• Les contrôleurs de domaine ne se restaurent pas « au hasard » : privilégier un DC permanent dans la région secondaire plutôt que de répliquer un DC (risque USN rollback géré par VM-GenerationID, mais complexité inutile).

11. Stockage : redondance, tiers, immutabilité

11.1 Redondance

Option	Copies	Protège contre	Lecture secondaire
LRS	3 dans un datacenter	Panne disque/rack	-
ZRS	3 réparties sur 3 zones	Perte d'une zone	-
GRS	LRS + LRS en région appairée (asynchrone)	Perte de région	Non (sauf RA-GRS)
GZRS	ZRS + LRS en région appairée	Zone + région	Non (sauf RA-GZRS)

11.2 Tiers d'accès blob

Tier	Stockage	Accès	Durée minimale facturée
Hot	Cher	Bon marché	-
Cool	Moins cher	Plus cher	30 jours
Cold	Encore moins cher	Plus cher	90 jours
Archive	Très bon marché	Réhydratation (heures)	180 jours

Lifecycle management : déplacer automatiquement selon l'ancienneté (ou le dernier accès si le suivi est activé).

{
  "rules": [{
    "name": "logs-tiering",
    "enabled": true,
    "type": "Lifecycle",
    "definition": {
      "filters": { "blobTypes": ["blockBlob"], "prefixMatch": ["logs/"] },
      "actions": {
        "baseBlob": {
          "tierToCool":    { "daysAfterModificationGreaterThan": 30 },
          "tierToArchive": { "daysAfterModificationGreaterThan": 180 },
          "delete":        { "daysAfterModificationGreaterThan": 2555 }
        }
      }
    }
  }]
}

az storage account management-policy create --account-name sterpprodfrc001 \
  -g rg-erp-prod-frc --policy @lifecycle.json

11.3 Protection des données

• Soft delete blobs et conteneurs, versioning, point-in-time restore pour les block blobs.
• Immutabilité WORM : politique « time-based retention » ou « legal hold », au niveau conteneur ou version. Une politique verrouillée ne peut plus être raccourcie ni supprimée, même par Microsoft : à valider juridiquement (et budgétairement) avant de verrouiller.
• Désactiver l'accès anonyme (allowBlobPublicAccess=false), la clé partagée quand c'est possible, imposer TLS 1.2 minimum.
• SAS : préférer les User Delegation SAS (signées par un jeton Entra, révocables) aux SAS de compte signées par la clé.

az storage account update -n sterpprodfrc001 -g rg-erp-prod-frc \
  --allow-blob-public-access false --allow-shared-key-access false \
  --min-tls-version TLS1_2 --https-only true

az storage account blob-service-properties update --account-name sterpprodfrc001 \
  -g rg-erp-prod-frc --enable-versioning true \
  --enable-delete-retention true --delete-retention-days 30 \
  --enable-container-delete-retention true --container-delete-retention-days 30

12. Azure Monitor, Log Analytics et KQL

12.1 Architecture de collecte

• Activity Log : opérations du plan de contrôle (90 jours en natif) → à exporter vers Log Analytics via diagnostic setting de subscription.
• Resource logs : via diagnostic settings par ressource (imposer par Azure Policy).
• Métriques plateforme : 93 jours, sans configuration.
• Invités VM : Azure Monitor Agent (AMA) piloté par des Data Collection Rules (DCR). Le Log Analytics agent (MMA/OMS) est retiré depuis août 2024 : toute VM qui l'utilise encore est à migrer.
• Serveurs on-prem : via Azure Arc + AMA.

12.2 Plans de tables et rétention

Plan	Usage	Limites
Analytics	Requêtes interactives, alertes	Coût d'ingestion le plus élevé
Basic	Logs de débogage volumineux	Requêtes facturées, fonctions KQL limitées
Auxiliary	Logs d'audit très volumineux, rarement interrogés	Performances de requête réduites

Les capacités exactes de chaque plan évoluent : vérifier la doc éditeur avant de basculer une table utilisée par des alertes.

12.3 Requêtes KQL utiles

// Qui a supprime quoi dans les 7 derniers jours
AzureActivity
| where TimeGenerated > ago(7d)
| where OperationNameValue endswith "/DELETE" and ActivityStatusValue == "Success"
| project TimeGenerated, Caller, OperationNameValue, ResourceGroup, _ResourceId
| order by TimeGenerated desc

// Affectations de roles RBAC creees
AzureActivity
| where TimeGenerated > ago(30d)
| where OperationNameValue =~ "Microsoft.Authorization/roleAssignments/write"
| where ActivityStatusValue == "Success"
| extend props = parse_json(Properties)
| project TimeGenerated, Caller, Scope = tostring(props.entity)

// VM dont le heartbeat AMA est absent depuis 15 minutes
Heartbeat
| summarize LastSeen = max(TimeGenerated) by Computer, _ResourceId
| where LastSeen < ago(15m)
| order by LastSeen asc

// CPU moyen et P95 par VM (perf collectee par DCR)
Perf
| where TimeGenerated > ago(1d)
| where ObjectName == "Processor" and CounterName == "% Processor Time" and InstanceName == "_Total"
| summarize avg(CounterValue), percentile(CounterValue, 95) by Computer, bin(TimeGenerated, 1h)
| render timechart

// Flux refuses par Azure Firewall (tables resource-specific)
AZFWNetworkRule
| where TimeGenerated > ago(1h) and Action == "Deny"
| summarize Hits = count() by SourceIp, DestinationIp, DestinationPort, Protocol
| top 20 by Hits

// Tables qui coutent le plus en ingestion (30 jours)
Usage
| where TimeGenerated > ago(30d) and IsBillable == true
| summarize GB = sum(Quantity) / 1024 by DataType
| order by GB desc

12.4 Alertes

• Metric alerts : quasi temps réel, dimensions (une alerte pour N VM).
• Log search alerts : sur requête KQL, fréquence 1 à 15 min (coût par fréquence).
• Activity log alerts : Service Health (incidents Azure, maintenances planifiées) et opérations sensibles.
• Les action groups sont partagés ; les alert processing rules suppriment les notifications pendant les fenêtres de maintenance.
• Les « Azure Monitor Baseline Alerts » (AMBA) fournissent un socle d'alertes par policy pour la landing zone.

Pour intégrer à une supervision existante, voir Monitoring.

13. Maîtrise des coûts (FinOps)

13.1 Leviers d'engagement

Levier	Portée	Flexibilité	Quand
Reserved Instances (1 ou 3 ans)	Famille de VM + région (flexibilité de taille dans la famille)	Faible ; échanges/annulations encadrés	Charge stable, famille connue (BDD)
Savings Plan for Compute	Engagement horaire en €, toutes régions/familles éligibles	Élevée	Parc qui évolue
Azure Hybrid Benefit	Licences Windows Server / SQL avec Software Assurance	-	Dès qu'on a les licences
Spot VMs	Capacité excédentaire, évictable	-	Batch, CI, rendu
Dev/Test pricing	Subscriptions Dev/Test	-	Non-prod

13.2 Budgets et anomalies

az consumption budget create --budget-name bud-erp-prod \
  --amount 5000 --category cost --time-grain monthly \
  --start-date 2026-11-01 --end-date 2027-10-31 \
  --resource-group rg-erp-prod-frc

• Seuils réels et prévisionnels (alerte à 100 % forecast pour agir avant dépassement).
• Un budget ne bloque rien : il notifie, ou déclenche un action group (runbook d'arrêt pour du sandbox).
• Activer les alertes d'anomalies de Cost Management par subscription.
• Exports quotidiens (format FOCUS disponible) vers un compte de stockage pour l'analyse dans un outil BI.

13.3 Gaspillages fréquents

# Disques manages non attaches
az disk list --query "[?diskState=='Unattached'].{name:name, rg:resourceGroup, sizeGb:diskSizeGb, sku:sku.name}" -o table

# IP publiques non associees
az network public-ip list --query "[?ipConfiguration==null && natGateway==null].{name:name, rg:resourceGroup}" -o table

# VM arretees mais non desallouees (toujours facturees en calcul)
az vm list -d --query "[?powerState=='VM stopped'].{name:name, rg:resourceGroup}" -o table

• Snapshots anciens, NIC orphelines, gateways de test oubliées (une VPN/ER gateway coûte même sans trafic).
• Egress inter-région et Internet, Private Endpoints à très fort trafic, ingestion Log Analytics (logs de debug en Analytics).
• Arrêter une VM depuis l'OS ne la désalloue pas : utiliser az vm deallocate.

14. Automatisation : az CLI, PowerShell Az, Bicep

14.1 Authentification non interactive

Contexte	Méthode recommandée
Pipeline GitHub Actions / Azure DevOps / GitLab	Workload identity federation (OIDC), aucun secret stocké
Script sur VM Azure	Identité managée (az login --identity)
Serveur on-prem	Azure Arc + identité managée, sinon principal de service avec certificat
Poste admin	Interactif + MFA (obligatoire pour la gestion Azure)

14.2 az CLI : techniques utiles

# Contexte
az login --tenant <TENANT_ID>
az account set --subscription <SUBSCRIPTION_ID>

# JMESPath + sortie tsv pour le scripting
az vm list --query "[?tags.Environment=='prod'].id" -o tsv | \
  xargs -I{} az vm deallocate --ids {} --no-wait

# Azure Resource Graph : inventaire multi-subscriptions instantane
az graph query -q "
Resources
| where type =~ 'microsoft.compute/virtualmachines'
| extend size = tostring(properties.hardwareProfile.vmSize)
| summarize count() by size, location
| order by count_ desc" --first 1000

# Ressources sans tag Owner
az graph query -q "Resources | where isnull(tags.Owner) | project name, type, resourceGroup, subscriptionId"

14.3 PowerShell Az

Connect-AzAccount -Tenant '<TENANT_ID>'
Set-AzContext -Subscription '<SUBSCRIPTION_ID>'

# Rapport des VM avec taille, zone et etat
Get-AzVM -Status | Select-Object Name, ResourceGroupName,
    @{n='Size';e={$_.HardwareProfile.VmSize}},
    @{n='Zone';e={$_.Zones -join ','}},
    PowerState | Export-Csv .\vms.csv -NoTypeInformation -Encoding utf8

# Toutes les subscriptions : NSG avec regle entrante ouverte a Internet sur 3389/22
Get-AzSubscription | ForEach-Object {
    Set-AzContext -SubscriptionObject $_ | Out-Null
    Get-AzNetworkSecurityGroup | ForEach-Object {
        $nsg = $_
        $nsg.SecurityRules | Where-Object {
            $_.Direction -eq 'Inbound' -and $_.Access -eq 'Allow' -and
            ($_.SourceAddressPrefix -in @('*','Internet','0.0.0.0/0')) -and
            ($_.DestinationPortRange -match '^(22|3389|\*)$')
        } | Select-Object @{n='NSG';e={$nsg.Name}}, Name, DestinationPortRange
    }
}

Pour les bonnes pratiques de signature et d'exécution des scripts, voir Sécurité PowerShell.

14.4 Bicep : exemple complet de spoke

Fichier spoke.bicep : VNet spoke, NSG, route table vers le firewall, peering vers le hub (le peering retour côté hub est déployé par un module à la portée du RG hub).

targetScope = 'resourceGroup'

@description('Nom court de la charge de travail')
param workload string

@allowed([ 'prod', 'nonprod' ])
param env string

param location string = resourceGroup().location
param addressPrefix string
param appSubnetPrefix string
param peSubnetPrefix string
param firewallPrivateIp string
param hubVnetId string

@description('Tags obligatoires')
param tags object = {
  Environment: env
  Application: workload
}

var vnetName = 'vnet-${workload}-${env}-${location}'

resource nsgApp 'Microsoft.Network/networkSecurityGroups@2024-05-01' = {
  name: 'nsg-snet-app-${workload}-${env}'
  location: location
  tags: tags
  properties: {
    securityRules: [
      {
        name: 'deny-vnet-inbound'
        properties: {
          priority: 4000
          direction: 'Inbound'
          access: 'Deny'
          protocol: '*'
          sourceAddressPrefix: 'VirtualNetwork'
          sourcePortRange: '*'
          destinationAddressPrefix: '*'
          destinationPortRange: '*'
        }
      }
    ]
  }
}

resource rt 'Microsoft.Network/routeTables@2024-05-01' = {
  name: 'rt-${workload}-${env}'
  location: location
  tags: tags
  properties: {
    disableBgpRoutePropagation: true
    routes: [
      {
        name: 'default-to-firewall'
        properties: {
          addressPrefix: '0.0.0.0/0'
          nextHopType: 'VirtualAppliance'
          nextHopIpAddress: firewallPrivateIp
        }
      }
    ]
  }
}

resource vnet 'Microsoft.Network/virtualNetworks@2024-05-01' = {
  name: vnetName
  location: location
  tags: tags
  properties: {
    addressSpace: { addressPrefixes: [ addressPrefix ] }
    subnets: [
      {
        name: 'snet-app'
        properties: {
          addressPrefix: appSubnetPrefix
          networkSecurityGroup: { id: nsgApp.id }
          routeTable: { id: rt.id }
          defaultOutboundAccess: false
        }
      }
      {
        name: 'snet-pe'
        properties: {
          addressPrefix: peSubnetPrefix
          privateEndpointNetworkPolicies: 'Enabled'
          defaultOutboundAccess: false
        }
      }
    ]
  }
}

resource peerToHub 'Microsoft.Network/virtualNetworks/virtualNetworkPeerings@2024-05-01' = {
  parent: vnet
  name: 'peer-to-hub'
  properties: {
    remoteVirtualNetwork: { id: hubVnetId }
    allowVirtualNetworkAccess: true
    allowForwardedTraffic: true
    useRemoteGateways: true
  }
}

output vnetId string = vnet.id
output appSubnetId string = vnet.properties.subnets[0].id

Fichier de paramètres spoke.prod.bicepparam :

using './spoke.bicep'

param workload = 'erp'
param env = 'prod'
param addressPrefix = '10.40.16.0/22'
param appSubnetPrefix = '10.40.16.0/24'
param peSubnetPrefix = '10.40.17.0/26'
param firewallPrivateIp = '10.40.0.4'
param hubVnetId = '/subscriptions/<SUBSCRIPTION_ID>/resourceGroups/rg-network-hub-frc/providers/Microsoft.Network/virtualNetworks/vnet-hub-frc-001'

Déploiement avec prévisualisation :

az bicep upgrade
az bicep lint --file spoke.bicep

az deployment group what-if -g rg-erp-prod-frc \
  --template-file spoke.bicep --parameters spoke.prod.bicepparam

az deployment group create -g rg-erp-prod-frc -n spoke-$(date +%Y%m%d%H%M) \
  --template-file spoke.bicep --parameters spoke.prod.bicepparam

# Deployment stack : gere le cycle de vie et protege contre les modifications manuelles
az stack group create -n stack-erp-spoke -g rg-erp-prod-frc \
  --template-file spoke.bicep --parameters spoke.prod.bicepparam \
  --action-on-unmanage detachAll --deny-settings-mode denyDelete

Comparatif avec Terraform et intégration en pipeline : Terraform, CI/CD.

15. Dépannage

15.1 Outils de diagnostic réseau

# Regles NSG effectives sur une NIC (subnet + NIC combines)
az network nic list-effective-nsg -g rg-erp-prod-frc -n vmerpapp01-nic

# Routes effectives (systeme + UDR + BGP)
az network nic show-effective-route-table -g rg-erp-prod-frc -n vmerpapp01-nic -o table

# Network Watcher : un paquet serait-il autorise ?
az network watcher test-ip-flow --vm vmerpapp01 -g rg-erp-prod-frc \
  --direction Outbound --protocol TCP \
  --local 10.40.16.4:60000 --remote 10.40.17.5:443

# Prochain saut pour une destination
az network watcher show-next-hop --vm vmerpapp01 -g rg-erp-prod-frc \
  --source-ip 10.40.16.4 --dest-ip 192.168.10.20

# Test de connectivite de bout en bout
az network watcher test-connectivity --source-resource vmerpapp01 -g rg-erp-prod-frc \
  --dest-address sterpprodfrc001.blob.core.windows.net --dest-port 443

Les VNet flow logs remplacent les NSG flow logs (en cours de retrait) : à activer sur les VNets sensibles, analyse via Traffic Analytics.

15.2 Tableau symptôme / cause / correction

Symptôme	Cause probable	Correction
Accès à un PaaS refusé depuis le on-prem (403 / AuthorizationFailure), OK depuis Azure	Résolution DNS publique côté on-prem	Redirecteurs conditionnels vers l'inbound endpoint du DNS Private Resolver (§5.3)
Spoke A ne joint pas spoke B	Peering non transitif / UDR manquante / règle firewall	show-next-hop, UDR vers le firewall des deux côtés, règle réseau
Connexions TCP coupées aléatoirement via le firewall	Routage asymétrique	UDR sur GatewaySubnet, propagation BGP désactivée sur les spokes
SkuNotAvailable au déploiement	Taille indisponible dans la région/zone ou restreinte pour la subscription	az vm list-skus -l francecentral --size D4as --output table (colonne Restrictions), changer de taille/zone ou demander l'accès
QuotaExceeded / OperationNotAllowed vCPU	Quota de la famille atteint	az vm list-usage -l francecentral -o table, demande d'augmentation
RequestDisallowedByPolicy	Azure Policy en Deny	Lire policyAssignmentId dans l'erreur ; corriger ou demander une exemption
AuthorizationFailed alors que l'utilisateur est Owner	Rôle PIM non activé, propagation RBAC (jusqu'à ~10 min), mauvais tenant/subscription en contexte, deny assignment (deployment stack)	az account show, activer PIM, rafraîchir le jeton (az account get-access-token après re-login)
VM inaccessible après mise à jour / changement réseau	Pare-feu OS, NIC désactivée, disque plein	Boot diagnostics + serial console, az vm run-command invoke, az vm repair
Key Vault : ForbiddenByRbac	Rôle plan de contrôle au lieu de plan de données	Affecter Key Vault Secrets User (et non Reader/Contributor)
Key Vault : ForbiddenByConnection	Accès public désactivé, requête venant d'Internet	Passer par le Private Endpoint (DNS), ou règle réseau temporaire
Agent AMA installé mais aucune donnée	Pas de DCR associée, identité managée absente, flux sortant bloqué vers les endpoints Monitor	Associer une DCR, activer l'identité, autoriser les service tags AzureMonitor ou utiliser AMPLS
Sauvegarde VM en échec UserErrorGuestAgentStatusUnavailable	Agent invité Azure (WindowsAzureGuestAgent / waagent) arrêté ou sans accès à 168.63.129.16	Redémarrer l'agent, vérifier proxy/pare-feu OS

15.3 Accès de secours à une VM

# Executer un script dans la VM sans reseau (via l'agent)
az vm run-command invoke -g rg-erp-prod-frc -n vmerpapp01 \
  --command-id RunPowerShellScript \
  --scripts "Get-NetFirewallProfile | Select Name,Enabled; Get-NetIPConfiguration"

# Reinitialiser la configuration RDP / le mot de passe local
az vm user update -g rg-erp-prod-frc -n vmerpapp01 -u azadmin -p "$NEW_PWD"

# Reparer un disque OS (VM de reparation avec le disque attache)
az extension add -n vm-repair
az vm repair create -g rg-erp-prod-frc -n vmerpapp01 --verbose
az vm repair restore -g rg-erp-prod-frc -n vmerpapp01 --verbose

15.4 Déploiements ARM/Bicep en échec

# Operations en echec d'un deploiement
az deployment operation group list -g rg-erp-prod-frc -n <DEPLOYMENT_NAME> \
  --query "[?properties.provisioningState=='Failed'].properties.statusMessage"

# Fournisseur de ressources non enregistre (MissingSubscriptionRegistration)
az provider register --namespace Microsoft.Network --wait

16. Checklist de mise en production

16.1 Gouvernance

• ☐ Hiérarchie de management groups en place, subscription rattachée au bon groupe.
• ☐ Policies : régions autorisées, tags obligatoires, diagnostic settings (DINE), refus d'IP publiques en Corp.
• ☐ Tags posés et hérités (Environment, Owner, CostCenter, Application).
• ☐ Verrous CanNotDelete sur les ressources partagées.
• ☐ Budget + alerte prévisionnelle + alertes d'anomalies.

16.2 Identité et accès

• ☐ RBAC par groupes, aucun utilisateur nominatif en Owner permanent ; Owner/UAA en PIM.
• ☐ Pipelines en workload identity federation, aucun secret de principal de service longue durée.
• ☐ Identités managées pour l'accès aux ressources ; clés partagées désactivées où possible.
• ☐ Key Vault : RBAC, purge protection, accès public désactivé, dates d'expiration sur les secrets.

16.3 Réseau

• ☐ Plan d'adressage documenté, sans chevauchement.
• ☐ Aucune IP publique sur les VM ; administration via Bastion/JIT.
• ☐ NSG sur chaque subnet avec deny intra-VNet explicite ; flow logs activés.
• ☐ Sortie Internet via Azure Firewall ; defaultOutboundAccess désactivé sur les subnets.
• ☐ PaaS en Private Endpoint, DNS testé depuis Azure et depuis le on-prem.
• ☐ Gateways en SKU AZ, active-active, BGP.

16.4 Calcul, données et continuité

• ☐ VM réparties sur zones (ou justification écrite du contraire), Trusted Launch, encryption at host.
• ☐ Azure Backup actif, soft delete, immutabilité/MUA sur le coffre, restauration testée.
• ☐ ASR ou autre PRA avec test failover planifié et documenté (RPO/RTO mesurés).
• ☐ Stockage : redondance conforme au besoin, versioning + soft delete, TLS 1.2, accès anonyme désactivé.

16.5 Exploitation

• ☐ AMA + DCR sur toutes les VM, aucun agent MMA résiduel.
• ☐ Activity Log et resource logs dans Log Analytics ; rétention conforme.
• ☐ Alertes : Service Health, santé des VM, sauvegardes en échec, saturation disque/CPU, dépenses.
• ☐ Defender for Cloud activé (plans adaptés), Secure Score suivi.
• ☐ Infrastructure décrite en IaC, déployée par pipeline, what-if revu en revue de code.
• ☐ Runbook d'exploitation : accès de secours, contacts, procédures de restauration.

Pour aller plus loin : Microsoft Entra ID, Kubernetes, PKI et certificats, Audit de sécurité.