Chapitre 2. Principes fondamentaux de la gestion des secrets

Objectifs pédagogiques¶

Appliquer confidentialité, intégrité et disponibilité au cas des secrets. Distinguer identité, authentification et autorisation. Traduire le moindre privilège en exigences. Justifier rotation et révocation comme propriétés de conception. Énoncer ce qu'exige une traçabilité exploitable. Situer séparation des responsabilités, défense en profondeur, Zero Trust, racine de confiance et credential éphémère.

Prérequis¶

Chapitre 1.

Cours¶

Ce chapitre est la grille d'évaluation du cours. Chaque principe est donné avec ce qu'il énonce, ce qu'il exige d'un système, et le critère qui permet de vérifier qu'il est appliqué plutôt qu'affiché. Ces principes reviendront à chaque chapitre technique, puis dans la grille d'analyse d'architecture de la partie IX.

2.1 Confidentialité, intégrité, disponibilité¶

La confidentialité d'un secret est évidente : lu par la mauvaise personne, il est perdu, sans dégât visible ni alarme. D'où la présomption de compromission au moindre doute.

L'intégrité compte sous deux formes : celle du secret (un secret substitué, comme une clé publique remplacée dans un fichier authorized_keys, détourne la confiance) et celle du système qui le distribue (qui modifie les règles d'accès du coffre en vide la confidentialité).

La disponibilité prend un caractère existentiel : les secrets sont nécessaires au démarrage des services. Un gestionnaire indisponible, c'est une infrastructure qui ne peut plus s'authentifier ni redémarrer.

D'où le conflit qui structure la discipline : tout ce qui augmente la confidentialité d'un secret réduit sa disponibilité, et réciproquement. Multiplier les copies rend disponible et indéfendable. Centraliser rend défendable et crée un point de défaillance. Exiger plusieurs personnes protège magnifiquement et fait attendre à trois heures du matin. Il n'existe pas de solution qui maximise les deux, seulement des arbitrages assumés, différents selon les secrets. Critère de vérification : une organisation sérieuse sait dire, pour chaque catégorie, où elle a placé le curseur et pourquoi.

2.2 Identité, authentification, autorisation¶

L'identité est ce que l'acteur est : l'application billing, l'administratrice Nadia, le pipeline du dépôt billing. C'est un référent stable, indépendant des moyens de le prouver. L'authentification est l'acte de prouver cette identité. L'autorisation est la décision de ce que l'identité prouvée peut faire.

Les droits s'attachent à l'identité, pas au moyen de preuve : une application garde ses droits et sa trace qu'elle s'authentifie par AppRole ou par Kubernetes, et l'on retire un moyen de preuve sans reconstruire les droits. Et un secret partagé fusionne les identités au niveau de la preuve : dix acteurs, une seule trace. Un compte unique tout-puissant fusionne en plus authentification et autorisation : prouver, c'est tout pouvoir.

2.3 Moindre privilège et besoin d'en connaître¶

Un acteur ne dispose que des droits strictement nécessaires à sa fonction, et n'accède pas à ce dont il n'a pas besoin même s'il est digne de confiance. Traduit aux secrets : billing lit ses secrets, pas ceux des autres applications, et lit son mot de passe sans pouvoir le modifier.

L'intérêt n'est pas moral mais quantitatif : le moindre privilège borne le rayon d'action d'une compromission. Une intrusion est une chaîne, et chaque privilège du maillon compromis est offert au maillon suivant. Un token limité à un périmètre transforme un vol en incident borné et une rotation ciblée. C'est le rayon qui fait la gravité, pas l'intrusion.

Critère de vérification : savoir dire, pour un acteur donné, la liste exacte des secrets qu'il peut lire, et la date de la dernière réduction d'un droit.

2.4 Rotation et révocation comme propriétés de conception¶

La capacité de remplacer et d'invalider doit être conçue dans le système, pas ajoutée par-dessus. Concrètement : des secrets versionnés pour que la rotation soit un recouvrement et non une coupure ; des consommateurs qui viennent chercher la valeur courante au lieu d'en détenir des copies ; une révocation dont l'effet est immédiat et vérifiable côté cible.

Critère de vérification : le temps mesuré entre la décision de révoquer et l'invalidation effective partout. Une organisation qui n'a jamais répété sa révocation découvrira sa procédure pendant l'incident.

2.5 Traçabilité et audit¶

Tout accès à un secret produit une trace : qui, quoi, quand, depuis où, avec quel résultat. Elle sert trois usages distincts : la détection pendant l'incident, l'investigation après coup, et la preuve pour la conformité.

