Vaultwarden Güvenli mi? Güvenlik Sıkılaştırma Rehberi

Vaultwarden güvenli mi? Kısa cevap

Vaultwarden, en önemli noktada güvenlidir; çünkü her kasa öğesi sunucuya ulaşmadan önce cihazınızda şifrelenir. Sunucu, içeriğini okuyamadığı veri bloklarını saklar. Veritabanının tamamını kopyalayan bir kişi, anlamlı bir veriye ulaşmak için yine de ana parolaya ihtiyaç duyar.

Bu cevap oldukça kapsamlıdır ve sistemin zayıf noktaları sizin yapılandırdığınız kısımlardır. Tahmin edilebilir bir token ile korunan yönetim paneli, internete açık bırakılmış bir container portu, düz metin halindeki bir config.json veya ana dizinde unutulmuş bir yedekleme arşivi buna örnektir. Bunların hiçbiri kriptografi sorunu değildir. Ancak tüm bunlar, self-hosted kasaların boşaltılmasının temel nedenleridir.

Aşağıdaki her şey, çalışan bir kurulum varsayar. Henüz bir kurulumunuz yoksa, önce VPS için Vaultwarden kurulum rehberi ile kurulumu tamamlayın, ardından bu listeyi sırasıyla uygulayın.

Sunucunun aslında ne depoladığı

Vaultwarden, Bitwarden'ın veri modelini uygular. Bir kasa öğesinin adı, kullanıcı adı, parolası, notları ve URI'leri, herhangi bir istek gönderilmeden önce istemci tarafında ana parolanızdan türetilen bir anahtarla şifrelenir. Ek dosya içerikleri de aynı şekilde şifrelenir. Sunucu, kendisine eklenmiş bir UUID (evrensel benzersiz tanımlayıcı) ile birlikte opak veriler alır.

Bazı veriler şifreli metin değildir ve tam olarak hangilerinin şifreli olmadığını bilmeniz gerekir:

• Hesap e-posta adresiniz, düz metin olarak.
• KDF (anahtar türetme işlevi) ayarlarınız ve salt değeriniz; çünkü istemcinin bir sonraki girişte anahtarı yeniden oluşturmak için bunlara ihtiyacı vardır.
• İstemcinin gönderdiği ana parola özetinin sunucu tarafındaki bir özeti; giriş işleminin kendisini doğrulamak için kullanılır.
• Üst veriler: organizasyon üyeliği, cihaz adları, son giriş zamanları.
• Vaultwarden girişini koruyan iki faktörlü kimlik doğrulama yönteminin gizli anahtarı. Bu veri twofactor tablosunda şifrelenmemiş olarak tutulur, çünkü sunucunun sizin kodunuzla karşılaştırmak için beklenen kodu hesaplaması gerekir. Bu, bir kasa öğesinin içinde sakladığınız ve diğer tüm alanlar gibi şifrelenmiş olan TOTP (zamana dayalı tek kullanımlık parola) gizli anahtarı ile aynı şey değildir.

Veri klasörü küçüktür. Docker kurulumunda bu, /data dizinine bağladığınız klasördür.

sudo ls -l /vw-data/

db.sqlite3 neredeyse tüm durumu tutar. attachments/, UUID başına bir tane olacak şekilde yüklenen dosyaları tutar ve veritabanı tablolarında bulunmayan tek önemli veri sınıfıdır. sends/, Send eklerini tutar ve geçici olması amaçlanmıştır. icon_cache/ atılabilir verilerdir. rsa_key.pem ve eşlik eden dosyalar, giriş yapmış kullanıcıların JWT'lerini (JSON web belirteçleri) imzalar; bu nedenle bu özel anahtarın bir kopyası, bir kasa giriş oturumunu taklit etmek için kullanılabilir. config.json yalnızca yönetici sayfasını etkinleştirdiğinizde oluşur ve proje bu konuda nettir: yönetici belirtecini ve SMTP kimlik bilgilerinizi düz metin olarak tutar.

