Tous les plans

Secrets chiffrés, toujours

Variables d'environnement chiffrées avec AES-256-GCM au repos. Séparation build-time et runtime. Opérations en masse. Deux modes d'édition. Vos secrets ne touchent jamais le disque en texte en clair.

Commencer gratuitement Sécurité

Conçu pour les équipes axées sur la sécurité

Stockage chiffré, accès basé sur les rôles et deux modes d'édition pour chaque flux de travail.

Chiffrement AES-256-GCM
Clé maître dérivée via PBKDF2 avec 100 000 itérations. Nonce aléatoire par fichier.
Build-time vs runtime
Marquez les variables comme disponibles pendant le build, l'exécution, ou les deux. Contrôle granulaire.
Deux modes d'édition
Éditeur clé-valeur pour l'édition structurée, éditeur .env brut pour le collage en masse.
URLs auto-générées
Chaînes de connexion aux bases de données générées automatiquement (postgres://user:pass@host:port/db).
Accès contrôlé par RBAC
Le lecteur ne peut pas voir les valeurs. Le développeur peut les révéler. L'administrateur peut les modifier. Contrôle basé sur les rôles.
Opérations en masse
Upsert de plusieurs variables en une seule requête PUT. Importez des fichiers .env entiers d'un coup.

Comment ça fonctionne

01

Ajouter des variables

Paires clé-valeur, collez le contenu d'un fichier .env, ou laissez sh0 auto-générer les chaînes de connexion à partir de vos bases de données.

02

Définir la portée

Choisissez si chaque variable est disponible au build-time, au runtime, ou les deux. Les variables de build-time sont injectées pendant docker build.

03

Chiffré au repos

AES-256-GCM avec nonce aléatoire par fichier. Vos secrets ne touchent jamais le disque en texte en clair. Le déchiffrement ne se fait qu'au moment de l'injection.

04

Injecté au déploiement

Les variables sont déchiffrées et injectées dans l'environnement du conteneur au runtime. Pas de fichiers .env dans les conteneurs.

Le pipeline de chiffrement

Variable ajoutée
Dérivation de clé PBKDF2
Chiffrement AES-256-GCM
Stockage chiffré
Déchiffré au déploiement

Le texte en clair n'existe qu'en mémoire lors de l'injection -- jamais écrit sur disque sans chiffrement

Tout ce dont vous avez besoin

Chiffrement AES-256-GCM

Chiffrement authentifié de qualité industrielle. Clé maître dérivée avec PBKDF2 (100 000 itérations). Nonce aléatoire par fichier avec dérivation par bloc.

Masqué par défaut

Les valeurs des variables sont masquées dans le tableau de bord. La révélation nécessite le rôle développeur ou supérieur. Aucune exposition accidentelle lors de partages d'écran.

Séparation build et runtime

Les variables de build-time sont disponibles pendant docker build. Les variables de runtime sont injectées dans le conteneur en cours d'exécution. Ou utilisez les deux.

Deux modes d'édition

Éditeur clé-valeur pour la gestion structurée. Éditeur .env brut pour coller des fichiers entiers. Basculez entre les deux librement.

Chaînes de connexion auto-générées

Déployez une base de données PostgreSQL, MySQL ou MongoDB et sh0 génère automatiquement l'URL de connexion. Un clic pour l'ajouter à votre application.

Contrôle d'accès RBAC

Le lecteur voit uniquement les noms des variables. Le développeur peut révéler les valeurs. L'administrateur peut créer, modifier et supprimer. Contrôle d'équipe granulaire.

L'ancienne méthode

  • x Fichiers .env sur le serveur en texte en clair
  • x Copier-coller entre environnements manuellement
  • x Pas de chiffrement -- toute personne avec un accès SSH peut lire
  • x Aucune piste d'audit de qui a changé quoi
  • x Committé accidentellement dans le contrôle de version
  • x URLs de base de données assemblées à la main

La méthode sh0

  • Chiffré AES-256-GCM au repos
  • Import en masse et portée par application
  • Contrôlé par RBAC : lecteur, développeur, administrateur
  • Masqué par défaut, la révélation nécessite une permission
  • Jamais committé -- géré dans le tableau de bord ou via l'API
  • URLs de connexion aux bases de données auto-générées

Questions et réponses

Quel algorithme de chiffrement est utilisé ? +
AES-256-GCM (Galois/Counter Mode) avec une clé maître dérivée en utilisant PBKDF2 avec 100 000 itérations. Chaque fichier reçoit un nonce aléatoire unique. C'est le même standard utilisé par les principaux fournisseurs cloud.
Qui peut voir les valeurs des variables ? +
Cela dépend de votre rôle. Les lecteurs peuvent voir les noms des variables mais pas les valeurs. Les développeurs peuvent révéler les valeurs. Les administrateurs ont un contrôle total incluant la création, la modification et la suppression. Tout accès est contrôlé côté serveur.
Comment migrer des fichiers .env existants ? +
Ouvrez l'éditeur .env brut dans le tableau de bord et collez le contenu de votre .env existant. sh0 l'analyse et crée des variables chiffrées pour chaque entrée. Vous pouvez également utiliser l'API avec une requête PUT pour un upsert en masse.
Y a-t-il une limite sur le nombre de variables ? +
Aucune limite stricte. Chaque application a son propre ensemble isolé de variables d'environnement. En pratique, la plupart des applications utilisent 10 à 50 variables, mais sh0 en gère des centaines sans problème.

Vos secrets méritent mieux que du texte en clair.

Chiffrement AES-256-GCM, contrôle d'accès basé sur les rôles, opérations en masse et URLs de base de données auto-générées. Inclus dans tous les plans.

Commencer gratuitement Sécurité