Conformité continue avec Chef : mesurer, corriger, re-mesurer

Un serveur durci une fois dérive. Sans mesure régulière, personne ne sait s'il respecte encore quoi que ce soit. Ce module installe la boucle qui manque : mesurer l'état réel contre un référentiel de durcissement reconnu, corriger les écarts avec un cookbook Chef, puis re-mesurer pour prouver la correction. Vous verrez aussi comment assumer une dérogation quand un écart ne peut pas être corrigé tout de suite. Public visé : intermédiaires ayant déjà écrit des tests InSpec.

Ce que vous allez apprendre

• Mesurer un serveur contre un référentiel de durcissement.
• Corriger les écarts avec un cookbook Chef.
• Prouver la correction en re-mesurant.
• Gérer une dérogation justifiée et datée.

Prérequis

• Un nœud convergé avec knife-zero.
• Les bases d'InSpec.

Tester son cookbook n'est pas mesurer sa conformité

La distinction est essentielle et souvent confondue. Les tests InSpec que vous avez écrits jusqu'ici répondent à « mon cookbook a-t-il fait ce que je lui ai demandé ? ». Ils valident votre intention.

La conformité répond à une question radicalement différente : « ce serveur respecte-t-il un référentiel de sécurité, indépendamment de ce que j'ai demandé ? ». Le référentiel vient de l'extérieur (CIS, ANSSI, ou un standard communautaire), et il vous dira des choses que vous n'aviez pas pensé à vérifier.

Nous utiliserons CINC Auditor, la distribution libre d'InSpec, cohérente avec le reste de ce parcours.

Mesurer avec un référentiel reconnu

Plutôt que d'écrire des centaines de contrôles, on part d'un référentiel maintenu par la communauté. Le profil dev-sec/linux-baseline couvre le durcissement classique d'un Linux : paramètres noyau, permissions, services, comptes.

Il s'exécute à distance, en SSH, contre la machine que vous avez convergée (remplacez l'adresse par celle de votre nœud) :

cinc-auditor exec https://github.com/dev-sec/linux-baseline \
  -t ssh://ubuntu@192.168.122.245 -i ~/.ssh/id_ed25519 --sudo

Le verdict est direct, et souvent brutal sur une machine fraîchement installée :

Profile Summary: 29 successful controls, 28 control failures, 2 controls skipped
Test Summary: 123 successful, 52 failures, 3 skipped

28 contrôles en échec. Le serveur fonctionne parfaitement, il sert son site web, et pourtant il est loin du référentiel. C'est précisément l'intérêt de la mesure : elle révèle ce que ni vous ni votre cookbook n'aviez regardé.

Un échec de conformité n'est pas une panne

Ne paniquez pas devant 28 échecs. Un référentiel générique est volontairement exigeant et couvre des cas qui ne s'appliquent peut-être pas à vous. Le but n'est pas d'atteindre 100 % à tout prix, mais de savoir où l'on en est, puis de décider consciemment : corriger, ou assumer l'écart.

Le code de sortie fait la barrière

Pour automatiser, il faut un signal exploitable. CINC Auditor sort avec un code 100 dès qu'un contrôle échoue :

cinc-auditor exec ... ; echo "code de sortie : $?"

code de sortie : 100

Ce code suffit à faire échouer un job de CI ou une tâche planifiée. Pour exploiter les résultats autrement que par l'œil, le rapport JSON donne le détail contrôle par contrôle :

cinc-auditor exec ... --reporter json:conformite.json cli

Ce fichier alimente ensuite un tableau de bord, une alerte, ou simplement un historique qui montre l'évolution de la posture dans le temps.

Corriger les écarts avec Chef

Voilà où Chef reprend la main. Le référentiel a désigné les écarts ; le cookbook les corrige, de façon idempotente et reproductible sur tout le parc.

Prenons quatre écarts relevés, avec leurs attentes exactes lues dans le rapport : auditd absent, kernel.yama.ptrace_scope à 0 au lieu de 2, kernel.sysrq non nul, et les log martians désactivés.

cookbooks/durcissement/recipes/default.rb

package 'auditd'

# La ressource sysctl lance « sysctl -p », qui lit /etc/sysctl.conf.
# Sur une Ubuntu minimale ce fichier n'existe pas : on le crée.
file '/etc/sysctl.conf' do
  owner 'root'
  group 'root'
  mode  '0644'
  action :create_if_missing
end

{
  'kernel.yama.ptrace_scope'           => 2,
  'kernel.sysrq'                       => 0,
  'net.ipv4.conf.all.log_martians'     => 1,
  'net.ipv4.conf.default.log_martians' => 1,
}.each do |param, val|
  sysctl param do
    value val
    action :apply
  end
end

La ressource sysctl échoue sur une Ubuntu minimale

Piège rencontré en pratique : la ressource sysctl écrit bien son fichier dans /etc/sysctl.d/, puis exécute sysctl -p, qui lit /etc/sysctl.conf. Sur une image Ubuntu minimale, ce fichier n'existe pas et la convergence part en erreur :

FATAL: sysctl: cannot open "/etc/sysctl.conf": No such file or directory

La parade tient en une ressource file avec create_if_missing, placée avant les sysctl.

Après convergence, les quatre ressources sont appliquées :

