VPNの「城壁」を解体せよ：ゼロトラスト（ZTNA）への現実的な移行戦略
こんにちは。ネットワークの暗黒面と、その光を追い続けてきたエンジニアです。
皆さんの現場では、いまだに「VPNに接続して社内LANへ」という魔法の杖を振るっていませんか？ もちろん、パンデミック以降、SSL-VPNはリモートワークの救世主でした。しかし、パケットを流し続けてきた経験から断言します。VPNは、一度門をくぐれば「何でもできてしまう」という、現代のセキュリティ脅威に対してあまりに無防備な“中世の城”なのです。
今回は、境界防御（境界の内側は安全という神話）から、アイデンティティとデバイスの信頼性に基づいた「ZTNA（Zero Trust Network Access）」へと、どうやって泥臭く、かつ確実に移行していくのか。その要諦を解説します。
—
1. なぜVPNでは「信頼」が足りないのか
従来のIPsecやSSL-VPNは、TCP/IP層で接続を確立し、ユーザーに社内ネットワークのIPアドレスを払い出します。これは事実上、ユーザーの端末が社内LANの物理的な一員になることを意味します。
もし、その端末がマルウェアに感染していたら？ あるいは、退職したエンジニアがまだVPNアカウントを持っていたら？ 攻撃者は、一度VPNの認証を突破してしまえば、ネットワーク内を横移動（ラテラルムーブメント）し放題です。
一方でZTNAは、「デフォルト拒否（Never Trust, Always Verify）」が原則です。アプリケーション単位でアクセスを制御し、IPアドレスではなく「誰が」「どのデバイスで」「どんな状態で」アクセスしようとしているかを厳格に評価します。
—
2. ZTNAの通信フロー：コネクタという名の「仲裁人」
VPNが「トンネル」を作るのに対し、ZTNAは「コネクタ」を介したプロキシ通信を行います。
従来のVPN
1. ユーザーがVPNゲートウェイに接続。
2. 認証成功後、社内LANへのルーティングが有効化。
3. サーバーへ直接アクセス（レイヤー3の接続）。
ZTNAの通信フロー
1. アイデンティティ認証: IdP（OktaやAzure ADなど）でユーザーを検証。
2. デバイス評価: ポスチャチェック（OSのパッチ状況、EDRの稼働有無など）。
3. リバースプロキシによる仲裁: ユーザーとアプリケーションの間にZTNAコネクタが介在。
4. 許可されたAPI/アプリのみへ到達: L3の接続は提供せず、L7のリクエストを中継。
—
3. 実践：従来のAPIアクセスをZTNAへ移行する
例えば、社内Web API（https://api.internal.corp）へアクセスする際、これまでVPN経由だったものを、ZTNA（あるいはアクセスプロキシ）経由に切り替える際のコード例を見てみましょう。
以前のPythonによるAPIアクセス（VPN依存）
import requests
# VPNが繋がっていれば、このIPへ直接届く
url = "http://10.0.5.20:8080/v1/data"
try:
# 認証もローカルのIPホワイトリストに依存しがち
response = requests.get(url, timeout=5)
print(response.json())
except Exception as e:
print(f"VPNが切れているかもしれません: {e}")移行後のZTNA対応アクセス（認証ヘッダー付与）
ZTNAへ移行すると、ローカルIPは隠蔽され、プロキシを介した認証付きリクエストになります。
import requests
# ZTNAゲートウェイのパブリックFQDN
api_url = "https://api-gateway.corp-ztna.com/v1/data"
# IdPから取得したOIDCトークンを付与
headers = {
"Authorization": "Bearer <JWT_TOKEN_FROM_IDP>",
"X-Device-ID": "device-uuid-12345" # 端末識別子をコンテキストとして送る
}
# プロキシ経由でリクエスト
proxies = {"https": "https://ztna-proxy.corp.com:443"}
response = requests.get(api_url, headers=headers, proxies=proxies, verify=True)
print(f"ステータスコード: {response.status_code}")—
4. 移行の際のトラブルシューティングTips
現場でよくあるのは、「ZTNA導入後に特定のアプリだけ繋がらない」という悲鳴です。以下のポイントをチェックしてください。
1. MTUサイズの問題: ZTNAのオーバーレイネットワークでは、カプセル化によってパケットサイズが大きくなりがちです。pingでdo-not-fragmentオプションを付けてパケットサイズを調整し、断片化が発生していないか確認してください。
2. DNSの挙動: VPNは社内DNSを強制的に使用しますが、ZTNAはローカルDNSと社内DNSを使い分けるスプリットトンネル構成が一般的です。ブラウザが意図しないリゾルバを使っていないか、nslookupやdigで泥臭く確認しましょう。
3. 証明書エラー: ZTNAはSSL/TLSの終端（SSLオフロード）を行うため、端末側にルート証明書が正しくインポートされていないと、SSL Certificate Verify Failedで全滅します。
まとめ：一気に変えるな、段階的に殺せ
VPNを明日すべて廃止するのは現実的ではありません。まずは「重要度の高いAPIサーバー」からZTNA経由のアクセスに切り替え、徐々にVPNの役割を縮小していくのが、運用の現場における定石です。
セキュリティとは、完璧な壁を築くことではありません。「誰が、何に、どうやって触れているか」を可視化し続けることです。
VPNという名の「城壁」に守られた時代は終わりました。これからは、個々の通信を信頼しすぎず、常に検証し続ける「ゼロトラスト」の精神で、快適で堅牢なネットワークを設計していきましょう。
もし現場でパケットキャプチャとにらめっこして行き詰まったら、思い出してください。ネットワークは常に、正直なパケットを運んでいるだけなのです。
コメント