Bu nedenle pratik tehdit modeli ağ şifrelemesi değil, dosya sistemi erişimidir. O dizine okuma erişimi; her kullanıcının e-posta adresini, giriş 2FA gizli anahtarlarını, oturumları taklit eden bir anahtarı ve boş zamanlarda saldırılmak üzere her kasanın çevrimdışı bir kopyasını ele geçirmenize olanak tanır. Aşağıdaki her adım, kişileri bu dizinden uzak tutmak için mevcuttur.

Önce yönetici token'ını düzeltin

/admin; kullanıcı listesi, davetiyeler, silme işlemleri ve tüm çalışma zamanı ayarlarını içeren tam kapsamlı bir kontrol panelidir. Bu panel, tek bir paylaşılan gizli anahtar ile korunur; başka hiçbir doğrulama yöntemi yoktur. Kullanıcı adı veya kullanıcı bazlı iki faktörlü doğrulama bulunmaz.

Eski kılavuzlar, ADMIN_TOKEN değerini openssl rand -base64 48 ile oluşturmanızı önerir. Bu yöntem çalışır ve gizli anahtarı düz metin olarak config.json dosyasına ve compose dosyanıza yazar. Vaultwarden, Argon2 PHC (password hashing competition) dizgilerini de kabul eder; bu sayede saklanan değer bir hash haline gelir. Çalışan bir container üzerinde hash oluşturmak için:

docker exec -it vaultwarden /vaultwarden hash

Veya çalışan container'a hiç dokunmadan:

docker run --rm -it vaultwarden/server /vaultwarden hash

Sistem sizden iki kez parola ister ve ardından $argon2id$ ile başlayan bir satır çıktısı verir. Bare-metal kurulumlarda ./vaultwarden hash komutunu çalıştırın. Eğer doğrudan argon2 CLI aracını kullanmak isterseniz, proje dokümantasyonunda belirtilen OWASP minimum parametrelerini kullanın:

echo -n 'MySecretPassword' | argon2 "$(openssl rand -base64 32)" -e -id -k 19456 -t 2 -p 1

Şimdi ise kullanıcıların saatlerini kaybetmesine neden olan tuzağa gelelim. Bir PHC dizgisi çok sayıda $ karakteri içerir ve Docker Compose, $ karakterini değişken enterpolasyonu (variable interpolation) olarak işler. Bu değeri kaçış karakteri kullanmadan bir environment: bloğuna yapıştırırsanız, container'a ulaşan değer bozulur ve /admin doğru olduğunu bildiğiniz token'ı reddeder. İki güvenli yöntem mevcuttur. docker-compose.yml içerisinde, her $ karakterini ikiye katlayın:

environment:
  ADMIN_TOKEN: $$argon2id$$v=19$$m=19456,t=2,p=1$$UUZxK1FZMkZoRHFQRlVrTXZvS0E3bHpNQW55c2dBN2NORzdsa0Nxd1JhND0$$cUoId+JBUsJutlG4rfDZayExfjq4TCt48aBc9qsc3UI

Bir .env dosyasında kaçış karakterine gerek yoktur, ancak tek tırnak kullanın:

ADMIN_TOKEN='$argon2id$v=19$m=65540,t=3,p=4$MmeKRnGK5RW5mJS7h3TOL89GrpLPXJPAtTK8FTqj9HM$DqsstvoSAETl9YhnsXbf43WeaUwJC6JhViIvuPoig78'

Ardından panel için hız sınırlaması (rate limit) uygulayın ve oturum süresini kısaltın:

ADMIN_RATELIMIT_SECONDS=300
ADMIN_RATELIMIT_MAX_BURST=3
ADMIN_SESSION_LIFETIME=20

Beş dakika içinde üç hatalı deneme yapıldığında panel, ilgili istemciye yanıt vermeyi durdurur. Yönetici oturumu, paneli kullanmaya devam edip etmediğinize bakılmaksızın giriş yaptıktan 20 dakika sonra sona erer; etkinlik süreyi uzatmaz.