Recipe: durcissement::default
  * apt_package[auditd] action install
  * file[/etc/sysctl.conf] action create_if_missing
  * sysctl[kernel.yama.ptrace_scope] action apply
  * sysctl[kernel.sysrq] action apply
  * sysctl[net.ipv4.conf.all.log_martians] action apply
  * sysctl[net.ipv4.conf.default.log_martians] action apply

Re-mesurer : la seule preuve qui vaut

Un cookbook qui converge sans erreur ne prouve rien sur la conformité. Seule la re-mesure le fait. On relance exactement la même commande :

Profile Summary: 32 successful controls, 25 control failures, 2 controls skipped
Test Summary: 137 successful, 49 failures, 2 skipped

28 échecs sont devenus 25, et les contrôles sysctl-17, sysctl-30 et sysctl-35 sont passés au vert. La boucle est fermée : mesurer, corriger, prouver. C'est cette boucle, répétée, qui constitue la conformité continue.

Pourquoi auditd reste rouge

Un détail mérite l'attention, car il est contre-intuitif. Nous avons bien installé auditd, et pourtant le contrôle package-08 échoue toujours.

En regardant le rapport de près, ce contrôle contient douze tests : un pour la présence du paquet, onze pour sa configuration. Le paquet est bien installé (ce test passe), mais deux réglages par défaut d'Ubuntu ne correspondent pas au référentiel (log_format vaut ENRICHED au lieu de raw, max_log_file_action vaut ROTATE au lieu de keep_logs).

Un contrôle est rouge tant qu'un seul de ses tests échoue. Retenez-le : « installer le paquet » ne veut pas dire « être conforme ».

Assumer une dérogation

Tous les écarts ne se corrigent pas immédiatement. Un réglage peut casser une application, ou la correction peut être planifiée pour plus tard. La mauvaise réponse est de retirer le contrôle du référentiel : vous perdriez la trace de l'écart.

La bonne réponse est une dérogation (waiver) : un écart assumé, justifié et surtout daté.

derogations.yml

package-08:
  expiration_date: 2026-10-31
  run: false
  justification: "Config auditd par défaut acceptée ; durcissement planifié au T4 2026"

cinc-auditor exec ... --waiver-file derogations.yml

Le contrôle est alors écarté, et le rapport le documente explicitement :

"waiver_data": {
  "expiration_date": "2026-10-31",
  "run": false,
  "justification": "Config auditd par défaut acceptée ; durcissement planifié au T4 2026",
  "skipped_due_to_waiver": true
}

La date d'expiration est le cœur du mécanisme

Sans expiration_date, une dérogation devient une exception permanente que plus personne ne relit. Avec une date, l'écart réapparaît automatiquement le jour venu, et il faudra soit le corriger, soit rejustifier consciemment. C'est ce qui distingue une dette pilotée d'une dette oubliée.

Rendre la mesure continue

Il reste à répéter la boucle sans y penser. Deux placements possibles, selon ce que vous voulez surveiller.

En exécution planifiée (tâche périodique ou pipeline programmé), la mesure tourne chaque nuit contre le parc. Le code 100 déclenche une alerte : vous êtes prévenu d'une dérive avant l'auditeur. C'est le mode le plus utile en exploitation.

En CI, après déploiement, la mesure agit comme une barrière : un cookbook qui dégraderait la conformité ne passe pas. Le rapport JSON archivé à chaque exécution donne en prime l'historique de la posture, très utile le jour où l'on vous demande de prouver une progression.

Dépannage

La conformité produit des messages déroutants : un contrôle rouge n'est pas toujours une erreur de votre part. Voici comment les interpréter.

Symptôme	Cause probable	Solution
sysctl: cannot open "/etc/sysctl.conf"	Fichier absent sur une image minimale	Le créer avec create_if_missing avant les sysctl
Le contrôle reste rouge après correction	Le contrôle contient plusieurs tests	Lire le rapport JSON : un seul test rouge suffit
Code de sortie 100 alors que « tout va bien »	Comportement attendu : des contrôles échouent	Corriger, ou poser une dérogation datée
La dérogation ne change rien	run: true laisse le contrôle s'exécuter	Passer à run: false pour l'écarter
Un écart revient après un moment	La dérogation a expiré	C'est le mécanisme voulu : corriger ou rejustifier

Glissez pour voir

À retenir

1. Tester son cookbook valide son intention ; mesurer la conformité confronte la machine à un référentiel externe.
2. Un référentiel communautaire comme dev-sec/linux-baseline révèle des écarts auxquels vous n'auriez pas pensé (28 échecs sur une machine neuve).
3. Le code de sortie 100 rend la mesure automatisable ; le rapport JSON la rend exploitable.
4. Chef corrige les écarts de façon idempotente, et seule la re-mesure prouve la correction (28 échecs devenus 25).
5. La ressource sysctl échoue si /etc/sysctl.conf est absent : le créer avant.
6. Un contrôle regroupe plusieurs tests : installer un paquet ne suffit pas à le rendre vert.
7. Une dérogation s'assume avec une justification et une date d'expiration, sinon c'est une dette oubliée.

Pour aller plus loin

• CINC Auditor : la distribution libre d'InSpec utilisée ici, et ses autres usages.
• Durcissement des serveurs Linux : le fond du sujet, au-delà de l'outillage.

×

📖 Voir la documentation →