【ITニュース解説】Self-Hosting a Password Manager on a Pi Zero 2W

システムエンジニアを目指す皆さんにとって、日々の情報セキュリティは非常に重要なテーマだろう。その中でも、パスワード管理は特に頭を悩ませる課題だ。オンラインサービスごとに異なる強力なパスワードを覚えるのは難しいし、使い回しは危険だ。そこで多くの人がパスワードマネージャーを利用するが、そのデータを「クラウド任せ」にするのではなく、「自分で管理する」という選択肢がある。この記事では、そうしたセルフホスティング、つまり自分のサーバーでパスワードマネージャーを動かす挑戦について、初心者にも分かりやすく解説する。

今回の挑戦者は、自分のデジタル環境を完全にコントロールしたいと考え、パスワードマネージャーのセルフホスティングを決意した。目標は、機密性の高いパスワードデータを完全にプライベートに保ちつつ、複数のデバイスからアクセスできるようにすること。そして、その過程でセルフホスティングの仕組み、データ暗号化技術であるTLS、サーバーの仲介役となるリバースプロキシ、そしてアプリケーションの実行環境であるDockerといった技術について深く学ぶことだった。使用するデバイスは非常に低消費電力で手のひらサイズのコンピュータ「Raspberry Pi Zero 2W」である。

まず、パスワードマネージャー選びから始まった。1PasswordやBitwardenといったクラウドベースのサービスは便利だが、データ管理の全権を自分で持ちたいという思いから、セルフホスト可能な選択肢を探した。そこで見つけたのが「Vaultwarden（ヴォルトワーデン）」だ。これは人気のパスワードマネージャーBitwardenの非公式な軽量版で、TOTP（時間ベースのワンタイムパスワード）などの主要な機能に対応しつつ、Raspberry Pi Zero 2Wのような限られたリソースのデバイスでもスムーズに動作するという特徴がある。個人で使うには必要十分な機能を持ち、かつ活発に開発が続けられている点が決め手となった。

次に、Raspberry Pi Zero 2Wの準備に取りかかった。まずは「Ubuntu（ウブントゥ）」というLinuxベースのOSをインストールし、SSH（Secure Shell）という技術を使って、別のパソコンからネットワーク経由でPiを遠隔操作できるように設定した。これにより、Piに直接モニターやキーボードを接続しなくても、コマンドラインで操作できるようになった。そして、アプリケーションを効率的に動かすための技術である「Docker（ドッカー）」と、複数のDockerアプリケーションをまとめて管理するための「Docker Compose（ドッカーコンポーズ）」をシステムに導入し、常に最新の状態に保つために必要なシステムアップデートも行った。Dockerが正しくインストールされていることを確認後、いよいよVaultwardenをDockerコンテナとして動かす準備が整った。

VaultwardenをDockerで初めて動かした際、すぐに重要な問題に直面した。「永続ボリュームが設定されていない」という警告だ。Dockerコンテナは、一度停止したり更新したりすると、その内部のデータが失われてしまうという性質がある。これではパスワードデータが消えてしまう危険性があるため、コンテナの外部にデータを保存する仕組みが必要となる。この解決策が「永続ボリュームのマッピング」だ。具体的には、Piのストレージ上に vw-data というディレクトリを作成し、それをDockerコンテナ内の /data ディレクトリに紐づける設定を docker-compose.yml という設定ファイルに記述した。これにより、Vaultwardenコンテナが停止・再起動しても、パスワードデータは vw-data ディレクトリに安全に保存されるようになった。また、この設定ファイルには、後にリバースプロキシと連携するための重要な項目 ROCKET_PROXY_PATH="/pass" も追記された。

ここで、Vaultwardenをインターネットに公開する際のURL設計について、二つの選択肢を検討した。一つは「サブドメイン」を使う方法（例: vault.mydomain.com）、もう一つは「サブパス」を使う方法（例: mydomain.com/pass）だ。サブドメインは見た目が分かりやすいが、それぞれに異なるSSL証明書が必要になったり、将来的に他のサービスをホストする際にDNS設定が煩雑になったりする可能性がある。また、VPN経由やモバイルからのアクセス時にDNS解決の問題が生じることも考えられた。一方、サブパスはメインのドメインで取得した一つのSSL証明書でカバーできるため、証明書の管理が非常にシンプルになる。複数のサービスを追加する場合でも、DNS設定を変更せずにリバースプロキシだけでルーティングを制御できるため、拡張性が高い。こうした理由から、今回はサブパス（/pass）を選択し、メインのパス（/）は将来的に他のサービスのために空けておくことになった。

