セルフホスト型パスワードボールト：なぜセキュリティチームが“鍵”を取り戻すのか

数か月おきに、だいたい同じ質問の形で相談を受けます。 「クラウドのプランにお金を払う代わりに、パスワードマネージャーをセルフホストすればいいのでは？」 正直な答えは、何を最適化したいかによります。管理すべきインフラがゼロであることを重視するなら、クラウドのままでよいでしょう。自分の資格情報（クレデンシャル）がどこに置かれているのかを正確に把握したい、最後にサーバーに触ったのが誰かを知りたい、さらにベンダーがあなたの要望なしに変更を押し込んできたらどうなるのかを知りたいなら、セルフホスト型パスワードボールトのほうが、より防御的（リスク管理の観点で筋が良い）な選択になります。セルフホスト型パスワードボールトがセキュリティレビューで話題に上がると、私が一番よく聞かれるのがこの質問なので、実際のトレードオフを見ていきましょう。

セルフホスト型パスワードボールトとは何ですか？

自社ホスティングのパスワード金庫（self-hosted password vault）とは、パスワード管理者であり、サーバー コンポーネントがベンダーのマルチテナント クラウドではなく、組織が所有または直接管理するインフラ上で稼働するものです。暗号化された金庫データ、データベース、そして通常は encryption キーは、社内ネットワーク内または自社のプライベート クラウド アカウント内に保持されます。ベンダーがソフトウェアを提供し、ユーザーがそれを運用します。

これがクラウド型パスワード マネージャーとの根本的な違いです。クラウド ツールでは、ベンダーがサーバーを運用し、あなたはその運用上のセキュリティを信頼します。一方、自社ホスティングのパスワード金庫では、あなたがサーバーを運用し、その責任を自社で負います。もちろん、そのメリットも含めてです。

なぜ自社ホスティングするのか

自社ホスティングのパスワード金庫への移行についての会話の多くは、技術的な好みではなく、コンプライアンス要件や取締役会レベルの質問から始まります。意思決定を後押しする典型的な要因をご紹介します。

真のデータ主権

圧力が取締役会から来るのか、あるいは顧客のセキュリティ調査票から来るのかにかかわらず、自社ホスト型のパスワードボルトは「データ主権」を単なる論点から事実へと変えます。資格情報は、あなたが管理するインフラから決して外に出ません。顧客がベンダーの秘密情報がどこに保管されているかを明確に尋ね、"AWS のどこか"よりも具体的な答えを期待する場合、この点は重要になります。

規制への準拠とデータの所在（データレジデンシー）

業界に厳格なデータレジデンシーのルールがある場合、たとえば国内のデータ保護法、業界特有の規制、または監査での指摘を受けて社内で作成した方針であっても、自社ホスト型のパスワードボルトなら、共有マルチテナントのSaaSボルト単体では満たしきれない要件をチェックできます。データがどの地域に置かれるか、そこにどれくらいの期間とどまるか、そしてアプリケーション層だけでなくインフラ層に誰がアクセスできるかを、あなたが管理します。

自社のセキュリティモデルを適用する

自社ホスト型のパスワードボルトでは、導入を自分たちの管理策で包み込むことができます。たとえばファイアウォールのルール、リバースプロキシ、ネットワークのセグメンテーション、侵入検知などです。ベンダーが「すべての顧客に対して十分だ」と判断した境界（パリメータ）に縛られることはありません。組織がすでに強化されたDMZを運用している、または zero trust ネットワークであるなら、そのボルトは“その外側”に置かれるのではなく、そのモデルに組み込まれます。

バックアップと可用性を自分で管理

クラウドの金庫を利用する場合、復旧時点目標（RPO）と復旧時間目標（RTO）はベンダーのSLAに記載されている内容どおりになります。自社ホスティングのパスワード金庫なら、バックアップの頻度、保持期間、フェイルオーバーを自分たちで管理できます。コンテナで実行し、独自のスケジュールでデータベースをスナップショットし、事業継続計画で必要なら2つ目のサイトへレプリケートしてください。インシデント発生時にベンダーのステータスページを待つ必要はありません。

ベンダーのロードマップを待たずに、変化するコンプライアンス要件を満たす

自社ホスティングのパスワード金庫は環境変数と設定の柔軟性を提供するため、コンプライアンス要件が変わったときに、機能要望を出してベンダーの次のリリースサイクルを待つことなく、導入を適応させられます。

破壊的（互換性に影響する）変更が来るのを把握できる

