従来の VPN アーキテクチャでは、トンネルはしばしばアイデンティティポリシーとは別に管理されます。一方にはエンタープライズディレクトリ、他方には VPN 検証システムがあり、さらに MFA サービス、デバイス信頼のための別のツール、監査のための別個のログ経路が存在します。この断片的な構造は、リモートアクセスをセキュアであるよりも運用的に脆弱なものにします。
ユーザーが正しいパスワードを知っているだけでは十分ではありません。デバイスは管理されているか、ディスク暗号化は有効か、セキュリティソフトウェアは最新か、ユーザーは正しいグループにいるか、送信元 IP や時間帯はリスクが高いか? これらの問いがトンネルを開く前に答えられなければ、VPN はエンタープライズネットワークを拡張する制御されない扉となります。
split tunneling、フルトンネル、セグメント単位のアクセスも、単なるネットワーク経路の問題ではありません。財務部門のユーザーと請負業者は同じネットワークにアクセスすべきではなく、管理されたエンタープライズデバイスと個人デバイスは同じ権限を持つべきではありません。トンネルポリシーがアイデンティティ、グループ、デバイス信頼とあわせて設計されないと、アクセス範囲は必要以上に広いままとなります。
運用面でも問題は大きくなります。SSL VPN、IKEv2、MFA、グループポリシー、セッション記録、SIEM 転送が個別に管理されると、セキュリティチームはインシデント時に全体像を把握できません。誰が接続したか、どのデバイスで接続したか、どのセグメントにアクセスしたか、接続が切断された理由は、単一の監査証跡に表れなければなりません。
TR7 AAM のアプローチは、VPN アクセスを別個のネットワークサービスとしてではなく、アイデンティティ、MFA、デバイスポスチャー、条件付きアクセス、監査の判断が一つにまとまる制御されたリモートアクセス層として扱います。
TR7 AAM は、クライアントベースのリモートアクセスを、プロトコル選択の前にアイデンティティ、デバイス信頼、アクセス範囲の判断として評価します。
ユーザーは LDAP/AD、RADIUS、OIDC、SAML、またはローカルユーザーソースを通じて検証できます。同じアイデンティティ判断が、SSL VPN や IKEv2 などのクライアントベースのアクセス選択肢に共通のポリシー基盤を形成します。
デバイス信頼スコアは、条件付きアクセス判断の一部として扱われます。管理されたデバイスには広いアクセス、個人デバイスには制限されたアクセス、信頼できないデバイスにはアクセス拒否というモデルを適用できます。
TLS ベースの SSL VPN アプローチはポート 443 経由で動作するため、エンタープライズファイアウォールやプロキシ環境での通過の容易さを提供します。split tunneling かフルトンネルかの判断はポリシーモデルに接続できます。
IKEv2/IPsec は、Windows、macOS、iOS、Android などの OS のネイティブ VPN クライアントと互換性のあるリモートアクセスモデルを提供します。モバイルネットワークの切り替え時のトンネル継続性において、IKEv2 アプローチは実用的な利点を提供します。
TR7 SSL VPN と IKEv2 は、トンネルプロトコルよりも、AAM のアイデンティティ、MFA、ポスチャー、アクセス範囲の判断を中心に据えます。
SSL VPN は、HTTPS/TLS ベースのトンネルアプローチにより、制限されたネットワークからエンタープライズリソースへのアクセスに位置づけられます。ポート 443 の使用は、多くの企業、ホテル、空港、または外部ネットワーク環境でアクセスの容易さを提供します。このモデルは、特に追加クライアントや専用 UDP ポートが制限される状況で価値を発揮します。
IKEv2/IPsec は、ネイティブ OS の VPN クライアントと互換性のあるエンタープライズリモートアクセスモデルに適しています。Windows、macOS、iOS、Android などのプラットフォームで、追加のユーザー体験の複雑さを軽減できます。モバイルユーザーがネットワークを切り替えるシナリオでは、IKEv2 アーキテクチャは再接続の面で有利です。
VPN 接続は、AAM の条件付きアクセスポリシーとあわせて評価できます。ユーザーアイデンティティ、グループメンバーシップ、送信元 IP、時間帯、デバイス信頼、リスクシグナルが、トンネルを開く前に判断プロセスに取り込まれます。このアプローチは、VPN をネットワークレベルの開いた扉から脱却させます。アクセス判断はユーザーとデバイスのコンテキストに制限されます。
TR7 AAM の MFA アプローチは、VPN アクセス判断にも適用される共通の信頼ファクターとして使用できます。TOTP、SMS OTP、またはメール OTP などの方式がユーザー検証を強化します。信頼されたデバイスまたはリスクベースの検証モデルにより、ユーザー体験とセキュリティのバランスを取れます。これにより、VPN 用の別個の MFA インフラを運用する必要性が軽減されます。
AAM は、LDAP/AD、RADIUS、OIDC、SAML、ローカルユーザーソースで動作できるアイデンティティプロバイダーモデルを備えています。VPN アクセスは別個のユーザーデータベースや別個のアイデンティティの孤島として扱われません。ユーザーがすでに組織内でどのアイデンティティで管理されているとしても、トンネルを開く判断は同じアイデンティティコンテキストに接続されます。この構造はユーザーライフサイクル管理を簡素化します。
ユーザーがどのネットワークセグメントにアクセスできるかは、グループメンバーシップまたは AAM ユーザーポリシーと関連付けることができます。財務チームは財務システムのみに、請負業者はプロジェクトサービスのみに、DevOps チームは開発環境のみに誘導できます。このモデルは、VPN が開かれた後に全ネットワークへのアクセスが付与されるという誤りを軽減します。トンネルアクセスはアイデンティティベースのセグメント制御へと変わります。
ETM デバイスポスチャーシグナルは、トンネルアクセスにおいて管理されたデバイスと管理されていないデバイスを区別するために使用できます。ディスク暗号化、セキュリティソフトウェア、パッチ状態、エンタープライズ管理シグナルがアクセスレベルに影響を与え得ます。信頼されたデバイスは全ネットワークに、信頼度の低いデバイスは限定された backend のみに誘導できます。このアプローチは、リモートアクセスにおけるデバイスリスクを可視化します。
VPN セッションは、ユーザーアイデンティティ、送信元 IP、セッション時刻、接続時間、ポリシー結果などのフィールドとともに監査証跡に接続できます。これらの記録は SIEM フローに転送され、セキュリティイベントと関連付けられます。運用チームは接続が開かれたことだけでなく、どの信頼判断のもとで開かれたかも確認できます。この可視性はコンプライアンスとインシデント調査にとって重要です。
split tunneling は、組織の IP 範囲または特定のサービスのみをトンネル経由で通過させます。フルトンネルはすべてのクライアントトラフィックをエンタープライズの通過ポイントに送ります。どのモデルを適用するかは、ユーザーグループ、デバイス信頼、ロケーション、またはリスクレベルに応じて決定できます。
接続中にデバイスポスチャーが悪化した場合、リスクスコアが変化した場合、またはユーザーポリシーが違反された場合には、セッションを切断するか再認証を要求する必要があります。TR7 AAM アーキテクチャは、この判断を条件付きアクセスと監査モデルに関連付けます。このアプローチは、VPN アクセスを一度開かれたら忘れられる恒久的なチャネルから脱却させます。アクセスはセッション全体を通じて観測可能であり、取り消し可能でなければなりません。
SSL VPN と IKEv2 アーキテクチャにおいて、検証済みの AAM アイデンティティ機能は、トンネル運用の要件とあわせて扱われなければなりません。
アイデンティティプロバイダー、MFA、条件付きアクセス、ETM デバイスポスチャーのコンセプトは、このページの信頼できる基盤です。ページの主要なメッセージは、VPN がこのアクセスエンジンに接続されることです。トンネルプロトコルは、アイデンティティとポリシー判断が適用されるチャネルとして位置づけられます。
SSL VPN アプローチは TLS 1.2+ とポート 443 経由で位置づけられます。これは、制限されたネットワークからのアクセスの面で利点を提供します。エンタープライズファイアウォールやプロキシ環境での通過の容易さは、IKEv2 と比べて際立つ実用的な利点です。
IKEv2/IPsec モデルでは、UDP 500 (IKE) と UDP 4500 (NAT-T) のポート、NAT-T の挙動、ファイアウォール許可が重要になります。SSL VPN と比べて、一部の制限されたネットワークではブロックされる可能性が高くなります。そのため、SSL VPN と IKEv2 は異なるアクセス条件に向けた補完的な選択肢です。
VPN アーキテクチャでは、各セッションに割り当てるトンネル IP プールを計画する必要があります。プールが枯渇した場合、新しい接続は拒否または待機させることができます。プールのサイズと管理モデルは、デプロイ要件に応じて構成する必要があります。
VPN アクセスでは、組織のドメインは内部 DNS 経由で、その他のドメインは外部解決経由で行く必要が生じる場合があります。split DNS は split tunneling 設計の自然な補完です。この挙動はデプロイアーキテクチャとポリシー構成に依存します。
トンネルプロトコルは追加のヘッダーコストを生じさせます。MTU/MSS の設定は、特に IPsec ESP と TLS トンネルのパフォーマンスにとって重要です。誤った設定は、フラグメンテーション、スループットの低下、または一部のアプリケーションでの接続問題を引き起こす可能性があります。
AAM ゲートウェイがペアで動作する際の VPN セッションのフェイルオーバー挙動は、トンネル技術に依存します。IKEv2 側ではモバイルの再接続アーキテクチャが有利になり得ます。SSL VPN 側では VIP とセッション継続性の設計を別途扱う必要があります。
自宅や出張先から働くユーザーは、エンタープライズアイデンティティと MFA で AAM を通じて検証されます。ETM デバイス信頼が十分であれば SSL VPN 経由でイントラネットサービスへのアクセスが付与され、個人デバイスではアクセスがより狭いセグメントに制限されます。
現場の技術者は、モバイルデバイスのネイティブ IKEv2 クライアントでエンタープライズネットワークに接続できます。デバイスが管理されたプロファイルと高い ETM 信頼スコアを持つ場合はより広いアクセスが付与され、ネットワーク切り替え時には IKEv2 アプローチがモバイル利用により適しています。
サードパーティの請負業者には、プロジェクト期間中のみ有効なユーザーアカウントと制限されたグループが割り当てられます。VPN アクセスはプロジェクトの backend が存在するセグメントのみに開かれ、すべてのセッションが監査記録に接続されます。
工場オートメーションエンジニアは、OT セグメントのみにアクセスするよう VPN ポリシーを受け取ります。条件付きアクセスが勤務時間、ユーザーグループ、送信元 IP、デバイス信頼で判断を制限し、一般的なエンタープライズネットワークへの広いアクセスは付与されません。
SSL VPN と IKEv2 トンネルを AAM アイデンティティエンジン、MFA、ETM デバイスポスチャーと統合するアーキテクチャをご覧ください。お客様の環境でライブセットアップをご案内します。