La confiance numérique doit pouvoir répondre à des questions concrètes : qui agit, avec quelle preuve, sur quelle ressource, pour quelle action et pendant combien de temps ? Identités, certificats et infrastructure participent à cette réponse, mais aucun de ces composants ne suffit isolément.
Séparer cinq décisions
Identifier consiste à désigner un sujet. Authentifier consiste à vérifier une preuve liée à cette identité. Autoriser consiste à décider si une action est permise. Protéger le canal contribue à la confidentialité et à l’intégrité des échanges. Tracer permet de comprendre les actions réalisées.
Ces responsabilités peuvent être distribuées entre plusieurs composants. Les fusionner dans une phrase comme « l’accès est sécurisé par TLS » empêche de voir les contrôles manquants.
Exemple pédagogique : un service possède un certificat client valide et établit une connexion mutuellement authentifiée. L’application doit encore déterminer quelles ressources cette identité peut utiliser. La possession du certificat n’est pas une autorisation universelle.
Penser à la ressource, pas seulement au réseau
Le NIST SP 800-207 présente Zero Trust comme une approche centrée sur les ressources, sans confiance implicite accordée uniquement à partir de la localisation réseau ou de la propriété d’un équipement. Ce cadre invite à examiner identité, contexte et décision d’accès.
Cela ne signifie pas supprimer les contrôles réseau. Ils restent une couche utile, mais ils ne doivent pas être la seule explication de la confiance. Une identité compromise à l’intérieur d’un réseau autorisé exige encore des limitations d’accès et des moyens de détection.
Une proposition de revue consiste à tracer le chemin d’une action : preuve présentée, composant de décision, politique appliquée, ressource et journal. Toute zone où la décision reste implicite mérite une clarification.
Donner un cycle de vie aux identités techniques
Les comptes de service peuvent survivre à l’application qui les utilisait. Une identité partagée complique l’attribution des actions ; une permission trop large accroît les conséquences d’une erreur. Ces risques ne se résolvent pas par une rotation de mot de passe seule.
Associer une identité à son propriétaire, son usage et son périmètre permet de décider quand la modifier ou la retirer. Lorsque la plateforme le permet, privilégier des mécanismes qui limitent la durée et la portée de la preuve, tout en assurant la continuité du service.
| Étape | Question de contrôle |
|---|---|
| Création | Quel usage justifie cette identité ? |
| Attribution | Quelles actions sont réellement nécessaires ? |
| Exécution | Quelle preuve est présentée et vérifiée ? |
| Révision | L’usage et le propriétaire sont-ils toujours valables ? |
| Retrait | Comment révoquer l’accès sans laisser de copie active ? |
Situer les certificats dans cet ensemble
Les certificats lient une clé publique à une identité dans un cadre de confiance. La chaîne PKI permet au client de vérifier cette relation selon ses politiques. Elle ne prouve pas que l’identité doit disposer de toutes les permissions demandées.
Un certificat à jour peut être déployé sur un service dont les règles d’accès sont incorrectes. À l’inverse, une politique d’autorisation correcte devient inutile si le client ne vérifie pas l’identité du service auquel il se connecte.
La gouvernance TLS à grande échelle relie ces objets aux responsabilités. Le retrait d’un service doit entraîner une revue de ses identités, de ses secrets et de ses certificats, pas seulement l’arrêt d’une machine.
Protéger les secrets sans les rendre ingérables
La fiche OWASP Secrets Management aborde le stockage, l’accès et le cycle de vie des secrets. Dans une architecture concrète, il faut aussi tester la dépendance au système qui les fournit.
Que se passe-t-il si ce système ralentit ? Les services conservent-ils une capacité de fonctionnement compatible avec la politique ? Une reprise utilise-t-elle une copie ancienne encore autorisée ? Les réponses doivent être explicites et testées sur le périmètre concerné.
Un coffre de secrets ne compense pas un compte administrateur permanent utilisé par toutes les automatisations. La portée des permissions et la séparation des responsabilités restent des décisions d’architecture.
Préparer la perte de confiance
Un système de confiance doit pouvoir retirer une permission, invalider une preuve ou remplacer une clé. Tester seulement le chemin nominal laisse de côté la question la plus importante en cas de compromission : comment réduire l’exposition sans perdre la maîtrise du service ?
Pour une illustration de méthode, préparer un scénario où une identité de service doit être remplacée. Définir les consommateurs, la période de transition, les vérifications et la condition qui interdit de réutiliser l’ancienne preuve. Une procédure de retrait qui n’a jamais été exercée reste une hypothèse.
Une revue de confiance en six questions
- Les identités correspondent-elles à des usages attribués ?
- Les preuves sont-elles vérifiées par les bons composants ?
- Les autorisations sont-elles limitées aux actions nécessaires ?
- Les secrets et certificats peuvent-ils être renouvelés et retirés ?
- Les actions sont-elles attribuables sans exposer les secrets ?
- Les dépendances de sécurité ont-elles un comportement d’échec défini ?
Cette grille est une proposition de travail, pas une certification de conformité. Le dossier Security, Identity & Digital Trust et la maîtrise des automatisations prolongent cette analyse.