Tüm bunlardan daha iyi bir yöntem ise sayfayı tamamen kapatmaktır. Çoğu kurulumda bu sayfaya yalnızca SMTP ayarlarını yapılandırmak ve ilk kullanıcıları davet etmek için bir kez ihtiyaç duyulur, sonrasında gerek kalmaz. Sayfayı devre dışı bırakmak için ADMIN_TOKEN veya DISABLE_ADMIN_TOKEN değerlerini boş bırakın, config.json dosyasındaki tüm "admin_token" anahtarlarını kaldırın ve ardından container'ı yeniden oluşturun. Anahtarı dosyadan silmek önemlidir çünkü yönetici sayfası ayarları oraya yazar ve config.json içindeki değer, ortam değişkenlerine göre önceliklidir. Yalnızca değişkeni kaldırmak, sayfanın açık kalmasına neden olur.

Kimse alan adını bulmadan kayıtları kapatın

SIGNUPS_ALLOWED=false
SIGNUPS_VERIFY=true
SHOW_PASSWORD_HINT=false

SIGNUPS_ALLOWED varsayılan olarak true değerindedir. Bu şekilde bırakırsanız alan adınıza ulaşan herkes bir hesap oluşturabilir ve verileri sizinkiyle aynı db.sqlite3 içinde tutulur. Bu ayarı false olarak değiştirin ve kullanıcıları, SMTP yapılandırması gerektiren yönetici sayfasındaki davetiyeler aracılığıyla ekleyin. INVITATIONS_ALLOWED de varsayılan olarak true durumundadır ve organizasyon yöneticilerinin başkalarını davet etmesine olanak tanır. Kullanıcılarınıza güvendiğiniz durumlarda bu uygundur; ancak tek kullanıcılı bir kurulumda false olarak ayarlanmalıdır. Yalnızca belirli alan adlarından kayıt alınması isteniyorsa, SIGNUPS_DOMAINS_WHITELIST=example.com seçeneği açık kayıttan daha kısıtlayıcıdır ancak davetiye sistemine göre çok daha zayıf bir güvenlik sağlar.

SHOW_PASSWORD_HINT varsayılan olarak false durumundadır ve bu şekilde bırakılmalıdır. Bu özellik açıkken ve SMTP yapılandırılmamışken, giriş formuna geçerli bir e-posta adresi yazıldığında o hesabın ana parola ipucu görüntülenir; bu durum hem ipucunun sızmasına hem de e-posta adresinin sistemde kayıtlı olduğunun doğrulanmasına neden olur.

Eğer kurulumunuz bir süre boyunca kayıt işlemlerine açık kaldıysa, tek kullanıcının siz olduğunuzu varsaymadan önce yönetici sayfasını açın ve kullanıcı listesini kontrol edin.

İstemeden dışarı açtığınız port

Docker imajı, container içerisinde 80 numaralı portu dinler. Çıplak metal (bare-metal) kurulumlarda varsayılan değer ROCKET_PORT=8000 şeklindedir. Belgelenmiş çalıştırma komutu, portu şu şekilde dışarı açar:

--publish 127.0.0.1:8000:80

127.0.0.1: ön eki, tüm meselenin özüdür. Bunun yerine -p 8000:80 yazarsanız Docker, 0.0.0.0 adresine bağlanır ve bunu nat tablosuna DNAT (hedef ağ adresi çevirisi) kuralları yazarak yapar. Bu kurallar, ufw tarafından yönetilen filter zincirlerinden önce değerlendirilir; bu nedenle ufw status portu engellenmiş olarak raporlasa da port internete yanıt vermeye devam eder. Mekanizmanın tamamını Docker portlarının ufw'yi atlamasına dair kılavuz içerisinde okumak faydalıdır.

Gerçekte neyin dinlendiğini kontrol edin:

sudo ss -tlnp | grep 8000

Sağlıklı bir sonuç, yalnızca 127.0.0.1:8000 adresine bağlı tek bir satırdır. 0.0.0.0:8000 adresine bağlı bir satır, kasanın doğrudan dışarı açık olduğu anlamına gelir. Eşleştirmeyi düzeltin ve ardından container'ı yeniden oluşturun; çünkü port bağlama işlemi container oluşturulduğu anda sabitlenir ve docker compose restart bunu değiştirmeyecektir:

