【実務・中級編】 VPN接続におけるスプリットトンネリングのセキュリティリスク – 暗号理論・認証基盤 & エンドポイントセキュリティ防御ガイド

おい、ちょっと手を止めてこっちを向いてくれ。

リモートワークが当たり前になった昨今、「社内システムへのアクセスにはVPNが必須だ」というのは、もはやセキュリティの基本中の基本だ。だがな、そのVPN接続において、利便性や回線コストを理由に安易に「スプリットトンネリング（Split Tunneling）」を導入している現場があまりにも多すぎる。

「社内リソース（社内Webやファイルサーバ）へのアクセスだけVPNを通り、YouTubeやプライベートのWeb閲覧、SaaSへのアクセスは直接インターネットへ抜ける」——一見すると、社内網の帯域圧迫を防ぐスマートなアーキテクチャに見えるかもしれない。しかし、攻撃者の視点から言わせてもらえば、これは自ら城の門を開け放ち、敵を招き入れているようなものだ。

今回は、このスプリットトンネリングが孕む致命的な攻撃対象領域の拡大と、それをエンドポイントセキュリティでどう封じ込めるのか、現場の泥臭い実態を踏まえて徹底的に解説しよう。

—

1. なぜスプリットトンネリングは攻撃者に狙われるのか？

VPNスプリットトンネリングの最大の弱点は、「社内ネットワーク」と「信頼できないパブリックなインターネット」が、同一のエンドポイント（社員のPC）上で同居するという点にある。

攻撃者はこの構造をどう突くか。よくあるインシデントのシナリオを話そう。

1. 自宅の野良Wi-Fiからの侵入: 従業員が自宅やカフェから、スプリットトンネリング有効の状態でVPN接続している。この時、社内通信は暗号化されてVPNを通るが、一般的なWebブラウジングは直接インターネットに出ている。
2. ローカルネットワーク経由の踏み台化（自宅LANの汚染）: もし同じ自宅LAN内に、脆弱なIoT機器やマルウェアに感染した別の端末が存在した場合、スプリットトンネリング中のPCのローカルインターフェース（Wi-Fiや有線LAN）に対し、横方向の移動（ラテラルムーブメント）を仕掛けられる。
3. DNSリバインディングや悪意あるWebからの誘導: ブラウザ経由でアクセスした悪意あるサイトから、ローカルネットワーク内のサービスや、スプリットトンネリングによって名前解決が可能になった社内リソースへ不正なリクエストが飛ぶ。

さらに最悪なのは、「VPN接続していれば社内からアクセスされたとみなす」という古いセキュア境界モデル（境界防御）をまだ信じ込んでいるシステムだ。VPNのトンネルの向こう側にいる＝安全、ではない。エンドポイントが汚染されていれば、VPNはそのまま社内ネットワークへの「直通ハイウェイ」になってしまうのだ。

—

2. 攻撃手法のリアル：スプリットトンネリングを逆用したセッションハイジャック

ここで、攻撃者がスプリットトンネリング環境下のクライアントに対して行う典型的な攻撃の流れをイメージしてほしい。

スプリットトンネリング環境では、PC上のブラウザは社内システム（例: https://internal.example.com）と、外部のSaaSやSNS（例: https://attacker-controlled.com）に同時にアクセスしている。
もし、このクライアントのブラウザが適切に分離されていなかったり、サードパーティ製プラグインや脆弱な拡張機能が入っていたりすると、CORS（Cross-Origin Resource Sharing）の不備やXSS（クロスサイトスクリプティング）を突いて、社内システムのセッションクッキーが外部に窃取されるリスクが生じる。

「いやいや、うちはちゃんと暗号通信（HTTPS）を使っているから大丈夫だ」と思ったそこの君。暗号化（共通鍵暗号のAESや、公開鍵暗号によるTLSハンドシェイク）は、あくまで「通信経路上での盗聴や改ざんを防ぐもの」であって、エンドポイント自体の乗っ取りや、アプリケーション層のロジックの隙を防ぐものではない。暗号の強さを過信して、ネットワーク設計やエンドポイントの衛生管理を怠るのが一番の悪手なのだ。

