「VPNは死んだ」――VPNからZTNAへの移行を、現場の泥臭い視点で語り尽くす
「とりあえずVPN張っとけば安全だろ？」
もし君のチームでまだそんな会話が飛び交っているなら、今すぐ耳を塞いでこの記事を読んでほしい。20年前なら正解だったかもしれない。だが、クラウドネイティブ全盛の現代において、VPNは単なる「社内ネットワークへの直通トンネル」に過ぎない。一度トンネルを抜ければ、そこは性善説に基づく「広大なオフィス」だ。ランサムウェアが一度侵入すれば、横展開（ラテラルムーブメント）で組織全体が蹂躙される。
今日は、そんなVPNという「境界防御の残骸」を脱却し、アプリケーション単位でアクセスを制御するゼロトラストネットワークアクセス（ZTNA）へ舵を切るための、実戦的な設計思想を解説しよう。
—
1. VPNとZTNAの「決定的な断絶」
VPNは「ネットワーク層」で動く。IPsecなりSSL-VPNなりでトンネルを確立した瞬間、ユーザーの端末には社内ネットワークのIPアドレスが付与される。これでは、ファイアウォールの穴を一つ広げているのと同義だ。
一方、ZTNAは「アプリケーション層」で動く。ユーザーがアクセスしたいのは「ネットワーク」ではなく「API」や「業務アプリ」そのものだ。ZTNAは、認証が終わるまでアプリケーションへの経路を一切公開しない（ダーククラウド）。
従来のVPNが抱える「罪」
- 過剰な特権: 接続した瞬間、同じサブネット内の他リソースへのポートスキャンが可能になる。
- 可視性の欠如: VPNトンネル内を流れる通信は、多くの場合ブラックボックス化している。
- 拡張性の限界: 物理的なゲートウェイがボトルネックとなり、リモートワーク急増時にスループットが悲鳴を上げる。
—
2. ZTNAへの移行：通信フローの再定義
ZTNAの肝は、「Verify Explicitly（明示的に検証せよ）」という原則だ。通信が成立する前に、IDプロバイダ（IdP）と連携し、デバイスの健全性（Posture）をチェックする。
ZTNAのシーケンス例
1. クライアント: ZTNAエージェントを通じて認証リクエストを送信。
2. コントローラ: IdPでユーザー認証し、同時にデバイスの状態（OSパッチ状況、証明書の有無）を評価。
3. ゲートウェイ: 認証成功後、特定の App-ID への一時的なリバースプロキシ経路を生成。
4. 通信: ユーザーとアプリ間が暗号化されたトンネルで接続される。
この時、ユーザーにはネットワークのIPアドレスなど見えない。見えるのは、プロキシされた先の api.internal.example.com というエンドポイントだけだ。
—
3. 実践：APIへのアクセス制御をコードで見る
ZTNA環境下では、APIクライアントも「信頼の証明」を伴う必要がある。例えば、Pythonで内部APIを叩く際、ヘッダーにZTNAコントローラから発行された短命なトークンを埋め込むのが定石だ。
import requests
# ZTNAコントローラから取得した短命なアクセス用トークン
# 従来のVPNなら不要だったが、ZTNAではこのJWTが鍵となる
ztna_token = "eyJhbGciOiJIUzI1NiIsInR5cCI6IkpXVCJ9..."
api_endpoint = "https://payroll-api.internal.corp/v1/salary"
headers = {
"Authorization": f"Bearer {ztna_token}",
"X-Device-ID": "device-uuid-12345", # デバイス固有IDによる紐付け
"Content-Type": "application/json"
}
# ZTNAゲートウェイがこのヘッダーを検証し、許可されたユーザー/端末か確認する
response = requests.get(api_endpoint, headers=headers, timeout=5)
if response.status_code == 200:
print("アクセス成功。ZTNAの検問を突破しました。")
else:
print(f"拒否されました: {response.status_code}")設定ファイルのTips：Nginxリバースプロキシでの制限例
もし自前でZTNAゲートウェイ的な振る舞いをNginxで実装する場合、以下のような設定が基本になる。
# ZTNAゲートウェイのコンテキスト
location /api/ {
# クライアント証明書による相互TLS(mTLS)を必須にする
ssl_verify_client on;
ssl_client_certificate /etc/nginx/certs/ca.crt;
# ヘッダー検証（ZTNAプロキシからの転送を想定）
if ($http_x_ztna_user = "") {
return 403; # 認証を通っていないアクセスは即座に拒否
}
proxy_pass http://backend-service;
}—
4. 現場でハマる「泥沼」トラブルシューティング
ZTNAへの移行で最も苦しむのは、レガシーアプリの「固定IP依存」だ。
- 問題: 「このアプリ、特定のセグメントのIPアドレスからしかアクセスできない設計なんです」
- 対策: アプリケーションを改修する余裕がない場合は、ZTNAゲートウェイの「Source IPヘッダー挿入機能」や、ゲートウェイ自身に固定IPを持たせ、そこを信頼の起点にする構成をとる。
また、「ZTNAエージェントがネットワークを遮断しすぎて業務が止まる」という相談も多い。これはデバイスの健全性チェック（Posture Check）の閾値を厳しくしすぎていることが原因だ。まずは監視モード（警告のみ）で運用を開始し、ログを分析してから防御を強めるのが鉄則だ。
—
結論：ネットワークを「信頼しない」勇気
ゼロトラストは、単なる製品の導入ではない。「ネットワーク境界が消滅した」という現実を受け入れる、思想の転換だ。
VPNを捨て、アプリケーション単位の制御に移行することは、最初は面倒で煩雑に感じるだろう。だが、一度この「明示的な信頼」の世界を構築すれば、君のシステムはランサムウェアの横展開に対して圧倒的な耐性を持つようになる。
パケットの行き先を制御するエンジニアとして、境界線に頼る時代はもう終わりだ。これからは、「誰が」「どのデバイスで」「何に対して」アクセスしているか、その一点に全知全能を注ごう。それが、次世代のインフラエンジニアに求められる責務だ。
コメント