docker compose up -d --force-recreate

Eski kılavuzlarda bir port daha varlığını sürdürmektedir: 3012 numaralı ayrı WebSocket portu. Bildirim trafiği ana HTTP portuna taşındığı için bu porta verilen destek Vaultwarden 1.31.0 sürümünde kaldırılmıştır. WEBSOCKET_ENABLED ve WEBSOCKET_PORT değişkenleri 1.29.0 sürümünden beri kullanımdan kaldırılmıştır ve göz ardı edilirler. Mevcut anahtar ENABLE_WEBSOCKET olup varsayılan değeri true şeklindedir. Güvenlik duvarınız veya compose dosyanız hala 3012 numaralı portu açıyorsa, bu portu kapatın.

TLS termination işlemini Rocket yerine reverse proxy katmanında yapın

Vaultwarden, web çatısı olan Rocket aracılığıyla TLS (transport layer security) hizmetini kendisi sunabilir; ancak proje, üretim ortamlarında bunun yapılmamasını tavsiye eder. Rocket'in yerleşik TLS desteği, katı SNI (server name indication) desteğinden yoksundur. Bu nedenle, hardening tavsiyeleri arasında örneğinize hiçbir zaman çıplak IP adresi ile değil, her zaman ana makine adı (hostname) ile erişmeniz gerektiği belirtilir. Genel IP aralıkları sürekli taranır; IP adresi üzerinden yanıt veren bir kasa, kolayca tespit edilen bir kasadır.

Bir nginx sunucu bloğunda önemli olan kısımlar şunlardır:

client_max_body_size 525M;

location / {
  proxy_pass http://127.0.0.1:8000;
  proxy_set_header Host $host;
  proxy_set_header X-Real-IP $remote_addr;
  proxy_set_header X-Forwarded-For $proxy_add_x_forwarded_for;
  proxy_set_header X-Forwarded-Proto $scheme;
  proxy_set_header Upgrade $http_upgrade;
  proxy_set_header Connection $connection_upgrade;
}

nginx varsayılan olarak client_max_body_size değerini 1 MB olarak ayarlar; bu nedenle ilgili satır olmazsa, ek yükleme işlemleri nginx hata günlüğünde 413 Request Entity Too Large hatasıyla başarısız olur ve Vaultwarden günlüklerinde hiçbir kayıt oluşmaz. Upgrade ve Connection başlıkları, WebSocket el sıkışmasını /notifications/hub adresine taşır. Bu başlıkları kaldırırsanız kasa çalışmaya devam eder ancak sayfayı manuel olarak yenileyene kadar diğer cihazlarınızdaki değişiklikler güncellenmez.

Caddy kullanımı daha kısadır ve sertifikayı kendi başına alır:

vw.example.com {
  reverse_proxy 127.0.0.1:8000 {
    header_up X-Real-IP {remote_host}
  }
}

Ardından bu durumu Vaultwarden'a bildirin:

DOMAIN=https://vw.example.com
IP_HEADER=X-Real-IP

IP_HEADER zaten varsayılan olarak X-Real-IP değerindedir; bu nedenle yapılması gereken, proxy'nin bu başlığı doğru ayarladığından emin olmaktır. Vaultwarden ayrıca bu başlığı yalnızca IP_HEADER_TRUSTED_PROXIES içinde listelenen adreslerden kabul eder; bu değer varsayılan olarak local şeklindedir: yani aynı ana makinede veya aynı Docker ağında bulunan bir proxy'yi kapsayan tüm yerel (global olmayan) adresler. Genel bir adresten bağlanan bir proxy'nin buraya eklenmesi gerekir. Başlık eksikse veya güvenilmeyen bir adresten geliyorsa, her günlük satırı ve her giriş hızı sınırlaması (login rate limit), proxy'nin kendi adresini görür. Bu durum, bir saldırganın başarısız denemelerinin örnekteki tüm kullanıcılar için sayılmasına neden olur. Eğer bunun yerine IP_HEADER=X-Forwarded-For kullanırsanız, 1.37.4 sürümü güvenilir bir proxy olmayan en sağdaki adresi alır; bu nedenle nginx önündeki bir CDN dahil olmak üzere zincirdeki tüm proxy'leri listeleyin. Ayrıca DOMAIN değerini gerçek https URL'si olarak ayarlayın; çünkü Vaultwarden davet ve parola sıfırlama bağlantılarını bu adrese göre oluşturur ve WebAuthn güvenlik anahtarları bu orijine bağlanır.

