VPNロックダウンの例外を、後から削除できる形で記録する方法
誰も説明できない例外は永久に残る。その例外が許可する通信、要件、障害時の動作、そしてそれを削除するコンポーネントを記録しておく。
目的が作者とともに去ったバイパスこそが、有用性を超えて生き残るものであり、ロックダウンポリシーは他のどの種類の設定よりも速くそれらを溜め込む。「ローカルネットワークを許可」と書かれた例外は、誰も擁護できず、誰も廃止できないルールである。その背後にある要件が、追加した人物とともに去ってしまったからだ。こうしたポリシーは、理由が蒸発したのにリスクだけが残った免除を抱え込むことで失敗する。スコープ、障害時の動作、削除手順を書くべき瞬間は、誰かがまだ理由を覚えているうちに、例外を追加するその瞬間である。
これはメモに何を含めるべきかという決定であり、埋めるべきテンプレートではない。以下の四つの項目が、一年後に会議なしでレビュー担当者がルールを削除できるかどうかを決める。どれも、欠けていることのコストが予測できるから存在する。
文書化されていないバイパスが決して廃止されない理由
説明のないバイパスはテストできず、したがって安全に削除できない。削除は危険に見え、保持は無害に見えるため、あらゆるレビューをすり抜け、すり抜けるたびに次のレビューもすり抜けやすくなる。コストは、監査がなぜプライベートレンジが免除されているのかと問うまで見えず、その頃には答えは肩をすくめることになる。
記録は、変更作業の時間内に実際に書ける程度に短くなければならない。通信に一行、それが満たす要件に一行。
スコープを通信として書く
アプリケーションまたは宛先レンジ、関与するアドレスファミリー、サービスとポート、ルールが適用されるネットワーク文脈を列挙し、承認者とそれを保持する正確なクライアントまたはプラットフォーム設定を名指しする。「プリンター」は意図にすぎない。「TCP 631 から 192.168.1.50、自宅ネットワークのみ」は誰かが検証できるスコープである。「これはどこにあるのか」への答えが「MDMプロファイルのどこか」なら、記録は未完成だ。ファイルパス、プロファイル名、レジストリキーのほうが、設定がありそうな場所の説明より優れている。
プラットフォームがアプリケーション単位のルールをサポートする場合は、アドレスレンジよりそちらを優先する。一つのアプリケーションにトンネルの迂回を許すほうが、プライベートサブネット全体を免除するより狭く、端末が新しいアドレスに移っても維持されるからだ。Android の VpnService ガイドはそのアプリケーション単位のモデルを説明している。デスクトップクライアントも独自のプロファイル設定を通じて同じ考えを表現する。アドレスベースの免除は、プラットフォームがより狭い手段を提供しないときの代替であり、だからこそより鋭いスコープ行が必要になる。
四種類の例外、四つの削除リスク
例外は一つのカテゴリではなく、その削除は異なる結果をもたらす。二種類の間で一行を共有するのは、プリンターの廃止が接続能力の廃止にもなるというやり方だ。
| Kind | Typical example | Removal risk |
|---|---|---|
| Endpoint bootstrap | reaching the gateway before the tunnel exists | high: nothing comes up without it |
| Captive portal | hotel or airport sign-in page | medium: only matters on untrusted networks |
| Local device | printer, casting target, test instrument | low: one service at one address |
| Excluded application | an app that must not use the tunnel | medium: depends on the app's own behaviour |
bootstrap、ポータル、デバイス、アプリケーションの例外は、実際に重なっていても別の行に保つ。プライベートレンジの免除は、到達したい一台のデバイスではなく、そのサブネット上のすべての隣人に静かにアクセスを与える。それが、擁護できるスコープと、願うだけのスコープの違いである。
トンネルが落ちたとき、バイパスは何をするか
三つの問いを立てて答えを書き留める。それがロックダウンが本物かどうかを決めるからだ。トンネルが落ちても例外は使えるままでいるか。キャプティブポータルなら使える必要があり、そうでなければ誰もサインインできない。一方、プライベートなリソースなら通常は使えてはならず、そうでなければポリシーは飾りになる。すべてのネットワークに適用されるのか、意図した環境だけで適用されるのか。自宅サブネットに限定したルールは、たまたま同じレンジを使う公衆ネットワークではまったく違う振る舞いをする。どの答えもルールとメモの両方を変えるので、答えを残した問いは、後で誰かが誤って下す決定である。
三つ目の問いは、宛先がアドレスを変えたときに何が起きるかであり、ここでドメインベースとアドレスベースの免除が分かれる。ドメインベースのルールは、名前解決がいつ行われるかと、クライアントが結果をどう適用するかに依存するため、無関係に見える変更の後に静かに一致しなくなることがあり、障害は古い免除ではなく壊れた VPN のように見える。
テストし、再テストし、削除手順を書く
許可される経路に無害なテストを一つ、近くの拒否されるケースを一つ書く。プリンターのページは読み込まれ、同じサブネット上のファイル共有は読み込まれない。この組が例外の狭さを証明し、レビュー担当者が元の依頼を理解せずに再現できる組でもある。次に再テストのきっかけを設定する。一度も再テストされない例外は、書かれた要件から離れていき、そのずれは何かが壊れるまで見えないままだ。
最後に、ルールを所有するコンポーネントを通じて削除する方法を記録し、秘密情報はメモに残さない。サービスと経路を説明するのに秘密鍵、パスワード、誰かの閲覧履歴は決して必要なく、短く保守された一覧は、書いた人より長生きした一時的なルールに勝る。