ガイド

著者 Matt Connor 2026-10-11

VaultwardenをVPSに構築する方法：Dockerでパスワード管理をセルフホスト

Q: 知らない人がサーバーに登録するのを防ぐにはどうすればよいですか？

自分のアカウントを作成した直後に、Compose ファイルで SIGNUPS_ALLOWED: "false" を設定し、docker compose up -d を実行します。それ以降は、/admin の Invite User ボタンから新しいユーザーを追加します。この操作には SMTP の設定が必要です。設定すると、招待リンクがユーザーに送信されます。管理者ユーザーの一覧を定期的に確認し、予期しないアカウントが作成されていないことを確認してください。

Q: Vaultwarden の保管庫をバックアップするにはどうすればよいですか？

コンテナを一時的に停止し、vw-data ボリューム全体、db.sqlite3、attachments/、sends/、config.json および rsa_key.* ファイルをアーカイブします。その後、アーカイブをサーバー外へコピーします。できれば毎晩 cron で実行してください。サーバーの実行中に SQLite ファイルをコピーすると、スナップショットが破損するおそれがあります。そのため、停止した状態で取得します。最も重要なのは、使い捨てのコンテナに一度復元してログインすることです。これにより、バックアップが実際に復元できることを、依存する前に確認できます。

VPSでVaultwardenを構築し、Bitwarden互換のパスワードマネージャーをセルフホストする手順を解説します。HTTPS化、管理者トークンの設定、Fail2banによる保護、データバックアップの運用まで、安全な環境構築に必要な設定を網羅しました。

構築するもの

完全に自身で所有するパスワードマネージャーです。HTTPS終端を行うリバースプロキシの背後で、1つの小さなコンテナとしてVaultwardenを動作させ、スマートフォン、ノートPC、ブラウザ上の公式Bitwardenアプリをそこへ接続します。VaultwardenはBitwardenサーバーAPIをRustで再実装したもので、bitwarden.comと同一のプロトコルを使用します。そのため、サーバーを最新の状態に保っていれば、公式クライアントをそのまま利用可能です（クライアントの新しいリリースに合わせてVaultwardenのリリースが必要になる場合があります。クライアント2026.8.0以降には1.37.2が必要です）。Vaultwardenは、公式の複数コンテナ構成とは異なり、約100 MBのRAMで動作します。

インストール自体は、Composeの十数行の設定で行えます。実際に重要であり、かつ障害の原因となりやすいのは以下の3点です。Web Vaultを読み込む前にTLSが確立されていること、自身のアカウントを作成した直後に公開登録を閉じること、そしてデータボリュームのバックアップを取得し、復元テストを行うことです。そのディレクトリには、所有するすべてのパスワードが格納されているためです。

前提条件と、事前に把握しておくべき注意点

Docker Engine と Compose plugin をインストールした VPS。root または sudo を使える、クリーンな Ubuntu 24.04 KVM 環境を想定します。RAM は 512 MB で十分です。1 GB なら余裕があります。これは実行できるサービスの中でも特に軽量で、セルフホストする価値があるサービスの候補でも上位に入ります。ただし、同じ VPS で動かす他のサービスも考慮して VPS の容量を決めてください。PhotoPrism や Immich のようなセルフホスト型フォトライブラリを同じ VPS に追加すると、必要な RAM は数 GB になります。一方、Vaultwarden による増加はわずかです。同じ計算は、後から追加するメディア用フロントエンドにも当てはまります。Jellyfin のライブラリを歩いて回れる 90 年代のレンタル店のように仕立てる場合は、常時稼働するコンテナが 1 つ増え、同じ予算内でトランスコード用の余裕も必要になります。
VPS を vault.example.com 指す A レコード（IPv6 を利用する場合は AAAA レコードも）が設定されたドメイン。TLS 証明書はこの正確な名前に対して発行されるため、開始前に DNS で名前解決できる必要があります。
インターネットからアクセスできる 80 番ポートと 443 番ポート。これらは reverse proxy で終端し、Vaultwarden が直接待ち受けてはいけません。80 番ポートは ACME 証明書チャレンジと HTTP から HTTPS へのリダイレクトにのみ使用します。
最初に把握しておくべき最大の注意点は、Bitwarden クライアントが HTTPS ではないサーバーへの接続を拒否することです。「まず http でテストする」という方法はありません。この方法が機能しない具体的な理由を次に説明します。

