NIS2 : mettre vos VPS et serveurs dédiés en conformité

La directive européenne NIS2 renforce les exigences de cybersécurité pour de nombreuses organisations exerçant une activité considérée comme essentielle ou importante. Pour les PME, éditeurs SaaS, plateformes e-commerce, sociétés de services numériques et équipes IT internes, cette évolution ne se résume pas à cocher une liste de mesures : elle impose une démarche de gestion du risque, pilotée par la direction et appuyée sur des preuves techniques.

Un VPS ou un serveur dédié n’est pas « conforme NIS2 » par nature. Il devient un composant d’un système d’information dont la sécurité doit être évaluée, configurée, surveillée et documentée. Une machine Linux correctement administrée, avec des accès maîtrisés, des journaux centralisés, des sauvegardes testées et une procédure de réponse aux incidents, constitue une base solide. À l’inverse, un serveur exposé sur Internet, géré avec un compte administrateur partagé et sans supervision, devient un risque opérationnel et réglementaire.

Ce guide se concentre sur les actions infrastructure réellement applicables lorsque vous exploitez des VPS ou des serveurs dédiés, chez un hébergeur ou dans votre propre environnement.

NIS2 : quelles entreprises et quelles infrastructures sont concernées ?

NIS2 est le nom courant de la directive (UE) 2022/2555 concernant des mesures destinées à assurer un niveau élevé commun de cybersécurité dans l’Union. Elle remplace progressivement la première directive NIS. Le texte a été publié au Journal officiel de l’Union européenne en décembre 2022 et prévoyait une transposition dans les droits nationaux des États membres avant le 17 octobre 2024.

La directive distingue deux catégories principales :

• les entités essentielles, qui relèvent notamment de secteurs tels que l’énergie, les transports, la santé, l’eau, les infrastructures numériques, l’administration publique ou l’espace ;
• les entités importantes, parmi lesquelles figurent notamment certains services numériques, services postaux, activités industrielles, fournisseurs numériques et acteurs de la gestion des déchets ou de la chimie.

Les règles d’application précises, les procédures de contrôle et les éventuelles adaptations dépendent de la transposition nationale. En France, il faut donc suivre les publications de l’ANSSI ainsi que le cadre légal applicable à votre secteur. Le texte européen reste toutefois une référence utile pour structurer les chantiers techniques.

La taille de l’entreprise compte, mais le secteur reste déterminant

NIS2 vise en principe les entités moyennes et grandes opérant dans les secteurs listés par ses annexes. Le seuil fréquemment retenu au niveau européen correspond à une entreprise d’au moins 50 personnes et dont le chiffre d’affaires annuel ou le total du bilan annuel dépasse 10 millions d’euros. Mais ce repère ne doit pas être interprété comme une exemption automatique pour toutes les petites structures.

Des organisations peuvent être incluses indépendamment de leur taille lorsqu’elles sont jugées critiques, lorsqu’elles fournissent certains services numériques ou lorsqu’elles présentent un risque systémique. Les fournisseurs de services gérés, les opérateurs de centres de données, les fournisseurs de cloud computing, les prestataires DNS, les bureaux d’enregistrement de noms de domaine et certains services de confiance sont explicitement visés par la directive.

Un éditeur SaaS n’entre donc pas nécessairement dans le périmètre uniquement parce qu’il héberge une application sur un VPS. En revanche, il peut être concerné en fonction de son activité, de son secteur, de ses clients, de sa taille ou de son rôle dans une chaîne de sous-traitance. Même hors champ direct, les exigences NIS2 sont susceptibles de se diffuser par les questionnaires fournisseurs, les contrats clients et les appels d’offres.

Le VPS et le serveur dédié font partie du périmètre de risque

La directive ne prescrit pas une technologie particulière. Elle demande aux organisations concernées de prendre des mesures techniques, opérationnelles et organisationnelles appropriées et proportionnées pour gérer les risques affectant la sécurité des réseaux et des systèmes d’information.

