Application web sécurisée de gestion de secrets, conçue pour le stockage chiffré de mots de passe, clés API, tokens, clés SSH, certificats, notes sécurisées et toute donnée sensible. Pensée pour les usages personnels et les équipes, elle offre une architecture de coffre-fort numérique avec chiffrement AES-256-GCM, authentification locale, SSO OIDC (Keycloak, Auth0, etc.), workspaces partagés, RBAC et audit complet.
État du projet : MVP fonctionnel et sécurisé, prêt pour un déploiement auto-hébergé via Docker.
- Ce que fait l'application
- Architecture rapide
- Prérequis
- Installation avec Docker
- Variables d'environnement
- Première utilisation
- SSO OIDC / Keycloak
- Reverse proxy
- Sauvegarde et restauration
- Sécurité
- Développement local
Sentinel Vault centralise la gestion de vos secrets sensibles dans une interface moderne et minimaliste, tout en gardant le contrôle total sur vos données.
-
Coffre personnel : chaque utilisateur dispose automatiquement d'un coffre privé, chiffré et isolé.
-
Workspaces partagés : créez des coffres d'équipe (Développement, Production, Client A, etc.) avec une isolation stricte des données.
-
Gestion des secrets : créez, modifiez, supprimez et consultez des secrets avec plusieurs templates (Login, API Key, Token, SSH Key, Database, Secure Note, Custom).
-
Chiffrement de bout en bout au repos : chaque secret est chiffré côté serveur avec AES-256-GCM via une clé de données unique par workspace (DEK), elle-même protégée par une clé maître.
-
Masquage des secrets : les valeurs sensibles restent masquées par défaut ; révélation et copie temporaire sur action explicite de l'utilisateur.
-
Générateur de secrets : générateur de mots de passe, Base64, HEX, UUID et API token, tous utilisant un générateur cryptographique sécurisé (CSPRNG).
-
Groupes (arborescence) : chaque coffre possède ses propres groupes imbriqués, avec fil d'Ariane, glisser vers un autre groupe, renommage, réordonnancement, déplacement en masse de secrets, et suppression récursive (les secrets partent en corbeille, jamais détruits). La hiérarchie d'une base KeePass importée est conservée à l'identique.
-
Organisation manuelle par glisser-déposer : réordonnez groupes et secrets à la souris (poignée dédiée), déposez un secret dans un groupe, imbriquez un groupe dans un autre, ou renvoyez un élément à la racine. Un groupe replié survolé 700 ms se déplie automatiquement, la liste défile pendant le drag, l'aperçu déplacé n'affiche que le nom (jamais une valeur), et chaque opération est atomique, versionnée (détection des réorganisations simultanées) et journalisée dans l'audit. Réservé aux rôles OWNER / ADMIN / EDITOR, revérifié côté serveur.
-
Recherche et organisation : recherche par nom, username, URL, description, tags et type ; favoris et tags.
-
RBAC : rôles par workspace (OWNER, ADMIN, EDITOR, VIEWER) avec permissions fines (création, lecture, révélation, copie, modification, suppression).
-
Audit logs : journalisation complète des actions sensibles (login/logout, création, modification, suppression, révélation, copie, etc.) sans jamais stocker les secrets en clair.
-
Administration : console
/adminpour le SUPER_ADMIN : gestion des utilisateurs, des workspaces d'équipe, des paramètres globaux, des logs d'audit et de la configuration OIDC. -
Blocage des inscriptions : dans l'administration, vous pouvez désactiver la création de nouveaux comptes et la connexion via Google.
-
Verrouillage automatique : inactivité configurable qui verrouille le coffre et redirige vers l'écran de connexion.
-
Authentification : email/mot de passe local (hachage scrypt) et SSO OIDC standard.
-
Mapping OIDC : synchronisez les groupes ou rôles de votre Identity Provider vers des workspaces et des rôles applicatifs.
- Frontend : React 19, TypeScript, TanStack Start, TanStack Router, Tailwind CSS v4, Radix UI.
- Backend : TanStack Start server functions (API interne) + routes API publiques (
/api/public/*) pour les webhooks, health checks et OIDC. - Base de données : PostgreSQL 17, accès direct via le driver
postgres.js. Aucune couche Supabase requise. - Authentification : sessions maison (cookie
vault_sessionhttpOnly, Secure, SameSite), mots de passe hachés en scrypt. - Chiffrement : envelope encryption avec AES-256-GCM. Une DEK par workspace est chiffrée par la clé maître
MASTER_ENCRYPTION_KEY(fournie en environnement, jamais en base). - Déploiement : image Docker multi-étapes (Bun pour le build, Node 22 Alpine pour le runtime) +
compose.yamlavec PostgreSQL.
Pour plus de détails sur le modèle de données, les menaces et les décisions de sécurité, voir le plan archivé dans .lovable/plan/.
- Docker et Docker Compose
- Un générateur de clé pour la master encryption key :
opensslou équivalent
- Cloner le dépôt
git clone <this-repository-url>
cd <repository-name>- Créer le fichier d'environnement
cp .env .env.local- Générer la clé maître de chiffrement (obligatoire)
openssl rand -hex 32Copiez la valeur dans .env :
MASTER_ENCRYPTION_KEY=votre_cle_32_octets_en_hex
POSTGRES_PASSWORD=un_mot_de_passe_fortAvertissement critique : sans cette clé, les secrets chiffrés existants deviennent définitivement indéchiffrables. Conservez-la dans un gestionnaire de secrets ou un coffre hors de ce serveur.
- Lancer l'application
docker compose up -d --build- Vérifier que les services sont prêts
docker compose ps
# Les deux services doivent être marqués "healthy"- Ouvrir l'application
http://localhost:3000
Lors du premier démarrage avec une base vierge, le schéma db/init.sql est appliqué automatiquement. Le premier compte créé via la page de connexion devient automatiquement SUPER_ADMIN et reçoit son coffre personnel.
# Voir les logs
docker compose logs -f app
# Redémarrer
docker compose restart
# Arrêter
docker compose down
# Arrêter et supprimer la base de données (attention : perte de données)
docker compose down -v| Variable | Obligatoire | Rôle |
|---|---|---|
MASTER_ENCRYPTION_KEY |
Oui | Clé maître AES-256-GCM. openssl rand -hex 32 |
POSTGRES_PASSWORD |
Oui | Mot de passe de la base PostgreSQL locale |
POSTGRES_USER |
Non | Utilisateur PostgreSQL (défaut : vault) |
POSTGRES_DB |
Non | Nom de la base (défaut : vault) |
APP_PORT |
Non | Port exposé sur l'hôte (défaut : 3000) |
DATABASE_URL |
Non | Chaîne complète pour un PostgreSQL externe (remplace le service db) |
- Appliquez le schéma sur votre base existante :
psql "$DATABASE_URL" -f db/init.sql- Renseignez
DATABASE_URLdans.env. - Supprimez le service
dbducompose.yaml(et ledepends_ondu serviceapp).
- Accédez à
http://localhost:3000. - Créez un compte via Sign up (tant que les inscriptions sont activées).
- Ce premier compte obtient le rôle
SUPER_ADMIN. - Depuis la console
/admin:- gérez les utilisateurs,
- créez des workspaces d'équipe,
- activez ou désactivez les inscriptions publiques,
- consultez les logs d'audit.
Les coffres personnels ne sont pas listés dans l'administration et ne peuvent pas être désactivés. Seuls les workspaces d'équipe peuvent être activés/désactivés par le SUPER_ADMIN.
- Créez un client confidential dans votre fournisseur OIDC avec l'URL de callback :
https://votre-domaine/api/public/oidc/callback
-
Dans Sentinel Vault : Administration → SSO / OIDC, renseignez :
- Issuer URL
- Client ID
- Client Secret (chiffré automatiquement avec la clé maître)
-
Configurez le mapping des groupes IdP vers les workspaces et rôles applicatifs dans Administration → OIDC Mapping.
En production, placez toujours l'application derrière un reverse proxy en TLS. Exemple avec Caddy :
vault.example.com {
reverse_proxy app:3000
encode zstd gzip
}Le cookie de session est marqué Secure : il nécessite donc du HTTPS pour être transmis par le navigateur. Les valeurs déchiffrées transitent entre le serveur et le navigateur lors des actions Reveal / Copy : chiffrez toujours ce canal avec TLS.
docker compose exec db pg_dump -U vault -Fc vault > backup-$(date +%F).dumpdocker compose exec -T db pg_restore -U vault -d vault --clean < backup-XXXX.dumpImportant : sauvegardez
MASTER_ENCRYPTION_KEYséparément. Un dump de la base sans cette clé ne permet pas de déchiffrer les secrets.
- Secrets chiffrés au repos : AES-256-GCM + envelope encryption.
- Pas de secret en clair dans la base, les logs, ou les réponses API.
- Authentification robuste : mots de passe hachés en scrypt, sessions opaques, cookies httpOnly Secure SameSite.
- Isolation des workspaces : vérifiée strictement côté serveur, jamais seulement côté client.
- Protection XSS / CSRF : headers de sécurité, validation stricte des entrées.
- Audit complet : toutes les actions sensibles sont journalisées avec timestamp, utilisateur, action et résultat.
Le mode Docker est la méthode recommandée pour faire tourner l'application en local avec PostgreSQL. Si vous souhaitez exécuter le code en dehors de Docker :
# Vous avez besoin de Bun ou Node.js + npm
npm i
npm run devNécessite une base PostgreSQL accessible et la variable DATABASE_URL configurée.
Built with Lovable.
Sentinel Vault importe des bases KeePass .kdbx (KDBX 3 et 4). Le fichier, le
mot de passe maître et le fichier clé sont déchiffrés uniquement dans le
navigateur et ne sont jamais envoyés au serveur ; les entrées sélectionnées sont
rechiffrées (AES-256-GCM) avant stockage. Voir docs/KEEPASS-IMPORT.md.