12. Cycle de clés et dossier de certification

Comprendre le mécanisme

Une clé a un propriétaire, un usage, un périmètre, une période d’activité et un mode de stockage. Séparez environnements et finalités ; une clé de signature ne doit pas devenir un secret universel. Rotation normale, compromission, restauration et destruction ont des objectifs différents. Changer la valeur ne suffit pas si les anciennes copies, sauvegardes et consommateurs restent inconnus.

Raisonner et vérifier

Pour préparer une évaluation professionnelle de développement sécurisé, constituez un dossier qui explique les décisions et leurs preuves : inventaire, menace, exigences, tests et incident simulé. Ce travail complète la révision des domaines publics d’une certification ; il ne remplace pas ses conditions officielles. Les preuves techniques doivent être expurgées et reproductibles, sans clés privées dans les supports de formation.

Inventaire et propriétaire

Une clé doit avoir un propriétaire et un usage. La gouvernance fait partie du cycle de secret. Enregistrez finalité, détenteurs, environnement, date de création et procédure de retrait. Une clé sans propriétaire rend difficiles la rotation, l’investigation d’incident et la justification de son maintien.

Séparation

Séparer les environnements limite l’impact d’un incident. La réutilisation élargit le périmètre affecté. Utilisez des clés distinctes entre test et production, ainsi qu’entre fonctions qui n’exigent pas de partage. La compromission d’un environnement de démonstration ne doit pas permettre de signer des demandes de production.

Compromission

Rotation normale et compromission ont des objectifs distincts. Le risque peut exiger un retrait plus rapide. Une rotation planifiée peut accepter une période de chevauchement. Une clé compromise peut demander un rejet immédiat et une révocation ; la politique doit annoncer le délai et les effets sur les clients.

Copies connues

Les copies et sauvegardes doivent être inventoriées. D’autres stockages et consommateurs peuvent conserver l’ancienne clé. Inventoriez coffre, variables CI, fichiers, images de conteneur et sauvegardes. Changer la valeur active ne retire pas les anciennes copies ni les capacités déjà distribuées aux consommateurs.

Restauration

Une restauration ne doit pas réintroduire un secret retiré. Le cycle de retrait doit rester cohérent après reprise. Testez une restauration ancienne avec la procédure actuelle de secrets. Elle doit récupérer la configuration admise sans réintroduire une clé révoquée simplement parce qu’elle figurait dans une sauvegarde historique.

Conservation

La destruction demande une politique de conservation. Les besoins et risques de copie doivent être maîtrisés. Définissez quand garder ou détruire une ancienne clé selon son usage. Une clé de déchiffrement nécessaire à des archives et une clé de signature compromise posent des besoins différents.

Preuves expurgées

Les preuves d’exercice doivent être expurgées. La décision et les tests suffisent sans capacité réelle. Un dossier peut montrer identifiants, versions et résultats de test sans révéler les secrets. Vérifiez captures, archives et rapports avant partage ; une preuve de sécurité ne doit pas créer une nouvelle fuite.

Limites du dossier

Un dossier doit annoncer ses limites. La connaissance et l’assurance d’implémentation diffèrent. Indiquez les consommateurs et environnements effectivement vérifiés. Une rotation testée sur un service ne démontre pas le retrait chez tous les partenaires ou dans toutes les copies historiques.

Délai de retrait

Le délai de retrait doit être observé chez les consommateurs. La propagation doit être vérifiée. Mesurez quand chaque vérificateur cesse d’accepter l’ancienne clé. Les caches et processus longs peuvent retarder la décision ; définissez un mécanisme d’invalidation compatible avec le délai requis.

Finalité conservée

Les clés doivent rester liées à leur finalité. Les protocoles et risques demandent une séparation adaptée. Une clé ne doit pas être réutilisée pour résoudre un besoin sans rapport simplement parce qu’elle est déjà disponible. La séparation des usages aide à raisonner sur les capacités et à limiter l’impact des incidents.

Atelier guidé : lire, expliquer et vérifier le code

emission:
  active_key: K2
validation:
  accepted_keys: [K1, K2]
incident:
  compromised_key: K1
  required_action: reject_K1

La configuration émet avec K2 mais accepte encore K1 alors que l’incident exige son rejet. Testez un objet signé par K1 et vérifiez le refus sur chaque consommateur. La nouvelle clé active ne suffit pas à prouver que l’ancienne capacité a disparu du système.

Le nom ne définit pas les clés acceptées. La configuration de validation contredit l’action requise. Changer l’émission ne retire pas la capacité admise côté réception. Aucune donnée ne démontre une compromission de K2.

Travail pratique : Réalisez un exercice de compromission fictive : identifiez les consommateurs, remplacez une clé de test et mesurez le délai de retrait.

Critères de correction : Vérifiez que les anciens usages sont refusés selon la politique et que la restauration ne réintroduit pas un secret retiré. Joignez les limites du test et reliez les décisions aux compétences du parcours.

PCI DSS côté marchand : ne pas retenir le CVV après autorisation

Dans le cas marchand posé, le CVV appartient aux données d’authentification sensibles. Sa conservation après autorisation est interdite, y compris sous forme chiffrée. Un besoin de support ou de paiement ultérieur ne transforme pas cette rétention en usage admissible.

Concevez la collecte pour qu’elle ne laisse pas de copie durable dans base, queue, logs, traces ou exports. Un champ retiré de la table principale peut encore subsister dans une capture automatique de requête. Vérifiez donc le chemin complet avec des données factices.

Les paiements futurs doivent utiliser l’intégration et les références du prestataire prévues pour ce besoin, sans conserver le CVV comme raccourci. La revue d’un système réel doit préciser son périmètre et les responsabilités applicables ; cet atelier enseigne la règle ciblée du cas présenté, sans prétendre réaliser à lui seul une évaluation PCI complète.

Points de vigilance : Le chiffrement n’autorise pas la conservation post-autorisation du CVV dans ce cas marchand. Le CVV est une donnée d’authentification sensible dont la rétention post-autorisation est interdite ici. Le consentement du client ne crée pas cette exception PCI DSS. La localisation géographique ne lève pas l’interdiction.

Clé PSP exposée : retirer la capacité et examiner les usages

Une clé committée puis intégrée à une image déployée doit être traitée comme compromise. Supprimer la ligne du dernier commit ne retire ni l’historique, ni les couches, ni les copies déjà tirées, et ne change pas la capacité chez le prestataire.

Déclenchez la procédure d’incident : confinement, révocation ou rotation selon les capacités PSP, investigation des usages et vérification des opérations. Distribuez une nouvelle clé par un mécanisme contrôlé et vérifiez les consommateurs réels. Distinguez la continuité de service nécessaire d’un maintien indéfini de l’ancienne clé.

Remplacez les artefacts et corrigez la chaîne de build pour éviter une nouvelle exposition. Inventoriez caches, logs et sauvegardes selon la procédure de traitement ; le nettoyage de visibilité est complémentaire au retrait de la capacité. Un exercice avec clé factice doit démontrer que l’ancienne valeur est refusée et que les services autorisés utilisent la nouvelle sans la recopier dans des images ou diagnostics.

Points de vigilance : Les copies et l’historique peuvent toujours contenir une clé active. La réécriture Git ne révoque pas la clé et ne supprime pas les images déjà distribuées. Changer l’emplacement ne change pas le fait que la clé est connue d’un tiers potentiel. L’incident nécessite confinement, rotation contrôlée, vérification des opérations et prévention des nouvelles fuites.