Modèle de sécurité : le serveur ne stocke que des données chiffrées

Avec Crunu, le contenu de chaque environnement est chiffré dans votre navigateur ou dans l’agent crunu, avant tout envoi. Le serveur conserve des données chiffrées, des clés publiques et des enregistrements signés, et à aucun moment du protocole il ne détient de clé capable de les déchiffrer.

Sur app.crunu.com, c’est Crunu qui exploite ce serveur. Si vous hébergez Crunu vous-même, c’est vous. Dans les deux cas, le serveur ne peut pas lire vos valeurs. Crunu est en accès anticipé : nous ne décrivons donc que ce que fait la version actuelle, et nous mettons cette page à jour quand cela change.

En bref

• Vos environnements sont chiffrés sur vos appareils. Le serveur ne stocke que des données chiffrées et n’a aucune clé pour les lire.
• Votre mot de passe et votre Secret Key ne quittent jamais votre appareil : une base de données volée n’aide donc personne à les deviner.
• Chaque environnement a sa propre clé. Les personnes, les machines et les jetons CI n’obtiennent que les environnements qui leur sont accordés.
• Les listes d’accès et les versions sont signées : le serveur ne peut ni s’ajouter comme destinataire ni modifier vos données sans que cela se voie.
• Le serveur voit tout de même des métadonnées : les noms, les adresses e-mail, le journal d’audit et le moment où chaque version a été enregistrée.
• Le principal risque qui subsiste est une page web modifiée. La page Limites connues le décrit, avec toutes les autres limites que nous connaissons.
• Nous ne publions ni rapport SOC 2 ni audit externe. Vous avez trouvé un problème ? Écrivez à security@crunu.com.

Le trajet d’un secret, étape par étape

Suivez STRIPE_SECRET_KEY depuis le moment où Priya l’enregistre jusqu’aux programmes qui la lisent.

1. Chiffrement et signature dans le navigateur de Priya. Son mot de passe et sa Secret Key, 26 caractères aléatoires créés sur son appareil, sont combinés pour former la clé de son compte, et aucun des deux n’est jamais envoyé. Quand elle enregistre, toute la nouvelle version de l’environnement, fichiers et variables compris, est chiffrée par le navigateur en un seul enregistrement, avec la clé de cet environnement (AES-256-GCM). Le navigateur complète cet enregistrement jusqu’à un nombre entier de blocs de 4 Ko pour que la taille exacte ne se voie pas, et signe la version au nom de Priya (Ed25519).
2. Le serveur stocke ce qu’il ne peut pas ouvrir. Il conserve un enregistrement chiffré par version, et non un par valeur, ainsi que la liste d’accès signée qui indique qui peut les lire. Il décide à qui remettre les données chiffrées, mais il n’a aucune clé pour les déchiffrer.
3. Un collègue n’obtient que les environnements qui lui sont accordés. Jonas reçoit les clés des environnements development et staging, chacune scellée pour sa propre clé publique (X25519). L’environnement production ne figure pas dans sa liste d’accès : il n’en reçoit donc jamais la clé. Son navigateur vérifie chaque signature et chaque numéro de version avant de déchiffrer.
4. Un serveur reçoit son environnement de la même façon. L’agent sur api-prod-1 reçoit la clé de production scellée pour cette machine, vérifie ce que le serveur a envoyé et garde l’environnement déchiffré en mémoire. Votre programme le reçoit via crunu run, ou sous forme de fichiers, là où vous les demandez avec crunu pull.
5. Un job CI obtient exactement sa part. Le jeton de service utilisé par GitHub Actions ne peut lire que web-app / staging. Avec une liaison CI (OIDC), il ne fonctionne que depuis le dépôt et la branche que vous avez choisis.

Sur app.crunu.com, le serveur tourne sur Cloudflare. La page Sous-traitants liste chaque entreprise qui traite des données pour le service et ce que chacune peut voir.

Dans la documentation : Comment fonctionne le chiffrement

Clés et algorithmes

Crunu s’appuie sur des briques standard : AES-256-GCM pour chiffrer, X25519 pour sceller des clés pour un destinataire, Ed25519 pour signer, et HKDF-SHA256 et PBKDF2-SHA256 pour dériver des clés. Le navigateur utilise WebCrypto, qui y est intégré, et l’agent la bibliothèque standard de Go. Les deux sont testés avec les mêmes vecteurs de test.

Si une copie de la base de données fuit, elle ne permet pas de deviner votre mot de passe : chaque tentative exige aussi votre Secret Key, qui n’a jamais été sur le serveur, et vérifier une seule tentative revient à explorer environ 2¹²⁸ possibilités. Les jetons ne sont stockés que sous forme de hachages à clé.

Dans la documentation : Emergency Kit et Secret Key · Code de récupération