İnsanların gözden kaçırdığı bir detay: WebSocket bağlantısı, oturum belirtecini (session token) sorgu dizisinde /notifications/hub?access_token=[JWT] olarak iletir. Bu veri, proxy erişim günlüğünüze açık metin olarak düşer. Günlük formatında access_token parametresini gizleyin veya bu günlüklerin kontrolünüz altında olmayan hiçbir yere gönderilmediğinden emin olun.

Giriş uç noktasında kaba kuvvet saldırılarını engelleme

Hız sınırlamaları varsayılan olarak etkindir (LOGIN_RATELIMIT_SECONDS=60, LOGIN_RATELIMIT_MAX_BURST=10). Bu sınırlamalar saldırganı yavaşlatır ancak durdurmaz. fail2ban saldırganı durdurur ancak bunun için Vaultwarden'ın başarısız giriş denemelerini okuyabileceği bir yere yazması gerekir. Docker ortamında en basit yöntem bir günlük dosyası kullanmaktır; Vaultwarden ise varsayılan olarak günlük dosyası oluşturmaz:

LOG_FILE=/data/vaultwarden.log
LOG_LEVEL=info
EXTENDED_LOGGING=true

Başarısız bir giriş denemesi tam olarak bir satır üretir; filtrenizin eşleşmesi gereken dizge şudur:

[2026-08-07 09:14:22][vaultwarden::api::identity][ERROR] Username or password is incorrect. Try again. IP: 203.0.113.10. Username: user@example.com.

Filtreyi /etc/fail2ban/filter.d/vaultwarden.local dosyasına yazın:

[INCLUDES]
before = common.conf

[Definition]
failregex = ^.*?Username or password is incorrect\. Try again\. IP: <ADDR>\. Username:.*$
ignoreregex =

Jail yapılandırmasını ise /etc/fail2ban/jail.d/vaultwarden.local dosyasına ekleyin:

[vaultwarden]
enabled = true
port = 80,443
filter = vaultwarden
banaction = %(banaction_allports)s
logpath = /vw-data/vaultwarden.log
maxretry = 3
bantime = 14400
findtime = 14400

Vaultwarden bir container yerine systemd servisi olarak çalışıyorsa LOG_FILE adımını atlayabilirsiniz: Projenin fail2ban wiki sayfası, logpath yerine journalmatch ve Vaultwarden birimi üzerinde backend = systemd kullanarak günlükleri doğrudan journal üzerinden okumayı önerir.

Yönetim panelini açık tuttuysanız, failregex değeri ^.*Invalid admin token\. IP: <ADDR>.*$ olan ikinci bir jail ekleyin. Yönetim paneli hataları farklı bir mesajla günlüğe kaydedildiğinden, giriş filtresi bunları görmeyecektir. Ardından çalışmanızı doğrulayın:

sudo systemctl restart fail2ban
sudo fail2ban-client status vaultwarden

Çalışan bir jail, günlük dosyanızı File list altında listeler ve Currently failed: 0 raporunu verir. Farklı bir ağdan üç kez yanlış parola girin; sayaç artacak ve ardından ilgili adres Banned IP list altında görünecektir. Sayaç hiç artmıyorsa, yaygın neden logpath hatasıdır: yol, container içindeki /data/... yolu değil, ana makine (host) üzerindeki dosya yolu olmalıdır. İkinci yaygın neden ise eksik veya güvenilmeyen X-Real-IP başlığıdır; bu durum tüm yasaklamaların kendi proxy adresinizi hedeflemesine neden olur. Hali hazırda çalıştırıyor olmanız gereken SSH jail dahil olmak üzere kurulumun geri kalanı için Ubuntu 24.04 için fail2ban rehberi incelenebilir.

