SecurSSH est une plateforme d'accès SSH d'équipe hébergée en UE, bâtie sur le chiffrement de bout en bout AES-GCM, une dérivation de clé PBKDF2 100k côté client, le droit à l'effacement RGPD et un journal d'audit de 24 mois sur le plan Team. Cette page documente ce que nous livrons aujourd'hui - et, avec la même honnêteté, ce que nous ne livrons pas encore.
La confidentialité du coffre ne dépend pas de la confiance accordée à l'équipe d'exploitation SecurSSH. Chaque secret est chiffré sur l'appareil de l'opérateur avec une clé que le serveur ne voit jamais. Une compromission de notre infrastructure expose du ciphertext, pas des identifiants.
Chaque identifiant, enregistrement d'hôte et snippet dans votre coffre est chiffré côté client en AES-GCM. Le serveur SecurSSH ne stocke que du ciphertext - votre mot de passe maître et les clés dérivées ne quittent jamais votre appareil, si bien que les opérateurs du serveur ne voient que des blobs opaques.
Votre mot de passe maître est étiré via PBKDF2 avec 100 000 itérations sur votre appareil, produisant la clé de chiffrement qui protège le coffre. Après déverrouillage, la biométrie (Touch ID, Face ID, Windows Hello) met en cache localement le déchiffrement - jamais le mot de passe lui-même.
Les coffres d'équipe utilisent une clé de contenu partagée, enveloppée individuellement pour chaque membre avec sa propre clé dérivée. L'ajout ou le retrait d'un coéquipier ré-enveloppe l'accès sans rechiffrer le contenu. Le serveur reste à tout moment aveugle à la clé déchiffrée.
SecurSSH opère entièrement à l'intérieur de l'Espace économique européen. Données de coffres, enregistrements d'audit, sauvegardes et métadonnées de compte restent sous juridiction UE, traités par un fournisseur basé en UE sur une infrastructure située en UE.
Toutes les données de coffres, enregistrements d'audit et métadonnées de compte sont stockés et traités exclusivement sur une infrastructure de l'Union européenne. Aucune réplication vers les États-Unis ni sous-traitant opérant hors de l'EEE.
Les applications natives pour macOS, Windows et Linux sont signées et notariées. Les mises à jour automatiques vérifient les signatures avant installation, de sorte que le binaire exécuté sur les postes des opérateurs est de manière prouvable celui publié par SecurSSH.
L'hébergement s'appuie sur un fournisseur cloud basé en UE, avec des centres de données à Francfort et Amsterdam. Les sauvegardes restent dans la même juridiction et sont chiffrées au repos.
Aucune donnée personnelle ne transite vers les États-Unis : l'incertitude juridique soulevée par l'arrêt SCHREMS II contre les transferts US ne s'applique pas. Les clients UE restent sous un régime juridique unique et prévisible.
La conformité est traitée comme de l'ingénierie, pas comme de la paperasse plaquée après coup. La minimisation des données, le droit à l'effacement et la responsabilité du traitement sont câblés dans le comportement du produit, et la documentation formelle suit le même chemin.
Les titulaires de compte déclenchent une suppression en un clic qui retire données de profil, contenu du coffre et appartenance d'équipe. L'article 17 du RGPD est honoré par conception, pas par ticket.
Les clients Team et Enterprise reçoivent sur demande un Data Processing Agreement signé, listant sous-traitants, durées de conservation et mesures de sécurité alignées sur l'article 28.
Un registre formel des traitements au sens de l'article 30 est en cours de finalisation pour 2026. Le DPA documente déjà le fond ; le registre publiera une référence stable et versionnée.
Pour les secteurs régulés, nous collaborons avec le DPO du client pour cartographier les flux de données, documenter les bases légales et préparer les éléments d'une AIPD.
Chaque changement sensible à l'intérieur d'un espace de travail d'équipe est enregistré dans un journal d'audit. Les plans Team conservent 24 mois d'historique ; les contrats Enterprise le conservent indéfiniment. Les enregistrements sont interrogeables depuis la console d'équipe, sans intervention d'ingénierie.
L'autorisation est en couches. Le RBAC régit qui peut voir et modifier quoi ; le verrouillage du coffre régit la façon dont un identifiant quitte le repos. Les deux sont appliqués à la frontière, pas délégués au système d'exploitation.
Les rôles admin, membre et viewer sont appliqués côté client et côté serveur. Les viewers peuvent se connecter sans droits d'écriture sur les identifiants ; les admins gèrent l'appartenance et l'accès à l'audit.
Touch ID, Face ID et Windows Hello déverrouillent une clé mise en cache localement, pas le mot de passe maître. Les données biométriques ne quittent jamais l'enclave sécurisée de l'appareil.
Les opérateurs choisissent la fenêtre d'inactivité après laquelle le coffre se reverrouille. L'accès suivant nécessite à nouveau biométrie ou mot de passe maître - aucune persistance silencieuse.
Des coffres distincts par projet, client ou environnement limitent la surface d'exposition. L'appartenance est accordée par coffre, si bien qu'un prestataire peut accéder à une mission sans voir le reste.
La transparence prime sur une liste de fonctionnalités plus longue. Les éléments ci-dessous sont sur la roadmap 2026 et ne doivent pas être supposés disponibles aujourd'hui. CTO et CISO en validation de SecurSSH doivent les comparer à leurs exigences internes actuelles.
La divulgation coordonnée est la bienvenue. Écrivez à security@securssh.com avec un détail technique et un chemin de reproduction. Nous accusons réception sous un jour ouvré et engageons une coopération de bonne foi avec les chercheurs opérant sous notre politique de divulgation de vulnérabilités.
Vault content is encrypted client-side using AES-GCM with a key derived from your master password through PBKDF2 with 100,000 iterations. The server only ever stores ciphertext and never receives your master password or derived encryption key.
Nobody. Because key derivation happens on your device and the server is blind to plaintext, SecurSSH staff cannot decrypt vault content. For team vaults, the team key is wrapped per member, so only invited members can unwrap it.
Your vault content is end-to-end encrypted and stored in the European Union.
An attacker who reached the database would only obtain ciphertext. Without your master password, AES-GCM vault content remains unreadable. We would notify customers under GDPR Article 33 within 72 hours of confirmed breach.
Parcourez l'architecture avec nos ingénieurs sécurité, demandez un DPA signé, ou lisez la roadmap produit complète couvrant les fonctionnalités livrées, partielles et à venir.