Chaque environnement est scellé séparément

• Les organisations sont séparées par leurs propres clés. Un même serveur peut héberger de nombreuses organisations. Chacune a ses propres clés de signature et de récupération, et ses clés d’environnement ne sont scellées que pour les membres et les machines que cette organisation a certifiés.
• L’accès à development n’ouvre pas production. Chaque environnement a sa propre clé, et une personne qui n’a pas la clé de production ne peut pas lire production.
• Specific files veut dire : ces fichiers et rien d’autre. Une personne qui a ce rôle, ou une machine réglée sur Selected files, ne reçoit une copie scellée que des fichiers choisis.
• Les opérateurs configurent les machines sans voir les valeurs. Ils ne détiennent aucune clé d’environnement. Une personne qui détient la clé approuve l’accès de chaque machine.
• Les règles réseau limitent les destinations du contenu. Un environnement peut n’être servi qu’à des plages d’adresses IP autorisées, pour les personnes comme pour les machines et les jetons. L’assouplissement d’une règle attend 15 minutes, avec une alerte, sauf si un second administrateur le signe. Le durcissement s’applique aussitôt. C’est une règle appliquée par le serveur, pas du chiffrement.

Dans la documentation : Rôles dans les organisations et les environnements · Règles réseau

Ce que le serveur peut voir, et ce qu’il ne peut pas voir

Un serveur aveugle a tout de même besoin de quelques informations : à qui remettre les données chiffrées et quoi écrire dans le journal d’audit. En voici la liste complète.

Lisible par le serveur

• Les noms des organisations, projets, environnements, machines, jetons de service, profils d’accès et listes de réseaux
• Les noms et adresses e-mail des membres, et les adresses auxquelles partent les invitations
• Qui a quel rôle dans quel environnement, d’après la liste d’accès signée
• Pour chaque version : son numéro, qui l’a enregistrée, quand, et sa taille arrondie au multiple de 4 Ko supérieur
• Quelle version chaque personne, machine et jeton a reçue, quand et depuis quelle adresse IP
• Le journal d’audit, vos appareils et vos sessions, et les adresses IP qu’ils utilisent
• Vos règles réseau : les plages d’adresses IP que vous autorisez
• Le secret de votre application d’authentification, si vous en utilisez une. Le serveur vérifie vos codes : il stocke donc ce secret chiffré avec sa propre clé.

Données chiffrées uniquement

• Tout ce qui se trouve dans un environnement : noms et valeurs des variables, noms de fichiers, chemins, contenus et notes. Chaque version est un seul enregistrement chiffré de tout l’environnement : le serveur ne voit donc ni les variables une par une ni laquelle a changé.
• Les fichiers que vous envoyez par des liens de partage
• Les clés privées des comptes et de l’organisation

Jamais envoyé au serveur

• Votre mot de passe et votre Secret Key
• Votre code de récupération. Le serveur détient une copie de la clé de votre compte que seul ce code peut déchiffrer.
• Les clés privées des machines, créées sur chaque machine, où elles restent
• La clé d’un lien de partage, placée après le # que les navigateurs n’envoient pas
• Les jetons de service eux-mêmes. Le serveur ne connaît que leurs clés publiques.

Voilà ce que nous entendons par serveur aveugle : il voit qui et quand, mais rien de ce que contiennent vos environnements. Sur app.crunu.com, la liste de ce qui est lisible correspond exactement à ce que Crunu peut voir, et la Politique de confidentialité indique combien de temps nous le conservons. Ne mettez pas de secrets dans les noms : un projet nommé d’après un accord pas encore annoncé révèle cet accord au serveur, même si chaque valeur qu’il contient reste chiffrée.

Dans la documentation : Ce que voit le serveur

Qui peut lire vos secrets

• Les personnes à qui vous donnez accès. Les membres n’obtiennent que les environnements qui leur sont accordés. Masquer les valeurs dans l’application relève de l’affichage : quiconque peut déchiffrer une valeur peut la copier.
• Les propriétaires et les administrateurs. Ils détiennent la clé de récupération de l’organisation et peuvent donc ouvrir tous les environnements partagés. Ils peuvent aussi ouvrir les environnements personnels des membres tant que le réglage de l’organisation pour la récupération des environnements personnels est activé, ce qui est le cas par défaut.
• Les machines et la CI. Chaque machine et chaque jeton ne lit que ce qui lui a été accordé. Les codes d’enrôlement sont valables 15 minutes par défaut et sont brûlés dès leur première utilisation, et vous n’approuvez une machine qu’après avoir comparé l’empreinte que crunu enroll y affiche. Une machine révoquée efface ses environnements en quelques minutes tant qu’elle est en ligne.
• Pas le personnel de Crunu. Sur app.crunu.com, c’est Crunu qui exploite le serveur, et le serveur n’a aucune clé. Nous voyons les métadonnées décrites plus haut. Pour atteindre vos valeurs, il faudrait modifier le code qui s’exécute sur votre appareil, par exemple au moyen d’une page web modifiée. La page Limites connues explique ce risque.
• Quiconque tente d’entrer dans un compte. La connexion admet 10 échecs par adresse IP et 5 par compte sur 15 minutes, et une adresse e-mail inconnue obtient la même réponse qu’un mauvais mot de passe. Une fois un second facteur activé, un nouvel appareil l’exige : application d’authentification ou clé d’accès (passkey). Les sessions prennent fin après 12 heures d’inactivité et au bout de 7 jours au plus, et une session volée ne peut changer ni votre mot de passe, ni votre Secret Key, ni les clés de votre compte.