—

3. 防御の要：ゼロトラストとエンドポイントセキュリティの連係

では、どうすればいいのか？
「じゃあ全トラフィックをVPNに通すフルートンネリングに戻そう」——それも一つの手だが、現代のクラウドファーストなインフラにおいては、全社通信を本社VPNに集約すると帯域がパンクする。

ここで私たちが取るべきアプローチは、「ネットワークの信頼に依存せず、エンドポイントとアイデンティティ（ID）を徹底的に検証する（ゼロトラスト・アーキテクチャ）」ことだ。

スプリットトンネリングを維持しつつ安全性を担保するためには、以下の3つを強制しなければならない。

1. EDR（Endpoint Detection and Response）の常時稼働: 端末が社内網にいようが野良Wi-Fiにいようが、不審なプロセス起動やメモリインジェクションを検知し、即座にネットワークから隔離（アイソレーション）できる状態にしておく。
2. DNSセキュリティ（DNS Filtering）: スプリットトンネリング時でも、会社の管理下にあるDNSサーバーまたはセキュアなDNSルーター（Cloudflare GatewayやCisco Umbrellaなど）を経由させ、C2サーバーへの通信やフィッシングドメインへのアクセスを強制的にブロックする。
3. 厳格なID/アクセスコントロール（クラウドIAM・CASBの活用）: VPNのIPアドレスだけで信頼せず、端末の証明書（クライアント証明書）、多要素認証（MFA）、さらには「管理された安全な端末（MDM導入済み）か」をコンテキストとして評価し、アクセスを動的に制御する。

—

4. 実務で使える！セキュアなアクセス制御の設定・実装例

口で言うだけではセキュリティチーフの名が廃る。ここからは、インフラやアプリケーションの現場で即座に実装・設定すべき具体的なコードや設定ファイルを見ていこう。

① Nginxにおけるリバースプロキシ設定：社内IP以外からのアクセス制限とセキュリティヘッダー

もし社内Webシステムを公開、あるいはVPN経由でルーティングする場合、Nginx側で「どのIPから、どのようなヘッダーで来ているか」を厳格にチェックし、不正なアクセスを弾く必要がある。

# /etc/nginx/conf.d/secure_internal.conf
server {
    listen 443 ssl http2;
    server_name internal.example.com;

    # 証明書の設定（TLS 1.3を強制し、レガシーな暗号スイートを排除）
    ssl_certificate /etc/letsencrypt/live/internal.example.com/fullchain.pem;
    ssl_certificate_key /etc/letsencrypt/live/internal.example.com/privkey.pem;
    ssl_protocols TLSv1.2 TLSv1.3;
    ssl_ciphers 'ECDHE-ECDSA-AES128-GCM-SHA256:ECDHE-RSA-AES128-GCM-SHA256:ECDHE-ECDSA-AES256-GCM-SHA384:ECDHE-RSA-AES256-GCM-SHA384';

    # 1. IPアドレス制限（社内VPNのセグメントのみ許可、パブリックIPからの直接アクセスを拒否）
    allow 10.100.0.0/16; # 社内VPNセグメント
    allow 192.168.10.0/24; # 本社オフィス内ネットワーク
    deny all; # 上記以外はすべて拒否

    location / {
        proxy_pass http://internal_app_backend;
        proxy_set_header Host $host;
        proxy_set_header X-Real-IP $remote_addr;
        proxy_set_header X-Forwarded-For $proxy_add_x_forwarded_for;
        proxy_set_header X-Forwarded-Proto $scheme;

        # 2. セキュリティヘッダーの付与（クリックジャッキングやXSS対策）
        add_header X-Frame-Options "DENY" always;
        add_header X-Content-Type-Options "nosniff" always;
        add_header X-XSS-Protection "1; mode=block" always;
        add_header Content-Security-Policy "default-src 'self'; script-src 'self';" always;
    }
}

② Python (Flask) によるアプリケーション層での追加検証とセッション管理