Ana parola tüm sistemin temelidir

İstemci tarafı şifreleme, ana parolanın anahtar olduğu anlamına gelir. Bir saldırganın veritabanını kopyaladığı bir örnekte kısa bir ana parola, bu yazıdaki hiçbir yöntemle korunmaz; çünkü saldırgan, donanımının izin verdiği hızda bu kopyaya çevrimdışı saldırı düzenler. Hiçbir sunucu ayarı, saldırganın kendi makinesine erişemez.

PASSWORD_ITERATIONS=600000 yanlış anlaşılmaya müsaittir. Bu ayar, istemcinin gönderdiği giriş hash'inin sunucu tarafındaki hash işlemi için yineleme sayısını belirler ve projenin yapılandırma şablonuna göre değiştirilen değer, mevcut kullanıcılara bir sonraki girişlerinde uygulanır. Bu ayar, çevrimdışı bir kasa saldırısının maliyetini belirleyen istemci tarafı KDF ayarına dokunmaz. KDF ayarı her hesaba özeldir ve web kasasında Ayarlar, Güvenlik, Anahtarlar menüsü altından değiştirilir; bu işlem anahtarı yeniden şifreler. Bitwarden belgelerine göre, 2026.2.1 sürümünden itibaren istemciler, 600.000 yinelemenin altındaki PBKDF2 ayarlarını kullanıcı giriş yaptığında veya ana parola ile kilidi açtığında otomatik olarak yükseltir. 10 Ekim 2026 itibarıyla bu davranışın bir Vaultwarden sunucusunda çalıştığı doğrulanmamıştır ve Argon2id ayarlarını hiçbir şekilde değiştirmez. Bu nedenle, yıllar önce kaydolan bir kullanıcı hala daha eski ve düşük bir KDF ayarında olabilir. Bunu kontrol edin ve kullanıcıyı bilgilendirin; çünkü sunucu bunu onlar adına yapamaz.

Ardından her hesap için iki faktörlü kimlik doğrulamayı etkinleştirin. Bu, kasa anahtarı yalnızca ana paroladan türetildiği için şifreli metni korumaz. Ancak çalınan bir parolanın giriş yapmak ve kopyayı senkronize etmek için yeterli olmasını engeller. REQUIRE_DEVICE_EMAIL=true, yeni cihazdan giriş e-postasını zorunlu kılar: Eğer Vaultwarden bu e-postayı gönderemezse giriş başarısız olur; böylece tanınmayan bir cihazdan yapılan girişler asla bildirilmeden gerçekleşmez. Bunun için çalışan bir SMTP yapılandırması gerekir, aksi takdirde yeni cihaz girişlerinin tümü reddedilir.

Yedeklemeler, self-hosted kasa kurulumlarının en zayıf halkasıdır

Aynı VPS üzerindeki bir ev dizininde bırakılan veri klasörünün tar czf yedeği, yukarıda atılan tüm adımları geçersiz kılar. Bu arşiv; her kullanıcının şifreli metnini içeren db.sqlite3 dosyasını, oturumları taklit etmeye yarayan rsa_key.pem dosyasını ve yönetici belirteci ile SMTP parolasını düz metin olarak barındıran config.json dosyasını içerir. Bu tek dosyaya okuma erişimi, tüm kasaya erişim sağlamakla eşdeğerdir.

Bu durum iki kural ile yönetilir. Arşivi sunucudan dışarı çıkarın. Sunucudan çıkmadan önce şifreleyin.

Ayrıca bir doğruluk sorunu da mevcuttur. Servis çalışırken db.sqlite3 dosyasını cp ile kopyalamak, yazma işlemi sırasında yarım kalmış ve açılamayacak bir dosya oluşturabilir; bunu ise ancak geri yükleme yapmaya çalıştığınızda fark edersiniz. Bunun yerine SQLite'ın kendi anlık görüntü alma özelliğini kullanın:

sqlite3 /vw-data/db.sqlite3 ".backup '/tmp/vw-db-backup.sqlite3'"

Kimsenin test etmediği diğer yarı olan geri yükleme süreci, Vaultwarden yedekleme ve geri yükleme kılavuzu içerisinde açıklanmıştır.

