誰が本当にレビューできるVPN設計ブリーフを書く

設計レビューの多くは最初の問いで止まる。依頼が判断ではなく製品を説明しているからだ。フロー、担当者、障害時の振る舞いを明示したブリーフなら、一度の会議で答えを出せる。安全なVPNを構築せよというブリーフには、そもそも答えようがない。何かを送る前に以下の六つのチェックを通せば、レビューは議論ではなく比較になる。

第一に、その問いは判断か願望か

判断には選択肢があり、その間を選ぶ観察がある。どれを選ぶために何を見るのか言えないなら、その問いはまだ願望だ。まず選択肢を書き出す。リストが二項目だけでも構わない。次に、それらを分けるトレードオフを書く。

願望は読み手も隠しがちだ。設計を誰が承認するのかを書く。同じブリーフでも、ネットワーク責任者、セキュリティレビュアー、財務承認者では読み方が違う。

答えが誰でもないならここで止める。持ち主のいない判断は、最も大きな声で不満を言う人によって作り直される。それは設計の問題ではなく統制の問題だ。

第二に、フローと拒否を明示する

機能すべきすべてのフローについて、送信元、宛先、アプリケーションを列挙する。次に、失敗し続けるべきフローを列挙する。黙って許可する設計は、そう言わずに要件を変えてしまっている。アドレスの重複や上流への到達性は、驚きではなく制約としてこのリストに入る。

方向を具体的に書く。本社への接続を開始できる拠点と、受け入れるだけの拠点は別の設計であり、その違いは後で書くすべてのルールに現れる。

エージェント付きの管理端末は、持ち込みのノートPCにはできないことができるので、クライアントとその管理状態も記す。

リストは検証できる長さに保つ。検証できる十本のフローは、検証できない四十本より優れている。

チェック 3：事実と仮定を分ける

検証した記述には印を付け、検証していない記述にも印を付ける。パブリックアドレス、利用可能なスループット、管理者アクセスの三つが、答えを最もよく変える仮定だ。そのうち一つが不明なら、どちらに転んでも設計がどう変わるかを書く。

例示用のネットワークは、ラベルを付けておけば問題ない。問題は、これまで持ったことのない二本目の上流リンクやパブリックアドレスブロックを、黙って手に入れる仮想の支社だ。

測定された一つの事実が議論の枝をまるごと消すので、レビューの前に確認できる仮定を確認する。

ip route get 10.50.0.10
traceroute -n -m 6 10.50.0.10
nc -vz 10.50.0.10 443

第四に、障害時の契約を書く

トンネルが落ちたときに何が起きるかを書き、二つの異なる約束を明確にする。再接続後に新しい接続を復旧させるのは約束しやすい。障害をまたいで確立済みのセッションを維持するのははるかに強い要件であり、技術の選択を制約する。

次にフォールバックを決める。通信を遮断するか、別の承認済み経路に流すか、アプリケーションごとに別のことをする。直接経路への静かなフォールバックも、誰も書いていなくても設計判断だ。

復旧目標として、拠点が劣化状態で稼働してよい時間や、インシデントを宣言する人などを平易な言葉で加える。

チェック 5 と 6：継ぎ目を選び、変更を記録する

すべてを決めようとするレビューは何も決めないので、議論する継ぎ目を一つ選ぶ。ルーティング、認可、暗号化は三つの異なる継ぎ目であり、ブリーフは問いがどれについてかを書くべきだ。RFC 4301 はここで有用な念押しである。ポリシー判断、保護された通信、セキュリティアソシエーションを一つの対象として扱わず分けているからだ。

次に、判断の後に何が変わったかを、修正した仮定も含めて記録する。その記録が次のレビューを短くする。

git diff --stat design/vpn-brief.md
grep -n 'assumption' design/vpn-brief.md
ip route get 10.50.0.10

六つのチェックをすべて通ったブリーフは、答えのある問いを生む。設計が示されたフローと障害時の契約を満たすか、名指しされた制約がそれを妨げるか、だ。後で制約が変わったとき、記録はどの判断を見直すべきか、どれが維持できるかを示す。だからこの演習は一度きりの議論ではなく、再利用できるものになる。