Chapitre 30. Durcissement, exposition, audit

Objectifs pédagogiques¶

Durcir l'hôte d'un nœud et nommer la menace que chaque mesure borne. Réduire l'exposition réseau et traiter les endpoints non authentifiés. Concevoir l'administration comme un chemin nominatif, court et journalisé. Configurer l'audit en double flux. Vérifier l'intégrité d'un journal et retrouver une valeur masquée. Écrire les requêtes d'exploitation qui servent en incident.

Prérequis¶

Chapitre 7 (l'installation, dont ce chapitre pousse les curseurs), chapitre 5 (les exclusions du modèle), chapitre 8 (l'audit et sa doctrine), chapitre 29 (la matrice, qui devient ici une configuration).

Cours¶

30.1 Durcir l'hôte¶

Le chapitre 7 a posé les bases ; passons au régime de production, mesure par menace.

Le compte de service : Vault tourne sous un utilisateur dédié, sans shell de connexion, propriétaire de rien d'autre que ses répertoires. La compromission d'un autre service de la machine ne donne pas la main sur les données.

Les privilèges : aucune capacité superflue dans l'unité systemd, ProtectSystem=full et PrivateTmp=yes autant que le service le permet, NoNewPrivileges=yes pour qu'aucune exécution n'acquière de droits en cours de route. L'objectif est qu'une exécution de code dans le processus reste enfermée dans le processus.

Les traces : LimitCORE=0. Un vidage mémoire est une copie du keyring en clair sur disque, et l'on interdit à la source plutôt que de nettoyer après.

L'échange : désactivé sans exception, contrepartie non négociable de disable_mlock = true (chapitres 5 et 24). Une machine Vault ne pagine jamais, et swapon --show doit ne rien renvoyer.

Les disques : chiffrés sous le système de fichiers, et surtout détruits de façon attestée à la réforme, avec la ligne de registre qui date la copie. Le répertoire /opt/vault/data est le coffre : son propriétaire est le compte de service, personne d'autre.

Le temps : synchronisation stricte. Baux, certificats, élections Raft et corrélation des journaux dépendent tous de l'horloge, et une dérive silencieuse produit des symptômes que personne ne relie à leur cause.

Les paquets : surface minimale. Pas de compilateur, pas de client de base, pas d'outillage de confort. Ce qui n'est pas installé n'a pas de vulnérabilité et ne sert pas à un attaquant qui obtient un shell.

30.2 Réduire l'exposition¶

La matrice du chapitre 29 devient une configuration de pare-feu, et l'exercice consiste à la relire en attaquant.

Les sept lignes de la matrice, et rien d'autre. Le pare-feu de chaque nœud refuse par défaut en entrée, autorise le 8200 depuis lb-vault-01 et admin-01, le 8201 depuis les deux autres nœuds seulement, le 22 depuis admin-01. Le reste tombe.

Les endpoints non authentifiés méritent une attention propre, car ils existent par nécessité : sys/health et sys/seal-status doivent répondre sur un serveur qu'on ne peut pas ouvrir. Ils révèlent le type de seal, l'état et la version. La conséquence n'est pas de les couper, les sondes en vivant, mais de savoir qu'ils sont la reconnaissance offerte, et donc de ne pas ajouter d'exposition inutile.

La télémétrie de sys/metrics ne s'ouvre qu'à monitor-01, sur un chemin authentifié ou filtré, jamais à toute la zone.

Le sens des flux d'observation, enfin : les nœuds poussent leurs journaux vers monitor-01, qui n'ouvre aucune session vers eux. La compromission du collecteur ne doit pas devenir un chemin vers les coffres.

30.3 L'administration comme chemin¶

L'administration est le vrai chemin d'attaque des systèmes bien construits. Le chapitre 29 en a fait une frontière, le chapitre 19 lui a donné son outil. Le régime d'Astrea compte quatre traits.

Nominatif : chaque administrateur s'authentifie sous son identité, par OIDC côté Vault (chapitre 10) et par certificats SSH signés de trente minutes côté machines (chapitre 19). Plus aucun compte partagé, plus aucune clé d'astreinte commune.

Court : les tokens d'administration ont des durées de session, pas de carrière. L'accès est un événement, pas un état.

Depuis un seul endroit : admin-01 est le point de passage. C'est lui qui figure dans la matrice, lui qu'on durcit, lui qu'on journalise. Les postes personnels n'atteignent pas la zone Vault.

Journalisé des deux côtés : l'audit dit qui a fait quoi dans Vault, les journaux système disent qui s'est connecté où, et la corrélation des deux transforme un soupçon en certitude.

Une note pour finir : l'administration hors ligne, console d'hyperviseur et accès physique, échappe à ce chemin par construction. Elle se compte dans la grille, se restreint à une liste courte, et ses usages se journalisent côté hyperviseur, faute de quoi le beau dessin a une porte dérobée légitime.