Dans une architecture classique, le périmètre peut inclure :

• les VPS de production, de préproduction et d’administration ;
• les serveurs dédiés hébergeant les applications, bases de données, dépôts de code ou outils de sauvegarde ;
• les hyperviseurs et interfaces d’administration fournis par l’hébergeur ;
• les bastions SSH, VPN et solutions de gestion des identités ;
• les buckets de stockage objet, snapshots et réplications inter-sites ;
• les outils de CI/CD, registres de conteneurs et plateformes d’observabilité ;
• les prestataires ayant un accès administratif ou une responsabilité sur l’exploitation.

Le premier travail consiste donc à établir une cartographie fiable : quels serveurs existent, où ils sont hébergés, qui les administre, quelles données ils traitent, quelles applications en dépendent et quelles interfaces sont accessibles depuis Internet.

Commencer par une cartographie et une analyse de risque utiles

La conformité ne commence pas par l’installation d’un agent de sécurité. Elle commence par la capacité à répondre rapidement à des questions simples : « Quel serveur héberge cette base client ? », « Qui peut se connecter en root ? », « Où sont les sauvegardes ? », « Peut-on reconstruire cette machine ? » et « Que se passe-t-il si cet hébergeur devient indisponible ? ».

Pour chaque VPS ou serveur dédié, conservez au minimum les informations suivantes :

• nom d’hôte, adresse IP, fournisseur et localisation d’hébergement ;
• environnement concerné : production, recette, développement, administration ou sauvegarde ;
• système d’exploitation, version, rôle applicatif et propriétaire technique ;
• données hébergées et niveau de sensibilité ;
• ports publiés, noms de domaine associés et mécanismes de filtrage réseau ;
• comptes disposant d’un accès privilégié ;
• dernière date de mise à jour, dernier contrôle de sauvegarde et dernière revue d’accès.

Un inventaire tenu dans GLPI, NetBox, Snipe-IT, une CMDB ou même un outil documentaire structuré est préférable à une liste dispersée dans des feuilles de calcul personnelles. L’important est de désigner un responsable et de relier l’inventaire au cycle réel de provisionnement et de suppression des machines.

Ensuite, évaluez les scénarios réalistes : compromission d’un compte SSH, vulnérabilité critique sur un serveur Web, effacement malveillant de volumes, fuite d’une clé API dans un dépôt Git, indisponibilité d’un datacenter, ransomware touchant un serveur de fichiers ou défaillance d’un prestataire infogérant.

Une analyse de risque exploitable doit conduire à des décisions concrètes : réduire une exposition, ajouter un contrôle, accepter un risque de manière formelle ou modifier une architecture.

Pour structurer cette démarche, des référentiels comme EBIOS Risk Manager de l’ANSSI peuvent aider. Il n’est pas toujours nécessaire de conduire une étude exhaustive pour chaque machine : un travail par service critique, complété par un inventaire détaillé, est souvent plus efficace pour une petite équipe.

Les chantiers techniques prioritaires sur un VPS ou serveur dédié

L’article 21 de NIS2 mentionne notamment l’analyse des risques, la gestion des incidents, la continuité d’activité, la sécurité de la chaîne d’approvisionnement, la sécurité lors de l’acquisition et de la maintenance des systèmes, l’évaluation de l’efficacité des mesures, la formation, la cryptographie, la gestion des accès et l’authentification multifacteur lorsque cela est approprié.

Pour une infrastructure Linux, ces principes se traduisent en priorités très concrètes.

Réduire la surface d’exposition Internet

Un serveur ne devrait exposer que les services nécessaires. Commencez par scanner vos propres adresses publiques avec des outils comme Nmap, puis comparez le résultat avec votre documentation. Les ports d’administration ne doivent pas être publiés par défaut sur Internet.

Quelques décisions généralement prioritaires :

