Un coffre-fort dont vous pouvez raisonner, y compris là où il s’arrête

Les questions qu’on vous posera

L’essentiel du travail de sécurité sur les secrets consiste à répondre à des questions. Qui peut lire production ? Qui l’a effectivement fait ? Qu’exposerait une intrusion chez l’hébergeur ? Qu’est-ce qui a changé après le départ de quelqu’un ?

Le besoin : disposer de ces réponses sous une forme que vous pouvez montrer à un auditeur, à un client ou à votre conseil d’administration.

Ce que vous pouvez affirmer, et pourquoi c’est solide

• Le serveur ne peut pas lire les valeurs. Le chiffrement n’a lieu que dans le navigateur et dans l’agent crunu. Le serveur stocke des données chiffrées, des clés publiques et des documents signés, et n’a de clé de déchiffrement à aucun moment du protocole.
• Une base de données volée n’ouvre pas les valeurs. La clé du compte est dérivée par PBKDF2-SHA256 en 1 000 000 d’itérations à partir du mot de passe et d’une Secret Key d’environ 128 bits, et ni l’un ni l’autre n’atteint le serveur. Une copie complète de la base de données ne sert à rien pour deviner.
• Le serveur ne peut pas s’accorder d’accès. Les listes d’accès et chaque version sont signées. Les clients et les agents vérifient les signatures et rejettent les états plus anciens que le plus récent qu’ils ont vu. Un appareil qui n’a jamais vu l’état le plus récent ne peut pas détecter un retour en arrière.
• Les rôles sont imposés par des clés. Un membre qui a accès à development n’a pas de clé de production. Un Operator enrôle des machines sans voir aucune valeur.
• Le journal rend les retouches visibles. Le journal d’audit est une chaîne de hachage : modifier, supprimer ou insérer une entrée se voit à la vérification. Vérifiez en un clic, ou exportez en JSONL et vérifiez hors de Crunu.
• L’affichage et la copie sont aussi consignés. Quand quelqu’un affiche, copie ou exporte une valeur, l’événement est enregistré avec sa signature et marqué comme signalé par le client.
• Les départs laissent une trace. Le retrait d’un membre produit un rapport d’exposition : quelles versions de quels environnements la personne a reçues, quand et depuis quelle adresse.
• Vous pouvez vérifier le client que vous utilisez. Les versions sont signées avec Ed25519, le client web se construit de façon reproductible, et l’application vérifie son propre build par rapport à la version signée à chaque chargement.
• La connexion est limitée en fréquence. 10 tentatives échouées par adresse et 5 par compte en 15 minutes, et « aucun compte » se présente exactement comme « mauvais mot de passe ». Une session dure 12 heures d’inactivité et 7 jours au plus, et ne peut ni changer le mot de passe ni supprimer le compte sans le mot de passe et la Secret Key.
• Des seconds facteurs sur chaque compte. Codes d’application d’authentification et clés d’accès (passkeys) sur le web ; dans le terminal, un code d’application ou l’approbation depuis un autre appareil connecté.

Algorithmes : AES-256-GCM pour les valeurs, X25519 pour sceller les clés, Ed25519 pour les signatures, HKDF-SHA256 pour la dérivation de clés. Le modèle de sécurité explique comment ils s’articulent.

Quand quelque chose semble anormal

• Les alertes se déclenchent sur les connexions depuis un nouvel appareil, un code d’enrôlement réutilisé, une machine sur une nouvelle adresse, un jeton CI rejoué, une série de refus, un bail expiré, une connexion par code de récupération, des certificats qui expirent, des clés non remises et des événements réseau comme une politique assouplie ou un accès d’urgence (break-glass). Elles partent vers un webhook signé par HMAC ou par e-mail.
• Les restrictions réseau ne servent production qu’aux plages d’adresses autorisées. Assouplir une politique attend 15 minutes, avec une alerte et une annulation possible ; l’accès d’urgence d’un propriétaire dure 60 minutes au plus, exige un motif et déclenche une alerte.
• L’action Device compromised remplace les clés du compte de la personne, déconnecte ses autres appareils et renouvelle les clés de chaque environnement dont elle détenait une clé.
• Une conservation que vous maîtrisez. Le journal d’audit est conservé 365 jours par défaut, et l’organisation ne peut qu’allonger cette durée, jusqu’à 36 500 jours ou sans limite. L’élagage garde un point de contrôle : la chaîne reste donc vérifiable.

Ce que Crunu ne peut pas protéger

• Un client web modifié reste le principal risque, comme pour tout coffre-fort qui tourne dans un navigateur : une page servie par un serveur compromis pourrait capturer le mot de passe et la Secret Key à la connexion. Les défenses sont le manifeste signé, par rapport auquel l’application se vérifie à chaque chargement, et une politique de sécurité du contenu avec intégrité des sous-ressources qui bloque les scripts tiers. Cette auto-vérification s’exécute dans la même page, si bien qu’elle ne peut pas repérer un serveur qui modifie les deux. Les signatures reposent sur la clé de publication : elles ne vous protègent donc pas de qui détient cette clé.
• Les valeurs déjà vues ne se reprennent pas. Le renouvellement des clés protège les nouvelles versions. Réémettez les valeurs elles-mêmes chez chaque fournisseur.
• Le serveur voit les métadonnées : noms des organisations, des projets, des environnements et des machines, adresses e-mail, journal d’audit, taille et heure des versions.
• Le serveur peut refuser le service ou perdre des écritures. Les exports, les copies hors ligne et, si vous l’auto-hébergez, les sauvegardes sont la parade.
• Un logiciel malveillant sur un appareil où les clés sont déchiffrées (enregistreur de frappe, extension de navigateur, root sur une machine) peut lire ce que cet appareil peut lire.
• Un code de récupération ouvre un compte après un délai d’attente, sans second facteur. Le délai est imposé par le serveur : un serveur compromis pourrait donc le sauter.
• Les restrictions réseau sont appliquées par le serveur, pas par le chiffrement.
• Les propriétaires et les administrateurs peuvent atteindre chaque environnement partagé grâce à la clé de récupération de l’organisation.
• Un serveur compromis agissant avec un membre retiré pourrait maintenir un nouvel appareil sur un état plus ancien de l’organisation. Fermer complètement cette porte demanderait un journal de transparence externe.
• Si la base de données du serveur et sa propre clé fuient ensemble, les codes des applications d’authentification sont affaiblis en tant que second facteur.
• Ni authentification unique ni SCIM.

Chaque limite, avec ce qu’il faut faire, figure sur la page des limites.

Vous avez trouvé quelque chose ?

Écrivez à security@crunu.com. Notre security.txt se trouve à l’adresse /.well-known/security.txt.

Documentation associée

• Comment fonctionne le chiffrement
• Ce que voit le serveur
• Limites
• Journal d’audit
• Alertes
• Règles réseau
• Gérer le départ d’un collègue