Conception et Déploiement d'une Architecture Cloud Hybride : On-Premise (Hyper-V / pfSense) & Microsoft Azure

1. Cahier des Charges & Contexte du Projet

1.1 Contexte et Objectifs

En parallèle de ma préparation à la certification Microsoft AZ-104, j’ai voulu construire un lab complet qui reproduise fidèlement les contraintes d’une infrastructure hybride d’entreprise. L’idée de ce projet était de concevoir, déployer et sécuriser de bout en bout une architecture Hub & Spoke hybride reliant mon datacenter local (hébergé sous Hyper-V) à un tenant Microsoft Azure.

Je me suis fixé deux objectifs méthodologiques dès le départ :

1. Maîtrise opérationnelle bas niveau : Faire tout le provisionnement initial « à la main », sans couche d’abstraction tierce, pour me confronter directement aux dépendances réseau, au routage dynamique, aux quotas et aux mécanismes de sécurité natifs d’Azure.
2. Industrialisation & FinOps : Mettre en place une approche Infrastructure as Code (IaC) avec des modèles Azure Resource Manager (ARM) afin de détruire et reconstruire à la demande les ressources facturées à l’heure (Passerelles VPN, Bastion) entre mes sessions de travail, sans jamais casser le socle existant.

1.2 Exigences Techniques & Fonctionnelles

2. Table des Matières

1. Cahier des Charges & Contexte du Projet
2. Table des Matières
3. Architecture Globale & Plan d’Adressage
4. Jalon 1 : Socle On-Premise (Hyper-V, pfSense & Active Directory)
5. Jalon 2 : Connectivité Hybride (Tunnel IPsec S2S, VTI & eBGP)
6. Ingénierie FinOps & Infrastructure as Code (Modèles ARM)
7. Jalon 3 : Identité Hybride & Architecture DNS Bidirectionnelle
8. Jalon 4 : Stockage Hybride Zéro-Trust & Azure File Sync
9. Jalon 5 : Compute Haute Disponibilité, VMSS & Application Gateway WAF v2
10. Jalon 6 : Sécurisation PaaS (App Service), Gouvernance & Sauvegarde (PRA)
11. Bilan Technique & Compétences Validées

3. Architecture Globale & Plan d’Adressage

3.1 Schéma Logique de l’Architecture

3.2 Plan d’Adressage Réseau & Paramètres de Routage

4. Jalon 1 : Socle On-Premise (Hyper-V, pfSense & Active Directory)

4.1 Architecture de Virtualisation Hyper-V

J’ai monté l’environnement sur site sur un hyperviseur de Type 1 Microsoft Hyper-V (processeur AMD Ryzen 5 5600 6C/12T, 32 Go de RAM, stockage SSD NVMe). Pour garder un ratio de souscription CPU optimal (inférieur à 1:1) et éviter toute latence d’accès disque (IOPS), j’ai configuré l’allocation des ressources en suivant plusieurs règles strictes :

• Machines virtuelles de Génération 2 : J’ai utilisé exclusivement le firmware UEFI et des contrôleurs SCSI synthétiques.
• Gestion différenciée de la mémoire : J’ai activé la Dynamic Memory (2048 Mo au démarrage, plafond à 4096 Mo) sur les serveurs Windows (SRV-DC et SRV-FS), mais j’ai fixé une RAM statique (2048 Mo) et désactivé le Secure Boot sur l’appliance pfSense (le noyau FreeBSD gérant mal le ballooning mémoire d’Hyper-V).
• Cloisonnement de Niveau 2 (vSwitch) :
  • Un commutateur virtuel Externe lié à la carte physique pour exposer uniquement l’interface WAN (hn0) de pfSense.
  • Un commutateur virtuel LAN (AGHCORP-LAN) qui isole complètement les serveurs Windows derrière l’interface LAN (hn1) du pare-feu pfSense.

4.2 Modèle de Tiering et Séparation des Rôles

Pour respecter les recommandations de sécurité Active Directory (sécurisation du Tier 0), j’ai séparé strictement les rôles dès l’installation :

