Tu vois le problème. Tout le monde parle de zero trust comme si c’était un produit à acheter, un bouton magique, un gros chantier réservé aux boîtes avec un SOC et 14 firewalls en cluster. Dans la vraie vie, surtout sur une petite infra, c’est rarement ça.
Zero trust, au fond, c’est plutôt une discipline. Une manière de dire : « je ne fais confiance à rien par défaut, je vérifie, je limite, je journalise, et je pars du principe que ça va finir par casser ». Et ça, même un petit SI peut le faire. Pas parfaitement. Mais assez bien pour réduire la casse.
L’idée de cet article, c’est un plan réaliste. Faisable. Avec des étapes. Et des compromis assumés.
Objectif : que ton infra reste utilisable, mais qu’un poste compromis ne se transforme pas en autoroute vers tout le reste.
Ce que veut dire zero trust sur une petite infra
On va simplifier sans trahir.
Sur une petite infra, zero trust veut dire :
- identité d’abord : qui est tu, et tu as le droit à quoi, maintenant
- moindre privilège : pas de droits permanents « au cas où »
- segmentation : tout le monde ne parle pas à tout le monde
- durcissement : on enlève les trucs inutiles, on garde le minimum
- visibilité : logs, inventaire, alertes basiques
- réponse : quand ça arrive, tu sais quoi faire, même à 23 h
Et surtout, un truc important : on ne déploie pas tout d’un coup. Sinon tu vas te faire détester par les utilisateurs, et tu vas toi même abandonner.
Avant de commencer : inventaire rapide, sinon tu bosses dans le vide
Je sais, c’est chiant. Mais c’est le socle.
En une demi journée, tu peux déjà sortir :
- la liste des machines : serveurs, PC, portables, VM, NAS
- la liste des comptes : AD, locaux, comptes de service, admin, prestas
- les applis critiques : ERP, partage fichiers, messagerie, outil ticketing, sauvegarde
- les flux : qui parle à quoi (même grossièrement)
Si tu es en environnement Windows, un duo simple :
- ADUC + GPMC pour les comptes et GPO
- un scan type Nmap depuis un VLAN admin pour repérer les services
Et oui, note tout. Même dans un doc moche.
Sur BTS SIO2 SISR Tech Lab, on peut faire un format « fiche d’infra » type E4 E5. Ça te force à structurer. Et après, tu le réutilises pour tout.
Étape 1 : verrouiller l’identité (c’est là que tout commence)
1. Mettre la MFA là où ça compte vraiment
Tu n’as pas besoin de MFA partout au début. Mets la MFA sur :
- messagerie et suite cloud (Microsoft 365, Google Workspace)
- VPN
- accès admin aux hyperviseurs, firewall, console cloud
- comptes à privilèges
Si tu n’as qu’un seul endroit à traiter, commence par la messagerie. Les compromissions partent souvent de là.
2. Nettoyer les admins et les comptes « historiques »
Classique : un compte « admin », un compte « admin2 », un compte « test », et personne ne sait à qui c’est. Là, il faut être un peu brutal.
- un admin = une personne, nominatif
- pas de comptes partagés, sauf exception documentée
- désactiver les comptes inactifs
- vérifier les appartenances aux groupes : Domain Admins, Enterprise Admins, Administrateurs locaux
Tu peux viser un truc simple : 2 comptes par personne.
- compte normal (mail, bureautique)
- compte admin (uniquement pour admin)
Et surtout : tu sépares les usages. Le compte admin ne navigue pas, ne lit pas ses mails, ne va pas sur Teams. Oui, c’est relou. Oui, c’est efficace.
3. Mettre une politique de mots de passe réaliste
Évite les règles absurdes. Sur un petit SI, tu veux surtout :
- pas de mots de passe faibles
- pas de réutilisation
- rotation seulement si suspicion ou exigence métier
- verrouillage après tentatives, sans casser la prod
Si tu peux, ajoute un gestionnaire de mots de passe (Bitwarden, KeePassXC en local selon contexte). Et impose le sur les comptes à privilèges.
Étape 2 : réduire la surface d’attaque des postes (sans sortir l’artillerie)
Le poste utilisateur, c’est le point d’entrée le plus probable. Donc on y gagne beaucoup vite.
1. Retirer les droits admin locaux
C’est LA bataille. Et elle est politique.
- les utilisateurs ne sont pas admin local
- exception : groupes dédiés, machine dédiée, justification claire
Tu peux faire ça proprement via GPO :
- « Restricted Groups » ou GPP Local Users and Groups
- LAPS (ou Windows LAPS) pour gérer le mot de passe admin local
Windows LAPS, c’est un énorme gain. Tu supprimes le vieux mot de passe « AdminPC2021! » répliqué partout. Et tu le remplaces par des mots de passe uniques, stockés dans AD.
2. Activer des basiques Microsoft Defender (si tu es sur Windows)
Sans rentrer dans un SOC, tu peux déjà :
- activer la protection cloud
- activer ASR rules (progressivement, en audit puis en blocage)
- bloquer les macros venant d’internet
- désactiver SMBv1 partout
Tu testes sur un petit groupe pilote. Toujours. Sinon tu vas bloquer un Excel de compta et tu vas entendre parler de toi pendant 3 semaines.
3. Chiffrement disque et verrouillage écran
BitLocker sur les portables. Même si tu ne fais que ça, c’est déjà énorme.
- BitLocker + recovery key stockée en AD ou Intune
- verrouillage auto après X minutes
- écran de veille avec mot de passe
Ce n’est pas glamour, mais ça évite des fuites bêtes.
Étape 3 : segmenter le réseau, mais version « petite infra »
Zero trust adore la micro segmentation. Mais toi, tu n’as pas forcément le temps. Donc on fait une segmentation pragmatique.
Le modèle simple en 4 zones
- VLAN utilisateurs
- VLAN serveurs
- VLAN admin (bastion, jump server, postes IT)
- VLAN invités ou BYOD (wifi invité, appareils perso)
Règles firewall :
- utilisateurs vers serveurs : seulement ports nécessaires (SMB, RDP si besoin, HTTP vers applis)
- utilisateurs vers admin : interdit
- admin vers tout : autorisé mais journalisé, et si possible via bastion
- invités vers LAN : interdit, internet seulement
Même sur un firewall SMB, tu peux le faire.
Bonus : un bastion, même minimal
Un jump server (Windows Server ou VM) dans le VLAN admin.
- accès RDP uniquement depuis postes IT
- pas d’accès internet
- outils d’admin installés dessus
- logs activés
Ça force un chemin d’accès. Et ça te donne un point de contrôle.
Étape 4 : sécuriser les serveurs, parce que c’est là que ça fait mal
1. Fermer les services inutiles
Sur tes serveurs :
- pas de RDP ouvert à tous les VLAN
- pas de partages « Everyone Full Control »
- pas de vieux protocoles
Fais une revue simple : ports ouverts, rôles, partages, comptes.
2. Gérer les comptes de service
Les comptes de service, c’est souvent le chaos.
Plan réaliste :
- identifier les comptes de service
- mot de passe fort, stocké en coffre
- interdire l’ouverture de session interactive
- limiter les droits aux seules ressources
Si tu peux aller plus loin : gMSA sur AD. Pas obligatoire au jour 1, mais très bon move.
3. Patch management sans te mentir
Tu n’auras pas un patching parfait. Vise plutôt :
- une fenêtre mensuelle
- un groupe pilote
- un reporting simple : « à jour », « en retard », « critique »
Le but, c’est de ne pas avoir des serveurs avec 18 mois de retard. Même 2 mois, c’est déjà mieux que rien.
Étape 5 : protéger l’accès distant (c’est souvent le trou béant)
Si tu as encore du RDP exposé sur internet. Stop. Vraiment. C’est non.
Options réalistes :
- VPN + MFA
- reverse proxy applicatif pour les applis web
- RDP via bastion, jamais directement
Et pour le VPN :
- pas d’accès full LAN par défaut
- split tunneling selon besoin, mais contrôlé
- profils par groupes : prestataires, IT, utilisateurs
- logs de connexion gardés
Étape 6 : les logs et la visibilité, version « je n’ai pas de SIEM »
Tu n’as pas besoin d’un SIEM hors de prix pour démarrer. Tu as besoin de :
- logs centralisés, même basiques
- une rétention minimale
- des alertes sur 5 ou 10 événements critiques
Centraliser les logs : trois options
- Windows Event Forwarding vers un serveur de collecte
- Syslog vers un petit serveur (rsyslog, Graylog, Loki)
- solution cloud si déjà en place
Ce que tu veux surveiller en priorité :
- échecs de connexion répétitifs
- ajout à un groupe admin
- création de compte
- connexions VPN
- exécution PowerShell suspecte (si tu peux)
Même si tu ne regardes pas tout, le jour où il se passe un truc, tu seras content d’avoir l’historique.
Étape 7 : sauvegardes, le vrai dernier rempart (et souvent le plus mal fait)
Zero trust ou pas, si tes sauvegardes sont chiffrées par un ransomware, c’est fini.
Checklist simple et efficace :
- règle 3 2 1 : 3 copies, 2 supports, 1 hors site
- une sauvegarde hors ligne ou immuable
- un compte dédié sauvegarde, sans droits admin partout
- tests de restauration (oui, vraiment)
Si tu as un NAS de sauvegarde accessible en SMB depuis tout le LAN, c’est fragile. Mets le dans un VLAN dédié. Restreins les accès. Et idéalement, utilise des snapshots immuables si possible.
Étape 8 : politique de moindre privilège, mais en mode humain
Le moindre privilège, sur le papier, c’est simple. Dans la vraie vie, les gens ont besoin de bosser.
Approche réaliste :
- tu enlèves les droits « permanents » les plus dangereux
- tu ajoutes un mécanisme d’élévation temporaire pour l’IT
- tu documentes les exceptions, pas 200, juste les vraies
Si tu es sur Microsoft, tu peux t’inspirer de :
- tiers admin model (admin workstation, séparation des rôles)
- Just Enough Administration (JEA) pour PowerShell
- PIM si tu es dans Entra ID / Azure AD (selon licences)
Mais même sans ça, tu peux déjà faire un truc : séparer les groupes.
- groupe « helpdesk reset mdp »
- groupe « admin serveurs »
- groupe « admin AD »
- groupe « admin hyperviseur »
Ça évite le « tout le monde Domain Admin parce que sinon ça marche pas ».
Un plan sur 30 jours (vraiment faisable)
Je te mets un plan simple. Pas parfait. Mais si tu le fais, tu auras déjà monté le niveau.
Semaine 1 : identité
- MFA sur mail, VPN, admins
- nettoyage comptes inactifs
- séparation compte user / compte admin
Semaine 2 : postes
- déploiement LAPS
- retrait admin local (pilote)
- blocage macros internet + durcissement Defender en audit
Semaine 3 : réseau
- création VLAN admin + serveurs si pas existant
- règles firewall minimales
- mise en place d’un bastion
Semaine 4 : sauvegarde + logs
- audit sauvegardes, mise en place copie hors site
- test restauration
- centralisation logs basique + alertes essentielles
Les erreurs classiques à éviter (parce que je les ai vues, et ça pique)
- vouloir « faire du zero trust » en achetant un outil avant d’avoir MFA et LAPS
- activer des règles ASR en blocage direct sur tout le parc, sans pilote
- segmenter sans comprendre les flux, puis passer 2 semaines à ouvrir « any any »
- oublier les prestataires et leurs accès
- sauvegardes accessibles comme un partage de fichiers normal
- pas de doc. puis incident. puis panique
Petit mot pour les étudiants BTS SIO SISR (et les admins juniors)
Si tu es en mode formation ou alternance, c’est un sujet en or.
Tu peux transformer ce plan en :
- projet E4 : segmentation VLAN, bastion, GPO, LAPS, durcissement postes
- projet E5 : procédures, documentation, matrice des flux, plan de reprise, journalisation
Et si tu veux, sur BTS SIO2 SISR Tech Lab (https://sio1blog.blogspot.com/), l’idée c’est aussi ça : partager des labs concrets, des checklists, des retours terrain, pas juste des définitions. Tu peux t’en servir comme base, ou t’en inspirer pour écrire ta propre doc.
Conclusion : zero trust, c’est une trajectoire, pas un produit
Tu n’auras jamais un zero trust « pur » sur une petite infra. Et ce n’est pas grave.
Ce que tu veux, c’est :
- réduire les accès implicites
- limiter les mouvements latéraux
- rendre l’attaque bruyante et détectable
- garder une capacité de restauration
Fais simple, fais solide, fais itératif. Et surtout, documente au fur et à mesure, même si c’est moche au début. C’est souvent ce qui fait la différence entre « on a eu un incident » et « on a perdu l’entreprise ».
Questions fréquemment posées
Qu'est-ce que le Zero Trust dans une petite infrastructure informatique ?
Le Zero Trust est une discipline qui consiste à ne faire confiance à rien par défaut, à vérifier, limiter les accès, journaliser les actions et partir du principe que des failles peuvent survenir. Dans une petite infrastructure, cela signifie mettre en place des contrôles d'identité, appliquer le principe de moindre privilège, segmenter le réseau, durcir les systèmes, assurer la visibilité via logs et alertes, et préparer une réponse aux incidents.
Pourquoi ne faut-il pas déployer toutes les mesures Zero Trust d'un coup ?
Déployer toutes les mesures Zero Trust simultanément peut engendrer une mauvaise expérience utilisateur et conduire à un abandon du projet. Il est préférable d'y aller par étapes avec des compromis assumés afin de garantir que l'infrastructure reste utilisable tout en renforçant progressivement la sécurité.
Comment commencer la mise en place du Zero Trust dans un petit SI ?
Avant tout, il faut réaliser un inventaire rapide de l'infrastructure : liste des machines (serveurs, PC, NAS), comptes utilisateurs et administrateurs, applications critiques et flux réseau. Ensuite, on commence par verrouiller l'identité en mettant notamment en place la MFA sur les services essentiels comme la messagerie, VPN et accès administratifs.
Quels sont les conseils pour gérer les comptes administrateurs dans un contexte Zero Trust ?
Il est conseillé d'avoir un compte administrateur nominatif par personne sans comptes partagés (sauf exception documentée), de désactiver les comptes inactifs et de vérifier régulièrement les appartenances aux groupes privilégiés. Idéalement chaque personne dispose de deux comptes distincts : un compte normal pour la bureautique et un compte admin réservé uniquement aux tâches d'administration.
Quelle politique de mots de passe adopter dans une démarche Zero Trust adaptée aux petites infrastructures ?
Il faut éviter les règles trop complexes ou inutiles. L'essentiel est d'empêcher l'utilisation de mots de passe faibles ou réutilisés, de ne faire tourner les mots de passe qu'en cas de suspicion ou besoin métier, et d'appliquer un verrouillage après plusieurs tentatives infructueuses sans pénaliser excessivement l'utilisateur.
Quels sont les bénéfices concrets du Zero Trust pour une petite infrastructure ?
Même s'il n'est pas parfait, le Zero Trust permet de réduire significativement les risques en limitant l'impact d'un poste compromis. Il empêche qu'une intrusion locale se transforme en accès libre à toute l'infrastructure grâce à des contrôles stricts d'identité, segmentation réseau et surveillance continue.
0 Commentaires