• placer les interfaces d’administration derrière un VPN, un bastion ou une liste d’adresses IP autorisées ;
• désactiver l’authentification SSH par mot de passe lorsque l’usage de clés est possible ;
• interdire la connexion SSH directe du compte root ;
• utiliser des règles pare-feu avec nftables, iptables, UFW ou firewalld selon votre distribution ;
• fermer les services installés mais inutiles ;
• protéger les panneaux d’administration, API et consoles de virtualisation par une authentification forte.

Une configuration de base doit également séparer les rôles. Le compte utilisé pour déployer une application ne devrait pas disposer automatiquement des mêmes privilèges que celui utilisé pour administrer le système. Les accès sudo doivent être nominatifs, limités et journalisés.

Notre guide sur le durcissement Linux peut servir de checklist complémentaire pour les réglages système.

Mettre en place une gestion des correctifs vérifiable

Les mises à jour ne doivent pas dépendre d’un rappel manuel ou de la mémoire d’un administrateur. Documentez la responsabilité, la fréquence de revue, les règles de priorité et le processus de validation. Un correctif critique sur un composant exposé n’a pas le même traitement qu’une mise à jour mineure sur un serveur isolé.

Sur Debian ou Ubuntu, les outils APT peuvent être associés à des mécanismes de mises à jour automatiques, selon les contraintes d’exploitation. Sur les environnements Red Hat Enterprise Linux, Rocky Linux ou AlmaLinux, DNF est l’outil courant de gestion de paquets. Pour industrialiser les changements, Ansible permet d’appliquer des configurations homogènes et de conserver les playbooks dans un dépôt versionné.

La bonne pratique n’est pas de redémarrer aveuglément tous les serveurs, mais de disposer d’un cycle clair :

• veille des avis de sécurité des distributions et éditeurs utilisés ;
• qualification sur un environnement de test lorsque c’est possible ;
• déploiement planifié et traçable ;
• redémarrage des services ou du système quand il est nécessaire ;
• contrôle post-changement ;
• traitement documenté des exceptions et des reports.

Un scanner de vulnérabilités tel que Greenbone/OpenVAS ou Nessus peut compléter cette organisation. Il ne remplace ni la gestion des actifs ni l’analyse humaine des résultats, mais il aide à identifier les systèmes oubliés et les versions exposées.

Protéger les données, les secrets et les sauvegardes

La disponibilité et l’intégrité sont aussi importantes que la confidentialité. Une sauvegarde présente sur le même serveur que les données de production ne protège pas contre une compromission complète, un effacement accidentel ou une attaque par ransomware.

Appliquez une stratégie de sauvegarde adaptée à vos objectifs de reprise. Les notions de RPO et RTO sont utiles :

• RPO : quantité de données que l’organisation accepte de perdre entre deux sauvegardes ;
• RTO : délai cible pour remettre un service en fonctionnement.

Une base PostgreSQL critique peut nécessiter des sauvegardes logiques ou physiques fréquentes, ainsi qu’une réplication selon les besoins. Pour des fichiers ou volumes, BorgBackup, Restic ou les mécanismes de snapshots proposés par certains hébergeurs peuvent être pertinents. Mais un snapshot ne constitue pas automatiquement une stratégie de sauvegarde complète : vérifiez sa rétention, sa localisation, ses droits d’accès et sa capacité de restauration.

Prévoyez au moins une copie distincte de l’environnement de production et testez régulièrement la restauration. Un test utile consiste à restaurer une application et sa base de données dans un réseau isolé, puis à mesurer le temps nécessaire et à vérifier l’intégrité fonctionnelle.

Les secrets ne doivent pas rester en clair dans les variables d’environnement exposées, les scripts de déploiement ou les dépôts Git. Des outils tels que HashiCorp Vault, Bitwarden Secrets Manager, AWS Secrets Manager ou les mécanismes de secrets de votre plateforme peuvent réduire ce risque, à condition que les accès et les clés de récupération soient eux-mêmes correctement administrés.

Journalisation, supervision et gestion des incidents : ce qu’il faut préparer

