LASSIC Media らしくメディア
Vaultwardenで実現する自前パスワード管理
LASSIC IT事業部｜元請（プライムベンダー）としてシステム保守・運用を受託
この記事のポイント
- Vaultwardenの仕組みとBitwarden公式クライアントとの互換性を確認できます。
- 組織・コレクション機能を使ったチームでのパスワード共有の考え方を整理します。
- 自社での構築・運用を続ける場合と外部パートナーに委ねる場合の判断軸を提示します。
目次
Vaultwardenの仕組みとBitwarden互換性
Vaultwardenとは、Bitwarden公式クライアントと互換性を持つ、Rust言語で実装された非公式のセルフホスト型パスワード管理サーバーです*1。IT事業部が扱う社内アカウント・共有パスワードを自社サーバー上で一元管理したい場合の選択肢になります。
プロジェクトはBitwarden, Inc.とは提携しておらず*1、コミュニティが開発するオープンソースソフトウェアという位置づけです。ライセンスはAGPL-3.0で公開されています*1。この点は導入時に確認しておく必要があります。
互換性の範囲は広く、公式のBitwardenクライアント（デスクトップアプリ・モバイルアプリ・ブラウザ拡張）をそのままVaultwardenサーバーに接続して使えます*1。個人vault・Send・添付ファイル・ウェブサイトアイコン・個人APIキーといった機能に加え、組織・コレクション・パスワード共有にも対応しています*1。クライアント側の操作性はBitwarden公式サービスと変わらないため、従業員側の学習コストを抑えられる点が特徴です。
SaaS型パスワードマネージャとの違い
SaaS型のパスワード管理サービスは、ベンダーが管理するクラウド上にvaultを預ける形態です。一方でVaultwardenは、同じBitwardenプロトコルを使いながらもサーバー本体を自社の管理下に置く形態になります。両者の違いを比較表で整理します。
| 比較項目 | Vaultwarden（セルフホスト） | SaaS型パスワード管理 |
|---|---|---|
| データの保管場所 | 暗号化vaultを自社サーバーに保管します。 db.sqlite3として管理者が直接把握できます*2。 |
ベンダーのクラウド環境に保管します。 保管先の物理環境は利用者側から見えません。 |
| 運用の主体 | サーバー構築・アップグレード・バックアップを自社（または委託先）が担います*2。 | サーバー運用はベンダーが担い、利用者は契約とアカウント管理を担当します。 |
| クライアント | Bitwarden公式クライアントをそのまま利用できます*1。 | 各サービス専用のクライアントを利用します。 |
| 組織・チーム共有 | Organizations・Collections・Groups・Event Logsに対応します*1。 | サービスごとにプラン単位で組織機能が提供されます。 |
| 初期費用と運用負荷 | ソフトウェア自体の利用料は発生しませんが、サーバー費用と運用の手間がかかります。 | 月額・年額のライセンス費用が発生する一方、運用の手間は小さくなります。 |
自社運用を選ぶ動機としては、機密性の高い認証情報を外部のクラウド事業者に預けたくないという要請が挙げられます。データの保管先・アクセス経路を自社の管理下に置けることが、セルフホストの中心的な価値になります。
セルフホスト構築の流れ
Vaultwardenは公式にDockerイメージ（vaultwarden/server）が提供されており、多くの環境ではDockerコンテナとして稼働させます*1。構築の大まかな流れは次のとおりです。
- サーバー（クラウドVMまたはオンプレミス）にDocker環境を用意します。
- vaultwarden/serverイメージを取得し、データ用ボリュームを指定してコンテナを起動します。
- リバースプロキシ（Nginx等）とTLS証明書を設定し、HTTPS経由でアクセスできるようにします。
- 管理者ページ用のトークンを設定し、新規アカウント登録の可否を決めます。
- 従業員のクライアント（デスクトップアプリ・ブラウザ拡張・モバイルアプリ）から自社サーバーのURLを指定して接続します。
TLSの設定を誤ると、認証情報が平文に近い状態で通信路に流れる恐れがあります。証明書の発行・更新の運用も含めて設計する必要があります。リバースプロキシの設定・証明書更新の失念は、稼働開始後にまとめてログイン不能を招く要因になりやすい点も見落とせません。
組織・コレクションによるチーム共有
Vaultwardenとは何を指すのか、個人利用の範囲で理解している方も少なくありません。しかし法人利用の主眼はチームでのパスワード共有にあります。Vaultwardenは、Bitwardenの仕組みに準じたOrganizations（組織）・Collections（コレクション）・Groups（グループ）機能を備えています*1。
組織を作成すると、その配下にコレクションという単位でパスワードやシークレットをまとめられます。部署やプロジェクトごとにコレクションを分け、必要なメンバーだけをそのコレクションに割り当てる形で、閲覧範囲を制御できます。メンバーには役割（Member Roles）を設定でき、管理者・利用者といった権限の切り分けが可能です*1。
操作記録についてはイベントログ（Event Logs）機能があり、誰がいつどのアイテムにアクセス・変更したかを追跡できます*1。退職者が出た際にはコレクションから即時に外し、共有していたパスワードは順次ローテーションする運用フローをあらかじめ決めておくことが望ましいでしょう。
2要素認証(2FA)の設定
Vaultwardenは、Two-step login（2要素認証・2FA）として複数の方式に対応しています。具体的には、メール認証・TOTPベースの認証アプリ・Duo・YubiKey・FIDO2 WebAuthn（NitrokeysやSolokeysなど）が挙げられます*1。
マスターパスワードだけに依存する運用は、パスワード漏えい時の被害範囲を広げます。組織全体で2FAを必須化するポリシーを設定できるため、管理者ページから有効化しておくことが実務上の対策になります。FIDO2 WebAuthn（Webサイトが公開鍵暗号方式でハードウェアキー等を用いて認証する標準規格）のような物理キーによる認証は、フィッシング耐性の面でも選択肢になります。
Bitwardenのアーキテクチャでは、マスターパスワードや暗号鍵はデバイス上で生成・管理され、暗号化もローカルで実行されます*3。サーバー側が平文のマスターパスワードを保持しない設計であるため、サーバー管理者であっても各利用者のマスターパスワードそのものを読み取ることはできません*3。この設計思想はVaultwardenが実装するプロトコルにも引き継がれています。
運用フェーズ：バックアップとアップグレード
構築後の運用で欠かせないのがバックアップとアップグレードです。バックアップ対象として、SQLiteデータベース（db.sqlite3）・attachmentsディレクトリ・rsa_key関連ファイルが挙げられています*2。db.sqlite3にはvaultのほぼすべての重要データが格納されるため、最優先のバックアップ対象になります*2。
設定ファイル（config.json）には管理ページの設定など機密情報が含まれるため、これも合わせてバックアップし、暗号化した状態で保管することが推奨されています*2。SQLiteのバックアップには、稼働中のデータベースにも対応する専用コマンドの利用が案内されています*2。
アップグレードについては、Dockerイメージを最新版に取得し直し、既存コンテナを停止・削除してから、データ用ボリュームを維持したまま新しいイメージでコンテナを起動する手順が案内されています*4。Docker Composeを使う場合は、イメージの取得と再起動のコマンドを実行するだけで更新できます*4。更新の自動化にWatchtowerのようなツールを使う方法も案内されています*4。
バックアップを取らずにアップグレードを進めると、データベースのスキーマ変更に不整合が生じた場合、vault全体へのアクセスができなくなるリスクがあります。アップグレード前のバックアップ取得は、運用ルールとして固定しておく必要があります。
内製と外注、判断が分かれる分岐点
Vaultwardenのセルフホストを内製で担うには、Docker・リバースプロキシ・TLS証明書運用・SQLiteのバックアップ設計・Linuxサーバーの基本的な保守知識が必要になります。加えて、脆弱性情報を継続的に追い、アップグレードを計画的に適用する体制も求められます。
専門パートナーに委ねる場合との違いは、日常監視・障害対応・アップグレード適用の体制が最初から組み込まれている点です。内製では、担当者の異動や退職によって運用知識が引き継がれず、アップグレードが滞留するといった事態が起こりえます。結果として脆弱性が指摘されたバージョンを使い続けるリスクにつながります。
判断軸としては、次の3点を確認すると整理しやすくなります。第一に、社内にDocker・Linuxサーバーの保守を継続的に担える人員がいるかどうかです。第二に、アップグレード・バックアップ・監視を運用ルールとして定着させられるかどうかです。第三に、パスワード管理サーバーの障害時に、代替の認証手段や復旧までの業務継続策を用意できているかどうかです。いずれかが不十分な場合は、構築・運用の一部または全部を外部パートナーに委ねる選択が現実的になります。
まとめ：Vaultwarden導入の3つの判断軸
本稿では、Vaultwardenの仕組みとBitwarden互換性、組織・コレクションによるチーム共有、2要素認証、バックアップ・アップグレードといった運用の要点を整理しました。要点を3つに集約すると、第一に認証情報を自社の管理下に置けることが自社運用の中心的な価値である点、第二に組織・コレクション機能によって部署単位の共有範囲を制御できる点、第三に構築後の運用体制を継続できるかどうかが内製・外注の分岐点になる点です。自社の体制を踏まえたうえで、構築だけを内製し運用監視を外部に委ねるといった組み合わせも検討に値します。
よくある質問
Vaultwardenは公式のBitwardenサーバーと同じものですか。
同じものではありません。VaultwardenはBitwarden, Inc.と提携しない、コミュニティ主導の非公式実装です*1。Bitwardenプロトコルに準拠しているため、公式クライアントから接続できますが、開発・保守の主体は別になります。
既存のBitwardenアプリからVaultwardenへ乗り換えられますか。
クライアントアプリはそのまま使えます。接続先のサーバーURLを自社のVaultwardenサーバーに変更し、既存アカウントで再ログインするか、vaultをエクスポート・インポートする形での移行が一般的です。移行前にはデータのバックアップを取得しておく必要があります*2。
従業員が多い組織でも運用に対応できますか。
Organizations・Collections・Groups機能により、部署やプロジェクト単位でアクセス範囲を分けて管理できます*1。ただし利用者数が増えるほどサーバーの可用性設計やバックアップ運用の重要性も増すため、体制面の検討が欠かせません。
サーバー管理者は従業員のパスワードを見られますか。
見られない設計です。暗号化と復号はクライアント側のデバイス上で行われ、マスターパスワードや暗号鍵はサーバーに送信されません*3。サーバー側が保持するのは暗号化された状態のvaultデータです。
構築だけを依頼して運用は自社で続けることはできますか。
対応できます。初期構築（サーバー選定・Docker環境・TLS設定・組織設計）のみを委託し、その後の日常運用は自社で担う分担も可能です。反対に、構築は内製し、アップグレードやバックアップの監視だけを委託する組み合わせも選択肢になります。
著者：テレリモ総研編集部 鈴木 亮佑
ご不明な点はお問い合わせフォームからもご連絡いただけます。
- *1 出典：dani-garcia「vaultwarden（GitHubリポジトリ）」
- *2 出典：dani-garcia「Backing up your vault（Vaultwarden Wiki）」
- *3 出典：Bitwarden, Inc.「Bitwarden Security White Paper」
- *4 出典：dani-garcia「Updating the vaultwarden image（Vaultwarden Wiki）」
