TLS VPN と IPsec：確認する価値のある五つの項目
TLS VPN と IPsec VPN を、リリース、プロトコルバージョン、スイート、ピアの識別情報、公開される範囲、そして実際に設定した障害時の結果で比較します。
TLS VPN を IPsec VPN とプロトコルファミリーで順位づけしても、誰も問うていない疑問に答えるだけで、たいていは両ファミリーが何年も前に捨てた構成を引き合いに出します。レビュー担当者が実際に評価できるのは、交渉された保護、ピアの識別情報、クライアントモデル、公開されるサービスです。この四つは配備の中で見え、どれも製品ラベルから導けるものではありません。五つの項目を求めれば、会話は具体的になります。
五つの項目、ラベルはその一つではありません
一つ目はサポートされるソフトウェアリリースです。バージョンのないプロトコル説明はパンフレットにすぎません。二つ目は交渉されたプロトコルバージョンで、どの構成がそもそも利用できるかを決めます。三つ目は保護スイート、四つ目はピアと利用者の両方の認証方式、五つ目は製品が受け入れ後に与えるアクセス範囲です。
SSL VPN というラベルは少なくとも三つの異なる製品を覆います。フルネットワーククライアント、アプリケーションプロキシ、そしてブラウザベースの旧来のポータルです。公開するサービスも失敗の仕方も異なるため、ラベルは範囲の項目の代わりにはなりません。
| Field | What a usable answer looks like |
|---|---|
| Release | A version with a support window, not a family name |
| Protocol version | TLS 1.3 or IKEv2 with the ESP suite named |
| Protection suite | An authenticated-encryption algorithm, not a cipher list |
| Authentication | Peer identity plus user or device identity, separately |
| Access scope | The services reachable after admission |
認証付き暗号化が実際に変えるもの
TLS 1.3 は認証付き暗号化を必須とし、古い MAC-then-encrypt 構成を任意として残すのではなくプロトコルから取り除きます。IPsec ESP にも同じだけ前から認証付き暗号化スイートがあり、AES-GCM は独自の RFC で定義されています。どちらのファミリーでも保証はファミリー名ではなく交渉されたスイートから来るため、項目一覧はバージョンから始まります。スイートを名指しできないレビュー担当者には評価するものがありません。
だから歴史的な比較は誤解を招きます。CBC スイートのまま古い TLS バージョンに固定した配備と、AEAD スイートで TLS 1.3 を動かす配備は、どちらも TLS VPN であっても同じセキュリティ姿勢ではありません。同じ分裂は IPsec 側にも、現代の ESP スイートと旧来の組み合わせの間にあります。
意図した設定ではなく、交渉された値を読んでください。以下のコマンドは、稼働中のエンドポイントと稼働中のトンネルが実際に何に合意したかを示します。
openssl s_client -connect vpn.lab.example:443 -tls1_3 -brief
ip xfrm state
swanctl --list-sasエンドポイントが TLS 1.3 を交渉しないなら、それは設定の好みではなく所見です。トンネルが想定外のスイートを列挙しているなら、重要な設定はピアが選んだものであり、テンプレートにあるものではありません。
ピアの識別情報は別の問いです
検証されたピアのない暗号化は、通信を観察者から守りつつ、接続に応答した相手にそのまま渡します。ピア認証は、どの識別情報を期待するのか、どの信頼材料がそれを検証するのか、答えが一致しないときにクライアントがどう振る舞うのかを問います。証明書チェーン、ピン留めした鍵、事前共有秘密は、それぞれ運用コストの異なる三つの答えです。
次に利用者や端末について同じ問いを立ててください。マシンを認証して誰でも受け入れるゲートウェイ、あるいはその逆は、想定ではなく書き留めるべき固有の姿勢を持っています。受け入れ後に適用されるリソース権限は同じ項目の一部です。認証は認可ではないからです。
ホスト名と証明書の検証を保つことは、ログイン画面の見慣れ以上に重要です。検証を無視するよう設定されたクライアントは、あなたのゲートウェイを説得力のある模倣から区別する唯一の手順を外しています。
製品が公開する境界
クライアント不要のポータルは、選ばれたアプリケーション操作をゲートウェイ経由で代理するため、利用者はネットワークではなくインターフェースに到達します。フルトンネルクライアントは経路とフィルタリング方針が選ぶものすべてを運び、はるかに大きな面になります。両者をプロトコルの強さで比べると、攻撃者がそれらを通じて何に届くかという違いを見落とします。一方はアプリケーションのインターフェースを、他方は経路制御されたネットワークを公開し、両者は異なるレビューを必要とします。
どのサービスが公開され、どの操作が認可され、ゲートウェイ自体が何を待ち受けているのかを尋ねてください。利用者ポータルと同じアドレスから到達できる管理インターフェースは配備上の所見であり、どのプロトコル選択もそれを補いません。
アプリケーションごとの範囲は面をさらに狭め、トンネルが落ちたときの障害時の振る舞いも変えます。フルトンネルの到達を前提とする設計は、アプリごとの設計が知らない壊れ方をし、サポート負荷がそれに続きます。
障害時の結果とライフサイクルを決めてください
認証や保護が利用できないときに何が起きるかは、レビューに属する方針の決定です。遮断された結果と告知のない直接フォールバックでは結果が異なり、その違いは機能一覧からは見えません。意図した振る舞いを、それが守るリソースの隣に書いてください。
ゲートウェイのパッチとサポートのライフサイクル、有効化された外部機能、クライアントの更新経路を含めてください。正しいプロトコル選択は、まずい配備のサービスを安全にはしません。多くの事故はスイートではなく、その隙間に住んでいます。
五つの項目、障害時の方針、ライフサイクルの責任者を一ページに書いてください。そのページがレビューであり、プロトコルファミリーの比較は意見です。