これは誰もランディングページには載せない話ですが、自社ホスティングのインフラを1年以上運用してきた管理者なら、誰でもつらい経験を通じて学んだことです。クラウドベンダーは好きなタイミングでアップデートを投入し、連携が止まって初めて破壊的変更（breaking change）の存在を知ることになります。自社ホスティングのパスワードボールト（password vault）なら、アップグレードの手順を自分でコントロールできます。変更履歴（changelog）を読み、ステージングでテストし、準備が整うまでバージョンを固定（pin）します。既に動作が確認できたリリースに固定して、ベンダーの都合ではなく自分のスケジュールでアップグレードする――この一つの実践が、計画されたメンテナンスウィンドウと、計画外の障害（outage）の違いになります。

ローカルキャッシュとオフラインアクセス

自社ネットワークにデプロイする自社ホスティングのパスワードボールト（password vault）は、インターネット接続が使えない状況でも動き続けます。WANリンクが落ちた場合や、ベンダーのクラウドが不調な日が来ても、チームは実際の問題を直すために共有されたサービスアカウントのパスワード（shared service account password）を引き続き必要とします。クライアント側でのローカルキャッシュ（local caching）と、自社ネットワーク内に存在するボールト（vault）を組み合わせることで、資格情報（credential）へのアクセスが第三者の稼働率（uptime）に依存しなくなります。これは自社ホスティングのパスワードボールトの中でも、あまり派手ではない主張の一つですが、当番（on-call）のエンジニアを納得させることが多いポイントでもあります。

自社ホスティングのパスワードボールトを選ぶ方法：導入前に確認すべきこと

どのチームにも必ず最適な、自社ホスティングのパスワードボールトは一つとしてありません。そして選択肢同士の違いは、多くのベンダーページが認めている以上に重要です。どれか一つに決める前に、候補をすべて同じ4つの基準で評価してください。

これらの基準はいずれも、特定の導入モデルを一方的に有利にするものではありません。評価している候補それぞれについて比較を行ってください。

オープンソース vs. プロプライエタリのセルフホスト型ボルト（金庫）

オープンソースのセルフホスト型ツールなら、セキュリティチームがコードを読み、暗号方式を検証し、ベンダーの説明を鵜呑みにせずに実装内容を直接監査できます。この透明性には大きな価値がありますが、トレードオフもあります。コミュニティ主導でメンテナンスされているプロジェクトは、常に、コンプライアンスチームがベンダーのリスク評価に必要とする正式な第三者監査の記録やSLAが提供されるとは限りません。

プロプライエタリのセルフホスト型ツール（Netwrix Password Secureを含む）は、ベンダーのサポート、文書化された監査、そして何かが壊れたときに責任を取るための契約上の当事者によって、そのギャップを埋めます。どちらのモデルも、常に一方が普遍的に優れているわけではありません。オープンソースは、コードを自分たちでレビューし、保守できる社内の専門知識を持つチームに向いています。プロプライエタリのセルフホスト型ツールは、自社でホスティングすることで得られるコントロールを望みつつ、ベンダーの説明責任を手放したくないチームに向いています。いずれにせよ、セルフホスト型のパスワードボルトを運用するかどうかは、結局「誰がコードをレビューし、壊れたときに誰が電話に出て対応するのか」を決めることなのです。

誰も言及しない「セットアップの問題」

これはもっともな疑問であり、常に出てくる問いでもあります。自己ホスト型のパスワード・ボールトが、機密を第三者に預けて信頼する必要をなくすはずだとするなら、そもそもボールトをセットアップするために使う認証情報（クレデンシャル）を守るのは何なのでしょうか？ データベースのパスワード、管理者アカウント、初期の暗号化キー――これらは、自己ホスト型のパスワード・ボールトがそれらを保存するために存在する前に、どこかに置かれていなければなりません。

この問題は完全に避ける方法がありません。そうでないと言うベンダーは、ブートストラップ問題をごまかしているだけです。あなたにできるのは、露出期間（攻撃にさらされる時間幅）を最小化することです。セットアップの認証情報は、再利用したパスワードではなくローカルのパスワード生成器で作成します。初期の管理者シークレットは、同じサーバー上のテキストファイルではなく、密封されたオフラインの場所、ハードウェアトークン、あるいは安全な保管場所に保管した印刷物として保管してください。ボールトが稼働し始めた直後にセットアップの認証情報をローテーションし、永続的に残す必要のないセットアップアカウントは削除します。セットアップフェーズは「すべてがボールトの中にある」という原則に対する、短く意図的な例外であって、うまく運用されている自己ホスト型パスワード・ボールトのセキュリティモデルに、恒久的な穴が空くわけではありません。

真のデータ・ソブリンティと取締役会の会話

