Sécurité et confidentialité
Vos secrets sont chiffrés là où vous êtes, pas là où nous sommes.
Les mots de passe, les clés de connexion, les éléments du coffre-fort et les identifiants de serveur sont chiffrés dans votre navigateur ou sur votre poste avant d’arriver chez nous. La plateforme stocke et transporte du texte chiffré; le fournisseur qui l’exploite n’est donc pas une partie capable de les lire. Lavawall® est conçu et exploité par ThreeShield, un cabinet d’audit de Calgary.
Commencer gratuitement, sans carte de crédit Voir les modules validés
Le principe
La plupart des plateformes chiffrent vos données sur leurs serveurs, ce qui signifie que le fournisseur détient toujours la clé. Lavawall est conçu à l’inverse pour ce qui compte le plus. Le secret est chiffré là où vous êtes, et seule la partie qui en a besoin (vous, votre poste ou votre serveur) détient ce qui l’ouvre. Un administrateur ayant un accès complet à notre base de données, à nos journaux et à nos disques lit du texte chiffré.
La même approche traverse le coffre-fort de mots de passe, le gestionnaire de secrets de serveur, la façon dont les identifiants parviennent à un poste, et la façon dont nous traitons le mot de passe de votre compte et vos clés de connexion. Voici chacun d’eux, en termes simples.
Où chaque secret est protégé
Le mot de passe de votre compte
La console ne reçoit jamais votre mot de passe. Votre navigateur en fait la preuve et n’envoie qu’un vérificateur, dont nous stockons une empreinte. Le mot de passe lui-même ne traverse jamais le réseau.
Vos clés de connexion
Les clés d’accès et les clés de sécurité gardent leur moitié privée sur l’appareil. Vous pouvez exiger une clé validée FIPS 140-3, la série YubiKey 5 FIPS (CMVP no 5291 (en anglais)), vérifiée à l’enregistrement et à chaque connexion.
Le coffre-fort de mots de passe
Chaque élément est chiffré dans votre navigateur, jusqu’aux adresses de sites Web et aux noms de dossiers. Nous stockons du texte chiffré. Voyez le gestionnaire de mots de passe.
Les identifiants de serveur
Le gestionnaire de secrets de serveur permet à un serveur Linux ou Windows d’aller chercher l’identifiant dont il a besoin, déchiffré sur ce serveur, jamais sur notre plateforme.
Les secrets envoyés à un poste
Quand un secret doit parvenir à un appareil, il est scellé dans votre navigateur et ouvert uniquement sur cet appareil. C’est ainsi que le déploiement de WireGuard traite les clés qu’il met en place.
Les sessions à distance
Une session de bureau à distance est protégée en transit par un module cryptographique validé FIPS 140-3, CMVP no 5247 (en anglais). Voyez le soutien à distance.
Le gestionnaire de secrets de serveur
Toute automatisation a besoin d’un identifiant quelque part : un mot de passe de base de données, une clé d’API, un compte de service. Trop souvent, ils se retrouvent en clair : codés en dur dans un script, dans une variable d’environnement ou collés dans un fichier de configuration. Le gestionnaire de secrets de serveur de Lavawall permet à un serveur Linux ou Windows d’extraire du coffre-fort exactement le secret dont il a besoin, sans personne au clavier et sans rien laisser traîner.
Le serveur est inscrit comme membre du coffre-fort et détient sa propre clé; le secret est donc déchiffré sur le serveur qui en a besoin, jamais sur notre plateforme. Renouvelez un identifiant une seule fois dans la console, et chaque serveur qui l’utilise prend le changement en compte. Vos scripts y accèdent depuis Go, PHP ou bash par un socket local, et vous décidez si le texte en clair est mis en cache pendant quelques secondes ou pas du tout, par entreprise, par serveur ou par secret.
Comment cela fonctionne
Le serveur est un membre du coffre-fort doté de sa propre clé ECDH P-256, et la clé de la collection est scellée sur sa moitié publique; la plateforme stocke et transporte donc du texte chiffré. La garde de la clé de l’hôte privilégie un TPM 2.0, puis un identifiant systemd, puis un fichier verrouillé. Le client Linux repose sur le Go Cryptographic Module, FIPS 140-3, CMVP no 5247 (en anglais). Les récupérations et les refus sont consignés dans la piste d’audit.
Modules validés et algorithmes approuvés
Il y a une vraie différence entre utiliser des algorithmes approuvés FIPS et passer par un module que le NIST a validé et auquel il a attribué un numéro de certificat. Nous gardons les deux bien distincts, et nous nommons les modules validés.
| Où cela s’applique | Module ou algorithmes | Norme |
|---|---|---|
| Agents, relais et client de secrets de serveur | Go Cryptographic Module v1.0.0, certificat no 5247 du CMVP (en anglais) | Module validé FIPS 140-3 |
| Clés de connexion de qualité FIPS | YubiKey 5 FIPS Series, certificat no 5291 du CMVP (en anglais) | Module validé FIPS 140-3 |
| Chiffrement dans le navigateur : coffre-fort, scellement des secrets, dérivation des mots de passe | AES-256-GCM, ECDH P-256, HKDF-SHA-256, PBKDF2-HMAC-SHA-256 | Algorithmes approuvés FIPS 140-3 |
Pour savoir comment cela se rattache à CJIS, HIPAA, PCI DSS et NIST 800-171, voyez la prise en charge de FIPS 140-3.
Ce que nous ne faisons délibérément pas
Certaines commodités offertes par d’autres plateformes ne sont possibles que parce que le fournisseur peut lire ce qu’il ne devrait pas. Nous les avons laissées de côté, et c’est justement le but.
Nous n’analysons pas, sur nos serveurs, les mots de passe de votre coffre-fort. Les vérifications de santé s’exécutent dans votre navigateur, sur votre propre coffre-fort.
Aucun administrateur n’a de bouton pour ouvrir l’élément de coffre-fort d’un utilisateur ou lire le secret d’un serveur. Il n’y a rien à construire, car la plateforme ne détient aucune clé.
Nous ne tenons pas d’index en clair des sites pour lesquels vous détenez des identifiants. La correspondance se fait sur votre appareil.
Résidence des données et responsabilité
Vos données et leur traitement par l’IA se déroulent au Canada par défaut, sur AWS à Montréal et à Calgary. La résidence aux États-Unis est offerte sur AWS en Oregon, avec AWS GovCloud et Microsoft GCC High pour le secteur public et les charges de travail réglementées, et d’autres régions sur demande. Voyez la résidence des données.
Les actions sensibles dans toute la plateforme sont consignées dans une piste d’audit à détection d’altération; « qui a fait cela, et quand » a donc une réponse qu’un évaluateur accepte. Le dossier de conformité se retrouve dans la même console grâce au module GRC.
Questions fréquentes
- Le personnel de Lavawall peut-il lire mes mots de passe, les éléments de mon coffre-fort ou les identifiants de mes serveurs?
- Non. Ces secrets sont chiffrés là où vous êtes, dans votre navigateur ou sur votre poste, avant d’arriver chez nous; la plateforme stocke donc et transporte du texte chiffré. Le fournisseur qui exploite la plateforme n’est pas une partie capable de les lire.
- Lavawall utilise-t-il la cryptographie FIPS 140-3?
- Les agents, le relais et le client de secrets de serveur reposent sur le Go Cryptographic Module, certificat no 5247 du CMVP du NIST (FIPS 140-3), et la connexion peut être exigée sur une clé validée FIPS 140-3, la série YubiKey 5 FIPS, certificat no 5291. Le chiffrement dans le navigateur utilise l’ensemble d’algorithmes approuvés par FIPS 140-3. Voyez la prise en charge de FIPS 140-3 pour savoir comment chaque élément s’intègre.
- Où mes données sont-elles hébergées?
- Au Canada par défaut, sur AWS à Montréal et à Calgary. La résidence aux États-Unis est offerte sur AWS en Oregon, avec AWS GovCloud et Microsoft GCC High pour le secteur public et les charges de travail réglementées, et d’autres régions sur demande. Voyez la résidence des données pour les détails.
- Qui a conçu Lavawall?
- ThreeShield Information Security Corporation, un cabinet d’audit de Calgary dont le personnel détient les titres CISSP et CISA. Les contrôles de sécurité qu’un évaluateur exige sont les valeurs par défaut, parce que les personnes qui ont conçu la plateforme siègent du même côté de la table que l’évaluateur.