• SRV-DC (Tier 0) : Il héberge uniquement les rôles Active Directory Domain Services (AD DS) et DNS Server pour la forêt aghcorp.lab. Je n’y ai installé aucun service web (IIS) ni d’accès distant pour réduire au maximum la surface d’attaque.
• SRV-FS (Tier 1) : C’est un serveur membre dédié au rôle File and Storage Services (SMB/CIFS), sur lequel j’ai ensuite déployé les agents de synchronisation hybride (Azure File Sync) et de sauvegarde (MARS).

4.3 Automatisation du Provisionnement AD (Modèle AGDLP)

Plutôt que de peupler l’annuaire à la main dans la console graphique, j’ai écrit un script PowerShell idempotent basé sur la technique du Splatting (@UserParams). En une exécution, il bâtit toute l’arborescence d’Unités d’Organisation (OU), les groupes de sécurité globaux (GG_IT, GG_RH, GG_Direction) et les comptes utilisateurs métiers :

Import-Module ActiveDirectory

$Domaine = "DC=aghcorp,DC=lab"
$RootOU = "OU=AGHCORP,$Domaine"
$UsersOU = "OU=Utilisateurs,$RootOU"
$MdpDefaut = ConvertTo-SecureString "AdminLab2026!" -AsPlainText -Force

# Création de l'arborescence d'Unités d'Organisation (OUs)
New-ADOrganizationalUnit -Name "AGHCORP" -Path $Domaine -ErrorAction SilentlyContinue
@("Groupes", "Ordinateurs", "Utilisateurs") | ForEach-Object {
    New-ADOrganizationalUnit -Name $_ -Path $RootOU -ErrorAction SilentlyContinue
}
@("Informatique", "Ressources_Humaines", "Direction") | ForEach-Object {
    New-ADOrganizationalUnit -Name $_ -Path $UsersOU -ErrorAction SilentlyContinue
}

# Création des groupes de sécurité (Modèle AGDLP)
$GroupesOU = "OU=Groupes,$RootOU"
@("GG_IT", "GG_RH", "GG_Direction") | ForEach-Object {
    New-ADGroup -Name $_ -GroupScope Global -GroupCategory Security -Path $GroupesOU -ErrorAction SilentlyContinue
}

# Fonction de provisionnement par Splatting
Function Creer-Utilisateur ($Prenom, $Nom, $Service, $Groupe) {
    $SamAccount = "$($Prenom.Substring(0,1).ToLower()).$($Nom.ToLower())"
    $UserParams = @{
        Name                  = "$Prenom $Nom"
        GivenName             = $Prenom
        Surname               = $Nom
        SamAccountName        = $SamAccount
        UserPrincipalName     = "$SamAccount@aghcorp.lab"
        Path                  = "OU=$Service,$UsersOU"
        AccountPassword       = $MdpDefaut
        Enabled               = $true
        ChangePasswordAtLogon = $true
        ErrorAction           = "SilentlyContinue"
    }
    New-ADUser @UserParams
    Add-ADGroupMember -Identity $Groupe -Members $SamAccount -ErrorAction SilentlyContinue
}

Creer-Utilisateur -Prenom "Aghiles" -Nom "Ounnas" -Service "Informatique" -Groupe "GG_IT"
Creer-Utilisateur -Prenom "Thomas" -Nom "Durand" -Service "Informatique" -Groupe "GG_IT"
Creer-Utilisateur -Prenom "Sophie" -Nom "Martin" -Service "Ressources_Humaines" -Groupe "GG_RH"
Creer-Utilisateur -Prenom "Lucas" -Nom "Bernard" -Service "Ressources_Humaines" -Groupe "GG_RH"
Creer-Utilisateur -Prenom "Marie" -Nom "Dubois" -Service "Direction" -Groupe "GG_Direction"

4.4 Focus Ingénierie : Résolution DNS (EDNS0 / DNSSEC) & Hiérarchie NTP Stratum

Lors de la mise en service du socle, j’ai dû diagnostiquer et régler deux problèmes classiques d’infrastructure :

