Un serveur compromis marque rarement la fin d’une attaque. Si ce serveur peut atteindre toutes les autres machines du réseau, un intrus peut l’utiliser comme point de départ pour voler des identifiants, déployer un rançongiciel, modifier des applications ou attaquer les systèmes de sauvegarde. La segmentation réseau réduit la portée de l’incident en contrôlant quels systèmes peuvent communiquer et pour quelles raisons.
La segmentation n’est ni un produit unique ni un simple paramètre. Il s’agit d’une discipline de conception qui combine VLAN, sous-réseaux, zones de sécurité, routage, règles de pare-feu, contrôles d’identité et supervision. L’objectif est simple : un serveur web ne devrait pas pouvoir établir des connexions arbitraires avec les ordinateurs portables des employés, une base de données ne devrait pas être accessible depuis l’Internet public et un serveur de production ne devrait pas disposer automatiquement d’un accès administratif à l’infrastructure de sauvegarde.
Pour les agences et les petites entreprises, une conception cohérente n’a pas besoin d’être complexe. Elle doit en revanche refléter le fonctionnement réel des systèmes, appliquer le refus par défaut chaque fois que cela est possible et être testée régulièrement. La segmentation doit également compléter une stratégie de sauvegarde isolée et récupérable. Elle ne peut pas garantir qu’une compromission sera contenue, ni restaurer des données qu’un attaquant a chiffrées ou supprimées.
Contre quoi la segmentation réseau protège-t-elle ?
La segmentation réseau divise l’infrastructure en zones distinctes et établit des frontières contrôlées entre elles. Ces frontières peuvent être mises en œuvre au moyen de réseaux physiques, de VLAN, de sous-réseaux routés, de pare-feu virtuels, de pare-feu hôtes ou d’une combinaison de ces contrôles.
Le principal avantage en matière de sécurité est de limiter les déplacements latéraux. Le déplacement latéral désigne le processus utilisé par un attaquant pour passer d’un système initialement compromis à d’autres systèmes au sein de l’environnement. Un serveur web exposé au public peut être compromis par l’intermédiaire d’un framework non corrigé. L’attaquant recherche alors des identifiants de base de données, des interfaces d’administration, des partages de fichiers, des services de domaine, des hyperviseurs et des consoles de sauvegarde. Chaque service accessible représente une nouvelle occasion d’attaque.
Un réseau plat facilite ce processus. Dans une conception plate, les serveurs, postes de travail, imprimantes, hyperviseurs et outils d’administration peuvent tous se trouver dans une large plage d’adresses IP. L’accessibilité réseau est souvent considérée comme une autorisation. Une fois à l’intérieur, l’attaquant peut analyser l’environnement, se connecter à des services qui n’ont jamais été destinés à être publics et exploiter des contrôles internes faibles.
La segmentation modifie cette hypothèse par défaut. Les systèmes sont placés dans des zones en fonction de leur rôle et de leur exposition, et le trafic entre les zones est contrôlé explicitement. Un serveur web compromis peut rester dangereux, mais il ne devrait disposer que des connexions nécessaires au fonctionnement de l’application. Il ne devrait pas pouvoir analyser le réseau d’administration ni se connecter à tous les serveurs via le bureau à distance et SSH.
Les équipes qui recherchent des informations sur la segmentation réseau et la sécurité des serveurs contre les déplacements latéraux trouveront de nombreuses architectures possibles. L’essentiel n’est pas de reproduire aveuglément un schéma. La conception doit suivre les dépendances réelles des applications, les processus d’administration et les exigences de récupération.
Les VLAN, les sous-réseaux et les zones de sécurité sont liés, mais différents
Les VLAN assurent une séparation logique
Un réseau local virtuel, ou VLAN, sépare les appareils au niveau de la couche 2, même lorsqu’ils utilisent le même équipement de commutation physique. Une entreprise peut par exemple placer les postes de travail du bureau dans un VLAN, les serveurs de production dans un autre et les interfaces d’administration dans un troisième. Les VLAN réduisent la portée des diffusions et créent des points précis où le trafic doit être routé.
Les VLAN ne constituent pas à eux seuls une frontière de sécurité. Si un routeur, un commutateur de couche 3 ou un pare-feu autorise tout le trafic entre les VLAN, la séparation est essentiellement administrative. La valeur de sécurité provient de l’inspection et du contrôle du trafic lorsqu’il franchit la frontière.
Les sous-réseaux définissent les réseaux routés
Chaque VLAN possède généralement son propre sous-réseau IP. Un sous-réseau de serveurs peut utiliser une plage d’adresses privées, tandis que le sous-réseau d’administration en utilise une autre. Les sous-réseaux facilitent la compréhension des routes et des règles de pare-feu, mais des plages IP distinctes n’empêchent pas automatiquement les communications. Le routage et les listes de contrôle d’accès déterminent toujours ce qui est autorisé.
Les zones de sécurité décrivent le niveau de confiance et l’exposition
Une zone de sécurité est un concept de politique. Elle regroupe des systèmes présentant un niveau d’exposition ou un objectif de sécurité similaire. Un petit environnement peut généralement comprendre :
- Zone Internet ou périphérique : pare-feu, proxies inverses, répartiteurs de charge et autres systèmes directement exposés aux réseaux externes.
- Zone web : serveurs web publics qui acceptent les requêtes d’Internet ou d’un proxy périphérique.
- Zone applicative : services applicatifs qui ne devraient accepter les requêtes que des systèmes web ou d’intégration approuvés.
- Zone de bases de données : serveurs de bases de données accessibles uniquement par des services applicatifs précis et des chemins d’administration approuvés.
- Zone d’administration : hôtes relais, consoles de supervision, systèmes de configuration, administration des hyperviseurs et autres interfaces administratives.
- Zone de sauvegarde : agents de sauvegarde, référentiels, systèmes d’administration et infrastructure de récupération séparés des charges de production.
- Zone utilisateurs : appareils des employés, imprimantes et autres équipements de bureau, qui nécessitent généralement une politique d’accès différente de celle des serveurs.
Ces zones peuvent être physiques, virtuelles ou hébergées par un fournisseur. L’essentiel est que le trafic entre elles passe par un point d’application des politiques et soit suffisamment journalisé pour permettre l’analyse des comportements inattendus.
Concevez l’architecture autour des besoins de communication
Le meilleur point de départ n’est pas une liste de numéros de VLAN. C’est un inventaire des services et de leurs besoins de communication. Pour chaque serveur, notez ce qu’il fournit, qui l’utilise, quels ports sont nécessaires, si la communication est initiée dans une seule direction ou dans les deux, et ce qui se passe lorsque la dépendance est indisponible.
Posez notamment les questions suivantes :
- La couche web doit-elle atteindre la couche applicative ou un proxy inverse interne peut-il assurer cette fonction ?
- Le serveur applicatif a-t-il besoin d’un accès direct à la base de données et, si oui, sur quel port ?
- Quels systèmes ont besoin du DNS, de la synchronisation horaire, de services d’identité ou de certificats ?
- La supervision interroge-t-elle les serveurs ou les agents envoient-ils leurs données à un collecteur ?
- Quels administrateurs ont besoin d’un accès SSH, d’un bureau à distance, d’une console ou d’un accès à l’hyperviseur ?
- Un serveur a-t-il réellement besoin d’un accès sortant à Internet et, si oui, vers quelles destinations ?
- Quelles connexions de sauvegarde sont initiées par le serveur de production, le serveur de sauvegarde ou les deux ?
Documentez les réponses dans une matrice de communication. Une matrice simple peut indiquer la zone source, la zone destination, le protocole, le port, la finalité, le sens, le responsable et la date de révision. Cela évite une erreur fréquente : autoriser un sous-réseau entier parce qu’une application a besoin d’une seule connexion.
Les dépendances applicatives doivent être vérifiées et non supposées. La documentation d’un fournisseur peut indiquer qu’un service utilise un port, alors que le déploiement réel dépend également du DNS, d’un fournisseur d’identité, d’un service de licence, d’un relais SMTP ou d’une API cloud. Commencez par une politique prudente, observez le trafic légitime, puis ajoutez des règles précisément définies, avec un responsable clairement désigné.
Une architecture pratique par niveaux pour les agences et petites entreprises
Une petite agence peut héberger des sites web de clients, des applications internes, des bases de données et des outils d’administration sur un nombre limité de serveurs physiques ou virtuels. Elle ne dispose pas nécessairement d’une équipe dédiée à la sécurité réseau. Une architecture utile peut néanmoins séparer les principaux risques sans créer un ensemble ingérable.
Niveau web
Le niveau web regroupe les systèmes qui traitent des requêtes non fiables. Ces serveurs doivent être considérés comme plus risqués, car ils exposent des services à Internet. N’autorisez le trafic entrant que pour les protocoles web nécessaires, normalement par l’intermédiaire d’un pare-feu, d’un proxy inverse ou d’une couche de répartition de charge. L’accès administratif doit passer par le chemin d’administration et non par l’interface publique.
Un serveur web doit généralement pouvoir établir des connexions vers le niveau applicatif, récupérer des mises à jour approuvées ou contacter certains services externes. Il ne devrait pas disposer d’un accès sans restriction au réseau des bases de données, aux partages de fichiers internes, aux appareils des employés ou aux interfaces d’hyperviseur. Si le serveur fournit uniquement du contenu statique, ses destinations autorisées peuvent être encore plus limitées.
Niveau applicatif
Le niveau applicatif exécute la logique métier, les API, les tâches en arrière-plan et les services d’intégration. Il ne devrait accepter du trafic que des serveurs web définis, d’intégrations fiables ou d’utilisateurs internes lorsque cela est nécessaire. Les accès sortants doivent être limités aux bases de données, files d’attente, services d’identité et API externes réellement utilisés par l’application.
Ne supposez pas que placer les serveurs applicatifs et les bases de données dans des VLAN distincts suffit. Le pare-feu doit autoriser uniquement le protocole et le port de base de données nécessaires à l’application, depuis les adresses applicatives précises. L’accès administratif aux bases de données doit utiliser une route d’administration séparée et une authentification renforcée.
Niveau bases de données
Les bases de données concentrent une valeur importante et doivent avoir l’exposition réseau la plus limitée possible. Elles ne devraient accepter de connexions ni depuis Internet ni depuis les réseaux généraux des utilisateurs. Dans de nombreux environnements, seuls quelques serveurs applicatifs devraient pouvoir se connecter au service de base de données.
Les serveurs de bases de données peuvent avoir besoin du DNS, de la synchronisation horaire, de la supervision et de la connectivité de sauvegarde. Ces besoins doivent être traités par des règles distinctes plutôt que regroupés dans une large politique d’autorisation. Si le moteur de base de données prend en charge le chiffrement en transit et une authentification forte, utilisez ces contrôles comme couche supplémentaire. La segmentation réseau réduit l’accessibilité ; elle ne rend pas à elle seule une connexion autorisée fiable.
Niveau supervision et journalisation
Les systèmes de supervision ont besoin de visibilité, mais la visibilité ne signifie pas un accès sans restriction. Si les agents de supervision envoient leurs données à un collecteur, autorisez la connexion sortante de l’agent vers ce collecteur. Si le collecteur interroge les systèmes, n’autorisez que les protocoles d’interrogation nécessaires depuis le sous-réseau de supervision.
Les journaux doivent être envoyés vers un emplacement qu’un attaquant ne peut pas facilement modifier après avoir compromis un serveur de production. Limitez les personnes autorisées à administrer la plateforme de supervision, protégez séparément ses identifiants et déclenchez des alertes lors des modifications des règles de pare-feu, des comptes privilégiés et de la configuration des sauvegardes. La supervision doit aider à identifier les attaques et les défaillances de segmentation.
Niveau administration
Le niveau d’administration est l’une des zones les plus sensibles de l’environnement. Il peut contenir des hôtes relais, des outils d’administration à distance, des consoles d’hyperviseur, la gestion de configuration, des services d’annuaire, l’administration des équipements réseau et des plateformes de sécurité.
Les interfaces d’administration ne doivent pas être directement exposées à Internet. Les administrateurs doivent se connecter via un service d’accès distant contrôlé et, lorsque cela est approprié, par un hôte relais renforcé. Cet hôte relais doit disposer d’un ensemble limité de destinations autorisées et ne doit pas servir à naviguer sur le web ou à consulter les e-mails ordinaires.
Utilisez des règles de pare-feu en refus par défaut
Le refus par défaut signifie que le trafic est bloqué, sauf si une règle précise l’autorise. Cette approche est plus sûre que l’autorisation d’un large accès interne suivie de tentatives de suppression des exceptions dangereuses. Elle rend également l’architecture prévue visible dans la base de règles.
Une règle de pare-feu utile doit répondre à cinq questions :
- Quelles adresses sources, identités ou zones sont concernées ?
- Quel système ou service de destination est nécessaire ?
- Quel protocole et quel port sont autorisés ?
- La connexion est-elle entrante, sortante ou bidirectionnelle ?
- Qui est responsable de la règle, pourquoi existe-t-elle et quand doit-elle être révisée ?
Préférez des adresses de serveurs précises ou des groupes d’adresses étroitement définis à des sous-réseaux entiers. Préférez des objets de service nommés aux plages de ports larges. Évitez les règles du type « toute source vers toute destination », sauf raison temporaire clairement documentée et assortie d’une date d’expiration.
L’ordre des règles est important. Une règle d’autorisation large placée avant une règle restrictive peut neutraliser silencieusement l’architecture prévue. Utilisez des règles de refus explicites lorsqu’elles améliorent la visibilité et journalisez sélectivement le trafic refusé. Journaliser chaque paquet peut submerger une petite équipe, mais enregistrer les tentatives refusées répétées entre des zones sensibles peut révéler une analyse réseau, un logiciel malveillant ou une dépendance applicative défaillante.
Les règles de pare-feu doivent être gérées comme une infrastructure et non modifiées de manière informelle sous la pression. Conservez un historique des changements, soumettez les politiques sensibles à une revue par les pairs et supprimez les accès temporaires une fois l’intervention terminée. Lorsque la plateforme le permet, intégrez les modifications de règles à la gestion de configuration et conservez les versions précédentes pour permettre un retour arrière.
Contrôlez le trafic est-ouest, pas seulement le trafic Internet
Le trafic nord-sud circule entre l’environnement interne et Internet. Le trafic est-ouest circule entre les systèmes internes. La sécurité périmétrique traditionnelle se concentre souvent sur le trafic nord-sud et considère que le réseau interne est fiable. Cette hypothèse échoue lorsqu’un attaquant compromet un serveur, vole les identifiants d’un administrateur ou connecte un appareil infecté au réseau du bureau.
Les contrôles est-ouest doivent couvrir le trafic entre :
- Les serveurs web et les serveurs applicatifs
- Les serveurs applicatifs et les bases de données
- Les serveurs de production et les interfaces d’administration
- Les serveurs et les postes de travail des utilisateurs
- Les machines virtuelles sur le même hôte ou cluster
- Les systèmes de production et les référentiels de sauvegarde
- Les collecteurs de supervision et les appareils supervisés
Les pare-feu basés sur les hôtes ajoutent une couche supplémentaire. Ils sont particulièrement utiles lorsque les charges de travail partagent un commutateur virtuel ou lorsque le trafic ne passe pas par un pare-feu physique central. Un pare-feu hôte peut restreindre les services locaux et bloquer des connexions qui ne devraient jamais être nécessaires, même si une politique réseau est accidentellement trop large.
La microsegmentation peut aller plus loin en appliquant des politiques à des charges de travail ou à des identités individuelles, plutôt qu’aux seuls VLAN. Les petites organisations n’ont pas toujours besoin d’une plateforme spécialisée de microsegmentation. Des pare-feu hôtes soigneusement administrés, des groupes de sécurité, des identités de service et des politiques locales peuvent fournir une séparation significative lorsqu’ils sont documentés et maintenus.
Séparez l’administration du trafic de production
L’accès administratif mérite son propre chemin, car les identifiants d’administrateur peuvent déverrouiller de nombreux systèmes à la fois. Mélanger le trafic utilisateur, applicatif et d’administration sur un seul réseau rend plus difficile la distinction entre une administration légitime et l’activité d’un attaquant.
Un modèle plus sûr consiste à faire connecter les administrateurs à une passerelle d’accès distant ou à un VPN, avec des comptes individuels et, lorsque cela est possible, une authentification multifacteur. Ils accèdent ensuite à un hôte relais renforcé ou à une zone d’administration. L’hôte relais se connecte alors aux interfaces de serveurs approuvées. L’accès direct d’un ordinateur portable non géré à chaque serveur doit être évité.
Les contrôles administratifs doivent inclure :
- Des comptes d’administrateur nominatifs distincts plutôt que des identifiants privilégiés partagés
- L’authentification multifacteur pour l’accès distant et les systèmes privilégiés
- Des autorisations limitées au strict nécessaire selon le rôle professionnel
- Un accès de courte durée ou juste-à-temps pour les tâches sensibles lorsque cette fonction est disponible
- Des restrictions sur les réseaux sources pouvant atteindre SSH, le bureau à distance et les API d’administration
- La journalisation centralisée des authentifications et des activités privilégiées
- Le stockage sécurisé et la rotation des identifiants de service
Ne négligez pas l’administration hors bande. L’administration des hyperviseurs, les contrôleurs de console distante, les systèmes de stockage et les équipements réseau doivent se trouver dans la zone d’administration, et non sur le même segment que les charges de travail ordinaires. Si un serveur de production est compromis, l’attaquant ne doit pas obtenir automatiquement un chemin vers la plateforme qui contrôle toutes les machines virtuelles.
Gardez le réseau de sauvegarde indépendant
Les sauvegardes sont fréquemment ciblées après qu’un attaquant a atteint la production. Si la console de sauvegarde, le référentiel et les serveurs de production partagent les mêmes identifiants et un accès réseau sans restriction, un rançongiciel peut être capable de supprimer les points de récupération avant de chiffrer les systèmes actifs.
Séparez autant que possible le trafic et l’administration des sauvegardes du trafic de production ordinaire. Un réseau de sauvegarde peut inclure des VLAN dédiés, des règles de pare-feu, des routes restreintes, des comptes de service distincts et un accès au référentiel indisponible depuis les zones utilisateurs ou web.
La segmentation doit répondre à deux questions différentes. Premièrement, le système de sauvegarde peut-il collecter ou recevoir les données dont il a besoin ? Deuxièmement, un serveur de production compromis peut-il modifier, supprimer ou administrer les points de récupération stockés ? La première connexion peut être nécessaire ; la seconde doit être strictement limitée.
Les contrôles réseau ne représentent qu’une partie de la résilience des sauvegardes. Les sauvegardes doivent être chiffrées avant de quitter l’environnement contrôlé par le client, la clé de chiffrement étant détenue par le client et non par le fournisseur de sauvegarde. Elles doivent être stockées à l’écart de la production et protégées contre la suppression ou la modification pendant toute la durée de rétention.
Si un serveur compromis atteint les systèmes de production et tente de détruire les options de récupération, un service isolé, chiffré et immuable tel que la sauvegarde externalisée Safenix pour les serveurs professionnels fournit une frontière de récupération supplémentaire. Safenix protège les serveurs contrôlés par le client ; ce n’est pas une solution de sauvegarde pour les sites web hébergés sur une offre mutualisée.
Examinez attentivement les infrastructures VPS et web hébergées
La segmentation est plus complexe lorsque l’infrastructure est hébergée par un fournisseur, car le client ne contrôle pas nécessairement les commutateurs physiques ou le réseau en amont. La conception doit distinguer les contrôles que le client peut configurer dans le VPS ou l’environnement cloud de ceux qui doivent être fournis par la plateforme d’hébergement.
Au niveau client, utilisez des réseaux virtuels distincts, des groupes de sécurité, des pare-feu hôtes et des interfaces privées lorsqu’ils sont disponibles. Limitez les interfaces publiques aux services nécessaires. Placez les bases de données et les points d’accès d’administration sur des réseaux privés et ne les exposez pas avec des adresses IP publiques par simple commodité.
Demandez au fournisseur comment fonctionne l’isolation réseau, si le trafic privé est filtré, comment les politiques de pare-feu sont appliquées et si l’accès d’administration est séparé des charges de travail du client. Examinez également la gestion des instantanés, des images et des sauvegardes par le fournisseur. Un instantané accessible via le même plan de contrôle compromis peut ne pas constituer une copie de récupération indépendante.
Pour les organisations qui utilisent une infrastructure VPS et web hébergée avec des zones de sécurité distinctes, les questions pratiques sont les mêmes que dans une salle serveurs : quel système peut initier une connexion, quel service est exposé, qui peut l’administrer et comment l’accès serait-il révoqué pendant un incident ? Un hébergement externalisé ne supprime pas le besoin de segmentation. Il modifie les contrôles disponibles et l’identité de l’exploitant.
L’hébergement mutualisé exige une attention particulière dans la description des responsabilités. Un client peut être en mesure de configurer les paramètres de son application ou un pare-feu au niveau de son compte, mais cela ne lui donne aucun contrôle sur le réseau de serveurs du fournisseur ni sur les comptes voisins. Safenix protège les serveurs professionnels contrôlés par le client et ne doit pas être présenté comme un service de sauvegarde pour un site hébergé sur une offre mutualisée.
Erreurs courantes de segmentation
Créer des VLAN sans appliquer de politique
Des VLAN distincts avec un routage inter-VLAN sans restriction donnent l’apparence d’une segmentation sans fournir la protection attendue. Examinez le chemin réel de transmission et la politique de pare-feu. Vérifiez que le trafic ne peut pas contourner le point d’inspection par une interface secondaire, un pont ou un commutateur non géré.
Autoriser tout le sous-réseau par commodité
Lorsqu’une application doit atteindre une base de données, autoriser tout le sous-réseau web est plus rapide que d’identifier la source exacte. Cela permet également à chaque hôte compromis ou mal configuré de ce sous-réseau d’atteindre la base de données. Utilisez plutôt des groupes d’adresses et des règles propres aux services.
Laisser des exceptions temporaires en place
Un accès d’urgence devient souvent permanent. Toute règle temporaire doit avoir un responsable, une justification, une date de création et une date d’expiration. Examinez les règles arrivées à expiration dans le cadre des opérations normales, et pas uniquement après un incident.
Utiliser des identifiants partagés
Les identifiants d’administrateur et de service partagés rendent difficile l’attribution des activités et facilitent les déplacements d’un attaquant entre les systèmes. Utilisez des comptes individuels pour les personnes, des identités de service distinctes pour les applications et des identifiants uniques pour les systèmes de sauvegarde et d’administration.
Placer les interfaces d’administration sur les réseaux de production
Les ports d’administration des serveurs, les consoles d’hyperviseur et l’administration du stockage ne doivent pas être accessibles depuis les appareils ordinaires des utilisateurs ou les charges de travail exposées au public. Un réseau d’administration n’est utile que si son propre accès est restreint.
Oublier les appareils qui ne sont pas des serveurs
Les imprimantes, caméras, systèmes du bâtiment et appareils réseau bon marché sont souvent moins bien maintenus que les serveurs. Ils ne devraient pas disposer d’un accès sans restriction à l’infrastructure sensible. Placez-les dans une zone adaptée aux appareils et n’autorisez que les services dont ils ont besoin.
Ne pas documenter les exceptions
Les règles non documentées deviennent des hypothèses permanentes. Lorsqu’un ingénieur quitte l’entreprise ou qu’une application évolue, personne ne sait pourquoi une connexion existe ni si elle peut être supprimée. La documentation fait partie du contrôle ; ce n’est pas un simple élément administratif.
Comment tester l’efficacité de la segmentation
Une architecture n’est pas validée par un schéma réseau. Testez les points d’application depuis les mêmes emplacements que pourrait utiliser un attaquant. Maintenez un plan de test approuvé afin que les analyses et les tentatives de connexion ne perturbent pas la production.
Tester les chemins autorisés
Depuis chaque zone source, vérifiez que les services nécessaires sont accessibles. Testez le protocole et le port exacts, et pas seulement la réponse de la destination à une requête ping. Confirmez que les transactions applicatives, la supervision, l’administration et les tâches de sauvegarde fonctionnent via les chemins prévus.
Tester les chemins interdits
Tentez des connexions depuis les serveurs web vers les interfaces d’administration, depuis les réseaux utilisateurs vers les bases de données, depuis les serveurs applicatifs vers des systèmes de production sans rapport et depuis des serveurs ordinaires vers les ports d’administration des sauvegardes. Ces tests doivent échouer. Une connexion réussie doit faire l’objet d’une investigation, même si le service ne révèle aucune donnée.
Tester depuis le point de vue d’un hôte compromis
Utilisez un compte de test contrôlé ou une évaluation de sécurité approuvée pour simuler un attaquant ayant obtenu l’accès à un serveur. Vérifiez si cette position permet la découverte du réseau, l’accès aux services d’identifiants, l’administration à distance, le partage de fichiers ou l’accès à d’autres zones. Recherchez les routes oubliées parce que la documentation initiale décrivait le trafic attendu plutôt que le trafic réel.
Examiner les journaux et les alertes
Vérifiez que les connexions refusées sont visibles avec un niveau de détail utile. Les alertes doivent signaler les analyses inhabituelles, les tentatives répétées d’accès aux zones sensibles et les changements de politique de sécurité. Assurez-vous que les journaux sont conservés à un emplacement qu’un serveur compromis ne peut pas effacer.
Tester les pannes et la récupération
Les pare-feu, les commutateurs et les passerelles VPN peuvent tomber en panne ou être mal configurés. Vérifiez le comportement de l’environnement lors d’une panne d’équipement, du déploiement d’une politique ou de la perte du chemin d’administration principal. Confirmez que l’accès d’urgence est contrôlé et documenté, plutôt que de dépendre d’un contournement non documenté.
Effectuez de nouveaux tests après les changements importants : nouvelles applications, migrations de serveurs, refonte des VLAN, changements de fournisseur et mises à niveau des pare-feu peuvent tous modifier l’accessibilité. La validation automatisée des politiques et l’analyse planifiée des vulnérabilités peuvent aider, mais elles doivent compléter l’examen humain des dépendances métier, et non le remplacer.
Segmentation et réponse aux incidents
Lors d’un incident, la segmentation doit aider l’équipe à isoler rapidement un serveur sans mettre toute l’entreprise hors ligne. Préparez des actions de confinement pour les situations courantes. Elles peuvent consister à désactiver le port d’un commutateur hôte, retirer un serveur d’un VLAN de production, bloquer un compte de service, restreindre les accès sortants d’une zone ou déplacer l’administration vers un chemin d’urgence.
Maintenez un inventaire précis des actifs et des dépendances. Si les intervenants ne savent pas quels services dépendent d’un serveur, ils risquent de l’isoler trop lentement ou de provoquer des perturbations inutiles. Pour les systèmes importants, consignez le responsable métier, le responsable technique, la zone, les dépendances critiques, la politique de sauvegarde et la priorité de récupération.
Les procédures de réponse aux incidents doivent préciser qui peut approuver les modifications urgentes du pare-feu, comment les changements sont enregistrés et comment la politique normale est rétablie ensuite. Testez ces procédures. Un contrôle qui n’existe que dans un document mais ne peut pas être utilisé sous pression offre une protection limitée.
Pourquoi la segmentation ne peut pas remplacer les sauvegardes isolées
La segmentation limite l’accessibilité ; elle ne rend pas un système compromis sûr. Un attaquant peut exploiter une connexion applicative autorisée, compromettre le poste de travail d’un administrateur, voler des identifiants, utiliser abusivement une exception de pare-feu ou attaquer le système de sauvegarde par des chemins d’administration légitimes. Les logiciels malveillants peuvent également corrompre les données avant l’exécution de la tâche de sauvegarde.
La récupérabilité exige davantage que la présence d’une copie quelque part. Cette copie doit rester disponible après une compromission de la production, être protégée contre les suppressions non autorisées, être correctement chiffrée, être conservée pendant la durée nécessaire et pouvoir être restaurée dans les objectifs de reprise de l’entreprise.
Safenix fournit une sauvegarde externalisée pour les serveurs professionnels contrôlés par le client. Les données sont chiffrées avec une clé que Safenix ne détient jamais, stockées en Allemagne et conservées de manière immuable pendant toute la durée de rétention. Ce modèle complète la segmentation : les contrôles réseau réduisent le risque de propagation d’un incident, tandis qu’une copie de récupération indépendante aide l’entreprise à revenir à un état fiable si les systèmes ou les sauvegardes locales sont endommagés.
Planifiez la connexion de sauvegarde comme une partie intégrante de l’architecture. Limitez les hôtes autorisés à envoyer les données de sauvegarde, éloignez l’administration des sauvegardes des comptes de production ordinaires et testez les restaurations au lieu de vérifier uniquement que les tâches indiquent une réussite. Une tâche de sauvegarde réussie prouve que les données ont été copiées ; une restauration réussie démontre qu’elles peuvent réellement servir à la récupération.
Un plan de mise en œuvre maîtrisable
Les petites équipes peuvent améliorer la segmentation progressivement. Commencez par les systèmes qui présentent les risques et la valeur les plus élevés, plutôt que de tenter une refonte parfaite en une seule fois.
- Cartographiez l’environnement. Identifiez les serveurs, machines virtuelles, utilisateurs, équipements réseau, interfaces d’administration, bases de données, systèmes de sauvegarde et dépendances externes.
- Classez l’exposition. Identifiez les systèmes exposés à Internet, internes, sensibles, administratifs et dédiés à la récupération. Repérez les endroits où une seule compromission aurait le plus fort impact.
- Définissez les zones. Commencez par des groupes pratiques tels que périphérie, web, applicatif, bases de données, administration, utilisateurs et sauvegarde. Ne subdivisez davantage les zones que lorsque la différence de politique justifie le coût opérationnel.
- Construisez la matrice de communication. Notez la source, la destination, le protocole, le port, le sens, le responsable et la finalité nécessaires.
- Appliquez d’abord les frontières les plus importantes. Séparez les serveurs publics des bases de données, les utilisateurs des systèmes d’administration et la production de l’administration des sauvegardes.
- Appliquez le refus par défaut. Ajoutez des exceptions précises pour les dépendances vérifiées et journalisez les tentatives de refus importantes.
- Renforcez les identités. Supprimez les identifiants partagés, activez l’authentification multifacteur pour l’administration distante et limitez l’accès privilégié au chemin d’administration.
- Testez et documentez. Vérifiez les chemins autorisés et bloqués, consignez les résultats et mettez à jour l’inventaire des actifs et des règles.
- Réexaminez continuellement. Revoyez les politiques après les changements d’applications, de personnel ou de fournisseur, les migrations et les incidents de sécurité.
L’objectif n’est pas de créer un environnement où rien ne peut communiquer. Il s’agit de garantir que chaque connexion importante est intentionnelle, limitée et justifiable. Lorsqu’un serveur est compromis, ces décisions déterminent si l’incident reste contenu ou devient une panne généralisée de l’infrastructure.