ホストの組における保護は、セキュリティアソシエーションが終端する場所から始まる。そしてこれは、ゲートウェイを前提とした直感が最も取りこぼす事実である。アプリケーションサーバーとそのデータベースサーバーは、経路上にリモートアクセス集約装置がなくても、自分たちの会話を直接保護できる。そのとき保護の境界はファイアウォールではなく、各ホストの内部に置かれる。

境界は SA が終端する場所

RFC 4301 は、トランスポートモードのセキュリティアソシエーションを、ホストの組の間でエンドツーエンド保護に使う典型的な構成として説明している。その二台のホストが鍵を保持し、それぞれが自分のどのパケットをアソシエーションに入れるかを決める。ゲートウェイのトンネルはまったく別の場所で終端し、追加の内部セグメントを通ってホストに届くので、パケットが行程の大半で暗号化されていても、それは別の信頼境界になる。

ただし、ホスト間とトランスポートモードは同義ではない。二台のホストの間でトンネルモードのアソシエーションを構築するのも同じくらい正しい選択なので、まずモードを選び、それから端点を記述する。モードだけを知っているレビュー担当はもう一方を想定してしまうため、ピアアドレスの隣の設計メモに両方を書き留めておく。

保護を決めるのは SPD、方向を決めるのはルート

ルーティングテーブルが答えるのは、パケットがどこへ行くかである。セキュリティポリシーデータベースが答えるのは、選んだトラフィックがどのように保護境界を越えるかであり、それを方向ごとに独自のセレクタで答える。この分離があるため、データベースへの経路が通っていることは要求が保護されたことを何も証明せず、また 確立済みのネゴシエーションがあること も、この特定のアプリケーションがそれに一致したことを何も証明しない。カウンタを比べる前にセレクタを比べるべきで、カウンタはそこまで到達したフローしか表していない。

Linux では、ip xfrm policy がそうしたエントリを方向・優先度・セレクタ・allow/block/trap の動作とともに表示し、ip xfrm state が結果としてできるアソシエーションとそのカウンタを表示する。両者を突き合わせて読むことで、より広い allow エントリが先に一致したためにトンネルを静かに迂回したフローを見つけられる。

優先度の順序は実装の詳細ではなく、ポリシーの一部である。データベースのポートを保護すべき狭いエントリは、より優先度の高い広いエントリに負けてしまい、その障害はポリシーが一度も参照されなかったように見える。

トランスポートモードが覆うのは次の層であり、IP ヘッダーではない

Transport modeTunnel mode
Original IP headerkept for routing the flowreplaced by an outer header
What ESP protectsthe carried next-layer payloadthe whole inner IP packet
Where it terminatescommonly the two hostsgateway pair, or a host pair

トランスポートモードでは、ESP ヘッダーは IP ヘッダーとペイロードの間に置かれ、そのヘッダーのアドレスフィールドは経路上のすべての装置から見えたままになる。アドレスが秘密ではなくペイロードが秘密である場合、これは問題ない。内部のトポロジーも隠す必要があるなら誤った選択であり、元のヘッダーを新しいヘッダーの中に包むのはトンネルモードだけである。

どちらのモードも複数の次層プロトコルを運ぶことができ、ESP はホストが送るすべてではなく、セレクタが一致したものを保護する。

選択の範囲は接続より狭い

ひとつのアソシエーションは複数のフローを運べるが、運べるのはポリシーが選んだものだけである。意図する関係について、ピアの ID、送信元と宛先のアドレス、プロトコル、サービスの範囲を記録し、それとは別に、一致しないトラフィックを平文で通してよいのか、保護しなければならないのか、アソシエーションが使えないときは破棄しなければならないのかを決める。最後の判断が意外を生むのは、誤った送信元に保護を要求するルールが、侵入者を遮るのと同じくらい確実に自分たちの管理アクセスも遮ってしまうからである。

適用の設定を変えている間は、承認済みの帯域外経路を確保しておき、両方のホストが到達不能になってからではなく、必要になる前に試験しておく。

マシンの ID はアプリケーションの権限ではない

IPsec は設定されたピアを認証し、選んだパケットを保護する。人がどのデータベースレコードを編集してよいかを決めるものではなく、信頼されたサーバーの ID をあらゆるアプリケーション権限の付与に変えるものでもない。アプリケーションのアカウント、ロール、認可はそのままの場所に残り、アプリケーション層の TLS 要件は、ネットワーク経路がすでに保護されていても独自の目的を保つ。

設計を受け入れるときは、想定した送信元からの操作をひとつと、拒否されるべき操作をひとつ使って確認し、必要なアソシエーションを確立できない場合に何が起きるかも含めておく。ふつうの到達性テストはパケットが流れることを教えてくれるだけで、書いたポリシーの下で流れたことは教えてくれない。

関連記事