Une trace exploitable remplit cinq conditions. Elle est attachée à des identités individuelles. Elle porte opération, chemin, origine et résultat. Elle est protégée en intégrité et expédiée hors du système observé, donc inaltérable par l'incriminé. Elle ne contient pas les valeurs secrètes. Et elle est interrogeable : on répond vite à « qui a lu ce secret ce mois-ci ». Un journal qui manque l'une de ces propriétés fait de « tout considérer comme volé » la seule conclusion honnête.

2.6 Séparation des responsabilités et quorums¶

Certaines opérations sont trop puissantes pour dépendre d'une personne : détenir la clé qui déchiffre tout, régénérer le pouvoir administratif suprême, restaurer l'ensemble du système. Elles exigent le concours de plusieurs personnes indépendantes.

Le quorum k parmi n protège contre trois risques simultanés : la malveillance d'une personne seule, la compromission partielle (voler k moins un fragments n'apprend rien), et l'erreur individuelle sur un geste irréversible. Son prix, au sens de 2.1, est la disponibilité : l'opération attend k humains joignables.

Critère de vérification : le quorum a-t-il été exercé à froid dans l'année ? Un quorum jamais répété est une procédure théorique.

2.7 Défense en profondeur¶

Superposer des contrôles indépendants, de sorte que la défaillance de l'un laisse les suivants. « Indépendants » est à prendre au sérieux : deux contrôles qui tombent ensemble ne font qu'une couche déguisée.

Empilement type pour les secrets : réseau restreint, authentification forte, autorisation minimale, chiffrement au repos, durées courtes, audit externalisé. Chaque couche suppose les autres défaillantes.

2.8 Zero Trust¶

Le modèle historique repose sur une équivalence implicite : être sur le réseau interne vaut preuve de légitimité. Le chapitre 1 a montré pourquoi elle est mortelle, les compromissions se jouant après l'entrée.

Le modèle Zero Trust retire au réseau son rôle de preuve : chaque accès, d'où qu'il vienne, est authentifié, autorisé et tracé sur la base d'une identité vérifiable. La segmentation demeure comme couche de défense en profondeur, réduisant qui peut seulement atteindre le service et tenter sa chance, mais cesse d'être un mécanisme d'autorisation.

2.9 La racine de confiance¶

La chaîne « une clé protège une clé » s'arrête nécessairement quelque part, sur un élément qui n'est protégé par rien d'autre que lui-même et les conditions matérielles et humaines de sa garde. Cet élément terminal est la racine de confiance. Sa sécurité ne se démontre pas par un mécanisme supérieur : elle se décide, et tout le reste en hérite.

Il faut savoir la désigner : dans une architecture donnée, quel objet précis occupe cette place. Et sa perte est aussi grave que son vol, parce qu'elle est irréparable par construction : le vol compromet les données, la perte les détruit.

2.10 Les credentials éphémères¶

Plutôt que de protéger de mieux en mieux des secrets durables, réduire la durée pendant laquelle il y a quelque chose à protéger. Un credential éphémère est créé à la demande, pour un consommateur précis, avec une durée courte, puis expire sans intervention.

Ce renversement traite trois plaies du chapitre 1. Le sprawl : une copie exfiltrée d'un credential expiré ne vaut rien. La rotation : le remplacement permanent devient le mode normal. L'imputabilité : un credential par instance produit des acteurs distincts dans les journaux.

Deux coûts en découlent : l'infrastructure d'émission devient critique en disponibilité, et les consommateurs comme les systèmes cibles doivent s'adapter.

Exemple : Astrea relue par les principes¶

Les sept constats du chapitre 1, passés au crible. La colonne d'exigences sert de cahier des charges aux parties III et IV.

Constat	Principe en cause	Exigence pour le système cible
Même mot de passe en production et préproduction	Moindre privilège (2.3)	Secrets distincts par environnement, cloisonnés par les autorisations
Clé SSH d'astreinte partagée	Identité (2.2), traçabilité (2.5)	Une identité par personne, des traces nominatives
Mot de passe inchangé depuis son commit	Rotation et révocation (2.4)	Rotation sans coordination, révocation vérifiable
Clé d'API imprimée dans les journaux de CI	Credentials éphémères (2.10)	Aucun secret durable dans la chaîne de livraison
Clé wildcard sur un partage	Moindre privilège (2.3), imputabilité (2.2)	Un certificat par service, émis à la demande
Variable d'environnement systemd	Défense en profondeur (2.7)	Lecture à l'exécution, durée courte, permissions strictes
Clé de sauvegarde dans le script	Racine de confiance (2.9)	Clé hors du flux qu'elle protège, gouvernée

Sécurité : ce que ces principes protègent, et ce qu'ils ne protègent pas¶

Les principes se tiennent ou tombent ensemble. Le moindre privilège sans traçabilité laisse un périmètre juste mais invérifiable. La traçabilité sans identités individuelles produit un journal qui n'accuse personne. Les durées courtes sans révocation ne couvrent pas la fenêtre entre la compromission et l'échéance.

