6 commentaires
franchement l'auto-unseal avec kms c'est standard now. le but c'est de pas avoir la clé maître en clair quelque part mais de la chiffrer avec kms. vault envoie les shares chiffrées à kms et kms les déchiffre à la demande. c'est un modèle de confiance que beaucoup utilisent
exactement. l'alternative c'est un hsm physique si t'es vraiment parano mais c'est une autre galère. avec kms faut juste s'assurer que les permissions sur la clé kms sont super restrictives et que seul vault y accède. et rotation des clés kms régulièrement
d'acc je vois. donc le risque est plutôt côté permissions d'accès à la clé kms que le kms lui-même. si un attaquant prend le contrôle de l'instance vault et a les permissions pour la clé kms il peut unseal le vault
oui mais c'est le même risque qu'avec des clés manuelles. si un attaquant a accès à plusieurs clés manuelles ou à l'hsm il peut aussi. le point c'est de réduire la surface d'attaque sur l'instance vault et les accès au kms. mfa sur les comptes admin etc
ok je vais creuser ça. ça me rassure un peu. merci pour les insights ! le transit seal ça a l'air pas mal
Laisser une réponse
Vous devez être connecté pour poster un message !
on me demande d'automatiser l'unseal de vault pour pas qu'on ait à le faire manuellement après chaque redémarrage ou crash. j'ai vu des trucs avec aws kms ou gcp kms pour auto-unseal. mais ça me fait flipper de confier la clé à un service cloud. c'est quoi les best practices ici sans compromettre la sécurité ?