La cryptographie, c'est surtout la gestion des clés.
ISO 27001:2022 A.8.24 (utilisation de la cryptographie) concerne l'utilisation efficace de la cryptographie pour protéger les informations, y compris la gestion des clés. Dans le code, cela se résume surtout à trois points : les clés sont-elles gérées en toute sécurité, les algorithmes sont-ils robustes et la configuration est-elle solide. Ces trois aspects sont des décisions prises lors des pull requests, et l'échec qui apparaît dans le code est souvent une clé mal placée plutôt qu'un algorithme faible.
The shapes the same control failure takes.
A.8.24 est affaibli lorsqu'une clé est mal gérée ou qu'un primitif est rétrogradé. Les formes récurrentes :
Une clé se retrouve dans le code
Un secret ou une clé privée est codé en dur ou commité au lieu d'être lu depuis un coffre-fort de secrets géré, il réside donc dans le dépôt et son historique.
Un primitif faible est introduit
Une modification utilise un hachage ou un chiffrement cassé ou faible (par exemple pour le hachage des mots de passe ou la signature) alors qu'un primitif robuste est requis.
Le seuil TLS baisse
Une version minimale de protocole ou une exigence de chiffrement est abaissée, affaiblissant la cryptographie protégeant un transport.
La vérification est désactivée
La vérification des certificats ou des signatures est désactivée, un canal chiffré ou un artefact signé n'est donc plus réellement de confiance.
La rotation ou la portée des clés est assouplie
La durée de vie d'une clé est prolongée indéfiniment, ou une clé commence à être réutilisée au-delà des limites qu'elle ne devrait pas franchir.
Une clé de signature codée en dur pour corriger un déploiement.
Une clé de signature de jeton était lue depuis un coffre-fort de secrets, mais le coffre n'était pas configuré dans un nouvel environnement et le déploiement a échoué. La solution rapide consiste à intégrer la clé en dur pour que le service démarre. Cela fonctionne, et la clé privée se retrouve maintenant dans le dépôt et son historique.
- const SIGNING_KEY = await secrets.get("jwt-signing-key")+ const SIGNING_KEY = "<the PEM private key, pasted inline>"const token = sign(claims, SIGNING_KEY)Une clé de signature dans le code source réside dans le dépôt, son historique, et chaque clone et cache CI, ce qui contredit la gestion des clés attendue par A.8.24. Restaurez-la depuis le coffre-fort de secrets et configurez le coffre dans le nouvel environnement, et faites tourner la clé, car une clé commité doit être considérée comme exposée.
La gestion des clés est la partie qui est échantillonnée.
Un auditeur examinant A.8.24 se soucie moins du chiffrement choisi et plus de la manière dont les clés sont générées, stockées, tournées et retirées. Un secret trouvé dans le code source, une clé sans rotation ou une vérification discrètement désactivée sont des types de constats qui ressortent, et ils ont tendance à apparaître via une modification visant à débloquer quelque chose. La pull request est l'endroit où la décision clé est prise et le lieu le moins coûteux pour la corriger.
Une revue, pas un audit crypto.
heygrc signale les modifications qui concernent A.8.24 et cite le contrôle afin que la correction ait lieu dans la pull request. Il ne conçoit pas votre schéma de gestion des clés ni ne réalise votre évaluation. Il détecte le moment où une clé est mal gérée ou un primitif affaibli, au niveau du diff.