Barındırılan Bitwarden yerine kendi kurulumunuzu yaptığınızda vazgeçtikleriniz

Dürüst bir değerlendirme yapmak gerekirse; Bitwarden'ın barındırılan hizmeti, işi sadece bu sistemi yönetmek olan profesyoneller tarafından yürütülür. Bu hizmet, yayınlanmış üçüncü taraf denetimlerine sahiptir ve gece saat 03:00'te bile müdahale edebilecek bir ekip tarafından desteklenir. Kendi kendine barındırma (self-hosting) yönteminde ise bu güvenceyi kendi yama takviminizle değiştirmiş olursunuz.

Vaultwarden, güvenlik düzeltmelerini standart sürümler halinde yayınlar ve bu sürümler sık aralıklarla gelir. Projenin sürüm akışı üzerinde 10 Ekim 2026 tarihinde yapılan kontrole göre, güncel sürüm 5 Ekim 2026 tarihinde yayınlanan 1.37.4'tür. Sürüm notları, en ciddisi "Yüksek" olarak derecelendirilmiş yedi güvenlik uyarısını kapsamakta ve mümkün olan en kısa sürede güncelleme yapılmasını şiddetle tavsiye etmektedir. Bu sürüm, 24 Temmuz 2026'daki 1.37.0 sürümünden bu yana yayınlanan dördüncü sürümdür: 1.37.1 sürümü 29 Temmuz'da, 1.37.2 sürümü 22 Ağustos'ta (2026.8.0 ve daha yeni istemci sürümleri için gereklidir) ve 13 Eylül'de yayınlanan 1.37.3 sürümü gelmiştir. 1.37.3 sürümü, kimlik bilgileri veya 2FA değiştiğinde 2FA hatırlama belirteçlerini (tokens) iptal etmekte, ayrıca giriş öncesi ve kimlik doğrulama istek uç noktalarına hız sınırlaması (rate limit) getirmektedir. Tam olarak güvenmediğiniz yöneticilere sahip organizasyonlar yönetiyorsanız, 1.37.4 sürüm notları güncelleme sonrasında her organizasyonun API anahtarını yenilemenizi de önermektedir. 1.37.4 sürümü ayrıca, yukarıdaki reverse proxy bölümünde ele alınan X-Forwarded-For üzerinden hangi adresin okunacağını da değiştirmektedir. Bir yıl önce kurduğunuz ve unuttuğunuz bir örnek, bir yıllık kodla çalışmaya devam eder. latest etiketi tek başına çözüm sağlamaz: çalışan bir container, siz docker compose pull komutunu çalıştırıp onu yeniden oluşturana kadar başladığı imajı kullanmaya devam eder. Ana makine paketleri için Ubuntu üzerinde katılımsız yükseltmeleri devreye alın ve container güncelleme işlemini mutlaka takip edeceğiniz bir takvim hatırlatıcısına ekleyin.

Dürüst bir okuyucunun çıkarması gereken sonuç şudur: Buradaki kriptografi Bitwarden'ın tasarımıdır ve güvenlidir; ancak operasyonel risk tamamen size geçer. Eğer sistemi güncel tutar ve yedeklerinizi başka bir yerde saklarsanız, kontrolünüz altındaki bir VPS üzerinde çalışan Vaultwarden örneği, parolalarınızı tutmak için makul bir yerdir. Eğer bu iki alışkanlığı sürdüremeyecekseniz, barındırılan hizmet için ödeme yapın ve dikkatinizi başka konulara verin. Özellik bazlı karşılaştırma Vaultwarden ile kendi kendine barındırılan Bitwarden karşılaştırması bölümünde yer almaktadır.

Konteynerin altındaki ana makineyi güçlendirme