Vaultwarden を公式の Bitwarden スタックではなく選ぶ理由

同じクライアントを使えますが、必要なリソースは大幅に少なくなります。公式の Bitwarden 自己ホスト構成は、MSSQL Express、Identity、Api、Admin などのコンテナ群として提供され、少なくとも 2 GB の RAM を必要とします。Bitwarden には、少なくとも 200 MB の RAM で動作する単一の Docker イメージ、Bitwarden lite もあります。ただし、これは個人利用やホームラボ向けであり、業務利用を想定していません。データベースとそのバックアップも、すべて利用者が管理する必要があります。Vaultwarden は単一のバイナリで、デフォルトではすべてのデータを SQLite データベースに保存します。アイドル時のメモリ使用量は数十 MB です。個人、家族、小規模チームで使うなら、明らかに適した選択肢です。Bitwarden API を忠実に実装しているため、データを Vaultwarden と bitwarden.com の間で移行できます。

一方で、エンタープライズ向けの機能の大部分は利用できません。SCIM プロビジョニングには対応していません（ただし、OpenID Connect SSO のサポートは 1.35.0 で追加されました）。また、運用者は利用者自身であるため、パッチ適用、HTTPS、バックアップも自分で管理する必要があります。このガイドでは、この 3 つの作業を扱います。

HTTPS が必須である理由

Bitwarden の Web vault とブラウザ拡張機能は、Web Crypto API (window.crypto.subtle) を使用してブラウザ内で暗号化キーを導出します。ブラウザが crypto.subtle を公開するのは、secure context、HTTPS、または http://localhost や http://127.0.0.1 などのループバックアドレスという特別な場合だけです。通常の http://vault.example.com では undefined であるため、アプリがキーを導出した瞬間に例外が発生し、コンソールには次のように表示されます。

Uncaught (in promise) TypeError: Cannot read properties of undefined (reading 'importKey')

ページがハングするか、一般的な暗号エラーが表示され、ログインできません。デスクトップ、モバイル、ブラウザの各クライアントは、自己ホスト URL に対して独自のチェックを実行します。http のエンドポイントや到達できないエンドポイントに対しては、次のエラーを返して拒否します。

This is not a recognized Bitwarden server. You may need to check with your provider or update your server.

どちらも原因は同じで、有効な HTTPS がないことです。そのため、最初に TLS を構成し、簡単な確認であっても vault を http で開くことは一度も行いません。

手順 1、DNS とリバースプロキシ（TLS を先に設定）

レコードを VPS に向け、正しいアドレスへ名前解決されることを確認します。

dig +short vault.example.com

出力される行は VPS の IP でなければなりません。空白または誤った値になる場合は DNS を修正し、TTL が切れるまで待ちます。名前解決できない名前に対しては、証明書の発行に失敗します。

HTTPS フロントエンドには Traefik を使用します。Traefik は Let's Encrypt の証明書を自動的に発行・更新でき、Compose にそのまま組み込めます。まだ運用していない場合は、先にTraefik のリバースプロキシと自動 TLS の設定に従ってください。この設定により、外部 Docker network（以下の proxy）と ACME resolver（letsencrypt）が作成されます。Vaultwarden サービスはこれらに接続します。手動で発行した証明書を使う通常の nginx でも、Vaultwarden 側の動作は同じです。

Traefik の代わりに nginx と Certbot を使用しますか？ Vaultwarden を 127.0.0.1:8080 に配置し（サービスに ports: ["127.0.0.1:8080:80"] を追加し、Traefik の labels を削除します）、証明書を発行して Vaultwarden へ proxy します。証明書の部分は、Certbot と nginx で Let's Encrypt 証明書を発行する方法で説明しています。追加で重要なのは、notifications パスでの WebSocket upgrade です。