Dans la documentation : Machines et baux · Lier un jeton de service à la CI avec OIDC · Se connecter depuis le terminal

Comment les publications sont construites et vérifiées

• Chaque publication de l’agent crunu et de l’application web est signée avec une clé de publication Ed25519.
• Les publications de l’agent sont mises en ligne sur releases.crunu.com : binaires, paquets .deb, install.sh et un manifeste signé. Le script d’installation vérifie le SHA-256 du binaire de l’agent, et crunu self-update vérifie la signature de la publication avec une clé intégrée à l’agent. La commande d’installation affichée par l’application web contient les sommes de contrôle issues de la publication signée.
• Crunu publie le manifeste signé de l’application web sur app.crunu.com. Au chargement, l’application vérifie cette signature, compare son propre build au manifeste et affiche « Signed build » dans la barre latérale. Sélectionnez cette mention pour vérifier chaque fichier du site. Si quelque chose ne correspond pas, l’application vous demande de ne pas saisir votre mot de passe.
• Cette vérification s’exécute dans du code livré par ce même serveur. Elle repère un déploiement cassé ou dépareillé, mais pas un serveur qui modifie à la fois la page et la vérification.
• Le build de l’application web est reproductible : un même commit source produit toujours les mêmes fichiers. La page n’autorise aucun script tiers et charge son propre code avec des sommes de contrôle d’intégrité (CSP et SRI).
• Peu de dépendances : l’agent n’utilise que la bibliothèque standard de Go, et le code du navigateur ne comprend qu’un seul paquet npm, yaml.

Dans la documentation : Mettre à jour crunu avec self-update

Sauvegardes, disponibilité et réversibilité

• Sur app.crunu.com, la base de données conserve jusqu’à 30 jours d’historique de restauration chez Cloudflare. Pendant l’accès anticipé, nous ne promettons aucun niveau de disponibilité. Consultez les Conditions d’utilisation.
• Gardez votre propre copie. L’application peut télécharger une copie hors ligne de chaque environnement auquel vous avez accès. Elle s’ouvre avec votre mot de passe et votre Secret Key, sans aucun serveur. Les environnements restreints par réseau n’y figurent pas.
• Hébergez le serveur vous-même, ou changez de plateforme. Le même serveur tourne dans Docker sur votre propre machine, sur Cloudflare Workers, Vercel et Google Cloud Run, ainsi que sur AWS App Runner dans les comptes qui y ont encore accès. Une seule archive, sans aucune valeur en clair, le fait passer de l’une à l’autre, et cette même archive vous sert de sauvegarde. Voir la page Auto-hébergement.

Dans la documentation : Export et copie hors ligne · Sauvegardes et restauration

Ce qui est conservé, et combien de temps

• Versions. Chaque environnement conserve ses 100 dernières versions, dans la limite de 64 Mo. Restaurer une ancienne version l’enregistre comme une nouvelle.
• Journal d’audit. Les connexions, invitations, changements de rôle, versions enregistrées, rotations des clés, machines, jetons, liens de partage et requêtes refusées vont dans un journal dont les entrées forment une chaîne de hachage. Modifier, supprimer ou insérer une entrée rompt la chaîne, et « Verify integrity » le montre. Le journal est conservé 365 jours par défaut, et les propriétaires peuvent allonger cette durée. Les valeurs n’y apparaissent jamais, car le serveur ne les a pas.
• Registres de livraison et suppression. Le registre indiquant qui a reçu chaque version est conservé 90 jours après la dernière livraison de cette version, puis fusionné dans un récapitulatif. Supprimer votre compte exige votre mot de passe et votre Secret Key. Une organisation supprimée devient aussitôt indisponible, puis est effacée par lots peu après. La Politique de confidentialité donne le tableau complet.

Dans la documentation : Journal d’audit · Versions et historique

Si le serveur lui-même est compromis

