すべてのデバイスを締め出さずにVPNパスワードを切り替える

三台のスマートフォン、ルーター一台、監視チェック一件がまだ古いパスワードを保持しており、そのうち一台は九十秒ごとに再接続している。アカウントのパスワードは十分前に変わったので、これらのクライアントは今やサーバーが拒否する値を送っている。そこで神話は崩れる：パスワード変更が触れるのはアカウントであり、各デバイスに残る古い値のコピーではない。続くのは、その変更がやらなかった作業だ。

神話：一度の変更で、すべてが同時に

パスワードを変えればすべてがサインアウトされ、きれいな再ログインが強制される、というのが通念だ。そうはならないのは、サーバーが最後に受け入れた資格情報だけを追跡し、クライアントは保存したものをそのまま持ち続けるからだ。保存済みパスワードを持つデバイスは独自のスケジュールで再試行し、誰かがアカウントのロックに気づくまで静かに失敗し続ける。コピーがアカウントの外に生きていると認めれば、ローテーションは単一の操作には見えなくなる。

これはどれもローテーションに反対する論拠ではない。保存済みのコピーを後回しの考慮ではなく変更の一部として扱うべきだという論拠だ。ロックアウトは通常、並行する再試行から生じる：各デバイスが独自のスケジュールで古い値を送り続け、カウンターが作動する。するとアカウントは攻撃を受けたように見えるが、実際には誰も置き換えていない資格情報を差し出されているだけだ。この区別は重要だ。解決策はデバイスの一覧であって、より厳しいロックアウト方針ではない。

ローテーションの前にコピーを棚卸しする

パスワードのフォームを開く前に一覧を書く。このアカウントとして認証するすべてのクライアント、スクリプト、自動化、管理対象プロファイルを挙げる：自分から接続するスマートフォン、二年前に設定したルーター、月曜にしか起きないノートPC、そして毎分試行する監視チェックだ。それぞれについて、資格情報がどこに保存されているか、変更中にデバイスへ到達できるか、再接続できない場合の復旧経路は何かを記す。この一覧が危険な変更を計画的な変更に変えるのであり、古いパスワードが使えなくなる前に存在していなければならない。

オフラインのデバイスは典型的な見落としだ。引き出しの中のノートPCが三週間後に戻り、最悪のタイミングで古い値を提示する。その場所とスケジュールも記すこと。待つのではなく追いかける必要があるからだ。

Linuxの群れでは、探索は賢いというより機械的だ。資格情報ファイルを参照するプロファイルを探し、次に資格情報ファイル自体を探す。書き換えるべきは二番目の一覧だからだ。デスクトップクライアントとスマートフォンでも同じ作業を繰り返す。そこでは保存場所はパスではなくプロファイルかキーチェーン項目だ。目的は作業できる一覧であり、すべてのコピーを見つけたと主張するスキャンではない。

grep -rl auth-user-pass /etc/openvpn /etc/NetworkManager
grep -rl auth-user-pass ~/.config 2>/dev/null

コピーを、それを所有する人と突き合わせる。誰も申告しないデバイスは誰も更新しないデバイスであり、再試行を続ける可能性が最も高いデバイスでもある。

実際に回しているのはどの秘密か

アカウントのパスワードはVPN展開における資格情報のひとつにすぎない。鍵のパスフレーズ、証明書の識別情報、任意のピア秘密は、それぞれ独自の置き換え経路と所有者を持つ。アカウントのパスワードを変えても証明書で認証するデバイスには何の効果もなく、証明書を再発行しても保存済みパスワードを持つクライアントには何の効果もない。解決策を名指す前に、秘密を名指すこと。

ローテーションが方針ではなく疑念に駆られているなら、インシデント手順が便宜の計画より優先される。証拠が要求するものを失効させ、デバイス一覧の追加作業を受け入れる。その判断はインシデントの所有者に属し、たまたまパスワード再設定フォームを持っている人ではない。

保存された値を、それが生きている場所で置き換える

サービスの文書化した仕組みで資格情報を変え、そのうえで保存済みのコピーを更新するか、残したいすべてのデバイスでサインインの流れを実行する。それを書き戻す管理ツールの背後にある生成済み設定を編集してはいけない。管理ツールは次の実行で古い値を復元し、編集は遅れて現れる障害になる。管理ツールが読むソースを更新するか、クライアント自身の資格情報ストアを使う。いずれにせよ、デバイスはクライアントが実際に読む場所に新しい値を持つ必要がある。

パスワードファイルを保存するクライアントはファイルの書き換えを必要とし、問い合わせるクライアントは完了したサインインを必要とする。NetworkManagerは接続プロファイルの中に秘密を保持するので、変更はテキストエディタではなくnmcliを通る：

nmcli connection modify work vpn.secrets "password=NEW"
nmcli connection up work

資格情報ファイルを読むプロファイルは三番目のケースだ。そのファイルの中身を置き換え、権限を閉じたままにし、それを指すプロファイルを編集するのではなくクライアントを再読み込みする。プロファイルは変わっていない。変わったのはそれが読む秘密だけだ。

意図したデバイスを一度ずつ、わざと再接続し、どれが失敗するかを見る。デバイスが失敗し続けるなら、パスワードを再び変える前に、それが指すアカウントと読むストアを確認する。二度目の変更は更新すべきコピーを増やすからだ。二度失敗するデバイスは通常、間違ったアカウントを指すか、まだ見つけていないストアを読んでいる。それを直してから再接続する。

セッションとトークンはパスワードより長く生きる

パスワードを変えても、既存のセッションや別個の証明書が失効したことにはならない。サービスの一部はセッションを有効期限切れか明示的な終了まで生かし続け、発行されたトークンは独自の寿命を持つ。変更が全体に及んだと仮定せず、サービスが実際に何をするかを確認する。疑念に駆られた変更なら、セッションを明示的に終了し、結果を確認する。

NIST SP 800-63Bの資格情報のライフサイクルに関する指針は、認証器とセッションを別のカテゴリーに置いている。だからこそパスワード変更と全体ログアウトは別の操作なのだ。二つの完了基準を持つ二つの作業として扱う。一つ目は新しい値が機能したときに終わり、二つ目は古いセッションが消えたときに終わる。

新しいパスワードを記録に書かずに完了を記録する。資格情報を含むローテーションログは、共有ドライブで待つ新しいインシデントだ。日付、更新したデバイス、まだ残っているデバイスを記す。