server {
    listen 443 ssl;
    server_name vault.example.com;

    client_max_body_size 525M;

    location / {
        proxy_pass http://127.0.0.1:8080;
        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_http_version 1.1;
        proxy_set_header Upgrade $http_upgrade;
        proxy_set_header Connection "upgrade";
    }
}

X-Real-IP の行に注目してください。これにより、Fail2ban は 127.0.0.1 ではなく実際の攻撃元を認識できます。Traefik と nginx のどちらを前段に置く場合でも、それ以外の手順は同じです。

手順2、Compose ファイル

最初にプロジェクトディレクトリを作成します。このガイドでは /opt/vaultwarden を使用します。これにより、Compose プロジェクト名とデータボリューム名を vaultwarden_vw-data として予測可能にできます。以下の Fail2ban とバックアップの手順は、この正確な名前に依存します。

sudo mkdir -p /opt/vaultwarden
cd /opt/vaultwarden

そのディレクトリ内に、管理者 Secret 用の .env と Compose ファイルを作成します。

# .env
ADMIN_TOKEN=paste-a-strong-token-here

openssl rand -base64 48 でこのトークンを生成し、貼り付けます。（より強固なハッシュ形式については次で説明します。最初は長いランダム文字列で問題ありません。）

# docker-compose.yml
services:
  vaultwarden:
    image: vaultwarden/server:latest
    container_name: vaultwarden
    restart: unless-stopped
    environment:
      DOMAIN: "https://vault.example.com"
      SIGNUPS_ALLOWED: "true"          # closed in Step 4, keep true just to register
      ADMIN_TOKEN: "${ADMIN_TOKEN}"
      IP_HEADER: "X-Forwarded-For"     # X-Real-IP if your proxy sends that instead
      LOG_FILE: "/data/vaultwarden.log"
      LOG_LEVEL: "warn"
    volumes:
      - vw-data:/data
    networks:
      - proxy
    labels:
      - "traefik.enable=true"
      - "traefik.http.routers.vw.rule=Host(`vault.example.com`)"
      - "traefik.http.routers.vw.entrypoints=websecure"
      - "traefik.http.routers.vw.tls.certresolver=letsencrypt"
      - "traefik.http.services.vw.loadbalancer.server.port=80"

volumes:
  vw-data:

networks:
  proxy:
    external: true

このファイルには、設計全体を支える重要な点が2つあります。ports: のマッピングはありません。そのため、Vaultwarden には Traefik とその TLS 経由でのみアクセスできます。ホスト上でポートを公開すると、誤って http で vault を提供することになります。また、DOMAIN には完全な公開 HTTPS URL を指定する必要があります。この値は添付ファイルのリンク、WebAuthn 2FA、通知エンドポイントに埋め込まれるため、サイトが読み込めても、値が間違っていたり http だったりするとこれらが動作しません。latest タグは、通常の「latest しない」というルールに対する意図的な例外です。Vaultwarden は安定版リリースを単一のローリングイメージとして提供し、:testing は別個のプレリリースチャネルです。そのため、目的を持って更新し、pull する前にリリースノートを確認してください。ただし、この例外の適用範囲は限定的です。長期間稼働するコンテナの多くは、正確なタグに固定する方が適しています。これにより、同じ VPS 上で常時稼働する自己ホスト型エージェントを再起動や pull の後も予測可能な状態に保てます。

起動してログを監視します。

docker compose up -d
docker compose logs -f vaultwarden

正常に起動すると、最後に Rocket has launched from http://0.0.0.0:80 のような行が表示されます。Traefik が証明書を取得するまで数秒待ってから https://vault.example.com を開きます。有効な南京錠が表示され、証明書警告のない Bitwarden Web vault が表示されます。

ステップ 3、強力な ADMIN_TOKEN、そして $$ の落とし穴