1. Interopérabilité DNS Windows Server ↔ Unbound (pfSense) : En configurant pfSense comme redirecteur (Forwarder) de mon serveur DNS Active Directory, j’ai fait face à deux comportements : la console Windows affichait Unable to resolve (ce qui est normal tant qu’aucun enregistrement inverse PTR n’existe pour l’IP du routeur), mais surtout, mes requêtes PowerShell Resolve-DnsName échouaient systématiquement avec une erreur Bad DNS packet. En creusant, j’ai compris que le rejet venait des signatures cryptographiques DNSSEC injectées par défaut par Unbound, qui fragmentent ou alourdissent les paquets UDP au-delà de ce qu’accepte Windows Server (conflit EDNS0). La solution : décocher Enable DNSSEC Support dans le résolveur pfSense, ce qui a immédiatement rétabli toute la chaîne de résolution récursive (Client → SRV-DC → pfSense → Internet).

2. Unification Temporelle Hybride (Modèle Stratum NTP) : Le protocole Kerberos impose une tolérance maximale de 5 minutes contre les attaques par rejeu (Replay Attacks), et tant la corrélation des logs que les renégociations IPsec exigent une horloge parfaitement alignée. J’ai donc mis en place une hiérarchie Stratum stricte :

   • Stratum 1/2 (Externe) : Pool public fr.pool.ntp.org.
   • Routeur de bordure (pfSense) : Synchronisé sur le pool externe et configuré comme serveur NTP maître sur l’interface LAN.
   • Contrôleur de Domaine (SRV-DC, Rôle FSMO PDC Emulator) : J’ai commencé par désactiver la synchronisation d’horloge matérielle d’Hyper-V (VMICTimeSync) dans les paramètres de la VM pour éviter qu’elle n’écrase la configuration réseau, puis j’ai forcé le pointage NTP vers pfSense :

     w32tm /config /manualpeerlist:"192.168.10.1,0x8" /syncfromflags:manual /reliable:yes /update
     Restart-Service w32time
     w32tm /resync
     

   • Machines membres (On-Premise & VMs Azure) : Elles se synchronisent désormais nativement sur le PDC Emulator à travers l’annuaire et le tunnel VPN.

5. Jalon 2 : Connectivité Hybride (Tunnel IPsec S2S, VTI & eBGP)

5.1 Architecture de la Passerelle Cloud (VpnGw1AZ)

Côté Azure, dans le réseau virtuel VNet-Hub (10.0.0.0/16), j’ai déployé une Virtual Network Gateway sur le sous-réseau dédié GatewaySubnet (10.0.1.0/24) avec la configuration suivante :

• SKU VpnGw1AZ : Bande passante garantie de 650 Mbps avec redondance zonale (Availability Zones), ce qui répartit les instances sous-jacentes dans des datacenters physiquement distincts de la région France Central.
• Mode Actif/Passif couplé à une adresse IP publique Standard Statique (51.138.199.177).
• Activation du routage BGP : J’ai conservé le numéro de système autonome (ASN) 65515 côté Azure, face à l’ASN privé 65516 que j’ai attribué à mon pfSense (déclaré dans l’objet Local Network Gateway LNG-OnPrem).

5.2 Conception du Tunnel en 3 Couches (NAT-T, Mode VTI & APIPA)

Comme mon routeur pfSense se trouve derrière une box opérateur (Bbox en 192.168.1.254 qui fait du NAT), j’ai structuré le montage de l’interconnexion en trois couches :

1. Couche 1 — Transport & Traversée NAT (Phase 1 / IKEv2) : J’ai d’abord placé la patte WAN de pfSense (192.168.1.28) en DMZ sur la box FAI (pour rediriger les ports UDP 500 et UDP 4500). C’est là que se joue un détail critique : par défaut, un routeur placé derrière un NAT envoie son IP privée dans le payload d’identification IKEv2, ce qu’Azure rejette immédiatement avec une erreur ID mismatch. Pour contourner le problème, j’ai forcé manuellement le champ Local ID de la Phase 1 sur pfSense avec l’adresse IP publique de ma fibre (176.145.211.146). L’authentification mutuelle passe alors sans encombre et encapsule les flux en NAT-T (UDP 4500).
2. Couche 2 — Interface Virtuelle de Tunnel (Phase 2 / Mode VTI) : Plutôt que d’utiliser des tunnels basés sur des politiques statiques (Policy-Based), j’ai monté une interface VTI (Route-Based) avec des sélecteurs de trafic universels (0.0.0.0/0). De cette façon, c’est la table de routage dynamique qui prend toutes les décisions d’acheminement.
3. Couche 3 — Adressage APIPA & Peering eBGP (FRR) : Pour éviter tout chevauchement d’adressage (IP Overlap) entre le lien point-à-point du tunnel et le plan d’adressage du Hub Azure (10.0.0.0/16), j’ai configuré l’interface VTI sur la plage réservée APIPA (169.254.21.0/30) :
   • Azure Custom BGP APIPA IP : 169.254.21.1 (ASN 65515)
   • pfSense VTI Local IP : 169.254.21.2 (ASN 65516)

