Durcissement & conformité — réduire, puis prouver

Le concept en une phrase

Durcir, c’est réduire la surface d’attaque d’un système ; la conformité, c’est mesurer l’écart restant contre un référentiel (CIS, ANSSI) — l’un sans l’autre est aveugle ou stérile.

Durcir sans mesurer, c’est avancer sans savoir où on en est. Mesurer sans durcir, c’est produire un rapport que personne ne corrige. Sur les TAAF, un système exposé sur un lien satellite ne peut pas se permettre l’un ou l’autre séparément : il faut réduire ce qui peut être attaqué, et pouvoir prouver que la réduction a été faite.

Les grands principes

1. La surface d’attaque — tout ce qui écoute, tourne, ou a des droits

La surface d’attaque d’un système, c’est l’ensemble des points par lesquels il peut être atteint ou compromis :

Ce qui écoute — chaque port ouvert, chaque service réseau exposé est une porte potentielle.
Ce qui tourne — chaque logiciel installé, chaque processus actif est du code qui peut contenir une faille.
Ce qui a des droits — chaque compte, chaque permission accordée est un levier qu’un attaquant peut détourner s’il en prend le contrôle.

Durcir un système, concrètement, c’est réduire ces trois axes : fermer les ports inutiles, désinstaller ou désactiver ce qui ne sert pas, retirer les droits qui ne sont pas strictement nécessaires. Un serveur minimal, avec peu de services et peu de comptes privilégiés, a une surface d’attaque plus petite qu’un serveur laissé à son installation par défaut — même si les deux tournent le même OS.

2. Moindre privilège et défense en profondeur

Deux principes structurent le durcissement, et ils se renforcent l’un l’autre.

Le moindre privilège — chaque compte, chaque service ne doit avoir que les droits strictement nécessaires à sa fonction, jamais plus. Un compte de service qui fait des sauvegardes n’a aucune raison d’être administrateur du domaine.
La défense en profondeur — aucune protection n’est infaillible seule, donc on empile des couches indépendantes (pare-feu, segmentation, durcissement OS, journalisation) pour qu’une seule défaillance ne suffise pas à tout compromettre.

Le cas d’école qui relie les deux, rejoué sur les TAAF : un compte de service (svc_backup) ajouté au groupe Domain Admins viole le moindre privilège — un compte censé faire des sauvegardes n’a aucune raison d’administrer le domaine. C’est exactement le genre d’écart qu’un audit de conformité doit détecter avant qu’un attaquant ne le trouve le premier.

3. Les référentiels comme checklists outillables

On ne durcit pas « à l’instinct » : on s’appuie sur des référentiels publics, éprouvés, qui listent des paramètres précis à vérifier.

CIS Benchmarks — des guides détaillés, par système (Linux, Windows, PostgreSQL, Docker…), qui listent des centaines de points de configuration concrets, souvent outillables (script ou scanner capable de les vérifier automatiquement).
Guide d’hygiène informatique — ANSSI — un référentiel plus large et pédagogique, orienté priorités et bon sens opérationnel, moins granulaire que CIS mais plus accessible comme point de départ.

Ces référentiels transforment une notion floue (« un système durci ») en une liste de cases vérifiables une par une.

4. Mesurer — Lynis, OpenSCAP, et la limite du score

flowchart LR
    S[Système] --> L[Lynis]
    S --> O[OpenSCAP]
    L -->|"scanne, note,\nrecommande"| R1[Rapport +\nsuggestions]
    O -->|"vérifie contre\nun profil CIS/STIG"| R2[Écarts précis\npar règle]
    R1 --> H[Humain]
    R2 --> H
    H -->|"priorise, corrige,\ncontextualise"| D[Décision]

Lynis — un scanner d’audit et de durcissement système (surtout Linux) qui inspecte la configuration, calcule un score de durcissement, et propose des pistes d’amélioration.
OpenSCAP — un outil plus formel qui vérifie un système contre un profil normalisé (souvent dérivé de CIS ou de STIG) et rapporte, règle par règle, ce qui est conforme ou non.

Ces outils sont précieux pour industrialiser un premier passage, mais le score qu’ils produisent n’est jamais la finalité. Un score élevé peut cacher une règle critique ignorée pour de mauvaises raisons ; un score bas peut inclure des recommandations sans réel impact sur le contexte du système audité. L’outil scanne, l’humain contextualise.

5. Conforme ≠ sécurisé — le piège de la case cochée

C’est le point le plus important de cette page, et le plus souvent oublié : passer un référentiel n’est pas la même chose qu’être en sécurité.

Un système peut cocher toutes les cases d’un CIS Benchmark et rester vulnérable à une faille qu’aucune checklist ne couvre — une logique métier mal pensée, une combinaison de permissions légitimes individuellement mais dangereuse ensemble, un compte de service dans le mauvais groupe qu’aucun scanner de conformité générique ne signalera comme critique. À l’inverse, un système peut être réellement bien protégé sans cocher toutes les cases d’un référentiel qui ne s’applique pas parfaitement à son contexte.

Retenez : la conformité est un outil de mesure et de priorisation, pas une garantie. C’est pour ça que l’audit de conformité se complète toujours par un scan de vulnérabilités et, idéalement, une mise à l’épreuve réelle en purple team.

Où ça sert dans TAAF

TP Conformité — Audit & Hardening — appliquer Lynis et OpenSCAP sur un système TAAF, avec le volet SBOM/Grype de la supply chain logicielle.
TP Audit AD — PingCastle — la même logique posture/référentiel, appliquée à l’Active Directory : PingCastle note la posture AD comme Lynis note un serveur Linux, et révèle l’écart qui a permis l’escalade svc_backup → Domain Admins.

Ressources associées

Ces liens sont des points de départ pour vos propres recherches — voir la bibliothèque complète sur la page Ressources, section Audit & durcissement.

À chercher par vous-même : « CIS Benchmarks », « ANSSI guide d’hygiène informatique », « Lynis hardening index », « OpenSCAP profile STIG », « principle of least privilege ».