CIS et Docker se contredisent, il faut trancher

Notre plateforme applique le référentiel de durcissement CIS sur l’ensemble des serveurs. Elle fait aussi tourner tous ses services dans des conteneurs. Ces deux phrases sont en conflit plus souvent qu’on ne le dit, et le conflit n’a que trois issues possibles.

Soit on applique le contrôle et on casse la plateforme. Soit on le saute en silence, et le rapport de conformité affirme quelque chose de faux. Soit on tranche explicitement, par écrit, avec le motif.

La troisième est la seule défendable, et c’est la moins pratiquée.

Le cas le plus net : le routage IP

Le référentiel demande de désactiver le transfert de paquets IP sur un hôte qui n’est pas un routeur. Le contrôle est parfaitement fondé : une machine qui route alors que ce n’est pas sa fonction offre un chemin latéral à un attaquant.

Docker, lui, en dépend structurellement. Le réseau par pont sur lequel reposent les conteneurs suppose que l’hôte transfère les paquets entre son interface physique et les interfaces virtuelles. Sans transfert, les conteneurs n’ont plus de sortie réseau.

Appliquer le contrôle sur un hôte Docker ne durcit donc pas la machine, cela éteint le service qu’elle rend. Et l’effet est particulièrement déplaisant parce qu’il est différé : la valeur peut être écrite dans la configuration persistante, la plateforme continuer de fonctionner sur l’état courant du noyau, et l’interruption ne se manifester qu’au redémarrage suivant, plusieurs semaines après le changement qui l’a causée.

La dérogation, écrite et motivée

Notre choix figure dans les variables d’inventaire, avec son motif sur la même ligne :

linux_kernel_disable_ip_forward: false   # all nodes run Docker — Docker manages ip_forward
linux_ip_forwarding_ubuntu_disabled: true  # skip ip_forwarding role — Docker manages this

Ce n’est pas une exception discrète enfouie dans un rôle, c’est une décision lisible à l’endroit où l’on configure le parc. N’importe qui reprenant l’infrastructure voit à la fois ce qui a été écarté et pourquoi, sans avoir à reconstituer l’intention.

C’est tout l’écart entre une dérogation et un oubli. Techniquement, la machine est dans le même état. En gouvernance, ce sont deux situations opposées : l’une est un risque accepté et documenté, l’autre est un écart non détecté.

Les autres arbitrages, et leur nature

Le routage n’est pas isolé. Le même parc porte plusieurs dérogations, et elles ne relèvent pas toutes de la même logique. La distinction mérite d’être faite, parce qu’elle change ce qu’on doit à un auditeur.

Contrôle inapplicable. Le référentiel demande un mot de passe sur le chargeur d’amorçage. Sur une machine virtuelle d’un fournisseur cloud, on n’a pas d’accès console au démarrage, et le modèle de menace correspondant ne s’applique pas. Le contrôle est écarté parce qu’il n’a pas d’objet.

Contrôle en conflit fonctionnel. Le confinement applicatif du système doit être ajusté là où les conteneurs ont besoin de profils spécifiques. Le contrôle n’est pas supprimé, il est déplacé vers le mécanisme qui, lui, comprend les conteneurs.

Contrôle couvert autrement. Le référentiel impose un outil de contrôle d’intégrité des fichiers. Le nôtre est désactivé, parce que la surveillance d’intégrité est assurée par l’agent du SOC, qui remonte en plus les évènements dans la chaîne de détection. L’objectif du contrôle est atteint par un autre moyen, mieux intégré.

Ce troisième cas est le plus intéressant, et c’est le vocabulaire de la conformité qui le nomme : une mesure compensatoire. Ce n’est pas une dispense, c’est un engagement, et il vaut ce que vaut la mesure qui remplace.

Contrôle contraire au contexte. Le référentiel propose de désactiver IPv6. Notre hébergeur l’utilise. Le désactiver dégraderait la connectivité sans bénéfice de sécurité identifiable.

Le vrai indicateur n’est pas le score

Un durcissement se mesure souvent par un pourcentage de contrôles satisfaits. C’est un indicateur commode et faible, parce qu’il ne distingue pas un contrôle appliqué d’un contrôle inapplicable, ni une dérogation motivée d’un oubli.

Deux parcs affichant le même score peuvent être dans des états très différents. La question utile n’est pas « combien de contrôles passent », mais « les contrôles qui ne passent pas sont-ils tous connus, motivés et datés ? ». Un parc à 78 % dont les 22 % restants sont documentés ligne à ligne est dans une bien meilleure situation qu’un parc à 92 % dont les 8 % sont inexpliqués.

C’est aussi la seule forme sous laquelle un durcissement survit au départ de celui qui l’a mis en place.

Ce qu’on en retient

1. Un référentiel généraliste ne connaît pas votre plateforme. CIS décrit un hôte Linux, pas un hôte Linux qui fait tourner des conteneurs. Les conflits sont attendus, pas exceptionnels.
2. Le silence est le pire des trois choix. Appliquer et casser se voit ; trancher et écrire se défend ; sauter sans le dire produit un rapport faux, qui est précisément ce qu’un rapport ne doit pas être.
3. Une dérogation se juge à son motif, et son motif doit vivre là où on configure, pas dans un document parallèle qui divergera.
4. Distinguer inapplicable, en conflit, et compensé. Ces trois cas n’engagent pas la même chose, et seul le troisième crée une obligation durable.
5. Un durcissement différé est un piège. Une valeur écrite qui ne prend effet qu’au redémarrage sépare la cause de l’effet de plusieurs semaines. Vérifiez ce qui survit à un redémarrage, pas ce qui est écrit dans le fichier.

Le point 2 est celui qui distingue une équipe qui fait de la sécurité d’une équipe qui produit des rapports de sécurité.