Sur pfSense, j’ai ensuite paramétré le démon FRR (Free Range Routing) au plus strict : j’ai coupé la redistribution automatique des réseaux connectés (Redistribute connected networks = No) pour éviter d’annoncer le réseau WAN de ma box domestique dans Azure, j’ai déclaré uniquement le sous-réseau 192.168.10.0/24, et j’ai activé les options eBGP Nexthop Connected et Disable eBGP Require Policy vers le voisin 169.254.21.1.

5.3 Audit du Plan de Contrôle et Validation du Transit Hub & Spoke

Pour que les machines du VNet-Spoke (10.1.0.0/16) puissent joindre mon LAN local à travers le Hub sans avoir à payer une seconde passerelle VPN, j’ai configuré le VNet Peering en cochant Allow gateway transit côté Hub et Use the remote virtual network’s gateway côté Spoke.

Une fois le tunnel monté, j’ai déroulé une vérification en quatre étapes pour valider le routage de bout en bout :

1. Audit du démon BGP (Shell vtysh) : Vérification de l’état de la session TCP 179 (Up/Down, compteurs MsgRcvd/MsgSent) directement en CLI avec vtysh -c "show ip bgp summary".
2. Table de routage du noyau FreeBSD : Contrôle dans Diagnostics > Routes que les préfixes Azure 10.0.0.0/16 et 10.1.0.0/16 sont bien injectés dynamiquement sur l’interface tunnel ipsec1.
3. Panneau BGP Peers Azure : Confirmation du statut Connected côté portail Azure et de la réception de ma route locale 192.168.10.0/24 (Routes learned: 1).
4. Audit des Routes Effectives (Effective Routes) : Sur la carte réseau (NIC) de ma VM dans le Spoke (10.1.1.4), j’ai vérifié que le préfixe 192.168.10.0/24 remontait bien dynamiquement avec la source BGP et comme prochain saut Virtual network gateway.

6. Ingénierie FinOps & Infrastructure as Code (Modèles ARM)

6.1 Stratégie de Déploiement Incrémentiel à la Demande

Dans Azure, des services managés comme la VPN Gateway (VpnGw1AZ) ou Azure Bastion tournent et facturent à l’heure en continu, sans bouton « Stop ». Pour ne pas brûler mon budget Cloud entre deux sessions de lab (FinOps), j’ai exporté l’architecture de mon groupe de ressources (AGHCORP-RG) sous forme de modèles ARM (template.json et parameters.json) avant de supprimer les ressources coûteuses.

Quand je reprends le travail, je réinjecte mon modèle via Deploy a custom template en mode Incrémentiel (Incremental) : Azure compare l’état décrit dans le JSON avec ce qui tourne déjà, ne touche pas aux ressources existantes (VNets, VMs, Stockage) et recrée uniquement les passerelles manquantes.

6.2 Focus Ingénierie : Résolution de la Dépendance Circulaire ARM & Gestion des Secrets

En réinjectant le modèle ARM généré automatiquement par Azure depuis ma topologie Hub & Spoke, je me suis heurté à deux blocages du moteur d’orchestration que j’ai dû corriger dans le code :

