Czy twój sejf Vaultwarden powinien być dostępny tylko przez VPN? Trzy warunki

Pierwsze logowanie na telefonie zastępczym to moment, w którym sejf dostępny tylko przez VPN pokazuje swój koszt: aplikacja nie ma pamięci podręcznej, serwer stoi za tunelem, a dane logowania do tunelu mogą znajdować się w sejfie, którego nie możesz otworzyć. To pytanie projektowe, a nie awaria, i taniej jest odpowiedzieć na nie przed wdrożeniem niż po nim. Trzy warunki decydują, czy prywatny sejf jest praktyczny dla twoich użytkowników. Jeśli któryś zawiedzie, właściwą odpowiedzią jest zwykle węższe wystawienie, a nie mur VPN.

Warunek 1: twoi użytkownicy docierają do serwera pierwszego dnia

Nowe urządzenie nie ma pamięci podręcznej, sesji ani zaufania. Potrzebuje rozwiązanej nazwy hosta serwera, trasy do niego oraz profilu VPN zainstalowanego, zanim użytkownik spróbuje się zalogować. Jeśli któryś z tych trzech elementów pojawi się dopiero po pierwszym logowaniu, wdrożenie zawiedzie w najgorszym możliwym momencie. Policz, ile kroków musi wykonać nowy pracownik, zanim otworzy swój sejf.

Tunel dzielony często pasuje tu lepiej: przenoś tylko punkt końcowy sejfu i potrzebną mu ścieżkę DNS, a resztę ruchu użytkownika zostaw w spokoju. To decyzja o trasowaniu podejmowana z właścicielem VPN, a nie założenie, że każdy klient mobilny przestrzega tej samej polityki. Obie rodziny adresów i nazwa hosta usługi muszą być zgodne z tym wyborem.

Jeśli użytkownicy nie mogą dotrzeć do serwera, zanim mają działające dane logowania, ten warunek zawodzi, a mur VPN ma zły kształt.

Warunek 2: dostęp z pamięci podręcznej jest tylko do odczytu, i to wystarcza

Klienci Bitwarden mogą pokazać już odblokowany sejf bez łączenia się z serwerem, a ta kopia offline jest tylko do odczytu. Przydaje się do odczytania hasła podczas awarii; to nie jest nowe logowanie ani edycja. Zdecyduj, czy tylko odczyt jest akceptowalny dla twoich użytkowników, zanim zaprojektujesz wokół tego.

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

Blokada i wylogowanie to różne stany, a różnica ma tu znaczenie. Zablokowany klient trzyma lokalny sejf zaszyfrowany i może go ponownie odblokować hasłem głównym lub biometrią; wylogowanie usuwa tę lokalną kopię i wymaga serwera. Jeśli skrypt wsparcia każe użytkownikom wylogować się i zalogować ponownie, aby naprawić problem z synchronizacją, usuwa to również ich dostęp offline. Sprawdź działanie limitu czasu w każdym kliencie, zamiast zakładać wartość domyślną.

Kopia w pamięci podręcznej nie jest kopią zapasową. Żyje na jednym urządzeniu, jest powiązana z jednym kontem i znika przy wylogowaniu lub czyszczeniu.

Warunek 3: odzyskiwanie nie przebiega przez sam sejf

Przypadek cykliczny łatwo zbudować przez pomyłkę: dane logowania VPN są w sejfie, sejf jest za VPN, a jedynym urządzeniem z pamięcią podręczną jest to, które zginęło. Wtedy odzyskiwanie zależy od dokumentu lub osoby spoza systemu. Zapisz tę ścieżkę uruchamiania i przetestuj ją na koncie, które można odzyskać, zanim ktoś będzie jej potrzebował. Procedura awaryjna, której nikt nie ćwiczył, jest tylko nadzieją.

Przetestuj sekwencję w kontrolowany sposób: potwierdź, które istniejące elementy pozostają czytelne offline, następnie przywróć ścieżkę sieciową i sprawdź, czy nowe logowanie i synchronizacja działają. Unikaj wylogowania z jedynej kopii w pamięci podręcznej jako eksperymentu, chyba że istnieje inna droga powrotna. Zapisz, co zaobserwowałeś, wraz z wersją klienta.

Jeśli odzyskiwanie wymaga sejfu, ten warunek zawodzi. Rozwiązaniem jest udokumentowana ścieżka poza pasmem, a nie ostrzejsze ostrzeżenie w dokumencie wdrożeniowym.

Co zachowujesz w każdym razie: HTTPS, kopie zapasowe i aktualizacje

HTTPS pozostaje na miejscu nawet za VPN. Daje usłudze internetowej tożsamość, którą przeglądarka może sprawdzić, i utrzymuje połączenie aplikacji chronione niezależnie od tego, gdzie kończy się tunel. Prywatny punkt końcowy nie powinien uczyć użytkowników omijania ostrzeżeń o certyfikatach, bo ten nawyk podąża za nimi na publiczne witryny.

Kopie zapasowe to odrębna dyscyplina od dostępności. Vaultwarden przechowuje dane w bazie danych, a spójna kopia wykonana przy zatrzymanej usłudze albo kopia zapasowa na poziomie bazy jest warta więcej niż plik skopiowany z działającego procesu. Trzymaj kopię poza hostem sejfu i przetestuj odtworzenie. Wyeksportowany materiał sejfu wymaga takiej samej ochrony jak oryginał, ponieważ eksport nie jest szyfrowany tak jak magazyn serwera.

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

Następnie utrzymuj serwer i klientów w aktualnym stanie. Dostęp tylko przez VPN zmniejsza ekspozycję; nie czyni podatnej implementacji nieszkodliwą i nie chroni przejętego punktu końcowego. Trzy warunki decydują o modelu dostępu, a konserwacja decyduje, czy ten model przetrwa rok.