30.4 L'audit en double flux¶

L'audit est le contrôle détectif principal, et le chapitre 4 en a donné la propriété qui commande tout : si aucun dispositif ne peut écrire, Vault refuse de répondre. La disponibilité cède devant la traçabilité.

Cette propriété a une conséquence directe : un dispositif unique dont le disque se remplit arrête le service. Deux dispositifs indépendants font qu'une panne de l'un laisse l'autre écrire.

[Production]

vault audit enable -path=file file file_path=/var/log/vault/audit.log
vault audit enable -path=syslog syslog tag="vault" facility="AUTH"
vault audit list -detailed

Le premier écrit localement, rapide et complet, à la merci du disque. Le second pousse vers monitor-01, hors de portée d'un attaquant qui obtiendrait la machine, ce qui est le point : un journal local seul est un journal que le compromettant peut éditer.

Trois disciplines complètent le montage. La rotation du fichier local est gérée à l'extérieur de Vault, avec une règle absolue : ne jamais casser le descripteur sans que Vault ne le rouvre. La rotation par copie et troncature est le piège classique ; le renommage suivi d'un signal est la bonne voie. L'espace disque du volume de journaux est supervisé avec une alerte précoce, parce que le disque plein n'est pas une gêne mais un arrêt de production. Et la charge : chaque requête produit deux lignes, et une flotte qui relit ses secrets à chaque transaction se paie d'abord ici.

30.5 Lire un journal d'audit¶

Une ligne d'audit est du JSON, et sa lecture demande de connaître trois traits.

Les valeurs sensibles sont masquées. Tokens et valeurs apparaissent en empreinte à clé, salée par une clé propre à l'installation. Le journal prouve qu'un secret a été lu sans le contenir, ce qui permet de l'expédier vers un collecteur.

Le masquage est interrogeable, et c'est la manœuvre qui sauve les enquêtes.

vault write sys/audit-hash/file input="hvs.CAESIJ..."
# -> hmac-sha256:9f3a...  : on compare CE hash aux lignes du journal

On ne déchiffre pas une empreinte : on recalcule celle d'une valeur qu'on soupçonne, et on la cherche. C'est ainsi qu'on répond à la question « ce token trouvé sur un poste a-t-il servi, et pour quoi ».

Les identités sont là : entité, nom d'affichage, policies, accessor du token, adresse source, horodatage, chemin demandé et issue. De quoi reconstituer une session complète.

Deux avertissements ferment la section. Les options d'exclusion de champs du masquage existent et transformeraient le journal en fuite : elles restent interdites au dossier. Et les journaux, parce qu'ils révèlent qui accède à quoi et à quel rythme, sont des actifs : accès restreint, intégrité vérifiable, rétention décidée.

30.6 Exploiter l'audit¶

Un journal qu'on ne sait pas interroger est une archive, pas un contrôle. Astrea prépare à froid quatre requêtes, testées et rangées dans le runbook : les quatre questions de trois heures du matin.

Question	Méthode	Ce qu'elle donne
Qu'a fait cette identité ?	filtrer sur `auth.entity_id`, ordonner par `time`	la session reconstituée
Qui a touché ce chemin ?	filtrer sur `request.path`, avec les issues	qui a lu, et qui s'est vu refuser
Qu'a fait ce token ?	recalculer son empreinte par `sys/audit-hash`, la chercher	remonter à l'accessor puis à l'émission
Qu'est-ce qui a échoué ?	filtrer les réponses en erreur	une rafale de refus signale une reconnaissance

Le dispositif se complète de trois manières. La corrélation avec les journaux système et ceux de lb-vault-01, qui suppose la synchronisation du temps. L'intégrité du flux : le collecteur conserve en écriture seule, et un contrôle périodique compare les volumes locaux et distants, un trou côté collecteur étant un événement en soi. Et la rétention, décidée par la conformité et le besoin d'enquête, avec la conscience que ces journaux sont une cartographie des usages.

Exemple : la revue de durcissement¶

Deux jours de travail consignés en une page.

Sur les hôtes. Compte de service vérifié sur les quatre machines, échange désactivé partout ; un nœud l'avait réactivé lors d'une reconstruction, d'où un ticket et l'ajout du contrôle à la recette de la gestion de configuration. Vidages mémoire confirmés interdits. Paquets superflus retirés : un client de base de données traînait sur un nœud, installé pour un diagnostic six mois plus tôt, exemple parfait de la surface qui s'accumule. Synchronisation du temps contrôlée, avec une dérive corrigée sur vault-transit-01.

Sur le réseau. Balayage depuis la zone applicative : seul le 8200 de lb-vault-01 répond, conforme. Balayage depuis admin-01, conforme. Test de refus vers vault-transit-01, bloqué et capté au journal du pare-feu.