このサブパスでのルーティングを実現するために、「Caddy（キャディ）」というリバースプロキシソフトウェアを導入した。リバースプロキシとは、外部からのリクエストをまず受け取り、それを内部の適切なサーバー（この場合はVaultwardenコンテナ）に転送する仲介役のことだ。CaddyはSSL証明書の自動取得・更新機能も持っているため、HTTPS（暗号化された安全な通信）を簡単に実現できる。しかし、初期設定ではVaultwardenが正常に動作しなかった。アセット（画像やCSSファイルなど）が壊れて表示されたり、WebSocket（リアルタイム通信に使われる技術）が機能しなかったり、URLの末尾にスラッシュがあるかないかで動作がおかしくなったりしたのだ。これは、Vaultwardenがサーバーのルートパス（/）でサービスを提供することを前提としているのに対し、リバースプロキシが /pass というプレフィックスを付けたままリクエストを転送していたためだ。解決策として、Caddyの設定に handle_path /pass/* という記述を追加した。これにより、Caddyは /pass 以下のリクエストを受け取ると、その /pass の部分を削除してからVaultwardenに転送するようになり、上記の問題がすべて解決された。また、クライアントのIPアドレスなどの情報をVaultwardenに正しく伝えるためのヘッダー情報も追加設定した。

次に重要なのが「TLS（Transport Layer Security）」、つまりHTTPSによる安全な通信環境の確立だ。自分自身のデバイス（デスクトップPCやスマートフォン）から、Pi上で動くパスワードマネージャーに安全にアクセスするためには、SSL証明書が必要になる。今回は外部の認証局ではなく、自分自身で作成した「ローカル認証局（CA）」とその証明書を使用した。mkcert（エムケーサート）というツールを使って panda.local や pass.local といったローカルドメイン用の証明書を生成し、そのローカルCAのルート証明書を、アクセスするすべてのデバイス（デスクトップPCやスマートフォン）に手動でインストールし、「信頼済み」として登録した。これにより、ウェブブラウザやモバイルアプリからアクセスした際に表示されるSSL警告が解消され、安全かつスムーズにサービスを利用できるようになった。

そして、自宅のネットワークをインターネットに直接公開するリスクを避けるため、VPN（Virtual Private Network）のようなソリューションを使ってリモートアクセスを確立した。これにより、外出先からでも安全にVaultwardenにアクセスできるようになった。当初はDNS解決の問題や証明書パスの設定でつまずいたが、ローカルのホストファイルにエントリを追加したり、証明書のパスを正しく設定したりすることで、これらも解決できた。このVPNとサブパスの組み合わせにより、メインのドメイン名と /pass パスだけで、将来的に他の個人的なサービスも追加できる、拡張性の高いシステムが構築できた。

これまでの道のりで直面した主要な問題と、その解決策をまとめると以下のようになる。まず、Dockerの「永続ボリュームが設定されていない」という警告は、 vw-data ディレクトリをDocker Composeでコンテナにマッピングすることで解決した。次に、サブパスでリバースプロキシを使用する際に発生した「アセットの読み込みやWebSocketの不具合」は、Caddyの handle_path /pass/* という設定で解消された。ウェブサイトの「SSL警告」については、 mkcert を使ってローカルCAと証明書を生成し、それをデスクトップやモバイルデバイスに手動でインストールして信頼させることで解決した。URLの「末尾スラッシュの有無による表示の不一致」も、 handle_path の設定が役立った。そして、「リモートアクセス時の接続の不安定さ」は、ローカルのDNSエントリや正しい証明書パスを設定することで改善された。最終的に「サブドメインとサブパスのどちらを選ぶか」という設計上の判断は、将来的な複数サービスのホスティングと証明書管理の簡素化を考慮し、サブパスを選択する形で解決した。

最終的なセットアップが完了した時、Raspberry Pi Zero 2W上でVaultwardenが /pass のパスで期待通りに動作し、デスクトップやモバイルデバイスから完全にHTTPSで信頼され、自宅ネットワークのセキュリティを損なうことなく外部からアクセスできるようになっていた。しかも、すべてのパスワードデータは永続的に保存される状態だ。実際にアカウントを作成し、モバイルアプリからログインし、TOTPコードを同期するなど、一通りの機能テストを行ったところ、すべてが問題なく機能した。

この挑戦を通して、いくつかの重要な教訓が得られた。Dockerを使う上では、コンテナのデータが誤って失われるのを防ぐために、永続ボリュームを適切に設定することが不可欠であること。また、サブパスでのサービス公開では、リバースプロキシの複雑な設定が成功の鍵を握ること。そして、TLSと証明書は情報セキュリティの根幹であり、セルフホスト環境では特にモバイルクライアントや内部利用のために証明書の信頼を個々のデバイスで手動管理する必要があること。サブパスルーティングは、複数のサービスを一つのドメインでホストする際に、DNS設定や証明書管理をシンプルにする上で非常に有効な手段であることも理解できた。 handle_path のような一見小さな修正や、CA証明書のインポートといった作業が、最終的なユーザー体験を大きく左右するということを実感した。

Raspberry Pi Zero 2Wのような小さなデバイスでVaultwardenをセルフホストするという今回の挑戦は、一人のユーザーにとって過剰に思えるかもしれない。しかし、これは単にパスワードマネージャーを動かすだけでなく、自分のデータに対する「制御」、究極の「プライバシー」、そして何よりも貴重な「学習」の機会を提供してくれた。Pi Zero 2Wは驚くほど高性能で、このシステムを問題なく動かすことができたし、Vaultwardenは期待通りの堅牢で軽量なソリューションだった。システムエンジニアを目指す皆さんにとって、このようなセルフホスティングの挑戦は、技術的な知識を深め、問題解決能力を養う絶好の機会となるだろう。まずは小さなことから始めて、途中で遭遇するであろう困難を学びの機会と捉え、一つ一つのエラーを解決していくことで、最終的に自分が設計したシステムが、証明書からWebSocketに至るまで完璧に機能するのを見る達成感は計り知れない。