暗号化された通過はキャリアへのアクセスを許さない

二台の承認済みゲートウェイが、信頼度の低いネットワークのトラフィックを制限された転送ネットワーク越しに運ぶ。ペイロードを暗号化すれば、通常の経路観測者には読めなくなる。これは人が最初に設計し、その後は考えなくなる部分である。暗号化が行わないのは、信頼度の低い側がどのリソースに到達できるかを定義することだ。設計には二つの境界が必要だ。運ばれる会話を囲む境界と、キャリアそのものへのアクセスを囲む境界である。

以下の手順を順番に実行し、どの手順での失敗も設定の微調整ではなく設計の変更として扱うこと。

設定に触れる前に両方の境界を定義する

第一の境界は会話である。どのゲートウェイの組がトンネルを確立でき、どの内部トラフィックをその中に通すか。第二はキャリアである。信頼度の低いホストがトンネルの外でどのアドレスとサービスに到達できるか。チームは通常、第一の境界を作り、第二の境界は既存のルーティングから引き継ぐ。こうして制約された設計が静かに広い設計へと変わる。レビューで信頼度の低いホストが誰も承認していない相手と通信していると分かったとき、その継承がよくある根本原因である。

両方をアドレス、ポート、方向の一覧として書き出すこと。一覧を書けないなら、境界はまだ定義されていない。

ステップ 1：外側のトンネルを制約する

キャリア側のインターフェースでは、トンネルに必要なものだけを許可する。二つのゲートウェイアドレス間の UDP 500 と 4500 の IKE、そして NAT トラバーサルを使わない場合の ESP である。そのインターフェースに届くほかのすべては、管理プロトコルも含めて拒否する。ESP 仕様は保護サービスを扱うが、ゲートウェイがキャリア自身のどのサービスを使えるかについては何も述べていない。明示的な許可リストとして表現し、新しく公開されたキャリアのサービスが既定で到達可能にならないようにする。

これが、設計をピアリングの取り決めではなく通過設計にするルール群である。

確認はゲートウェイのコンソールからではなく、信頼度の低い側から行う。そこのホストは、トンネルが上がる前からキャリアの DNS サーバーに到達できないはずだ。

ステップ 2：遠端のゲートウェイが何を届けるかを決める

遠端では、復元されたトラフィックが特定の場所へ行かなければならない。どの内部サービスを、どの送信元範囲から許可するか、応答が対称であることを期待するかを定義する。管理アクセスは別に確認する。同じゲートウェイが、通過計画の一部ではなかった管理インターフェースをしばしば公開しているからだ。

復号の成功で止まる図は、最も重要な決定を飛ばしている。

ステップ 3：層ごとに所有権を保つ

通過装置は今も外側のパケットを受信して転送するため、パッチと容量計画が必要である。トンネルの端点は保護されたプロトコルを処理し、内部トラフィックを自分の転送経路に公開するため、独自のルールと独自の監視が必要である。最終的なアプリケーションはペイロードを処理する。不透明なペイロードは、復号されたダウンロードが無害である証拠にはならない。

各層に所有者を割り当てる。所有者のいない層こそがずれていく。

ステップ 4：検証し、その後で所管当局に引き渡す

トンネルを上げ、キャリアのルールを適用した状態で外側の経路を検証する。次に、信頼度の低い側が到達すべきでない各リソースを試し、失敗が拒否であって経路を隠すタイムアウトではないことを確認する。可用性とリソース上限も確認する。暗号化されたリンクでも飽和しうるからだ。

規制対象または分類された環境では、設計を所管のセキュリティ当局に持ち込み、その承認済みの分離アーキテクチャを使う。VPN 設定と概念的な説明は認定を確立しない。この手順は書類仕事ではない。設計がそもそも存在してよいかを決めるものである。