Nous concevons Crunu pour le pire des cas : une base de données compromise, un exploitant malveillant ou un compte cloud détourné, après quoi le serveur peut répondre ce qu’il veut. Vos appareils vérifient ce qu’il envoie : même dans ce cas, il ne peut ni lire vos valeurs, ni s’ajouter comme destinataire, ni substituer une clé, ni modifier une version, ni renommer production, ni faire passer pour la vôtre une organisation de son cru, ni glisser une autre clé à l’arrivée d’un nouveau membre. Les applications et les agents retiennent aussi l’état le plus récent qu’ils ont accepté et refusent tout ce qui est plus ancien : une liste d’accès rejouée ne fait donc pas revenir une personne que vous avez retirée. Un appareil tout neuf n’a aucun point de comparaison : lors de sa première visite, il ne peut donc pas repérer un retour à un état antérieur.

Il peut en revanche encore refuser le service, lire les métadonnées et servir une page web modifiée. Des alertes signalent les connexions depuis de nouveaux appareils, les codes d’enrôlement réutilisés, les jetons CI rejoués et les refus répétés. Quand quelqu’un part, l’application renouvelle les clés que cette personne détenait et liste les valeurs à réémettre. Pour un appareil volé, l’action « Device compromised » remplace les clés de votre compte et renouvelle les clés de tous les environnements dont vous déteniez une clé.

Si nous apprenons qu’app.crunu.com a subi une intrusion, nous préviendrons par e-mail les titulaires des comptes concernés dans les meilleurs délais : ce qui s’est passé, quelles données sont en cause et que faire ensuite. Une intrusion dans le service expose des données chiffrées et des métadonnées, pas les valeurs de vos environnements, qui ne peuvent pas être déchiffrées sans votre mot de passe et votre Secret Key. La Politique de confidentialité prend le même engagement.

Dans la documentation : Gérer le départ d’un collègue · Renouveler les clés d’environnement · Alertes

Ce qui dépend de vous

Le chiffrement retire le serveur de la liste de ce qui peut lire vos secrets. Il reste quelques gestes que vous seul pouvez faire.

• Imprimez votre Emergency Kit à l’inscription et conservez-le loin de vos appareils. Personne, nous compris, ne peut réinitialiser votre mot de passe ni récupérer votre Secret Key.
• Créez un code de récupération et rangez-le à l’écart de l’Emergency Kit. Il ouvre votre compte après un délai d’attente, une heure par défaut, sans votre second facteur.
• Activez un second facteur et gardez un délai de verrouillage court. Par défaut, l’application oublie vos clés après 10 minutes d’inactivité.
• Ne donnez à chaque personne et à chaque machine que ce dont elle a besoin, et limitez le nombre de propriétaires et d’administrateurs.
• Quand quelqu’un part, réémettez chez chaque fournisseur les valeurs que cette personne a vues. La rotation protège les nouvelles versions, pas ce qu’elle a déjà vu.
• Si l’application affiche « Build signature doesn’t match: do not enter your password », ne le saisissez pas et prévenez votre administrateur.

Dans la documentation : Limites · Verrouillage et délai d’inactivité

Audits et documents

Crunu est récent et en accès anticipé. Nous ne détenons pas de certifications comme SOC 2 ou ISO 27001 et n’avons pas publié d’audit externe.

Ces documents décrivent la façon dont le service traite les données :

• Politique de confidentialité : ce que nous détenons, pourquoi et pendant combien de temps
• Sous-traitants : qui exploite le service avec nous, et où
• Conditions d’utilisation et Politique d’utilisation acceptable

Pour vos propres contrôles, les propriétaires et les administrateurs peuvent exporter le journal d’audit en JSONL et vérifier sa chaîne de hachage hors de Crunu. Quand quelqu’un part, le rapport d’exposition montre quelles versions de quels environnements la personne a reçues, quand et d’où, et vous pouvez le télécharger.

Signaler une vulnérabilité

Écrivez à security@crunu.com en indiquant les étapes pour reproduire le problème. Ne mettez aucun vrai secret dans votre signalement.

Pendant vos tests, merci de :

• ne tester que sur des comptes et des organisations que vous avez créés vous-même, ou avec l’autorisation de leurs propriétaires ;
• ne pas consulter ni conserver les données d’autrui, et nous prévenir si vous y accédez par accident ;
• ne pas mener de tests de déni de service, ne pas envoyer de spam et ne pas recourir à l’ingénierie sociale ;
• garder les analyses automatisées assez légères pour ne pas gêner les autres utilisateurs.

Nous accuserons réception de votre signalement et vous tiendrons au courant pendant que nous le traitons. Nous conviendrons avec vous d’une date de divulgation, normalement dans les 90 jours suivant votre signalement.

La Politique d’utilisation acceptable contient l’ensemble des règles, dont notre promesse de ne pas engager de poursuites contre une recherche menée de bonne foi. Le même contact figure dans security.txt.