Vaultwarden, Linux sunucusu üzerinde çalışan tek bir süreçtir ve uygulama nasıl yapılandırılırsa yapılandırılsın, sunucudaki root kullanıcısı /vw-data dosyasını okuyabilir. Konteyneri, compose dosyanızda user: "1000:1000" kullanarak yetkisiz bir kullanıcı olarak çalıştırın, veri klasörünün sahipliğini buna göre ayarlayın ve konteynerin yazmadığı her şeyi :ro ile salt okunur olarak bağlayın. Ardından ana girişi kapatın: VPS üzerinde SSH güçlendirme rehberi, yukarıdakilerin tümünü aşan sıradan saldırıları durdurmak için anahtar tabanlı girişi ve parola kimlik doğrulamasını devre dışı bırakmayı ele almaktadır.

FAQ

Vaultwarden veritabanını çalarlarsa parolalarımı okuyabilirler mi?

Doğrudan okuyamazlar. Her kasa öğesi, istemci tarafında ana paroladan türetilen bir anahtarla şifrelenir, bu nedenle db.sqlite3 şifreli metin içerir. Saldırganın anında elde edeceği veriler; her hesabın e-posta adresi, KDF ayarları, giriş ve cihaz meta verileri ile twofactor tablosundaki iki faktörlü doğrulama anahtarlarıdır. Bu anahtarlar şifrelenmemiş olarak tutulur çünkü sunucunun beklenen kodu hesaplaması gerekir. Saldırganlar, kasa içindeki şifreli metne çevrimdışı olarak istedikleri kadar saldırabilirler; bu nedenle ana parolanın uzunluğu, sonucun ne olacağını belirleyen temel faktördür.

ADMIN_TOKEN kullanmalı mıyım yoksa yönetici sayfasını tamamen devre dışı mı bırakmalıyım?

Mümkünse devre dışı bırakın; çünkü çoğu kurulumda yönetici sayfası yalnızca SMTP yapılandırması ve kullanıcı daveti için bir kez kullanılır, sonrasında ihtiyaç duyulmaz. Devre dışı bırakmak için ADMIN_TOKEN veya DISABLE_ADMIN_TOKEN değişkenlerini ayarlamayın, config.json içindeki herhangi bir "admin_token" anahtarını kaldırın ve ardından container'ı yeniden oluşturun. Yalnızca ortam değişkenini kaldırmak yeterli değildir; çünkü yönetici sayfası tarafından yazılan ayarlar config.json içinde saklanır ve önceliklidir. Sayfayı tutmanız gerekiyorsa, token değerini düz metin bir rastgele dizi yerine vaultwarden hash ile üretilmiş bir Argon2 hash'i olarak saklayın ve ADMIN_RATELIMIT_MAX_BURST=3 ayarını yapın.

ADMIN_TOKEN değerim doğru ancak /admin sayfası reddediyor. Sorun nedir?

Sorun neredeyse her zaman $ enterpolasyonundan kaynaklanır. Bir Argon2 PHC dizisi birkaç $ karakteri içerir ve Docker Compose bunları bir docker-compose.yml environment: bloğu içinde değişken olarak genişletir. Bu nedenle, dosyanız doğru görünse bile container bozuk bir değer alır. Compose dosyasındaki her $ karakterini $$ ile ikiye katlayın veya değeri, kaçış karakterine ihtiyaç duyulmayan tek tırnak içine alınmış bir .env dosyasına taşıyın. Ortam değişiklikleri yeniden başlatma ile algılanmadığından, işlem sonrasında container'ı yeniden oluşturun.

Bildirimler için 3012 numaralı portu hala açmam gerekiyor mu?

Hayır. Bildirimler ana HTTP portuna taşındığı için 3012 numaralı port üzerinden WebSocket trafiği desteği Vaultwarden 1.31.0 sürümünde kaldırılmıştır. WEBSOCKET_ENABLED ve WEBSOCKET_PORT ayarları 1.29.0 sürümünden beri kullanımdan kaldırılmıştır ve dikkate alınmazlar. Mevcut ayar ENABLE_WEBSOCKET olup, varsayılan değeri true şeklindedir. Güvenlik duvarınızda 3012 numaralı portu kapatın ve compose dosyanızdan silin. Ardından reverse proxy'nizin Upgrade ve Connection başlıklarını ilettiğinden emin olun; gerçek zamanlı eşitleme artık tamamen buna bağlıdır.