1. Correction de la boucle de dépendance (Circular dependency detected) : À cause du peering bidirectionnel, l’export natif d’Azure crée une dépendance croisée : Vnet-Hub attend que Vnet-Spoke existe, mais Vnet-Spoke contient aussi une référence vers Vnet-Hub dans son bloc "dependsOn". Au déploiement, le validateur ARM rejette immédiatement le fichier avec l’erreur InvalidTemplate. La solution : ouvrir le template.json et vider le tableau "dependsOn" sur la déclaration du réseau Spoke pour casser la boucle, tout en gardant intactes les 6 autres dépendances légitimes (sous-réseaux et connexions) :

   {
       "type": "Microsoft.Network/virtualNetworks",
       "apiVersion": "2025-07-01",
       "name": "[parameters('virtualNetworks_Vnet_Spoke_name')]",
       "location": "francecentral",
       "dependsOn": [],
       "properties": { ... }
   }
   

2. Persistance de l’IP Publique & Sanitization de la clé PSK : En prenant soin de ne pas supprimer l’objet IP publique statique (VPN-PUBLIC1, SKU Standard) lors du nettoyage, ma passerelle VPN récupère exactement la même IP (51.138.199.177) à la reconstruction, ce qui m’évite de toucher à la configuration de pfSense. En revanche, comme Azure n’exporte jamais les secrets en clair dans les JSON, la clé pré-partagée (sharedKey) est remplacée par une valeur factice à l’export — ce qui provoque une erreur MAC mismatched dans les logs IPsec au redémarrage. Il suffit de réinjecter la vraie PSK dans l’objet Connection (ou via parameters.json / Azure Key Vault) au moment du déploiement pour que le tunnel IPsec et la session BGP remontent tout seuls.

7. Jalon 3 : Identité Hybride & Architecture DNS Bidirectionnelle

7.1 Synchronisation d’Identités avec Microsoft Entra Connect

Pour unifier les identités entre mon domaine local aghcorp.lab et le Cloud, j’ai installé l’agent Microsoft Entra Connect sur mon serveur local en activant le Password Hash Synchronization (PHS) et le Seamless Single Sign-On (SSO). Tous les comptes et groupes que j’avais créés via mon script PowerShell au Jalon 1 remontent ainsi automatiquement dans le tenant Microsoft Entra ID avec le statut On-premises sync enabled : Yes.

/user%20synch.png>

7.2 Résolution DNS Hybride Croisée (Private Resolver & Private DNS Zones)

Dès qu’on passe sur une architecture Zéro-Trust à base de Private Endpoints, le DNS devient la pièce maîtresse : si la résolution de noms échoue, plus rien ne communique. J’ai donc monté une résolution DNS bidirectionnelle entre Hyper-V et Azure :

• Sens Azure → On-Premise : J’ai déployé un Azure DNS Private Resolver (ou DNS Forwarder) dans le Hub avec une règle de transfert pour envoyer toutes les requêtes visant la zone aghcorp.lab / corp.local vers mon contrôleur de domaine local (192.168.10.2 / .10).
• Sens On-Premise → Azure : J’ai créé les Azure Private DNS Zones (privatelink.blob.core.windows.net, privatelink.file.core.windows.net et privatelink.azurewebsites.net) liées à mes VNets, puis j’ai configuré des Redirecteurs Conditionnels (Conditional Forwarders) sur mon serveur DNS Windows Server local pointant vers l’Inbound Endpoint du résolveur Azure à travers le VPN.

Tests de validation (Health Checks) :

# 1. Depuis une VM Azure (connectée via Azure Bastion) vers le serveur de fichiers On-Premise :
Resolve-DnsName -Name srv-fs.aghcorp.lab
# -> Retourne avec succès l'enregistrement A privé : 192.168.10.11

# 2. Depuis le serveur On-Premise vers la zone DNS privée Azure :
Resolve-DnsName -Name privatelink.blob.core.windows.net
# -> Traverse le tunnel IPsec et retourne l'enregistrement SOA / A privé d'Azure DNS

8. Jalon 4 : Stockage Hybride Zéro-Trust & Azure File Sync

8.1 Synchronisation et Cloud Tiering avec Azure File Sync

Pour étendre la capacité de mon serveur de fichiers local (SRV-FS) sans saturer les disques de mon hôte Hyper-V, j’ai déployé un Storage Sync Service dans Azure et enregistré SRV-FS via l’agent Azure File Sync.