Aucun de ces principes ne protège contre le détenteur légitime. Un acteur autorisé qui abuse de ses droits reste dans son périmètre et laisse une trace conforme. Ce qu'ils apportent alors n'est pas l'empêchement mais la détection et le bornage du rayon.

La rotation est le principe le plus proclamé et le moins tenu. Son coût est réel et son échec invisible tant qu'aucun incident ne survient. Le chapitre 18 lui substituera un mécanisme plutôt qu'une discipline.

Le théâtre de sécurité consomme le budget de la sécurité réelle. Chaque mesure spectaculaire mais inefficace occupe un temps et une ligne de dépense qui n'iront pas aux mesures ennuyeuses qui fonctionnent.

Erreurs fréquentes¶

Réciter les principes, mesurer autre chose. L'écart entre la politique écrite et le réel se détecte par les critères de vérification : qui peut lire ce secret, quand a-t-il tourné, qui l'a lu ce mois-ci. Un principe sans critère mesuré est un slogan.

Planifier la rotation, oublier la révocation. Le test réel est la révocation en urgence, non planifiée.

Collecter l'audit sans le lire. Le journal qui part vers un puits que personne n'interroge donne le confort de la conformité sans la détection.

Confondre segmentation et autorisation. Le réseau réduit qui peut tenter ; il n'accorde rien (2.8).

Traiter tous les secrets au même curseur. Le mot de passe de préproduction et la clé racine de la PKI n'appellent pas le même arbitrage (2.1).

Instaurer un quorum sans jamais l'exercer. Une procédure de crise jamais répétée n'existe pas (2.6).

Empiler des couches dépendantes. Deux contrôles assurés par le même composant ne font qu'une couche (2.7).

Mise en pratique : classer, puis débusquer le théâtre¶

Sans machine. Réponses commentées en fin de partie.

Pour chacune des huit mesures suivantes, indiquez le ou les principes qu'elle sert réellement, ou pourquoi elle relève du théâtre de sécurité.

a) Exiger un mot de passe de quatorze caractères sur le compte partagé « admin » de la console d'infrastructure. b) Chiffrer les sauvegardes avec une clé stockée dans le script de sauvegarde. c) Donner à chaque microservice sa propre identité et son propre credential d'accès à la base. d) Faire expirer au bout d'une heure les credentials de déploiement émis pour la CI. e) Exiger deux validations humaines pour toute restauration complète du gestionnaire de secrets. f) Masquer les secrets dans les journaux de CI par remplacement de motifs. g) Placer le gestionnaire de secrets sur un réseau dédié, en plus de son authentification. h) Conserver cinq ans de journaux d'accès en écriture seule, avec revue mensuelle.

Parmi les mesures classées comme du théâtre, choisissez-en une et proposez la mesure qui traiterait réellement le risque visé, en nommant le principe servi.
Trois de ces mesures se renforcent mutuellement. Identifiez-les et expliquez ce que chacune apporte que les deux autres n'apportent pas.

Questions de compréhension¶

Énoncez le conflit entre confidentialité et disponibilité, avec deux exemples aux extrêmes du curseur.
Définissez identité, authentification et autorisation, puis dites ce que fusionne un secret partagé, et ce qu'un compte unique tout-puissant fusionne d'autre.
Pourquoi les droits doivent-ils être attachés à l'identité plutôt qu'au moyen d'authentification ?
En quoi le moindre privilège borne-t-il le rayon d'une compromission ? Illustrez avec un token volé.
Quelles conditions une trace d'audit doit-elle remplir pour être exploitable ? Citez-en au moins quatre.
Que protège un quorum k parmi n, contre quels risques, et à quel prix ?
Reformulez le Zero Trust et dites ce qu'il reste à la segmentation réseau.
Qu'est-ce qu'une racine de confiance, et pourquoi sa perte est-elle aussi grave que son vol ?
Quels problèmes le credential éphémère traite-t-il, et quels coûts introduit-il ?

Synthèse¶

Dix principes, chacun outillé d'un critère de vérification. L'arbitrage assumé entre confidentialité et disponibilité. La séparation identité, authentification, autorisation, avec des droits portés par l'identité. Le moindre privilège comme borne du rayon de compromission. La rotation et la révocation conçues dans le système. La traçabilité nominative, protégée et lue. La séparation des responsabilités matérialisée par des quorums exercés. La défense en profondeur par couches indépendantes. Le Zero Trust, qui retire au réseau son rôle de preuve. La racine de confiance, qu'il faut savoir désigner. Et le credential éphémère, qui réduit la surface en réduisant la durée. Cette grille est l'instrument de mesure du reste du cours.