ベンダーの図は通常、暗号化されたリスナーで終わる。公開アドレスを持つのはその部分だからだ。セキュリティ態勢を決める問いは、復号後に何が起きるかである。パケットは通常のIPになり、ルーティングテーブルが許す限りの到達先に届く。その区間を誰も描いていなければ、誰も責任を持たない。以下の手順はまずそれを描き、次に復号されたリクエストが実際に何を越えるかで配置を比較する。

復号後のパケットを描く。復号前ではない

外側の経路はベンダーが文書化する部分である。公開エンドポイント、接続を許可するトランスポートポリシー、そして接続を終端するサービスだ。内側の経路は、パケットがトンネルのヘッダーを失った瞬間に始まり、そこからはトンネルとは無関係なルーティングとフィルターの規則が支配する。両方を同じページに置くこと。最初のものだけを示す図は、受け入れと認可が一つの判断だと示唆してしまう。そうではなく、両者の間の隙間こそが、ほとんどの配置が誤る場所である。

内側の区間は、矢印ではなく、名前を付けた機器種別による番号付きの順序として書く。矢印はリクエストがフィルターを越えるかどうかを隠すが、越えるか否かが問いのすべてである。以下の各ホップは機器とそこで働くルールセットを名指しするので、欠けているフィルターは線で示唆されるのではなく隙間として現れる。

  1. リモートクライアント:トンネルを生成する利用者側の機器。
  2. エッジポリシー:外側のトランスポートを公開リスナーへ受け入れるルールセット。
  3. 終端アプライアンス:カプセル化を解除し、パケットを通常のIPに渡すVPNエンドポイント。
  4. 内側フィルター:クライアントからサービスへの通信を制限する転送規則またはセキュリティグループのルールセット。
  5. アプリケーションホスト:復号されたリクエストを受け取るサービス。

二つのポリシー、二人の所有者

外側のポリシーは、誰がトンネルを確立できるかに答える。それは終端サービスへのトランスポートを許可する規則に表れる。内側のポリシーは、認証された利用者がどのサービスに到達できるかに答える。それは転送規則、セキュリティグループ、あるいはアプリケーション自体の中に存在する。一つの機器が両方を担うこともでき、複数の機器による設計でも両方は存在する。それらを別々に名付けることで初めて、利用者がアプリケーションに届かないときに、どちらが失敗したのかを言える。

証明書や多要素認証といった受け入れの制御は、身元に答えるだけで、それ以外には答えない。配置を決めることもなく、利用者が内側に入った後にリソース単位の許可を与えることもない。

配置が、リクエストが越える境界を決める

三つの配置が一般的であり、それぞれが復号されたリクエストの越える境界を変える。そこで何が終端するか、何が平文を見られるか、どの制御がなおリクエストを拒否できるか、アプライアンスと共に何が落ちるかで比較する。以下の表は一般論の問いではなく、それら四つの列を使う。答えのそれぞれが別の設計判断だからだ。

PlacementWhat terminates thereWhat sees plaintextWhich control can still denyFailure domain
Termination in a dedicated segmentA dedicated VPN endpointThe endpoint and anything on its segmentThe filter between that segment and the applicationThe segment path can bypass the filter if no rule sits on it
Termination on the edge firewallThe firewall's public listenerThe firewall, after decapsulationThe firewall's inner rule setAdmission and inspection fail together
Termination on the protected LANThe appliance's LAN legEvery host on the protected LANOnly a host control or a downstream gatewayThe appliance and the protected hosts fail together

第三の配置は、適用を静かに取り除くものである。保護されたセグメント上の区間は、図が示さないかもしれない直接の経路をアプライアンスに与える。絵ではなくインターフェースと経路を調べること。ip route get 10.20.5.10 はパケットがどのインターフェースから出るかを報告し、その答えは設計が想定したものではないことが多い。ポスチャ間の通信を制御するというファイアウォールの古典的な役割は、次の文書に記述されているとおり、ここで有用な試験になる。NIST SP 800-41。保護されたネットワークへの無制限の区間を持つ機器は、ほとんど何も制御していないからだ。経路の照会は、プレゼンの図より正直な図である。

管理は、明示的に許可された独自の経路に属する。利用者にアプリケーションへの到達を許すことは、機器の制御インターフェースへの到達を許すことを決して要求しない。二つの許可は別の規則から与えるべきである。両方の経路を別々に監査すること。共有された規則は、どちらが開かれたのかを隠す。

変換は、下流の規則が見えるものを変える

送信元変換は便利であり、情報を破壊する。masquerade の後では、どのクライアントもアプライアンスのように見えるので、利用者を区別するために書かれた下流の規則はもはやそれができない。これは記録だけの問題ではなく、ポリシーの問題である。クライアントアドレスを鍵とする規則は、静かにゲートウェイを鍵とする規則になる。利用者ごとのポリシーが重要なら、送信元を保つか、変換の前にポリシーを適用すること。

戻りの経路も同じ精査に値する。宛先が戻りパケットにどの経路を選ぶかを記録すること。非対称な戻りはステートフル検査を迂回し、確立した後に止まる接続を生む。両方向が描いた境界を越えなければ、その境界は飾りである。

sudo tcpdump -ni inside0 host 10.20.5.10
ip route get 10.20.5.10
sudo iptables -t nat -S POSTROUTING

許可される操作と拒否される操作を受け入れる

管理ホストからではなく、実際のリモートクライアントから試験すること。管理ホストは通常、利用者が決して行かない場所に座っている。許可される操作が一つあれば経路が機能することが証明され、拒否される操作が一つあればポリシーが何かをしていることが証明される。配置を変えるたびに両方を実行し、使った送信元の識別と宛先を記録すること。成功だけを証明する試験は、正しい規則と欠けた規則を区別できない。

次に、状態を変える場合を試験する。再接続、鍵のローテーションを超えて続くセッション、アプライアンス自体の故障である。更新、容量、復旧を同じ配置の一部として比較すること。複数の論理制御を抱える一つのアプライアンスは、複数のラベルをまとった一つの故障ドメインである。共有の管理者資格情報や無制限の経路が、作るはずだった境界を破るなら、二台目の箱も独立ではない。

エンドポイント、復号された経路、それを制限する制御を文書化すること。実装が何と呼ばれようと、その三行は意味を持ち続ける。

関連記事