ADMIN_TOKEN は、インスタンス上のすべてのユーザーと設定を読み取れる管理パネル /admin を保護します。root のパスワードと同じように扱ってください。使用できる形式は 2 つあります。

簡単な形式は、openssl rand -base64 48 で生成済みのランダム文字列です。base64 には $ が含まれないため、エスケープせずにそのまま .env に設定できます。

より安全な形式は Argon2 PHC ハッシュです。平文のトークンをディスクに保存しません。同じイメージに対して次のコマンドを実行して生成します。

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

2 回入力を求められ、$argon2id$v=19$... で始まる文字列が出力されます。ここで、1 時間を失いかねない落とし穴があります。Docker Compose は $ を変数展開として扱います。そのため、Compose ファイルの environment: の下にハッシュを直接貼り付ける場合は、$ をすべて $$ に倍にする必要があります。値を引用符で囲んでも問題ありません。重要なのはエスケープです。

    environment:
      ADMIN_TOKEN: $$argon2id$$v=19$$m=19456,t=2,p=1$$c29tZXNhbHQ$$RdescudvJCsgt3ub+b+dWRWJTmaaJObG

ハッシュを .env に保存する場合は、規則が逆になります。$ は 1 つのままにし、値全体を単一引用符（ADMIN_TOKEN='$argon2id$v=19$...'）で囲みます。既存の ${ADMIN_TOKEN} 行が Compose ファイル内でその値を読み込みます。.env 内の $ を 2 つにしてはいけません。Compose ファイル自体に単一の $ を残すと、Compose は The "argon2id" variable is not set と警告し、トークンを空にします。その結果、/admin は正しいパスワードも拒否します。docker compose up -d を実行し、プロンプトに入力した平文は自分のパスワード管理ソフトに保存してください。

手順 4: アカウントを登録してから、アクセスを閉じる

SIGNUPS_ALLOWED: "true"で https://vault.example.comを開き、アカウントを作成をクリックして、メールアドレスと強力なマスターパスワードを使用して登録します。このマスターパスワードは復元できず、リセットもありません。先に、確実に保管できる場所へ保存してください。

次にアクセスを閉じます。Compose ファイルを編集して、サインアップを無効にします。

      SIGNUPS_ALLOWED: "false"

docker compose up -dで再適用します。これは後回しにできるハードニングではありません。有効なままにすると、URLを見つけた人が、実際にはクローラーも含めて、サーバー上にアカウントを作成できます。あなたの vault を読み取ることはできませんが、リソースを消費し、非公開のインスタンスを公開サービスに変えてしまいます。無効化し忘れたことを示す兆候は、/adminに自分で作成していないアカウントが表示されることです。

後から家族やチームメンバーを追加する場合は、公開サインアップを再び有効にせず、/adminのユーザーを招待ボタンを使用します。この方法では SMTP の設定が必要です。招待されたユーザーがリンクを受け取るためです。

Step 5: /admin にアクセスする

https://vault.example.com/admin にアクセスし、平文の admin token（ランダムな文字列、またはハッシュ化したパスワードであり、ハッシュそのものではない）を入力します。管理画面では、ユーザーの一覧表示、設定の調整、テストメールの送信、データベースのスナップショット取得ができます。

ページに The admin panel is disabled, please configure the 'ADMIN_TOKEN' variable to enable it と表示される場合、ADMIN_TOKEN が空または未設定です。この状態では管理画面全体が無効になります。管理画面を使う必要がない場合は、これも有効な構成です。ページは表示されるものの token が拒否される場合は、下記の障害一覧にある $$ のエスケープに関する注意点を確認してください。token を忘れた場合、復旧プロンプトはありません。.env または Compose ファイルを編集して新しい token を設定し、docker compose up -d を実行します。

手順 6: Bitwarden クライアントを接続する

公式クライアントはすべてセルフホストサーバーを指定できます。通常のストアから Bitwarden のデスクトップ、モバイル、またはブラウザークライアントをインストールしてください。専用の Vaultwarden ビルドは必要ありません。