ネットワーク層だけでなく、アプリケーション側でも「このリクエストは本当に信頼できる文脈から来ているか」を検証する実装例だ。ここでは、リクエストに含まれるカスタムヘッダー（プロキシやゼロトラストアーキテクチャの境界で付与されるデバイス検証トークン等）をチェックするロジックを入れている。

# app.py
from flask import Flask, request, abort, jsonify
import hmac
import hashlib

app = Flask(__name__)

# 共有シークレット（実際にはAWS Secrets Managerや環境変数から安全に取得すること）
DEVICE_HEADER_SECRET = b"super-secret-device-verification-key"

def verify_device_token(auth_header, body_content):
    """
    エンドポイント（EDR/MDM）が正常な状態であることを示す署名を検証する
    """
    if not auth_header or not auth_header.startswith("Bearer "):
        return False
    
    token = auth_header.split(" ")[1]
    
    # 簡易的なHMAC検証の例（本番ではJWTやmTLSの証明書検証を使用すること）
    expected_signature = hmac.new(
        DEVICE_HEADER_SECRET, 
        body_content, 
        hashlib.sha256
    ).hexdigest()
    
    return hmac.compare_digest(token, expected_signature)

@app.route('/api/v1/sensitive-operation', methods=['POST'])
def sensitive_operation():
    # リクエストボディの取得
    raw_data = request.get_data()
    
    # ゼロトラストプロキシ等から渡されるデバイス検証ヘッダー
    device_auth = request.headers.get("X-Device-Authorization")
    
    # 端末の健全性・正当性を検証
    if not verify_device_token(device_auth, raw_data):
        # 認証失敗時は監査ログに記録し、アクセスを即座に拒否
        app.logger.warning(f"Unauthorized access attempt from IP: {request.remote_addr}")
        abort(403, description="Access denied: Invalid endpoint compliance or device token.")
    
    # 正常な処理の継続
    data = request.json
    return jsonify({
        "status": "success",
        "message": "Sensitive operation executed securely."
    }), 200

if __name__ == '__main__':
    # デバッグモードは本番環境では絶対に有効化しないこと
    app.run(host='0.0.0.0', port=5000)

③ JavaScript (Node.js/Express) でのセッションクッキーの厳格な属性設定

スプリットトンネリング環境において、万が一ブラウザがマルウェアや悪意あるサイトに晒されたとしても、セッションクッキーを保護するための設定だ。SameSite属性とSecure属性の徹底は基本中の基本だが、現場ではまだ漏れが見つかることが多い。

// server.js
const express = require('express');
const cookieParser = require('cookie-parser');
const app = express();

app.use(cookieParser());

app.login('/login', (req, res) => {
    // 認証処理が成功したと仮定
    const sessionToken = "example_secure_session_token_xyz";

    // セッションクッキーを極めてセキュアに発行する
    res.cookie('session_id', sessionToken, {
        httpOnly: true,     // JavaScriptからのアクセスを完全に禁止（XSS対策）
        secure: true,       // HTTPS通信でのみ送信を許可（盗聴対策）
        sameSite: 'strict', // クロスサイトリクエストによるクッキー送信を禁止（CSRF対策）
        maxAge: 3600000,    // 有効期限: 1時間
        path: '/'
    });

    res.status(200).send({ message: "Login successful and secure cookie set." });
});

app.listen(3000, () => {
    console.log('Secure server running on port 3000');
});

—

5. チーフからの最後のメッセージ

VPNのスプリットトンネリングは、利便性と引き換えにセキュリティの「境界」を曖昧にする諸刃の剣だ。「うちは大丈夫だ」という思い込みほど、インシデントの温床になるものはない。

インフラエンジニア、Webアプリケーションエンジニア、そしてセキュリティ担当者が一体となり、「ネットワークの暗号化やVPNに頼り切らない、エンドポイントとアプリケーションの多層防御」を構築してほしい。

自分の書いたコード、自分が組んだインフラが、明日標的になったときに耐えられるか——常にその視点を忘れずに、堅実なシステム運用を続けてくれ。期待しているぞ。