Les principes de défense derrière chaque règle

Pourquoi des principes, et pas seulement une checklist ?

Un référentiel de durcissement ressemble à une longue liste plate : des centaines de réglages sans logique apparente. Pris ainsi, il devient un exercice de cases à cocher : on déroge à des règles parce que plus personne ne sait pourquoi elles existent, les exceptions s'accumulent, et la posture se dégrade en silence. La vraie menace, c'est l'incompréhension. Il suffit à un attaquant d'un seul réglage oublié (une valeur par défaut permissive, un privilège jamais abandonné, une action que personne n'a journalisée) pour transformer un petit point d'appui en compromission totale. La liste n'est pas l'essentiel ; ce sont les principes derrière elle. La plupart ont été nommés en 1975 par Saltzer et Schroeder et tiennent toujours.

Pourquoi c'est important

Les principes sont ce qui rend un référentiel tenable en production. Quand on comprend qu'une règle sert le moindre privilège ou la réduction de la surface d'attaque, on peut juger une exception sur le fond au lieu d'y déroger à l'aveugle, et on peut étendre la politique à des systèmes que le référentiel n'a jamais couverts. Six principes sous-tendent quasiment chaque règle de durcissement Linux, et chacun se traduit en configuration concrète et auditable.

Principe, contrôle Pavois, norme

Les six principes, appliqués

• Défense en profondeur : ne jamais reposer sur un seul contrôle. La pile noyau est durcie via sysctl et les protocoles inutilisés sont désactivés et un pare-feu est présent, pour que la défaillance d'une couche soit rattrapée par la suivante.
• Moindre privilège : chaque identité reçoit le strict nécessaire. Pas de connexion root directe, pas de comptes UID 0 supplémentaires, un sudo finement cadré, un umask restrictif, des fichiers système possédés par root.
• Réduction de la surface d'attaque : ce qui ne tourne pas ne peut être exploité. Retirer les services hérités (telnet, rsh), décharger les modules noyau inutilisés, élaguer les fonctions optionnelles de sshd.
• Valeurs sûres par défaut : l'état sûr doit être l'état par défaut. Verrouillage après échecs (faillock), pwquality fort, règles d'audit qui se ferment sur erreur disque, permissions conservatrices d'origine.
• Séparation des rôles : aucun compte n'est à la fois acteur et auditeur. Des utilisateurs nominatifs escaladent via sudo (imputable), et la piste d'audit est immuable pour que les surveillés ne puissent l'effacer.
• Traçabilité : ce qui n'est pas enregistré n'a pas eu lieu. auditd capture les actions privilégiées et les changements DAC, journald rend les journaux persistants, les bannières affirment la politique.

Anti-patterns qui brisent un principe en silence

• Un NOPASSWD: ALL sudo généralisé par confort détruit d'un coup le moindre privilège et la traçabilité. Cadrez-le à la commande exacte.
• Un chmod -R 777 pour corriger une erreur de permission échange un débogage de cinq minutes contre un trou permanent dans le moindre privilège. Trouvez plutôt le seul bit fautif.
• Désactiver le pare-feu ou auditd pour déboguer, puis oublier transforme la défense en profondeur en point unique de défaillance. Réactivez dans le même changement.
• Ne journaliser que localement laisse le root compromis effacer la preuve. Exportez les logs hors machine (traçabilité).
• Déroger à une règle sans raison consignée : c'est ainsi qu'un référentiel pourrit, le relecteur suivant ne distingue plus une exception délibérée d'un oubli.

Ce que Pavois audite

Pavois vérifie la configuration effective, pas seulement les fichiers sur disque, l'angle qui le distingue des sondes fichier d'OVAL/oscap. Chaque principe devient des contrôles concrets : sshd -T pour les réglages résolus du démon, sysctl -a pour la pile noyau en vigueur, systemctl show pour l'état des unités, plus auditd/journald, faillock, pwquality, sudo, umask, les bases de comptes et la propriété des fichiers. Parce qu'il lit l'état résolu, il voit les Include et drop-ins qu'un scan par fichier rate, une règle ne passe donc que lorsque le principe est réellement en vigueur.

FAQ

Pourquoi apprendre les principes si je me contente d'appliquer le référentiel ? Parce qu'un référentiel ne peut couvrir tous les systèmes ni toutes les exceptions. Connaître le principe permet de juger une dérogation et d'étendre la politique là où la checklist se tait.

D'où viennent ces principes ? Les classiques (moindre privilège, valeurs sûres par défaut, séparation des privilèges) ont été formalisés par Saltzer et Schroeder en 1975 ; les normes (NIST 800-53 AC/AU/CM/SC, ANSSI BP-028, CIS) les encodent en contrôles concrets.

Quel principe compte le plus ? Ils se composent : le moindre privilège limite le rayon d'impact, la défense en profondeur évite qu'une faille soit fatale, la traçabilité permet de détecter et reconstituer. Une lacune dans l'un est l'endroit où passe l'attaquant.