• Mes partages SMB locaux (avec leurs permissions NTFS basées sur le modèle AGDLP) se synchronisent en temps réel vers un partage Azure Files.
• J’ai activé le Cloud Tiering : seuls les fichiers les plus utilisés restent en cache sur le disque local de SRV-FS, tandis que les fichiers froids sont automatiquement convertis en pointeurs (reparse points) et stockés dans Azure de manière transparente pour l’utilisateur.

8.2 Cloisonnement Zéro-Trust & Gestion du Cycle de Vie

Pour coller à une approche Zéro-Trust, j’ai complètement verrouillé le compte de stockage :

• Coupure de l’accès public : Toute requête arrivant depuis Internet est rejetée à la porte.
• Private Endpoints : Les services File et Blob ne sont exposés que via des interfaces réseau privées dans Subnet-Endpoints (10.1.3.0/24), avec leurs enregistrements A poussés dans les zones DNS privées privatelink.*.
• Contrôle d’accès & FinOps sur les données : J’ai géré les droits via RBAC Entra ID et des jetons SAS (Shared Access Signatures) restreints dans le temps, et j’ai ajouté une règle de Lifecycle Management pour basculer automatiquement les blobs vers les tiers Cool puis Archive au fil des jours.

9. Jalon 5 : Compute Haute Disponibilité, VMSS & Application Gateway WAF v2

9.1 Cluster VMSS Multi-Zones (Availability Zones)

Pour la brique frontale web IaaS, j’ai mis en place un Virtual Machine Scale Set (VMSS) dans Subnet-Compute (10.1.1.0/24), réparti sur les trois Zones de Disponibilité (Availability Zones 1, 2 et 3) de la région avec des règles d’Auto-scaling pour absorber les pics de charge.

9.2 Routage Applicatif L7 (Path-Based) & Protection OWASP (WAF v2)

En frontal de ce cluster, j’ai placé un Azure Application Gateway WAF v2 dans son propre sous-réseau afin de gérer deux besoins :