ログインする前に、ログイン画面の設定ギアを開きます（Self-hosted または Region → Self-hosted と表示されます）。Server URL に https://vault.example.com を設定して保存します。登録したメールアドレスとマスターパスワードでログインすると、クライアントはすぐに接続し、認証情報の入力と保存を提案します。

クライアントに This is not a recognized Bitwarden server. You may need to check with your provider or update your server. が表示される場合は、URL が正しくないか、http を使用しているか、証明書が信頼されていません。まずブラウザーで https://vault.example.com が問題なく読み込めることを確認してください。他のデバイスで更新が遅れる場合は WebSocket プッシュが原因であり、後述します。

ログインエンドポイント用のFail2ban jail

Vaultwardenは、LOG_FILEで指定したファイルにログイン失敗をすべて記録します。これはブルートフォース攻撃対策に必要な情報です。Fail2banをまだ導入していない場合は、インストール方法と基本設定をFail2banによるSSH強化ガイドで確認してください。ここではvault用のjailを1つ追加します。

まず、Fail2banがログを読み取れるように、名前付きvolumeがホスト上のどこにあるかを確認します。

docker volume inspect vaultwarden_vw-data --format '{{ .Mountpoint }}'

次のような結果が表示されます。/var/lib/docker/volumes/vaultwarden_vw-data/_data。この中のvaultwarden.logがログファイルです。filterを作成します。

# /etc/fail2ban/filter.d/vaultwarden.conf
[Definition]
failregex = ^.*Username or password is incorrect\. Try again\. IP: <ADDR>\. Username:.*$
ignoreregex =

次にjailを作成します。

# /etc/fail2ban/jail.d/vaultwarden.local
[vaultwarden]
enabled   = true
filter    = vaultwarden
logpath   = /var/lib/docker/volumes/vaultwarden_vw-data/_data/vaultwarden.log
banaction = iptables-allports
chain     = DOCKER-USER
maxretry  = 5
findtime  = 600
bantime   = 3600

sudo systemctl restart fail2banでreloadし、sudo fail2ban-client status vaultwardenで確認します。

Dockerでは、次の3点によって保護が機能するかどうかが決まります。1つ目は、ログに失敗した試行ごとにIP: 127.0.0.1またはプロキシのアドレスが記録される場合です。この場合、Vaultwardenはプロキシをbanしてしまいます。IP_HEADERに、プロキシが実際に送信するヘッダーを設定してください。TraefikではX-Forwarded-For、上記のnginx設定ではX-Real-IP、Cloudflareの背後ではCF-Connecting-IPを使用します。X-Forwarded-Forを使用すると、1.37.4以降のVaultwardenはIP_HEADER_TRUSTED_PROXIESに含まれない最も右側のアドレスを使用します。IP_HEADER_TRUSTED_PROXIESのデフォルトはlocalで、同じホストまたはDocker network上のプロキシを対象にします。プロキシの前段にCDNがある場合は、そのアドレスもここに追加してください。

2つ目は、適切なiptables chainがプロキシによって異なることです。公開ポートを設定したcontainerとしてTraefikを実行している場合、通信はDockerのFORWARD経路を通るため、上記のようにbanをDOCKER-USERに設定する必要があります。一方、Step 1のhost-nginx構成を選択した場合、接続はホストのINPUT chain上のnginxで終了します。そのため、DOCKER-USER banでは接続を検出できません。この場合はchain = DOCKER-USER行を削除し、Fail2banにデフォルトのINPUT chainを使用させてください。

3つ目は、ポートベースのデフォルトではなくbanaction = iptables-allportsを使用することです。このjailではポートを定義していません。DOCKER-USERで全ポートをbanすると、ホスト上で公開されているすべてのserviceから攻撃元を確実に遮断できます。

手順 8、vault をバックアップして、実際に復元する

vw-data volume は、パスワードマネージャーそのものです。db.sqlite3（すべてのエントリ）、attachments/ ディレクトリと sends/ ディレクトリ、ログインセッションに署名する rsa_key.* ファイル、管理パネルからの config.json が保存されています。これらのいずれかを除外したバックアップは、必要なときに復元できません。

