4方式を比べる5つの判断基準

この記事では5つの観点で比べる。1つ目の「攻撃される入口の大きさ」は、インターネットから直接届くサービスやポートがどれだけあるかを指す。2つ目の「パッチ運用の負担」は、脆弱性が公表されてから修正を当てるまでの作業を、誰がどれだけ早く回す必要があるかである。3つ目の「ログの取りやすさ」は、誰がいつどのシステムに入ったかを後から追えるかどうか。4つ目の「導入費用」は、初期費用と、利用者数に応じて増える継続費用を分けて考える。5つ目の「既存システムとの相性」は、オンプレミスの業務アプリや独自の通信方式を作り替えずに通せるかを見る。

どの基準を重く見るかで答えは変わる。入口を小さくすることを優先するならZTNAが有利になる。既存の資産をそのまま通すことを優先するならVPN系が有利になる。管理者が少なく、修正を即日当てられない組織では、パッチ運用の負担を最優先にする。VPN機器の脆弱性は公表直後から悪用されることが多く、修正が遅れればそのまま侵入につながるからである。

方式ごとの比較表

方式入口の大きさパッチ負担ログ費用の傾向既存との相性
SSL-VPN大(Webポータルを常時公開)高(自社で即時適用)接続記録が中心で、通信先の粒度は粗い機器と保守。利用者が増えても上がりにくい高
IPsec VPN中(IKEのUDPポート)中〜高接続記録が中心機器と保守。クライアント設定の手間がかかる高。ただし通らないネットワークがある
ZTNA小(受信ポートを開けない構成が可能)低(コネクタの更新が中心)アプリ単位で詳細月額・利用者単位の課金中。通信方式に制約がある製品もある
踏み台/RDゲートウェイ中(HTTPS 1ポート)中(OSの月例更新)操作セッション単位で詳細サーバーとライセンス。比較的低い低〜中。画面操作・SSHが中心

方式ごとの強みと弱点

SSL-VPN(VPNアプライアンス)

ブラウザか軽いクライアントですぐ接続でき、接続後は社内ネットワーク全体に届く。既存システムとの相性は4方式で最も高い。弱点は入口の大きさにある。執筆時点でも、Fortinet、Ivanti、Palo Alto Networks、Citrixなど主要ベンダーのVPN製品やゲートウェイ製品で、認証前に悪用できる脆弱性が繰り返し公表され、実際の攻撃に使われてきた。米CISAのKnown Exploited Vulnerabilities Catalog(悪用が確認された脆弱性の一覧)にも多数載っている。さらに、ネットワーク単位で中に入れるため、認証情報が漏れると横展開(侵入後に他の端末へ広がること)を止めにくい。一部のベンダーはSSL-VPN機能を縮小し、IPsecやZTNAへの移行を案内している。自社で使っている機種のサポート方針を確認しておく必要がある。

IPsec VPN

IKEv2などの標準規格に基づく方式で、拠点間の接続にも使える。Webポータルを持たないため、SSL-VPNより公開する面は小さい。ただし、同じ機器でSSL-VPNや管理画面を公開していれば、入口は結局小さくならない。ホテルや公衆Wi-FiではIKEが使うUDPの通信が遮断され、つながらないことがある。ネットワーク単位で中に入れる点はSSL-VPNと変わらないため、接続後のアクセス制御は別に設計する必要がある。

ZTNA(クラウド型のアクセス制御)

ZTNAは、利用者と社内アプリの間をクラウドの仲介サービスが取り持つ方式である。利用者のIDと端末の状態を確認し、アプリ単位で接続を許可する。社内側には外向きの通信だけを行うコネクタを置くため、受信ポートを開けずに済む。Zscaler Private Access、Cloudflare Access、Microsoft Entra Private Accessなどが代表的な製品である。考え方の土台はNIST SP 800-207にまとまっている。

弱点は4つある。1つ目は、IdP(ID基盤)が事実上の入口になることだ。多要素認証や条件付きアクセスの設定が甘ければ、効果は大きく落ちる。2つ目に、提供事業者のサービスが止まると全員が入れなくなる。3つ目に、利用者単位の課金なので、人数が多いほど継続費用がかさむ。4つ目に、アプリの棚卸しと通信方式の確認が前提になるため、導入には時間がかかる。サーバー側から通信を始めるアプリや、特殊なUDP通信を使うアプリは、製品によっては通しにくい。

踏み台サーバー/RDゲートウェイ

RDゲートウェイはWindows Serverの役割の一つで、リモートデスクトップの通信をHTTPSで包んで中継する。リモートデスクトップのポートをそのままインターネットに公開する構成とは別物である。直接の公開は避けなければならない。強みはログで、誰がどのサーバーに何時間接続したかを残せる。操作を録画できる製品もある。弱点は用途の狭さだ。管理者によるサーバー操作や特定端末の画面操作には向くが、一般社員がファイルサーバーや業務アプリを日常的に使う用途には向かない。また、踏み台が乗っ取られると、その先の全サーバーに届く。踏み台自体の更新と権限の絞り込みは、他のサーバー以上に厳しく行う必要がある。

組織の規模と管理体制ごとの選び方

専任の情報システム担当がいない小規模組織

自社でVPN機器を公開し、緊急の修正を即日当て続けるのが最も難しい体制である。ZTNAのように事業者が入口を運用する方式を優先するとよい。予算の都合で既存のVPN機器を使い続ける場合は、保守契約の継続、脆弱性情報の通知受信、管理画面の非公開、多要素認証の4つを最低条件にする。目的が特定のPCやサーバーの遠隔保守だけなら、RDゲートウェイで足りることも多い。

情報システム担当が数名いる中規模組織

一度にすべてを置き換えるより、段階的に移す方が現実的である。Webアプリやクラウド化した業務からZTNAへ移し、管理者のサーバー操作は踏み台に集める。そのうえで、VPNの利用者と届く範囲を絞っていく。VPNを最後まで使い続ける業務が何かが明確になれば、機器の更新時期に廃止できるか判断しやすい。

セキュリティ専任部門がある大規模・多拠点組織

方式を役割で分けるのが一般的である。拠点間の接続にはIPsec、社員のアクセスにはZTNA、特権操作には踏み台と特権ID管理を使う。各方式のログはSIEM(ログの集約・分析基盤)に集める。ZTNAは人数が多いほど費用が大きくなるため、契約条件の交渉とIdPの冗長化を計画に含める。

工場や医療機器など古いシステムが残る環境

独自の通信方式や古いOSが残る環境では、ZTNAで通せない通信が出やすい。その部分に限ってIPsecや踏み台を使い、届く範囲を最小限に区切る。

選定前に確認すること

まず、インターネットに公開しているVPN機器と管理画面を洗い出す。次に、機種とバージョンを前述のKEVやJPCERT/CCの注意喚起と照らし合わせる。そのうえで、過去の脆弱性公表から修正適用までに実際にかかった日数を調べる。この日数が数日を超えるなら、自社で運用して公開する機器を減らす方向に進めるべきである。方式で迷ったときは、「脆弱性が公表された翌日に、誰が修正を当てられるか」を判断の基準にする。答えが出ない方式は、自社の体制では選ばない方がよい。脅威の状況は変わり続けるため、導入後も各ベンダーの公式アドバイザリを定期的に確認する。