1. Routage basé sur le chemin d’URL (Path-Based Routing, Couche 7 OSI) :
   • Le trafic classique (/*) est envoyé vers le Backend Pool contenant les instances du VMSS.
   • Dès qu’une requête cible /images/*, le répartiteur l’aiguille dynamiquement vers un second Backend Pool où tourne mon serveur d’images dédié (10.1.1.4).
2. Pare-feu Applicatif Web (WAF) en mode Prevention : J’ai activé le jeu de règles managées OWASP Core Rule Set. Pour vérifier qu’il faisait bien son travail, j’ai tenté une injection SQL (SQLi) directement dans l’URL depuis mon navigateur : l’Application Gateway a immédiatement intercepté le payload en bordure et m’a renvoyé une erreur 403 Forbidden avant même que la requête ne touche les VMs.

J’ai ensuite validé l’ensemble des flux et mes règles de filtrage (NSG/UDR) avec les outils d’Azure Network Watcher (IP Flow Verify, Next Hop et Connection Monitor).

10. Jalon 6 : Sécurisation PaaS (App Service), Gouvernance & Sauvegarde (PRA)

10.1 Isolation Entrante et Sortante d’Azure App Service

Côté PaaS, j’ai déployé une Web App sur Azure App Service en utilisant les Deployment Slots (Staging ↔ Production) pour valider les mises en production par basculement (Swap) sans coupure de service.

Le défi avec un service PaaS managé, c’est qu’il est exposé sur Internet par défaut. Pour l’enfermer dans mon réseau privé, j’ai isolé les deux sens de circulation :

• Verrouillage des flux entrants (Inbound) : J’ai coupé l’accès public (ce qui renvoie immédiatement un 403 Forbidden depuis Internet) et j’ai rattaché un Private Endpoint dans Subnet-Endpoints pour que l’application ne soit joignable que depuis le réseau interne et le VPN.
• Intégration réseau sortante (Outbound VNet Integration) : J’ai connecté la sortie de la Web App au sous-réseau délégué Subnet-AppService (10.1.2.0/24). Grâce au transit BGP configuré au Jalon 2, mon application PaaS peut ainsi interroger directement mes serveurs locaux sous Hyper-V.

Validation depuis la console de diagnostic Kudu (Advanced Tools) de la Web App :

tcpping 192.168.10.10:53
# Connected to 192.168.10.10:53, time taken: 18ms

Ce simple tcpping confirme que le flux sortant de l’App Service emprunte bien le sous-réseau délégué du Spoke, traverse le peering VNet, passe par la passerelle VPN du Hub et descend dans le tunnel IPsec jusqu’au port DNS (53) de mon contrôleur de domaine local.

📸 [Console Kudu de l’App Service affichant le succès de la commande tcpping 192.168.10.10:53 vers le contrôleur de domaine On-Premise]

10.2 Gouvernance Cloud (Azure Policy, RBAC & Supervision)

Pour encadrer le tenant et éviter les dérives de conformité ou de coûts, j’ai mis en place plusieurs garde-fous :

• Azure Policy (Restriction géographique / Souveraineté des données) : J’ai appliqué une stratégie Allowed locations qui limite les déploiements aux seules régions européennes autorisées. Pour tester son efficacité, j’ai tenté de provisionner une ressource dans la région East US : le déploiement a été bloqué net par le moteur de conformité (Resource disallowed by policy).
• Supervision centralisée : J’ai raccordé les ressources à un Log Analytics Workspace pour centraliser les journaux de diagnostic et les métriques de performance, avec des règles d’alerte en cas d’anomalie.

📸 [Message d’erreur du portail Azure bloquant la création d’une ressource dans la région “East US” grâce à l’Azure Policy active]

10.3 Plan de Sauvegarde Hybride (Recovery Services Vault & Agent MARS)

Enfin, pour assurer le Maintien en Conditions Opérationnelles (MCO) et la reprise après sinistre (PRA) sur l’ensemble du périmètre, j’ai centralisé les sauvegardes dans un coffre Azure Recovery Services Vault :

1. Sauvegarde Cloud IaaS : Mise en place d’une politique de sauvegarde quotidienne par snapshots cohérents au niveau applicatif pour les VMs Azure.
2. Sauvegarde On-Premise vers le Cloud (Agent MARS) : J’ai installé l’agent Microsoft Azure Recovery Services (MARS) directement sur mon serveur de fichiers local (SRV-FS), enregistré la machine auprès du coffre Azure avec sa clé d’authentification et une phrase secrète de chiffrement, puis lancé un Back Up Now de mes volumes locaux vers Azure à travers le tunnel VPN.

📸 [Console locale de l’agent “Microsoft Azure Backup” (MARS) sur SRV-FS montrant le statut “Transfert des données terminé” vers le Recovery Services Vault]

11. Bilan Technique & Compétences Validées

Construire ce laboratoire de bout en bout m’a permis de mettre en pratique et de valider l’ensemble des briques critiques d’une infrastructure hybride de production :

• Ingénierie Réseau & Routage Avancé : Montage de tunnels IPsec IKEv2 en mode VTI, résolution des blocages liés au NAT opérateur (NAT-T UDP 4500 et forçage du Local ID), routage dynamique eBGP sur adressage APIPA et architecture Hub & Spoke avec transit de passerelle.
• Administration Système & Identité : Cloisonnement par Tiering Active Directory, automatisation PowerShell (Splatting), hiérarchie temporelle NTP Stratum, synchronisation Microsoft Entra Connect et résolution DNS hybride bidirectionnelle (Private Resolver & Private DNS Zones).
• Architecture Cloud Haute Disponibilité & Zéro-Trust : Équilibrage de charge L7 et protection WAF OWASP (Application Gateway v2), élasticité multi-zones (VMSS), isolation PaaS entrante/sortante (Private Endpoints & VNet Integration) et Cloud Tiering (Azure File Sync).
• Gouvernance, PRA & FinOps (IaC) : Conformité automatisée par Azure Policy, sauvegarde hybride (Recovery Services Vault / MARS) et maîtrise des coûts via le déploiement incrémentiel de modèles ARM JSON débogués.