Vaultwarden の書き込み中に db.sqlite3 をコピーすると、書き込み途中の破損ファイルが取得される可能性があります。そのため、停止した状態でスナップショットを取得します。停止時間は数秒です。

#!/usr/bin/env bash
set -euo pipefail
STAMP=$(date +%F)
DEST=/root/vw-backups
VOL=$(docker volume inspect vaultwarden_vw-data --format '{{ .Mountpoint }}')
mkdir -p "$DEST"
docker compose -f /opt/vaultwarden/docker-compose.yml stop vaultwarden
tar czf "$DEST/vw-$STAMP.tgz" -C "$VOL" .
docker compose -f /opt/vaultwarden/docker-compose.yml start vaultwarden

これを cron から毎晩実行し、.tgz をサーバーの外部にもコピーします。保護対象のサーバー上にしか存在しないバックアップは、バックアップとはいえません。別のサーバーまたはオブジェクトストレージへの毎晩の restic バックアップが適切です。アーカイブを暗号化し、重複するスナップショットを自動的に排除できます。管理パネルの Backup Database ボタンは、SQLite ファイルだけを対象とする手軽なホットスナップショットです。ただし、添付ファイルと鍵は含まれません。

本物のバックアップと、復元できるはずという期待を分ける手順は、実際に1度復元して動作を確認することです。

mkdir -p /tmp/vw-restore
tar xzf /root/vw-backups/vw-2026-07-15.tgz -C /tmp/vw-restore
docker run --rm -p 127.0.0.1:8888:80 -v /tmp/vw-restore:/data vaultwarden/server

ノート PC から ssh -L 8888:127.0.0.1:8888 you@your-vps でトンネルを作成し、http://localhost:8888（または http://127.0.0.1:8888）を開きます。ループバックアドレスはセキュアコンテキストとして扱われるため、ここでは crypto.subtle を利用できます。このアドレスでは、vault は通常の http 接続を介して復号されます。通常の http が許可されるのは、この種類のアドレスだけです。マスターパスワードでログインし、エントリが存在することを確認します。存在していれば、データベース、RSA 鍵、マスターパスワードがすべて正常に往復できています。新しい VPS でも数分で再構築できます。Ctrl-C でコンテナを停止し、/tmp/vw-restore を削除します。インターネットに公開してはならない、サーバー上の他の管理 UI にも、このトンネルの習慣を適用してください。自己ホスト型の open-kritt セキュリティスキャナーにも、同じ方法で port 5173 経由でアクセスできます。

障害の種類と表示される文字列

ブラウザーのコンソールに Cannot read properties of undefined (reading 'importKey') が表示される。 Vault は http 経由で読み込まれているため、crypto.subtle は未定義です。https:// 経由でのみアクセスし、プロキシで HTTP から HTTPS へのリダイレクトを追加します。

クライアントに This is not a recognized Bitwarden server... が表示される。 Server URL が http になっているか、入力を誤っているか、証明書が信頼されていません。https://vault.example.com に有効な南京錠アイコンが表示されることを確認し、クライアントの self-hosted 設定に正しい URL を再入力します。

/admin が正しいパスワードを拒否する。 Argon2 ハッシュのエスケープが失われています。Compose ファイルでは、すべての $ を $$ にする必要があります。ただし .env 内の単一引用符で囲まれた部分では、単一の $ を使用します。または、ハッシュが表す平文ではなく、ハッシュ自体を入力しています。

デバイス間の同期が遅く、コンソールに WebSocket connection to 'wss://vault.example.com/notifications/hub' failed が表示される。 プロキシが Upgrade/Connection ヘッダーを転送していません。Traefik では自動的に処理されます。nginx では Step 1 の 2 行の upgrade 設定が必要です。Vault は引き続き動作しますが、開いたときだけ同期されます。v1.31.0 以降、専用の旧ポート 3012 は廃止されているため、個別の WebSocket ルートは必要ありません。

