Monter un serveur client sans rien oublier
Un serveur de site, c'est des dizaines d'éléments : pare-feu, tunnel IPsec vers le réseau du client, accès à distance, connexion par clé, usagers, sauvegardes, surveillance, suivi de la configuration. Monté à la main, ça prenait 2 à 3 jours, et le vrai danger n'était pas le temps : c'était l'élément oublié. Un pare-feu laissé ouvert ou un tunnel mal configuré ne se voit pas. Le site fonctionne, mais toute sa sécurité est compromise.
Avant / maintenant
Avant
2 à 3 jours, un oubli possible
- Monter le serveur à partir des notes du dernier site · 1 à 2 jours
- Sécurité configurée de mémoire : pare-feu, IPsec, SSH · heures
- On teste ce qui doit marcher, pas ce qui doit être fermé · heures
- Un élément oublié reste invisible… jusqu'à l'incident · inconnu
Maintenant, avec l'IA
2 à 3 heures, rien d'oublié
- Étape manuelle : installer le système et le premier compte administrateur ; déclarer le site dans l'inventaire · < 1 h
- L'agent suit le guide complet, éprouvé d'abord sur une VM de labo · 1 à 2 h
- Chaque élément de sécurité est vérifié de l'extérieur, pas seulement configuré · minutes
- Le site n'est déclaré prêt que si toute la liste passe · minutes
Comment c'est construit
- Inventaire de la flotteSite déclaré une fois
- VM de laboGuide éprouvé d'abord
- Agent IAPropose le plan
- HumainApprouve
- Script de montage34 éléments appliqués
- Vérification externePrêt seulement si tout passe
Système Agent IA Humain Source
Démo rejouée
La démo reconstitue la vérification finale d'un montage, inspirée de montages réels. Le temps est accéléré.
Choisissez une situation (cliquez de nouveau pour rejouer) :
- Pare-feu : tout fermé par défaut
- Tunnel IPsec vers le réseau client
- Accès : clés seulement, limité au site
- Sauvegardes et surveillance
- Configuration tracée
- Site déclaré prêt
Ce que le script applique et vérifie
Seule la première étape est manuelle : installer le système et créer le premier compte administrateur. Tout le reste est appliqué par le script, puis vérifié. Voici la liste, regroupée par thème.
Comptes et droits
- Tout compte humain vient d'une liste déclarée ; aucun autre ne doit exister
- Une clé SSH par personne, vérifiée
- Mots de passe verrouillés (sauf un mot de passe de console tiré du coffre)
- sudo : une règle par personne, jamais pour un groupe entier
- Intervenants automates : ni sudo général ni Docker ; une commande à liste fermée, tracée
- Aucune session inactive plus de 24 h
SSH
- Connexion root interdite
- Mot de passe désactivé : clé seulement
- Le script refuse de couper les mots de passe tant qu'un compte n'a pas de clé
- Tentatives limitées, sessions surveillées, pas de transfert X11
Réseau et isolation
- Mesh privé : tout est refusé par défaut
- Deux clients ne peuvent jamais se voir
- Clé d'enrôlement à usage unique, vérifiée consommée puis supprimée
- Accès des intervenants par personne et par site, jusqu'à l'équipement
- Chien de garde qui relance l'agent réseau
- Pare-feu actif — et Docker le contourne : seule la chaîne DOCKER-USER filtre vraiment les conteneurs
- Services internes jamais exposés sur toutes les interfaces ; tout port inattendu est signalé
Journalisation et détection
- Audit des actions privilégiées
- Bannissement après 5 échecs en 10 min
- Liste blanche vérifiée dans la mémoire du service, pas seulement dans le fichier
- Configuration système sous git, un commit par changement
- Rotation des journaux des conteneurs
- Trace d'audit applicative : ajout seulement, ni modification ni effacement, active depuis moins de 7 jours
Correctifs
- Aucune mise à jour sans approbation
- Arriéré de correctifs de sécurité et redémarrages requis rapportés
Continuité et sauvegardes
- Sauvegarde quotidienne de la base, rapatriée la nuit ; alerte si plus de 48 h
- Instantané de la configuration toutes les 3 h
- Code de l'automate rapatrié en lecture seule, empreinte versionnée
- Hôte approuvé qui se rapporte avec sa propre clé
- Aucun conteneur malade, disque sous 85 %
- Versions des images et du schéma de base suivies
Selon le rôle du serveur
- Automate logiciel : licence active, gestion des utilisateurs exigée, aucun réglage de sécurité désactivé
- Passerelle de programmation jamais exposée hors du réseau usine
- Serveur exposé à Internet : SSH fermé à Internet, certificats renouvelés seuls, correctifs de sécurité automatiques (exception déclarée)
Pièges courants : des éléments qu'on croit faits, mais qui ne le sont pas vraiment.
Les garde-fous
- La liste complète, chaque foisLe guide de montage ne dépend pas de la mémoire de quelqu'un ; l'agent le suit en entier.
- Vérifier de l'extérieurUn pare-feu est « fait » quand les ports fermés le sont vraiment, pas quand la commande a réussi.
- Labo d'abordTout changement est éprouvé sur une VM de labo avant de toucher un serveur client.
- Proposer avant d'appliquerL'agent présente son plan et ses correctifs ; rien ne s'applique sans approbation.
- Tout est tracéLa configuration système est versionnée : on voit ce qui a changé, quand, et pourquoi.
Correspondance avec les normes
Ces pratiques correspondent aux contrôles suivants et produisent les preuves qu'un audit demande. Il s'agit d'une correspondance, pas d'une certification.
ISO/IEC 27001:2022
- 8.2 Droits d'accès privilégiés
- 8.5 Authentification sécurisée
- 8.8 Gestion des vulnérabilités techniques
- 8.9 Gestion de la configuration
- 8.15 Journalisation
- 8.16 Surveillance des activités
- 8.20 Sécurité des réseaux
- 8.22 Cloisonnement des réseaux
SOC 2
- CC6.1 Sécurité des accès logiques
- CC6.6 Protection du périmètre
- CC7.1 Détection des changements et vulnérabilités
- CC7.2 Surveillance des anomalies
ISO/IEC 42001
L'agent propose son plan et ses correctifs ; un humain approuve avant toute application.
Résultats
Technologies
Les autres cas
Un contexte semblable chez vous ?
Je peux vous aider à repérer où l'IA peut faire gagner des heures, et à la mettre en place avec les bons garde-fous.