VPNパスワードの秘匿性は検証者のそれと同じだけしかない

VPNログインについて四つの問いを順に考えます。通信中にパスワードを守るのは何か、どのコンポーネントがそれを受け取るか、そのコンポーネントはそれをどう扱うか、その後何が保存されるか。答えはそれぞれ別の統制であり、一つに強い答えがあっても他について何も語りません。誤りは、トンネル暗号化が四つすべてを覆うかのように扱うことです。覆うのは最初の一つだけです。

セッションが暗号化されているかではなく、誰がセッションを終端するかを問いましょう。

誰に対して暗号化されているのか、正確には。

TLSが守るのは、クライアントと接続を終端するものとの間のパスワードです。その端点がVPNゲートウェイなら、ゲートウェイの認証コードは平文のパスワードを見て、検証し、そのままか派生値を先へ渡します。これは意図された設計であり、漏えいではありません。経路上のネットワーク観測者は有益な情報を得ず、検証を行うコンポーネントは必要なすべてを得ます。

OpenVPNコミュニティはこれを明示的に文書化しています。auth-user-pass-verifyは送信された資格情報を検証スクリプトやプラグインへ渡します。これはコンポーネント間の意図的な受け渡しであり、名前のある当事者として信頼モデルに属します。

検証者はパスワードを見る

コンポーネントが検証のためにパスワードを受け取ると、秘密が内側にとどまるかどうかは、そのコンポーネントのアクセス制御、ログ記録、コード品質で決まります。資格情報をログに書き込むスクリプトや、それをキャッシュするプラグインは、プロトコルが生んだよりはるかに大きな露出を生みます。アクセスはトンネルではなくアーキテクチャと役割に依存するため、検証者を管理するサービス所有者も評価に含まれます。

方式が違えば露出する素材も違う。証明書認証は秘密鍵を送らずに証明し、フェデレーションの流れはパスワードを識別プロバイダに残したままVPNへ限定された表明を発行できます。こうした設計は輪を狭めますが、信頼する当事者をすべて排除するものではありません。

保存されたハッシュが守るのは別の段階

NISTの指針は、保護された伝送と耐性のある検証者保管を分けています。ソルトとコストを伴うハッシュ方式が扱うのは保存済み検証者への脅威、つまりデータベースが漏れた後に起きることです。比較のために入力を必ず受け取る実行時コンポーネントについては何もしません。実行時の秘匿を約束しているかのように指針を読むのはカテゴリー錯誤です。

したがって、よくハッシュ化されたパスワード保管庫と露出した検証スクリプトは、矛盾なく一つの製品に共存できます。

輪を狭める方式を選ぶ

ゲートウェイが再利用可能なパスワードを決して受け取らないことが要件なら、それを実際に保証する方式を選んでください。データ暗号を変えてもその性質は生まれません。VPNサーバーの証明書を検証すれば、どの相手に到達したかは分かりますが、その相手がその後資格情報をどう扱うかは何も語りません。サーバー検証は維持し、サービスごとに別の資格情報を使い、組織が採用する識別フローに従ってください。

パスワードを受け取る当事者、それを検証する当事者、そしてどの形で保持されるかを記録してください。この三つの答えは接続プロファイルの隣に置くべきです。どのトンネルよりも長く残るからです。

有用な問いは、パスワードが暗号化されているかではなく、誰から隠されているか、どのコンポーネントが受け取るか、その後どの形が残るかです。