Fail2ban が ban を報告するが、攻撃者が接続し続ける。 IP_HEADER が誤っているため、127.0.0.1 を ban しています。または、ban が誤った iptables チェーンに設定されています。chain = DOCKER-USER と banaction = iptables-allports を設定します。

アップグレード

新しいイメージを取得してコンテナを再作成します。名前付きボリュームとすべてのデータは保持されます。

docker compose pull
docker compose up -d

Vaultwarden は頻繁にリリースされます。パッチバージョンを固定するのではなく、プロジェクトのリリースノートを監視してください。リリースによっては移行に関する注意事項が含まれるためです。メジャーアップグレードの前には、毎回新しいバックアップを作成してください。ロールバックする場合は、tarball を新しいボリュームに復元できます。

FAQ

Vaultwarden は Bitwarden と同じですか？

互換性のある独立したサーバーであり、公式サーバーではありません。Vaultwarden は Bitwarden サーバー API を Rust で再実装しているため、公式のデスクトップ、モバイル、ブラウザー、CLI クライアントをすべて接続して使用できます。公式スタックの一部のリソースで動作します。保管庫の形式は同じなので、エクスポートとインポートにより、どちらの方向にも移行できます。

HTTPS は本当に必要ですか。LAN 上で http を使うことはできますか？

loopback でのテスト以外では HTTPS が必要です。Bitwarden の Web 保管庫と拡張機能はブラウザーの Web Crypto API を使用します。この API は secure context でのみ利用できるため、平文の http ではクライアントが Cannot read properties of undefined を返し、ログインできません。使用できる http アドレスは http://localhost や http://127.0.0.1 のような loopback アドレスだけです。そのため、Step 8 の復元テストでは SSH トンネルを使用します。

知らない人がサーバーに登録するのを防ぐにはどうすればよいですか？

自分のアカウントを作成した直後に、Compose ファイルで SIGNUPS_ALLOWED: "false" を設定し、docker compose up -d を実行します。それ以降は、/admin の Invite User ボタンから新しいユーザーを追加します。この操作には SMTP の設定が必要です。設定すると、招待リンクがユーザーに送信されます。管理者ユーザーの一覧を定期的に確認し、予期しないアカウントが作成されていないことを確認してください。

Vaultwarden の保管庫をバックアップするにはどうすればよいですか？

コンテナを一時的に停止し、vw-data ボリューム全体、db.sqlite3、attachments/、sends/、config.json および rsa_key.* ファイルをアーカイブします。その後、アーカイブをサーバー外へコピーします。できれば毎晩 cron で実行してください。サーバーの実行中に SQLite ファイルをコピーすると、スナップショットが破損するおそれがあります。そのため、停止した状態で取得します。最も重要なのは、使い捨てのコンテナに一度復元してログインすることです。これにより、バックアップが実際に復元できることを、依存する前に確認できます。

パスワードを自分でホストしても本当に安全ですか？

このガイドで説明する3つの対策を実施すれば安全です。実際の HTTPS、登録の無効化と強力な管理者トークン、そしてテスト済みのバックアップです。保管庫はマスターパスワードでクライアント側暗号化されるため、サーバーでさえパスワードを平文で見ることはできません。db.sqlite3 が盗まれても、マスターパスワードなしではエントリを復号できません。ただし、サーバーにはアカウントのメールアドレスと、各マスターパスワードから生成されたソルト付きハッシュが保存されます。攻撃者はこれをオフラインで解析できるため、データベースファイルとそのすべてのコピーを保護してください。代わりに、パッチ適用とバックアップは自分の責任になります。そのため、この構成では Fail2ban と復元手順を省略できません。これらを準備したら、自分でホストした保管庫が実際にどこから攻撃される可能性があるかを詳しく確認することが次の有用な手順です。エントリ自体はクライアント側で暗号化されているため、残る防御対象は管理者トークンとバックアップアーカイブです。

#vaultwarden #passwords #security #docker #self-hosting