Un SI à rendre résistant aux rançongiciels
Xanadu préparait son déménagement vers un nouveau siège, Atlantis, et devait y raccorder un site distant, Springfield, qui abrite un laboratoire et ses machines de mesure. Son système d'information s'était construit au fil de l'eau : le réseau était à plat, plusieurs services partageaient le même compte, les utilisateurs étaient administrateurs de leurs postes, l'ERP circulait en HTTP et les sauvegardes reposaient sur des scripts manuels et des disques USB restés sur place.
La direction avait été marquée par une entreprise voisine bloquée trois semaines par un rançongiciel. La demande formulée était donc de concevoir un système d'information capable de résister à ce type d'attaque, de redémarrer les services critiques en moins de quatre heures et de garantir au laboratoire une liaison avec le siège sous les cinquante millisecondes de latence. Le livrable attendu comprenait l'architecture cible documentée, la politique de sécurité et de sauvegarde, puis une maquette démontrant que cette architecture tenait réellement.
Dix VLAN découpés selon le niveau de risque
L'architecture impose qu'aucun flux ne passe d'une zone à une autre sans être inspecté. Le réseau du siège est découpé selon le niveau de risque, avec les serveurs d'un côté, les services qui manipulent des données sensibles comme la comptabilité, les RH ou la direction d'un autre, les commerciaux à part puisque leurs postes reviennent de réseaux d'hôtels ou de clients, et les imprimantes isolées parce que leurs systèmes sont rarement mis à jour. Un VLAN d'administration réservé à un poste durci accueille les interfaces de gestion et le stockage des sauvegardes, et une DMZ héberge le site public sans aucune donnée.
La passerelle de chacun de ces VLAN est portée par le pare-feu UTM plutôt que par un commutateur de niveau 3, ce qui oblige chaque paquet qui change de zone à être inspecté. La politique de filtrage part d'un refus par défaut et n'ouvre que les flux nécessaires, comme le port de PostgreSQL entre le serveur applicatif et la base de données, ou l'accès web à l'ERP pour les postes utilisateurs.
L'annuaire Active Directory s'appuie sur deux contrôleurs de domaine au siège et sur un contrôleur en lecture seule à Springfield. Ce dernier permet aux chercheurs d'ouvrir leur session même si la liaison avec le siège tombe, sans exposer la base complète des mots de passe si le serveur venait à être volé.
Un ERP et un VPN au-delà du cahier des charges
La liaison MPLS entre les deux sites découle directement de l'exigence de latence, puisque seul un lien opéré garantit contractuellement moins de cinquante millisecondes de latence et moins de dix de gigue. Le pilotage des machines du laboratoire reste en revanche sur un serveur local, car passer par cette liaison aurait ajouté un délai incompatible avec des commandes en temps réel.
Nous avons voulu aller au-delà de la demande sur l'ERP, qui n'était même pas exigé dans la maquette. J'ai mis en place Odoo Community en architecture trois tiers, avec un reverse proxy qui porte le chiffrement HTTPS, un serveur applicatif qui ne parle jamais directement aux utilisateurs et une base de données qui refuse toute connexion ne venant pas de lui. L'ERP s'authentifie sur l'annuaire en LDAPS, et ses comptes métiers sont rattachés aux comptes Active Directory selon le secteur d'activité de chaque collaborateur, de sorte qu'un départ ou un changement de service se gère à un seul endroit.
La gestion des droits suit la méthode AGDLP : un utilisateur n'est jamais autorisé directement sur un dossier, il appartient à un groupe qui représente son métier, lui-même placé dans un groupe qui représente l'accès à la ressource. Nous avons aussi séparé les comptes d'administration en trois niveaux, pour qu'un administrateur n'utilise jamais un compte à privilèges élevés pour lire ses courriels.
Pour les accès distants, j'ai configuré le VPN SSL avec une double authentification et un contrôle de conformité du poste inspiré des principes du ZTNA, qui refuse la connexion d'un poste dont l'antivirus n'est pas actif. Ce contrôle ne figurait pas non plus au cahier des charges, mais il répondait directement au risque des postes nomades.
La politique de sauvegarde applique la règle 3-2-1-1-0 : trois copies sur deux supports différents, dont une hors site répliquée chaque nuit vers Springfield, une copie immuable que même un serveur de sauvegarde compromis ne peut effacer, et zéro erreur grâce à une vérification automatique de la restauration.
Une maquette montée sur un vrai serveur Dell
Nous avons monté la maquette sur un serveur physique et non dans un simulateur. Je me suis occupé de la configuration de l'hyperviseur Proxmox, du pare-feu Stormshield qui porte la passerelle de tous les VLAN, de l'ERP et du VPN SSL, ainsi que du site public, hébergé dans un conteneur Docker sur une machine Debian placée en DMZ. J'ai également aidé à la mise en place des sondes Zabbix et de la supervision SNMP, tout en supervisant et en testant les stratégies de groupe déployées sur les postes.
La maquette a servi de banc de validation. Nous y avons vérifié que le poste d'un commercial ne pouvait atteindre ni la base de données ni les partages RH, que l'authentification survivait à l'arrêt d'un contrôleur de domaine et qu'un poste distant sans antivirus actif restait à la porte du VPN.
Noté A avec les bases d'un PCA et d'un PRA
L'ensemble a été démontré en soutenance et l'unité d'enseignement a été validée avec la note A. Le dossier pose aussi les bases d'un PCA et d'un PRA : les objectifs de reprise sont fixés par type de donnée, avec une perte maximale d'une heure et un retour en moins de quatre heures pour la base de l'ERP et les partages de la direction, et la réplication vers Springfield permet de redémarrer l'activité si le siège subit un sinistre. Il comprend enfin une dizaine de scripts d'administration en PowerShell et en Bash, ainsi qu'une stratégie de supervision qui associe dix événements critiques à une action automatique, comme l'ouverture d'un ticket en cas d'échec de la sauvegarde nocturne.