取締役会のメンバーや、顧客の調達（購買）チームが「このデータは実際どこに保存されているのですか？」と尋ねるとき、クラウドのボールトで正直に答えるなら、多くの場合「その四半期にベンダーのインフラがある場所ならどこでも」ということになります。自己ホスト型のパスワード・ボールトなら、ストレートに答えられます。つまり「ここです。こちらのデータセンターに、こちらのサーバー上に、こちらのアクセス制御ポリシーのもとで管理されています」。この具体性こそが、「データ・ソブリンティ」をマーケティングの言葉から、監査に耐える事実へと変える要素であり、運用上のオーバーヘッドが現実に存在していても、規制産業が自己ホスティングに繰り返し戻ってくる理由でもあります。

個人用の金庫とは違う形で、エンタープライズ向けの金庫が機能する場面

上記は、ホームラボを保護している場合でも、5,000人規模の組織を保護している場合でも当てはまります。ただし、規模によって「self-hosted」が提供すべきものが変わってきます。個人向けの self-hosted パスワード金庫は、通常、少数のユーザーを1人の管理者が管理する形で設計されています。 Netwrix Password Secure は、まったく逆の課題に対応するために作られています。つまり、組織全体にわたる中央集権型のガバナンス（centralized governance）を実現し、ロールベースのアクセス（role-based access）、特権情報（privileged secrets）の承認ワークフロー（approval workflows）、そして IT が監査人にそのまま渡せる完全な監査ログ（full audit trail）を備えます。クラウド、オンプレミス（on-prem）、ハイブリッドのいずれでも self-hosted のパスワード金庫として動作するため、データの所有権に関する判断はSaaSベンダーではなく貴社の組織に残ります。そのうえで、ITチームだけでなくすべての従業員に、管理された形で資格情報を保存できる場所を提供します。

クラウド向けの利用者ツール vs. self-hosted の代替

クラウドのパスワードマネージャーと self-hosted のどちらを選ぶか迷う多くの人が、同じ2つの質問に行き着きます。どちらも、はっきりと正面から答える価値があります。

実際の違いは何ですか？

クラウドの消費者向けパスワードマネージャーはSaaS専用です。ベンダーがインフラを運用し、パッチを適用し、暗号化された金庫（vault）を保持します。メンテナンスはゼロで、完成度の高いすぐに使えるインターフェースが手に入りますが、インフラ、パッチ適用のタイミング、インシデント対応をベンダーに完全に委ねることになります。セルフホスト型の代替では、暗号化された金庫を自分で管理するサーバーに置きます。「とにかく動く」手軽さは手放し、パッチ、バックアップ、稼働率（uptime）を自分で引き受ける必要がありますが、資格情報は自分が所有していないインフラ上に置かれることはありません。

ローカルマシンへのアクセスは、ローカルのパスワードへのアクセスを意味しますか？

実績のあるパスワードマネージャーは、クラウドでもセルフホストでも、ゼロ知識（zero-knowledge）かつエンドツーエンド暗号化を採用しています。つまり、マスターパスワードが金庫（vault）を復号する鍵を生成し、その復号はサーバーではなくあなたのデバイス上で行われます。金庫がロックされていて、マスターパスワードなしで誰かがあなたのマシンを手に入れた場合、その人が見るのは暗号文（ciphertext）です。ですが、金庫がすでにアンロックされている場合、または攻撃者があなたが入力している最中にマスターパスワードを捕捉できる手段を持っている場合（キーlogger、クリップボードへのアクセス権を持つマルウェア、侵害されたブラウザー拡張機能など）には、暗号化はもはやあなたを守っているものではありません。セルフホスト型のパスワード金庫を選ぶと、暗号化データが置かれる場所は変わりますが、金庫が開いている状態でデバイスが侵害された後に何が起きるかは変わりません。これは エンドポイントセキュリティの問題であって、ホスティング方式の問題ではありません。どの金庫を選ぶにせよ、デバイスの衛生（device hygiene）と短い自動ロックのタイマーで解決する価値があります。

要するに

セルフホスト型のパスワード金庫は、セキュリティ管理を本来あるべき場所に置きます。つまり、第三者ではなくあなたの手の中です。あなたがサーバー運用の業務を引き受け、その代わりに、資格情報がどこに保存されるか、バックアップがどのように行われるか、アップデートがいつ適用されるか、そしてあらゆる層で誰が金庫に到達できるかを直接コントロールできます。データ主権に関する本質的な要件があるチーム、規制された環境、あるいは消費者向けレベルの金庫では手に負えなくなってきた組織の従業員がいる場合、そのコントロールは“任意”ではなく、まさにそれが目的です。

スプレッドシートや個人用ボールトが“修正策”ではなく、実際のリスクになっている段階をチームが過ぎているなら、集中管理によるガバナンスを備えたセルフホスト型のエンドツーエンド暗号化ワークフォース・ボールトを検討する価値があります。 Netwrix Password Secure がセルフホスト型のワークフォース向けパスワード管理をどのように扱うのかを確認してください。