Votre coffre Vaultwarden doit-il être accessible uniquement par VPN ? Trois conditions

La première connexion sur un téléphone de remplacement est le moment où un coffre accessible uniquement par VPN révèle son coût : l’application n’a pas de cache, le serveur se trouve derrière un tunnel et les identifiants du tunnel peuvent être dans le coffre que vous ne pouvez pas ouvrir. C’est une question de conception et non une panne, et il est moins coûteux d’y répondre avant le déploiement qu’après. Trois conditions décident si un coffre privé est praticable pour vos utilisateurs. Si l’une d’elles échoue, la bonne réponse est généralement une exposition plus étroite plutôt qu’un mur de VPN.

Condition 1 : vos utilisateurs atteignent le serveur dès le premier jour

Un nouvel appareil n’a ni cache, ni session, ni confiance. Il a besoin que le nom d’hôte du serveur soit résolu, d’une route pour l’atteindre et d’un profil VPN déjà installé avant que l’utilisateur tente de se connecter. Si l’un de ces trois éléments n’arrive qu’après la première connexion, le déploiement échoue au pire moment possible. Comptez combien d’étapes une nouvelle recrue doit accomplir avant de pouvoir ouvrir son coffre.

Un tunnel divisé convient souvent mieux ici : ne transportez que le point de terminaison du coffre et le chemin DNS dont il a besoin, et laissez le reste du trafic de l’utilisateur tranquille. C’est une décision de routage à prendre avec le propriétaire du VPN, et non la supposition que chaque client mobile respecte la même politique. Les deux familles d’adresses et le nom d’hôte du service doivent être cohérents avec ce choix.

Si les utilisateurs ne peuvent pas atteindre le serveur avant d’avoir des identifiants fonctionnels, cette condition échoue et le mur de VPN a la mauvaise forme.

Condition 2 : l’accès en cache est en lecture seule, et cela suffit

Les clients Bitwarden peuvent afficher un coffre déjà déverrouillé sans atteindre le serveur, et cette copie hors ligne est en lecture seule. Elle est utile pour lire un mot de passe pendant une panne ; ce n’est pas une nouvelle connexion et ce n’est pas de l’édition. Décidez si la lecture seule est acceptable pour vos utilisateurs avant de concevoir autour d’elle.

curl -sI https://vault.example.com/alive
openssl s_client -connect vault.example.com:443 -servername vault.example.com </dev/null

Verrouiller et se déconnecter sont deux états différents, et la différence compte ici. Un client verrouillé garde le coffre local chiffré et peut le déverrouiller à nouveau avec le mot de passe principal ou la biométrie ; la déconnexion supprime cette copie locale et exige le serveur. Si un script de support dit aux utilisateurs de se déconnecter puis de se reconnecter pour corriger un problème de synchronisation, il supprime aussi leur accès hors ligne. Vérifiez l’action d’expiration sur chaque client au lieu de supposer la valeur par défaut.

Une copie en cache n’est pas une sauvegarde. Elle vit sur un seul appareil, elle est liée à un seul compte et elle disparaît avec une déconnexion ou un effacement.

Condition 3 : la récupération ne passe pas par le coffre lui-même

Le cas circulaire est facile à construire par accident : l’identifiant VPN est stocké dans le coffre, le coffre est derrière le VPN et le seul appareil doté d’un cache est celui qui a été perdu. La récupération dépend alors d’un document ou d’une personne hors du système. Écrivez ce chemin d’amorçage et testez-le avec un compte récupérable avant que quiconque en ait besoin. Une procédure d’urgence que personne n’a pratiquée n’est qu’un espoir.

Testez la séquence de manière contrôlée : confirmez quels éléments existants restent lisibles hors ligne, rétablissez ensuite le chemin réseau et vérifiez qu’une nouvelle connexion et une synchronisation fonctionnent. Évitez de vous déconnecter de la seule copie en cache par expérience, sauf s’il existe un autre chemin de retour. Notez ce que vous avez observé, y compris la version du client.

Si la récupération exige le coffre, cette condition échoue. Le correctif est un chemin hors bande documenté, et non un avertissement plus fort dans le document d’intégration.

Ce que vous conservez dans tous les cas : HTTPS, sauvegardes et mises à jour

HTTPS reste en place même derrière le VPN. Il donne au service web une identité que le navigateur peut vérifier et maintient la connexion de l’application protégée indépendamment de l’endroit où le tunnel se termine. Un point de terminaison privé ne devrait pas apprendre aux utilisateurs à ignorer les avertissements de certificat, car cette habitude les suit sur les sites publics.

Les sauvegardes relèvent d’une discipline distincte de la disponibilité. Vaultwarden stocke ses données dans une base de données, et une copie cohérente prise pendant que le service est arrêté, ou une sauvegarde au niveau de la base, vaut mieux qu’un fichier copié depuis un processus en cours d’exécution. Gardez la copie hors de l’hôte du coffre et testez une restauration. Le matériel exporté du coffre a besoin de la même protection que l’original, car une exportation n’est pas chiffrée comme le stockage du serveur.

sqlite3 /data/db.sqlite3 ".backup '/backup/vault-2026-11-03.sqlite3'"
docker compose ps

Ensuite, gardez le serveur et les clients à jour. L’accès uniquement par VPN réduit l’exposition ; il ne rend pas inoffensive une implémentation vulnérable et ne protège pas un point de terminaison compromis. Les trois conditions décident du modèle d’accès, et la maintenance décide si ce modèle survit à l’année.