12 — Monitoring Network

Surveiller, diagnostiquer et sécuriser le réseau Azure → Network Watcher, flow logs et Traffic Analytics, protection DDoS et Defender for Cloud.

A. Network Watcher

Network Watcher = la boîte à outils centrale de monitoring et diagnostic réseau Azure. Regroupe des outils de monitoring, diagnostic et logging. Une ressource Network Watcher existe par région.

A.1 Caractéristiques

• 1 ressource Network Watcher par région (créée automatiquement à la création du 1er VNet de la région, sauf si désactivé)
• Régional : les outils opèrent sur les ressources de leur région
• Accessible via Network Watcher dans le portail

A.2 Les 3 familles d'outils

B. Monitoring Features

B.1 Topology

• Génère une carte visuelle des ressources réseau d'un VNet et leurs relations (VNets, subnets, NICs, NSG, VMs, gateways, peerings…)
• Vue d'ensemble rapide de l'architecture
• Utile pour documenter / auditer une infra existante

B.2 Connection Monitor

Connection Monitor = monitoring continu E2E de la connectivité et latence entre des endpoints (à l'intérieur comme à l'extérieur d'Azure), via des agents installés sur les machines.

Caractéristiques :

• Mesure : latence, perte de paquets, % de réussite, hop-by-hop (le chemin complet)
• Endpoints : VMs Azure, machines on-prem (via agent), endpoints externes (URL, IP)
• Nécessite des agents : Network Watcher Agent extension sur les VMs Azure, ou Azure Arc + agent pour les machines on-prem
• Le seul outil Network Watcher vraiment hybride (mesure depuis une machine on-prem)

Use cases :

• Monitorer en continu la latence VM Azure → SQL Azure
• Monitorer depuis une machine on-prem → service Azure (valider un lien VPN/ER)
• Détecter une dégradation avant que les users s'en plaignent
• Alertes sur seuils de latence / perte

💡 Arc-enabled : pour monitorer une machine hors Azure (on-prem, autre cloud), il faut l'onboarder via Azure Arc puis y installer l'agent → elle devient un endpoint source/destination de Connection Monitor.

C. Diagnostic Features

C.1 Tableau de synthèse

C.2 IP Flow Verify

Détermine si les paquets d'une VM sont bloqués ou autorisés par un NSG.

• On spécifie : VM, direction (inbound/outbound), protocole, IP+port local, IP+port distant
• Network Watcher retourne : Allow ou Deny, et quelle règle NSG a décidé
• Use case : "pourquoi ma VM ne reçoit pas le trafic sur le port 443 ?" → IP Flow Verify identifie la règle bloquante

C.3 NSG Diagnostics

• Version plus complète que IP Flow Verify
• Évalue un flux contre toutes les couches : NSG (subnet + NIC) + AVNM Security Admin Rules
• Montre le verdict final + la règle qui décide à chaque niveau

C.4 Effective Security Rules

Affiche la collection complète des règles NSG appliquées sur une NIC.

• Affiche toutes les règles NSG effectives sur une NIC (combinaison subnet NSG + NIC NSG + règles par défaut + AVNM admin rules)
• Use case : comprendre l'ensemble des règles qui s'appliquent réellement, sans les chercher manuellement dans plusieurs NSG

C.5 Next Hop

Pour le debug des route tables : montre la route réellement prise pour atteindre une destination.

• On spécifie : VM source + IP destination
• Network Watcher te dit le next hop type (Virtual Network, Internet, Virtual Appliance, Virtual Network Gateway, None) + l'IP du next hop
• Use case : "pourquoi le trafic ne va pas vers mon firewall ?" → Next Hop montre quel hop est réellement pris (debug UDR)

C.6 Packet Capture

• Capture le trafic réseau d'une NIC de VM (comme Wireshark)
• Stockage : Storage Account ou disque local de la VM
• Le fichier .cap doit être analysé avec un outil externe (Wireshark, etc.)
• Nécessite l'agent Network Watcher sur la VM
• Use case : analyse fine d'un problème applicatif (handshake TLS, retransmissions…)

C.7 Connection Troubleshoot

• Test ponctuel (one-shot) de connectivité TCP/ICMP
• Source : VM, Bastion, ou Application Gateway
• Destination : autre VM, FQDN, IP
• Retourne : statut (reachable/unreachable), latence, hops, et la raison du blocage (NSG, UDR, etc.)

💡 Connection Troubleshoot vs Connection Monitor :

• Troubleshoot = test ponctuel (maintenant, one-shot)
• Monitor = surveillance continue dans le temps (avec historique, alertes)

C.8 VPN Troubleshoot

• Diagnostic d'une VPN Gateway ou d'une Connection
• Identifie les erreurs IKE (Phase 1/2), problèmes de PSK, mismatch IPsec policy
• Génère un rapport (stocké dans un Storage Account) avec logs + recommandations
• Use case : tunnel S2S qui ne monte pas → VPN Troubleshoot pointe l'étape qui échoue

D. Logging Features

D.1 NSG Flow Logs (déprécié) ⚠️

• Log le trafic qui passe par un NSG (allow/deny, 5-tuple, bytes, packets)
• Stocké en JSON dans un Storage Account, agrégé par intervalle (~1 min)
• 🚨 DÉPRÉCIÉ :
  • Plus de création de nouveaux NSG Flow Logs après le 30 juin 2025
  • Retraite complète le 30 septembre 2027 (les ressources NSG Flow Log seront supprimées, Traffic Analytics sur NSG Flow Logs ne sera plus supporté)
  • → Migrer vers VNet Flow Logs

D.2 VNet Flow Logs (le remplaçant)

• Log le trafic au niveau du VNet (pas du NSG) → plus simple, plus complet
• Capture le trafic même sans NSG attaché
• Avantages vs NSG Flow Logs :
  • 1 config au niveau VNet (vs 1 par NSG)
  • Pas affecté par les changements de NSG
  • Capture le trafic des ressources sans NSG
  • Coût et volume optimisés
• Stocké en Storage Account (+ Traffic Analytics optionnel)
• C'est la méthode recommandée 2026 pour tout nouveau déploiement

D.3 Interpréter un VNet Flow Log

L'objectif AZ-700 distingue implement (activer) ET interpret (lire). Un VNet Flow Log est du JSON (schéma flowLogVersion = 4), collecté au niveau VNet par intervalles de 1 min, opérant en Layer 4.

Structure JSON : chaque record → flowRecords.flows[], où chaque flow porte un aclID (la ressource qui évalue le trafic : un NSG ou un Azure Virtual Network Manager ; unspecified si deny par chiffrement) et des flowGroups[] avec le rule (nom de la règle qui a allow/deny). Le cœur = les flowTuples, chaînes CSV.

Le tuple (13 champs, ordre exact) :

💡 Les compteurs bytes/packets sur un tuple C ou E sont cumulés depuis le tuple précédent → pour le total d'une conversation, additionner tous les C + E. Un tuple B a toujours des stats à 0.

⚠️ Filtrer le bruit : des entrées peuvent apparaître sous une platform rule (trafic géré par la plateforme Azure, pas par un NSG/AVNM) — informatif, à exclure de l'analyse sécurité.

Différence avec les NSG Flow Logs (dépréciés, création bloquée 30 juin 2025, retraite 30 sept 2027) : leur schéma logge au niveau NSG et expose le 5-tuple autrement — un champ Traffic decision séparé (A=Allow / D=Deny), et le Flow State (B/C/E) n'existe qu'en Version 2. Le VNet Flow Log, lui, fusionne allow/deny dans le flowState (le D y est un état de flux) et ajoute encryption status + l'identification AVNM + bytes/packets sur flux stateless — choses absentes des NSG Flow Logs.

Comment les exploiter : soit Traffic Analytics (§D.4) pour la visualisation (top talkers, géo, flux bloqués), soit une requête KQL brute dans Log Analytics sur la table NTANetAnalytics (remplace l'ancienne AzureNetworkAnalytics_CL des NSG Flow Logs), soit l'analyse directe du JSON brut depuis le Storage Account.

D.4 Traffic Analytics

• Analyse et visualise les flow logs (NSG ou VNet) → dashboards, top talkers, flux malveillants, géo-distribution du trafic, ports les plus utilisés
• Nécessite un Log Analytics Workspace (les flow logs bruts vont au Storage, Traffic Analytics les enrichit dans le Workspace)
• Transforme les logs JSON bruts en insights exploitables (qui parle à qui, quels flux bloqués, anomalies)
• Use case : détecter un flux suspect, identifier les ressources les plus sollicitées, audit de sécurité

⚠️ Pré-requis Traffic Analytics : VNet (ou NSG) Flow Logs activé + Log Analytics Workspace.

E. Azure Monitor for Networks (Network Insights)

Objectif AZ-700 : "Monitor and troubleshoot networks by using Azure Monitor for Networks"

Network Insights (dans Azure Monitor) = vue centralisée de la santé et des métriques de toutes les ressources réseau, sans config.

E.1 Caractéristiques

• Topology visuelle enrichie avec l'état de santé
• Métriques pré-construites pour chaque type de ressource (LB, App Gateway, VPN Gateway, Public IP, ExpressRoute, Firewall…)
• Pas d'agent requis (s'appuie sur les métriques de la plateforme)
• Accessible via Azure Monitor > Insights > Networks ou Network Watcher > Network Insights

E.2 Connection Monitor y est intégré

• Network Insights agrège les résultats de Connection Monitor
• Vue consolidée santé + connectivité + dépendances

E.3 Network Watcher vs Network Insights

F. DDoS Protection

Protège contre les attaques Distributed Denial of Service. Deux types de DDoS Protection Plan payants existent (IP Protection et Network Protection), au-dessus de la protection d'infrastructure gratuite.

F.1 Les 3 niveaux

F.2 Features comparées

🚨 Quatre features sont Network Protection only : support Public IP Basic tier, DDoS Rapid Response, Cost Protection et WAF discount.

F.3 DDoS = L3/L4 uniquement

• DDoS Protection protège contre les attaques volumétriques L3/L4 (SYN flood, UDP flood, amplification)
• Les attaques L7 (HTTP flood) ne sont PAS couvertes par DDoS → c'est le WAF rate limiting (fiche 11) qui s'en charge
• → DDoS et WAF sont complémentaires

F.4 Implémentation Network Protection

• Protège les ressources avec IP publique (pas les IPs privées)
• 1 DDoS Protection Plan créé dans une sub
• Associé à un ou plusieurs VNets (le plan se partage entre les subs d'un même tenant)
• Un seul plan peut couvrir plusieurs VNets / subscriptions du tenant → mutualisation du coût (le plan est cher, ~$3k/mois, mais couvre jusqu'à 100 ressources publiques)

F.5 Implémentation IP Protection

• Activable directement sur une Public IP Standard (pas Basic)
• Mode on/off par IP
• Moins cher quand il n'y a que quelques IPs à protéger
• Pas de DRR team, pas de cost protection

F.6 Monitoring DDoS

• Métriques dans Azure Monitor : Under DDoS attack or not (0 = non, 1 = attaque en cours)
• Alerte recommandée : IfUnderDDoSAttack > 0 → notifier le SOC
• Logs : DDoS mitigation reports + flow logs (pendant et après attaque)

G. Microsoft Defender for Cloud (MDC)

Defender for Cloud = plateforme CNAPP (Cloud-Native Application Protection Platform) : posture de sécurité + protection des workloads, multi-cloud. Sa gamme de features couvre Security Posture, Regulatory Compliance, Workload Protection, DevSecOps, Alert & Automation et Integration.

G.1 Les grandes familles de features

G.2 Secure Score (objectif AZ-700)

Objectif : "Evaluate network security recommendations identified by Microsoft Defender for Cloud Secure Score"

• Score de sécurité (%) basé sur les recommandations appliquées
• Alimenté par le Microsoft Cloud Security Benchmark (MCSB) : des policies évaluent la sub entière + ressources
• Recommandations réseau typiques :
  • "Les NSG devraient restreindre l'accès SSH/RDP depuis internet"
  • "Les sous-réseaux devraient être associés à un NSG"
  • "Les machines exposées sur internet devraient être protégées par un NSG"
  • "Activer DDoS Standard sur les VNets"
  • "Les endpoints de management ne devraient pas être exposés"
• Chaque recommandation = des points → appliquer = augmenter le score

G.3 Attack Paths (objectif AZ-700)

Objectif : "Evaluate network security recommendations identified by Microsoft Defender for Cloud attack paths"

• Attack Path Analysis : montre les chemins d'attaque exploitables qu'un attaquant pourrait suivre
• Ex : "VM exposée sur internet (NSG ouvert) → a une vulnérabilité critique → a une managed identity avec accès à un Storage contenant des données sensibles"
• Visualise la chaîne d'exploitation possible (graphe)
• Priorise les remédiations selon l'impact réel (pas juste une liste de findings isolés)
• Use case réseau : identifier qu'un NSG trop ouvert + une VM vulnérable = un chemin vers la donnée sensible

G.4 Cloud Security Explorer (objectif AZ-700)

Objectif : "Identify network resources by using Microsoft Defender for Cloud Security Explorer"

• Moteur de requête sur le graphe de sécurité du cloud
• Permet de chercher des ressources selon des critères de sécurité
• Exemples de requêtes réseau :
  • "Toutes les VMs exposées à internet"
  • "Toutes les ressources avec une IP publique sans DDoS protection"
  • "Tous les NSG autorisant le port 3389 depuis Any"
  • "Les ressources accessibles publiquement avec des vulnérabilités critiques"
• Use case : audit proactif de la surface réseau exposée

G.5 Regulatory Compliance & Workload Protection

• Regulatory Compliance : assessment automatisé/manuel contre une baseline (MCSB), des standards industrie (ISO, PCI, NIST), ou custom
• Workload Protection : "Defender for Servers / Databases / Storage / Containers…" — plans payants, parfois achetables hors MDC mais gérables dedans

G.6 Implémentation

• Ouvrir Defender for Cloud → onboarding automatique gratuit (CSPM Foundational : Secure Score + recommandations)
• Multi-cloud : connecteurs AWS, GCP (via connectors)
• MCSB : le benchmark par défaut qui check la sub et génère le score + recommandations
• Plans payants (Defender for Servers, etc.) activables par ressource

G.7 Rôles RBAC

• Security Reader : lecture (voir le score, les recommandations)
• Security Admin : lecture + modifier les policies de sécurité, dismisser des alertes, gérer les plans
• Rôles Azure standards (Owner, Contributor) pour gérer les ressources sous-jacentes

H. Microsoft Defender EASM (bonus — vue externe)

⚠️ Note : EASM n'est pas explicitement listé dans les objectifs AZ-700, mais c'est un complément utile sur la posture externe (vu de l'attaquant). À connaître en culture générale sécu.

Là où Defender for Cloud donne une vue interne de l'infra, EASM (External Attack Surface Management) découvre et monitore la surface d'attaque externe : comment l'extérieur accède aux ressources, leur vulnérabilité aux attaques, l'exposition public/privé, l'état SSL, le mail, le DNS — c'est-à-dire ce qu'un attaquant voit depuis internet.

H.1 Capacités

• Attack Surface Discovery : découvre en continu la surface externe
• Finds the Unknown : trouve les assets inconnus/non monitorés à partir de "seeds" (domaines de départ)
• Broad Inventory : domaines, pages web, blocs IP, IPs
• Security Reporting : dashboards (attack surface summary, OWASP Top 10, compliance)
• Inventory Management : track + label des assets externes
• Integration : MDC, Copilot, etc.

H.2 Mise en place

• Créer une EASM Instance (ressource parente sur Azure pour gérer l'inventaire)
• Inventory assets : définir les assets de l'organisation (domaines, IPs) → les "seeds"
• Discovery : MS scanne à partir des seeds tous les items connectés externellement

H.3 Asset states

Chaque asset découvert reçoit un état selon la relation avec lui :

💡 Workflow : EASM découvre des candidates → investigation → classement en Approved Inventory (assets possédés) ou Dependency/Monitor Only (assets non possédés). C'est l'organisation qui valide ce qui lui appartient.

🚨 La découverte part des seeds (domaines/IPs propres à l'organisation), et on ne doit scanner que des assets que l'on possède (sinon scan non autorisé d'infra tierce = problème légal). Les assets découverts arrivent en "candidate" et la propriété doit être confirmée avant de les classer en Approved Inventory.

I. Connection Monitor (Arc-enabled & hybride)

Déjà introduit en §B.2. Précisions pour l'hybride :

• Pour monitorer une machine on-prem ou autre cloud comme endpoint → l'onboarder via Azure Arc (Arc-enabled servers) puis installer le Network Watcher Agent / Monitoring Agent
• Une fois Arc-enabled, la machine apparaît comme endpoint source/destination dans Connection Monitor
• Permet de monitorer la connectivité bidirectionnelle on-prem ↔ Azure (valider un lien VPN/ER en continu)

🏢 Scénarios d'entreprise (CAF/WAF)

Scenario 1 : Banque — monitoring hybride continu de la connectivité critique

Contexte business : Une banque a un ExpressRoute vers Azure. Son app core banking on-prem doit joindre Azure SQL en moins de 10 ms. Son SLA exige de détecter toute dégradation réseau en moins de 5 min. Elle est auditée par l'ACPR. Choix architectural : Connection Monitor (machines on-prem Arc-enabled → Azure SQL) + Network Insights + alertes Azure Monitor + VNet Flow Logs + Traffic Analytics. Architecture / pattern :

• Les machines on-prem sont Arc-enabled avec l'agent Network Watcher
• Connection Monitor : source = serveurs on-prem, destination = l'Azure SQL privé (via Private Endpoint), test TCP/1433 toutes les 30s
• Seuils : latence > 10 ms ou perte > 1% → alerte vers un Action Group (SOC + astreinte)
• Network Insights : une vue de santé regroupant la gateway ExpressRoute, le circuit et les Private Endpoints
• VNet Flow Logs + Traffic Analytics → audit des flux (qui parle à la base) Trade-offs assumés :
• Gain : détection proactive et continue des dégradations (<5 min), audit des flux conforme ACPR.
• Perte : machines on-prem à Arc-enabler, Log Analytics et agents à exploiter en continu (coût/maintenance). Pièges à éviter :
• Utiliser Connection Troubleshoot (test ponctuel) au lieu de Monitor (continu) → pas de détection proactive. Pour le SLA, c'est Monitor
• Oublier d'Arc-enabler les machines on-prem → impossible de monitorer depuis on-prem
• Utiliser les NSG Flow Logs (dépréciés) au lieu des VNet Flow Logs → migration imposée avant septembre 2027
• Activer Traffic Analytics sans Log Analytics Workspace → aucune analyse, juste des logs JSON bruts

📐 Réf. CAF/WAF — WAF Operational Excellence OE:07 (observabilité) : conçois la stack de monitoring (Connection Monitor + métriques + logs) découplée de la charge de travail pour détecter les incidents avant qu'ils n'affectent l'expérience. Lien

Scenario 2 : E-commerce — protection DDoS pour Black Friday

Contexte business : Un e-commerce est régulièrement visé par des attaques DDoS pendant les pics de vente (concurrents, extorsion). Il a plusieurs VNets (web, API, paiement) et veut une protection volumétrique avec de la visibilité. Choix architectural : un DDoS Network Protection Plan (couvre tous les VNets) + du rate limiting WAF (niveau 7) + des alertes + la cost protection. Architecture / pattern :

• Un seul DDoS Network Protection Plan, associé aux 3 VNets (web, API, paiement)
• Il protège toutes les IPs publiques (Front Door, App Gateway, LB)
• Rate limiting WAF (sur Front Door, fiche 11) pour les attaques HTTP flood niveau 7 : le DDoS ne couvre que les niveaux 3/4
• Alerte Azure Monitor : Under DDoS attack > 0 → le SOC est notifié
• Cost Protection : des crédits Azure couvrent le scale forcé pendant une attaque (inclus dans Network Protection) Trade-offs assumés :
• Gain : protection volumétrique L3/4 sur tous les VNets, cost protection et visibilité pendant les pics.
• Perte : ne couvre pas le L7 (HTTP flood → rate limiting WAF requis) ni les ressources privées, coût du plan. Pièges à éviter :
• Compter sur le DDoS pour les attaques niveau 7 (HTTP flood) → le DDoS ne fait que les niveaux 3/4. Compléter avec le rate limiting WAF
• Prendre l'IP Protection (par IP) pour 20 IPs publiques → plus cher et moins pratique que Network Protection (par VNet) à cette échelle
• Oublier que le DDoS ne protège que les IPs publiques (pas les ressources privées)
• Pas d'alerte sur Under DDoS attack → on détecte l'attaque trop tard

📐 Réf. CAF/WAF — Service guide DDoS Protection (best practices monitoring/alerting) : active les diagnostic settings sur chaque IP publique et une alerte métrique Under DDoS attack or not envoyée aussi à Defender for Cloud / Sentinel pour corréler. Lien

Scenario 3 : Troubleshooting — pourquoi le trafic ne passe pas ?

Contexte business : Une équipe dev signale qu'une nouvelle VM ne reçoit pas le trafic HTTPS venant de l'App Gateway. Personne ne sait si c'est un NSG, une UDR, ou un souci de routing. Choix architectural : une démarche méthodique avec les outils de diagnostic de Network Watcher. Architecture / pattern (séquence de diagnostic) :

1. IP Flow Verify : le paquet HTTPS entrant vers la VM est-il autorisé ou bloqué ? → dit si un NSG bloque, et quelle règle
2. Si bloqué → Effective Security Rules sur la carte réseau : voir toutes les règles qui s'appliquent (subnet + NIC + admin AVNM) → trouver la règle fautive
3. Si autorisé mais ça ne marche toujours pas → Next Hop : le trafic part-il au bon endroit (et pas dévié par une UDR vers un firewall tombé) ?
4. Si le routing est bon → Connection Troubleshoot depuis l'App Gateway vers la VM : latence, sauts, blocage
5. Si besoin d'aller plus loin → Packet Capture sur la carte réseau, puis analyse dans Wireshark Trade-offs assumés :

• Gain : diagnostic méthodique du chemin réseau (NSG → routing → connectivité) sans modification au hasard.
• Perte : démarche manuelle outil par outil, agent Network Watcher requis pour la capture de paquets. Pièges à éviter :
• Modifier les NSG au hasard sans faire d'IP Flow Verify d'abord → perte de temps. Diagnostiquer avant
• Oublier que Effective Security Rules inclut les Admin Rules AVNM (une règle Deny AVNM prend le dessus sur le NSG)
• Lancer un Packet Capture sans l'agent Network Watcher → ça ne marche pas
• Ne pas vérifier le Next Hop → une UDR vers un firewall en panne jette le trafic sans rien dire

📐 Réf. CAF/WAF — Service guide Network Watcher (monitoring overview) : Network Watcher fournit les outils de diagnostic régionaux (IP Flow Verify, Next Hop, Connection Troubleshoot, Packet Capture) pour surveiller, diagnostiquer et visualiser l'état du réseau. Lien

DEMO — chemins portail

1. DEMO — Monitoring with Network Watcher

Tour des outils.

Home > Network Watcher

Topology

Network Watcher > Topology → sélectionner Sub + RG + VNet → carte visuelle générée.

IP Flow Verify

Network Watcher > IP flow verify

• VM : vm-web
• Direction : Inbound, Protocol : TCP
• Local IP+port : 10.0.1.4:443, Remote IP+port : 203.0.113.5:51000
• → Résultat : Allow/Deny + nom de la règle NSG

Next Hop

Network Watcher > Next hop

• Source VM : vm-web, Destination IP : 10.0.3.10
• → Next hop type (ex Virtual Appliance) + IP

Effective Security Rules

Network Watcher > Effective security rules (ou NIC > Effective security rules)

• Sélectionner la VM/NIC → liste de toutes les règles NSG effectives

Connection Troubleshoot

Network Watcher > Connection troubleshoot

• Source : vm-web (ou Bastion, App GW)
• Destination : FQDN/IP/autre VM, port
• → Statut + latence + hops + raison de blocage éventuelle

VPN Troubleshoot

Network Watcher > VPN troubleshoot

• Sélectionner la VPN Gateway / Connection
• Storage Account requis pour le rapport
• → Diagnostic + logs téléchargeables

Packet Capture

Network Watcher > Packet capture > + Add

• VM cible (agent Network Watcher requis)
• Destination : Storage Account ou disque local
• Filtres optionnels (protocole, IP, port)
• → Fichier .cap à analyser dans Wireshark

2. DEMO — Connection Monitor

Network Watcher > Connection monitor > + Create

1. Basics : Name cm-hybrid, Region
2. Test groups :
   • Sources : VMs Azure (agent Network Watcher) ou machines Arc-enabled (on-prem)
   • Destinations : VM Azure, FQDN (sql.database.windows.net), IP
   • Test configuration : protocole (TCP/HTTP/ICMP), port, fréquence (ex 30s), seuils
3. Review + create
4. Dashboard : latence, % réussite, hop-by-hop dans le temps + alertes

Pré-requis : agent Network Watcher sur les VMs Azure / agent + Arc sur les machines on-prem.

3. DEMO — VNet Flow Logs + Traffic Analytics

NSG Flow Logs étant déprécié, on configure des VNet Flow Logs.

Pré-requis : un Storage Account + (pour Traffic Analytics) un Log Analytics Workspace.

Network Watcher > Flow logs > + Create

1. Flow log type : Virtual network (recommandé ; NSG = legacy)
2. Target resource : sélectionner le VNet
3. Storage account : sélectionner/créer (stockage des logs JSON)
4. Retention : ex 30 jours
5. Traffic Analytics :
   • Enable : On
   • Log Analytics Workspace : sélectionner
   • Processing interval : 1h (ou 10 min)
6. Review + create

Exploitation : Network Watcher > Traffic Analytics → dashboards (top talkers, flux bloqués, géo-distribution, ports, hosts malveillants détectés).

4. DEMO — Configure DDoS Protection (IP Protection)

Le moins cher pour quelques IPs.

Public IP address > <pip> > Properties > DDoS protection (ou à la création de la Public IP)

• DDoS protection : IP protection → On
• Save

→ La Public IP Standard est maintenant protégée (mode on/off par IP).

5. DEMO — Configure DDoS Protection (Network Protection)

Cher mais couvre tout un VNet (et multi-VNet).

Étape 1 — Créer le plan :

Home > DDoS protection plans > + Create

• Name : ddos-plan-corp, Region, RG
• Review + create (⚠️ ~$3k/mois)

Étape 2 — Associer à un VNet :

Virtual network > <vnet> > DDoS protection

• Enable : Network protection
• DDoS protection plan : ddos-plan-corp
• Save

Le plan peut être associé à plusieurs VNets (même cross-sub dans le tenant) → mutualisation. Protège toutes les ressources avec IP publique du VNet.

Monitoring : Azure Monitor > Metrics > <Public IP> > Under DDoS attack or not → alerte si > 0.

6. DEMO — Get Started avec Defender for Cloud

Home > Microsoft Defender for Cloud

1. Getting started : onboarding (CSPM Foundational gratuit activé)
2. Cloud Security :
   • Security posture : Secure Score + recommandations (filtrer par "Networking")
   • Inventory : tous les assets + leur état de sécurité
   • Attack path analysis : chemins d'attaque exploitables
   • Cloud Security Explorer : requêtes (ex "VMs exposées internet")
3. Regulatory compliance : voir la conformité MCSB + standards
4. Environment settings : activer les plans Defender payants par ressource, ajouter des connecteurs AWS/GCP
5. Rôles : Security Admin pour gérer, Security Reader pour lire

7. DEMO — Defender EASM (bonus)

Home > Microsoft Defender EASM > + Create

1. Créer l'EASM instance (essai 30 jours)
2. Discovery : fournir les seeds (domaines/IPs possédés par l'organisation)
3. Lancer la discovery → MS scanne à partir des seeds
4. Dashboards : attack surface summary, security posture, GDPR compliance, OWASP Top 10
5. Inventory : classer les assets découverts (Approved Inventory / Dependency / Monitor Only…)

⚠️ Ne scanner que les assets possédés (seeds appartenant à l'organisation). Les candidates découverts doivent être validés avant classification.