Sans traces exploitables, il est difficile de déterminer ce qui s’est produit lors d’un incident, d’en mesurer l’impact et de documenter les décisions prises. La journalisation est donc une exigence opérationnelle centrale, pas un simple sujet d’audit.

Centraliser les journaux utiles

Au minimum, conservez et centralisez les événements relatifs aux accès administrateurs, aux authentifications, aux changements de privilèges, aux services exposés, aux erreurs applicatives, aux pare-feu et aux sauvegardes. Sur Linux, journald et rsyslog permettent de collecter de nombreux événements système.

Pour une centralisation, Elastic Stack, Graylog, OpenSearch ou Grafana Loki sont des solutions couramment utilisées. Le choix dépend du volume, des compétences internes, du budget et des besoins de recherche. Le point essentiel est d’éviter que les journaux critiques disparaissent avec le serveur compromis.

Définissez une durée de conservation cohérente avec vos obligations, vos besoins d’investigation et les contraintes de protection des données. La durée ne doit pas être choisie arbitrairement : documentez sa justification et contrôlez l’accès aux logs, qui peuvent contenir des identifiants, adresses IP ou données techniques sensibles.

Superviser les services et déclencher des alertes actionnables

La supervision doit détecter les indisponibilités, mais aussi les signes précurseurs : saturation disque, mémoire insuffisante, expiration prochaine d’un certificat TLS, échec de sauvegarde, hausse inhabituelle de connexions ou tentatives répétées d’authentification.

Prometheus et Grafana constituent une combinaison largement adoptée pour les métriques. Zabbix, Centreon, Icinga ou Nagios peuvent également convenir selon l’existant. Pour l’intégrité des fichiers et la détection d’événements de sécurité sur les hôtes, Wazuh est souvent évalué par les équipes qui souhaitent déployer des capacités de type SIEM ou HIDS.

Évitez les alertes sans propriétaire. Pour chaque alerte importante, précisez :

• le seuil ou l’événement déclencheur ;
• le canal de notification ;
• la personne ou l’astreinte responsable ;
• les premières vérifications à réaliser ;
• les conditions d’escalade ;
• le moyen de clôturer et de documenter l’événement.

Préparer le signalement et la réponse aux incidents

NIS2 prévoit un processus de notification gradué pour les incidents significatifs : une alerte précoce dans les 24 heures suivant la prise de connaissance de l’incident significatif, une notification d’incident dans les 72 heures, puis un rapport final au plus tard un mois après cette notification. Les modalités exactes doivent être appliquées selon le droit national et les instructions de l’autorité compétente.

Ces délais impliquent une préparation préalable. Une équipe ne peut pas déterminer en urgence qui contacte l’hébergeur, qui valide la communication client, où sont les journaux ou qui décide d’isoler un serveur.

Votre procédure de réponse doit inclure :

• une définition interne de l’incident et des niveaux de gravité ;
• des contacts à jour : hébergeur, infogérant, direction, juridique, DPO si nécessaire, prestataire de cybersécurité ;
• des consignes de préservation des preuves avant réinstallation ou suppression ;
• des procédures d’isolement réseau et de révocation des accès ;
• un modèle de chronologie d’incident ;
• un retour d’expérience incluant les mesures correctrices.

La chaîne de sous-traitance : vérifier l’hébergeur sans déléguer votre responsabilité

Choisir un fournisseur de VPS ou de serveurs dédiés ne transfère pas la totalité du risque. L’hébergeur peut sécuriser le datacenter, le matériel et, selon l’offre, l’hyperviseur ; le client reste généralement responsable du système d’exploitation, des applications, des identités et des données installées sur son instance.

Avant de contractualiser ou de renouveler une offre, examinez notamment :

