保存された VPN パスワード：誰がいつ復号できるのか

XML に暗号化されたパスワードを表示する VPN クライアントは、ほとんど何も教えてくれていません。暗号文が答えているのは、その表現では値が平文で保存されていないということだけです。誰が、どの鍵で、どのユーザーコンテキストで復号できるのかが、その保存が役に立つかどうかを決める問いです。ファイルを安全か危険かと評する前に、それらに答えてください。

何が保存されているかを特定する

製品の文書化された保存モデルから始めます。クライアントは復元可能なパスワード、トークン、または資格情報ストアへの参照を保存することがあり、それぞれ露出の度合いが異なります。XML 要素の名前は設計ではなく、base64 に見える文字列も暗号化の証拠ではありません。

接続時にどのコンポーネントが値を読むのかを、ベンダーまたは管理者に確認してください。

次に、文書化されていれば保護 API を特定します。Windows では CryptProtectData が、暗号化するユーザーのログオン資格情報から導出した鍵でデータを保護し、マシン単位のオプションによって復号できる相手が変わります。これは範囲がなぜ重要かを示す具体的な例です。特定の VPN クライアントがその API を使っている証拠ではありません。

盗まれたコピーと実行時の利用を分けて考える

尋ねずに再接続するクライアントには、資格情報を復元するためのサポートされた手段が必要です。バックアップのコピーを保護しても、その能力はなくなりません。正しいユーザーコンテキストで動くプログラムなら同じ経路を使える可能性があり、だからこそエンドポイント自体が信頼境界の内側にあります。ファイルのアクセス許可とプロセスの特権はその境界を狭めますが、なくしはしません。

オフラインファイルに関する主張が通常取り違えるのは、この区別です。保存時の暗号化は、アカウントなしで一つのファイルをコピーする相手を止められます。アカウントとして動くコードは止められません。

両方の主張は同時に成り立ち得ますし、インシデント対応で重要なのは後者です。

実際に適用されるアクセス制御を読む

ファイルの ACL とその上位ディレクトリを確認し、ファイルモードだけを見ないでください。Windows では、ユーザープロファイルの実効アクセス許可を、クライアントのサービスまたはスケジュールされたタスクの許可と比較します。あるユーザーに対して保護された秘密は、管理者から自動的に保護されるわけでも、自動的に管理者に露出するわけでもありません。

icacls "%APPDATA%\Vendor\Client\profiles.xml"
whoami /priv

クライアントを実行している ID が復号の主体だからこそ、その ID を記録してください。

管理された端末群では、該当する制御はファイルではなくデバイス管理である場合があります。資格情報が委託保管されているか、遠隔で失効できるか、端末を紛失したときの手順は何かを確認してください。

復号を試すのではなく、露出に備えて計画する

主張を通すために、未知の抽出ツールをファイルに対して実行しないでください。動くかもしれませんし、プロファイルを壊すかもしれませんし、いずれにせよ証拠を変えてしまいます。文書化された設計と、検証が本当に必要なら承認された評価を使ってください。

露出が確認されたら、ID の所有者のところで資格情報をローテーションします。

保存されたエントリを削除することは失効ではない。それによってそのクライアントが値を再提示するのを止められますが、すでに取得されたコピーやすでに承認されたセッションには何の効果もありません。資格情報を交換し、所有者が終了できるセッションを終了し、何をいつローテーションしたかを記録してください。

ベンダーレビューで尋ねる質問

どの秘密が保存され、どのコンポーネントが使い、どのユーザー鍵またはマシン鍵が保護し、通常利用とバックアップにどのアクセス制御が適用され、保存ポリシーと遠隔失効がどう扱われるかを尋ねてください。その五つの答えが設計を説明します。XML は説明しません。

次のレビュー担当者が同じ作業を繰り返さないよう、回答を配備記録と一緒に保管してください。

保存された資格情報は利便性と露出の交換です。その交換を意図的に行い、誰が受け入れたのかを書き留めてください。