フィールド機器のTLSとVPN：どの境界が何を守るのか

フィールド機器がサービスへ接続を開くと、設計上の問いはVPNとTLSのどちらを選ぶかという形で現れます。しかしこの枠組みは誤りで、両者は別の仕事をします。TLSはアプリケーションの端点を認証し、会話を保護します、VPNは到達性を制御し、ピア間のパケットを保護します。デバイスから外側へ接続をたどると、各階層にそれぞれの答えがあります。

TLSがどこで終端するかを言えないなら、アプリケーションが実際に何を信頼しているかも言えません。

TLSが実際にどこで終端するかを見極める

デバイスのアプリケーションから始め、ハンドシェイクを完了するプロセスまで接続を追います。プロキシがメインフレームの手前でTLSを終端するなら、保護された経路はプロキシで終わります。残りの区間には独自の文書化された保護が必要です。

これを仮定で端から端までと呼ぶことが、設計レビューが着隙を承認する手順です。終端点と信頼の基点を同じ図に描きます。

TLSは要求と応答を双方向に運ぶため、双方向のアプリケーションが本質的にTLSの代わりにVPNを必要とするわけではありません。逆もまた真です。同じデバイス上の他のプロトコルのために、展開が依然としてVPNを必要とすることがあります。

デバイスが何を認証すべきかを決める

サーバー識別子の検証と想定する信頼のルートを設定します。各デバイスが自身の識別子を証明する必要があるなら、対応するクライアント認証モデルを選び、デバイスごとに別の資格情報を登録します。資格情報の共有は、一台の盗難を部隊全体の問題に変えます。

出荷前に鍵の保護、更新、失効、復旧を計画します。更新の失敗後に再登録できない現場のデバイスは現地訪問になり、そのコストがハンドシェイク以上に設計を形作ります。

対応するライブラリと最新の指針を用います。現代のTLS展開ガイダンスはTLS 1.0と1.1の交渉を禁止しており、古い設計メモのTLSv1への言及は要件ではありません。

ハンドシェイクが失敗したら閉じる

失敗したハンドシェイクや識別子の確認が、黙って元の平文プロトコルへ戻ってはなりません。そのフォールバックこそ、TLSの作業が塞ぐはずだった脆弱性です。失敗をデバイスの運用者とサービスに見えるようにし、機密操作には保護された経路を必須にします。そのうえで、認証済みデバイスが何をしてよいかはアプリケーションの認可が決めます。

接続の寿命、フレーミング、タイムアウト、再試行の挙動を契約の一部として定義します。暗号化は繰り返しのコマンドを安全にはせず、不確実な前回の操作の後の再試行にはアプリケーション層の答えが必要です。

フォールバックの規則を書き留めます。「ハンドシェイクが失敗したらTLSなしで再接続する」は設計判断であり、明示されるべきです。

VPNには果たせる仕事だけを与える

VPNは到達性を制限し、自身のピアまでのパケットを保護できます。TLSは選択した端点とのアプリケーションの関係を保護します。両者の終端点は異なりえ、どちらも端点の保存データや管理アクセスを守りません。

どちらかの仕組みが速いと仮定するのではなく、実機でハンドシェイクのコスト、定常的なメッセージ交換、再接続を測定します。次に重要な四つのケースを試します。想定した交換、誤ったサーバー識別子、許可されていないデバイス、不確実な操作の後の再接続です。各ケースの結果を、デバイスが表示するエラーも含めて記録します。