• la localisation des données et les conditions de transfert éventuel ;
• les engagements de disponibilité et de support ;
• les mécanismes de notification en cas d’incident ;
• les fonctions de sauvegarde, snapshots, réseau privé et contrôle d’accès proposées ;
• les conditions d’accès du support aux machines ;
• la réversibilité et les modalités de restitution ou d’effacement des données ;
• les certifications ou attestations fournies, sans leur attribuer une portée supérieure à ce qu’elles couvrent réellement.

Cette revue doit aussi inclure les fournisseurs de DNS, de messagerie transactionnelle, de CDN, de gestion de code source et de sauvegarde. Une application peut être hébergée sur un serveur dédié bien maîtrisé tout en dépendant de plusieurs services externes indispensables à son fonctionnement.

Pour choisir l’architecture adaptée, consultez également notre comparatif VPS vs serveur dédié. Le niveau de contrôle offert par un serveur dédié peut être utile pour certains usages, mais il s’accompagne d’une responsabilité accrue sur l’exploitation.

Plan d’action NIS2 en 90 jours pour les équipes infrastructure

Le but d’un plan de 90 jours n’est pas de promettre une conformité complète en trois mois. Il vise à réduire rapidement les risques manifestes, produire les premiers éléments de preuve et installer une dynamique durable.

Jours 1 à 30 : connaître l’existant et fermer les expositions évidentes

• désigner un pilote infrastructure et identifier les interlocuteurs sécurité, direction et métiers ;
• recenser les VPS, serveurs dédiés, comptes privilégiés, services publics et fournisseurs critiques ;
• classer les services selon leur impact métier ;
• supprimer les comptes inutilisés et activer l’authentification multifacteur sur les consoles qui le permettent ;
• désactiver l’accès root direct et revoir les clés SSH ;
• fermer les ports non nécessaires et restreindre les accès d’administration ;
• identifier les correctifs de sécurité urgents et les systèmes en fin de support.

Jours 31 à 60 : industrialiser les contrôles fondamentaux

• formaliser une politique de gestion des correctifs et un processus de changement ;
• centraliser les journaux prioritaires hors des machines de production ;
• déployer une supervision des ressources, des services critiques et des sauvegardes ;
• mettre en place ou renforcer les sauvegardes séparées de la production ;
• réaliser un premier test documenté de restauration ;
• documenter les dépendances fournisseurs et les responsabilités partagées ;
• établir une procédure de gestion d’incident avec un canal d’escalade clair.

Jours 61 à 90 : tester, corriger et rendre compte

• organiser un exercice simple de réponse à incident, par exemple la compromission supposée d’un compte SSH ;
• tester l’isolement d’un serveur et la restauration d’un service critique ;
• vérifier les droits des administrateurs, des prestataires et des comptes de service ;
• documenter les écarts non corrigés, leur niveau de risque, leur responsable et leur date cible ;
• présenter un tableau de bord à la direction : actifs critiques, couverture des sauvegardes, état des correctifs, incidents et actions en cours ;
• planifier une revue périodique des mesures, des fournisseurs et des scénarios de risque.

La direction joue un rôle important dans NIS2 : elle doit être en mesure de comprendre les principaux risques, d’approuver les mesures de gestion du risque et de suivre leur mise en œuvre. Un rapport synthétique et régulier est souvent plus utile qu’un dossier technique impossible à exploiter par les décideurs.

Conclusion : faire de NIS2 un programme d’exploitation plus robuste

NIS2 ne se limite pas à l’achat d’un outil de sécurité ou à la rédaction d’une politique générale. Pour une équipe qui exploite des VPS et des serveurs dédiés, les fondations sont concrètes : inventaire fiable, accès administratifs contrôlés, correctifs suivis, sauvegardes restaurables, journaux centralisés, supervision active et procédure d’incident testée.

Commencez par évaluer vos serveurs les plus critiques et par corriger les expositions les plus immédiates. Cette démarche améliorera à la fois votre préparation réglementaire et votre capacité à maintenir les services lorsque survient un incident. Pour aller plus loin, utilisez notre checklist de choix d’un VPS afin d’intégrer les critères de sécurité dès la sélection de votre infrastructure.