漏えいした VPN 鍵の交換：サーバーがすべきこと

クライアント鍵を入れたノート PC を紛失したとき、最初の行動はたいていローカルコピーの削除だ。サーバー側では何も変わらない。サーバーはその鍵を受け入れる認可を、誰かが取り除くまで保持している。交換は二つの操作であり、古い資格情報に関わるのは二つ目だけだ。

ローカルコピーは権限ではない

VPN の資格情報が受け入れられるのは、サーバー側の設定がそう定めているからだ。証明書の場合、証明書が信頼された発行元につながり、ゲートウェイが参照する失効リストに載っていないことを意味する。WireGuard の場合は、ピアの公開鍵がインターフェース設定に載っていることを意味する。クライアント上のファイルを削除すると秘密のコピーが一つ消えるだけで、受け入れの規則は手つかずのまま残る。

だからこそ 明白な後始末をしても盗まれた鍵は動き続けるのであり、新しい設定を入れてもインシデントが解決した感じにならないのだ。

サーバーの規則から始め、そこから外へクライアントへと進む。

証明書：判断はサーバーが持つ

交換は発行元自身の手続きで発行し、新しい身元を記録する。そのうえで署名付き失効で古いものを取り下げる。ゲートウェイはその失効ソースを参照するよう設定し、再読み込みしなければならない。そうしないとファイルはディスク上に残ったまま、トンネルは古いシリアルを受け入れ続ける。アクティブなセッションも再ネゴシエーションまで生き残ることがあるので、再接続を計画する。

交換が目的のアプリケーションで機能することを確認し、そのうえで承認された手続きにより、引退した証明書がもはやアクセスを確立しないことを確認する。

これは二つの別のテストであり、両方が必要だ。RFC 5280 はゲートウェイが依拠する証明書と失効の意味論を定義している。

WireGuard：ピア鍵が身元そのもの

WireGuard には証明書層がない。ピアの公開鍵が身元であり、サーバーの allowed-ips エントリが認可だ。インターフェース設定から古いピアを削除することが失効であり、新しいハンドシェイクには即座に適用される。

既存のセッションは次のハンドシェイクが失敗した時点で終わる。通常は即座ではなく数分以内だ。

新しい設定は、パスワードを預けるのと同じくらい信頼する経路で配布する。秘密鍵が資格情報だからだ。鍵は端末ごとに一つに保ち、一つの端末を失っただけで全端末を変えずに済むようにする。

そのバンドルには何が入っていたか

クライアントバンドルは秘密鍵以上のものを運ぶことが多い。静的 TLS 鍵、ユーザー名とパスワード、事前共有秘密、プロビジョニングトークンなどだ。インシデントの範囲を実際に露出したものに限定し、それらもローテーションする。証明書をローテーションしながら共有の静的鍵を残すと、一方の扉を閉めて別の扉を開けたままにすることになる。

バンドルが端末間で共有されていたなら、それを運ぶすべての端末が露出を引き継ぐ。

何をローテーションしたかを書き留める。次の監査が尋ねるからだ。

拒否を証明し、交換を記録する

交換が完了するのは二つの事実が成り立つときだ。新しい身元が目的のサービスで機能し、古い身元が拒否される。後者はテスト環境から引退した資格情報で、あるいは組織が承認する統制された試行で検証し、ゲートウェイのログを読んで、拒否が方針によるものでタイプミスによるものではないことを確認する。そのうえで古い識別子、新しい識別子、変更時刻を記録する。監査人が再構成に必要とするのはこの三つの値だからだ。チケットの他の何もその空白を説明しない。

秘密鍵をチケットやチャットに残さない。方針に従い、保管庫とバックアップから不要なエクスポートを削除する。

拒否テストのない交換は修正ではなく想定にすぎない。