Premiers pas sur Azure : monter une base réseau sécurisée

Je vais être direct : ce projet est basique. C’est voulu.

Ça fait plusieurs mois que je travaille sur mon homelab, pfSense, Proxmox, VLANs, Wazuh, et je voulais enfin me confronter à Azure pour de vrai. Pas juste parcourir la documentation pour préparer l’AZ-900. Alors j’ai ouvert un compte PAYG et j’ai commencé par le plus simple : poser une base réseau sécurisée, comprendre la logique du portail, et ne pas me retrouver avec une facture inattendue à la fin du mois.

C’est le premier d’une série de quatre projets pour couvrir le terrain de l’AZ-500 avant d’entrer en master cybersécurité en septembre.

La chose qui m’a pris le plus de temps à vraiment saisir

Sur mon homelab, quand je pense “réseau”, je pense topologie : un switch MikroTik, un pfSense, des câbles, des VLANs avec leurs sous-réseaux. Chaque élément a une place dans un rack ou sur une étagère.

Sur Azure, tout tourne autour du Resource Group. C’est un conteneur logique : machine virtuelle, réseau, règles de sécurité, tout vit dedans. Supprimer le Resource Group, c’est supprimer l’intégralité du projet en un clic.

La hiérarchie n’est pas visuelle ou spatiale, elle est administrative. Sur pfSense, je vois mon réseau parce que j’ai branché les câbles. Sur Azure, je le construis en déclarant des ressources qui se référencent entre elles. C’est une autre façon de penser. Je ne dirais pas que c’est plus compliquée, c’est juste que le modèle mental est différent et qu’il faut le temps de le construire.

Ce que j’ai construit

Un VNet avec trois sous-réseaux : subnet-mgmt pour l’administration, subnet-app pour les workloads applicatifs, et AzureBastionSubnet réservé pour Azure Bastion que je testerai dans un prochain sprint.

Les deux sous-réseaux principaux sont en mode privé, sans accès internet sortant par défaut. Pour que subnet-app puisse joindre internet, j’ai ajouté une NAT Gateway. Petit détail à ne pas oublier : elle génère un coût fixe même quand toutes les VMs sont éteintes. La règle que j’ai adoptée, supprimer la NAT Gateway entre les sessions et la recréer en cinq minutes au démarrage.

Les Network Security Groups jouent un rôle proche de pfSense au niveau du sous-réseau. À la différence que pfSense travaille en L7 et les NSGs s’arrêtent au L4, mais l’idée est la même : des règles avec priorité numérique, entrantes et sortantes. J’en ai configuré deux :

• nsg-mgmt : bloque le trafic entrant depuis subnet-app et interdit l’accès internet en sortie
• nsg-app : autorise SSH depuis Bastion et depuis mon IP personnelle, bloque le trafic vers subnet-mgmt

Pour tester, j’ai déployé une VM Ubuntu sur subnet-app. Premier accroc : la famille de VM que j’avais choisie avait un quota à zéro sur France Central. Azure l’indique clairement dans le message d’erreur, j’ai basculé sur une autre famille sans perdre plus de cinq minutes.

Gouvernance dès le départ

Une chose qui m’a surpris positivement : la gouvernance est accessible dès les premiers projets, pas réservée aux architectures de prod à cinquante ressources. J’ai configuré deux politiques sur le Resource Group via Azure Policy.

La première hérite automatiquement les étiquettes du groupe de ressources sur chaque nouvelle ressource créée. Ça paraît anecdotique, mais c’est exactement le genre de chose qu’on oublie systématiquement dans une infra qui grossit. Le chaos de facturation en entreprise commence souvent là.

La seconde restreint les régions autorisées à France Central uniquement. C’est une politique de type Deny, elle bloque la création à la source plutôt que de signaler après coup. Le cas d’usage concret : empêcher qu’une ressource soit déployée dans une région non approuvée, pour des raisons de coût ou de localisation des données au sens RGPD.

Ce qui m’a aidé à saisir la mécanique : une politique Modify doit agir sur des ressources existantes, donc elle a besoin d’une identité managée pour avoir les droits nécessaires. Une politique Deny bloque la requête avant que la ressource soit créée, il n’y a rien à modifier, donc pas d’identité. La distinction fait sens une fois formulée comme ça.

Ce que j’en retiens

Azure est bien pensé pour quelqu’un qui vient de l’écosystème Microsoft. J’ai retrouvé des réflexes de Power BI : interface en français, navigation par panneaux successifs, logique de recherche dans la barre globale. Ça ne veut pas dire que tout est simple, mais l’interface ne rajoute pas de friction inutile. La prise en main est honnête.

Ce qui demande de la discipline, c’est l’organisation. Tagging dès le départ, scope des politiques bien défini, règle d’hygiène sur les ressources facturées même à l’arrêt. Je retrouve exactement les mêmes réflexes que sur une infra physique bien tenue. La différence, c’est que sur Azure les erreurs d’organisation ont un coût direct et immédiat sur la facture.

Je suis ressorti de ce premier projet avec une question que je n’avais pas au départ : jusqu’où la logique Resource Group tient-elle quand on multiplie les environnements et les équipes ? Je pense que c’est exactement là que le Projet 2 sur l’identité et les accès va devenir intéressant.

La suite

• Tester Azure Bastion en tier Developer sur ce même projet
• Projet 2 : Identity & Zero Trust — Entra ID, RBAC, Privileged Identity Management, Conditional Access

Les configurations de ce projet sont disponibles sur GitHub.