Sur l'audit. Second dispositif activé, car le fichier local était seul depuis le chapitre 8. Alerte d'espace disque branchée. Rotation vérifiée par un test réel. Et l'exercice qui compte : une valeur de token de test recalculée puis retrouvée dans les deux flux, preuve que la manœuvre du chapitre 31 fonctionne avant d'en avoir besoin.

Deux découvertes notables au passage. Les journaux de lb-vault-01 n'étaient pas expédiés à monitor-01, alors que la corrélation en avait besoin. Et personne n'avait vérifié que monitor-01 ne pouvait pas ouvrir de session vers les nœuds : il le pouvait, par une règle héritée, supprimée le jour même.

Sécurité : le contrôle des contrôles¶

L'audit bloquant est une décision d'architecture, pas une gêne. Le double dispositif existe pour que la traçabilité n'ait jamais à être choisie contre la disponibilité, et la supervision du disque de journaux devient de fait une supervision de disponibilité.

Un journal local seul est un journal éditable. L'attaquant qui obtient la machine efface ses traces. Le flux vers un collecteur en écriture seule est ce qui rend l'audit opposable, et le contrôle de volume détecte le trou.

Le collecteur est une cible, et un chemin à sens unique. Il concentre la cartographie des usages : il se durcit, se restreint, et n'a aucun chemin d'initiative vers les zones qu'il observe.

Le durcissement se recette, sinon il se perd. Échange réactivé, paquet réinstallé, règle héritée : les machines dérivent au rythme des interventions. Ces contrôles entrent dans la gestion de configuration et dans la revue trimestrielle.

Erreurs fréquentes¶

Un seul dispositif d'audit. Le disque se remplit, Vault s'arrête : un incident de production causé par un contrôle de sécurité mal dimensionné (section 30.4).

Rotation par copie et troncature. Le fichier est tronqué sous le descripteur : les écritures partent dans le vide ou l'audit échoue, donc le service (section 30.4).

Exclure des champs du masquage pour faciliter le débogage. Le journal devient un dépôt de secrets, expédié et conservé des mois (section 30.5).

Croire qu'une empreinte est inexploitable. L'enquêteur qui abandonne devant un hash perd le seul moyen de tracer un token trouvé dans la nature (sections 30.5, 30.6).

Laisser monitor-01 initier des connexions. La commodité ouvre un chemin du moins critique vers le plus critique (section 30.2).

Découvrir l'exploitation du journal en incident. Sans requêtes préparées ni format connu, l'enquête commence par un cours de JSON à trois heures du matin (section 30.6).

Négliger l'horloge. Une dérive de quelques secondes brouille toute corrélation et fatigue Raft, et le symptôme apparaît loin de sa cause (section 30.1).

Mise en pratique : durcir, prouver, interroger¶

Sur papier ; réponses commentées en fin de partie.

Rédigez la liste de contrôle de durcissement d'un nœud, au moins dix points, chacun avec la menace qu'il borne et la commande ou le constat qui le prouve.
Concevez le dispositif d'audit complet : dispositifs, chemins, rotation, expédition, alertes, rétention, contrôles d'intégrité, et le test de recette de chacun.
Écrivez les quatre requêtes d'exploitation sous forme de commandes concrètes, avec le résultat attendu de chacune.

Questions de compréhension¶

Donnez cinq mesures de durcissement de l'hôte et, pour chacune, la menace qu'elle borne.
Pourquoi l'interdiction des vidages mémoire et la désactivation de l'échange relèvent-elles de la même préoccupation ?
Quels endpoints répondent sans authentification, pourquoi existent-ils, et quelle posture adopter ?
Justifiez le sens unique des flux d'observation.
Énoncez les quatre traits du chemin d'administration, et ce que la corrélation des deux journalisations permet.
Pourquoi le double dispositif d'audit, et quel incident de production évite-t-il ?
Que contient une ligne d'audit, comment retrouve-t-on une valeur masquée, et pourquoi ne parle-t-on pas de déchiffrement ?
Citez les quatre questions d'exploitation, et le signal le plus précieux parmi elles.
Pourquoi les journaux d'audit sont-ils des actifs au sens du chapitre 29 ?

Synthèse¶

Le durcissement de production tient dans une liste courte dont chaque ligne borne une menace nommée : compte de service et privilèges minimaux, vidages mémoire et échange interdits, disques chiffrés et détruits en conscience, horloge stricte, paquets réduits. L'exposition se ramène aux flux de la matrice, les endpoints non authentifiés se connaissent au lieu de s'ignorer, et l'observation ne remonte jamais vers ce qu'elle observe. L'administration devient un chemin nominatif, court, unique et journalisé des deux côtés. Et l'audit passe en régime de production : deux dispositifs pour que la traçabilité bloquante ne coûte pas la disponibilité, un flux hors de portée du compromettant, un masquage interrogeable, quatre requêtes préparées à froid.