Durcissement d'infrastructure
Sûr par défaut — et cela le reste.
Un rapport plein de constats ne change rien à lui seul. Le durcissement, c'est le travail qui transforme ces constats en un référentiel auquel vos systèmes sont tenus — écrit en code, donc imposé à chaque déploiement plutôt que retenu par celui qui était là ce jour-là.
Le problème
La configuration dérive en arrière.
Quelqu'un durcit un serveur en mars. En juillet, un incident exige un correctif rapide ; en septembre, un nouvel ingénieur copie un vieux modèle ; et en décembre, la machine est à peu près revenue à son point de départ. Personne n'a mal agi : le référentiel n'avait simplement nulle part où vivre.
La solution est peu spectaculaire : exprimer l'état voulu en code, l'appliquer automatiquement, et rendre la dérive visible dès qu'elle survient. Le durcissement devient alors une propriété du système plutôt qu'un épisode de son histoire.
Imposé, pas documenté. Si la seule trace d'un contrôle est un paragraphe dans une politique, il sera vrai jusqu'à la première fois où quelqu'un est pressé. Nous mesurons le durcissement à ce qu'un changement non conforme soit refusé, non à ce qu'il soit déconseillé.
Périmètre
Les couches que nous traitons.
De l'extérieur vers l'intérieur. Chaque couche a un état cible défini et un moyen de le vérifier automatiquement.
- Identités et accèsMoindre privilège en pratique : conception des rôles, arrivée–mobilité–départ, comptes de secours, et double facteur là où cela compte vraiment.
- Cloisonnement réseauAccessibilité réduite au nécessaire, vérifiée en testant les chemins plutôt qu'en lisant le jeu de règles.
- Gestion des secretsIdentifiants hors des dépôts et des fichiers d'environnement, renouvelés selon un calendrier, avec un inventaire de ce qui existe.
- Discipline de correctifsUn rythme réaliste pour votre exploitation, plus une voie pour le cas d'urgence qui n'exige pas d'héroïsme.
- Journalisation et détectionCouverture là où cela compte, rétention qui survit à une enquête, et alertes qu'un humain lira encore au sixième mois.
- Sauvegarde et restaurationDes restaurations testées, pas seulement des sauvegardes réussies. On découvre la différence au pire moment possible.
Déroulement
Du constat au référentiel imposé.
Fixer la cible
Choisir le référentiel, l'ajuster à votre réalité, et consigner chaque exception délibérée avec sa raison et son responsable.
Mettre en code
Exprimer l'état cible en code d'infrastructure et de configuration, dans votre chaîne d'outils existante plutôt que dans une nouvelle.
Déployer par vagues
Hors production d'abord, puis la production par étapes, chacune avec un retour arrière. Un durcissement qui arrête l'activité ne survit pas.
Le garder honnête
Vérifications continues face au référentiel, dérive signalée dès qu'elle apparaît, et revue trimestrielle des exceptions.
Livrables
Ce qui est sur la table à la fin.
Référentiel en code
Dans votre dépôt, dans votre chaîne de déploiement, relisible et réversible comme tout autre changement.
Contrôle de conformité
Un rapport automatique indiquant où la réalité correspond au référentiel et où elle s'en écarte, exécutable à la demande.
Registre des exceptions
Chaque écart accepté avec sa raison, son responsable et la date de sa prochaine revue.
Un rapport et aucun plan ?
Envoyez-nous les constats — les nôtres ou ceux d'un autre. Nous vous dirons lesquels relèvent d'un changement de configuration, lesquels d'un projet, et lesquels ne valent pas l'effort.