Jamf Concepts
ガイド

ガイド

ネットワークエンジニア向け Jamf Connect ZTNA ガイド

~4 min read

対象者と目的

このドキュメントは、ネットワークとセキュリティの基礎知識を持つ IT 管理者向けです。VPN テクノロジーに関する実務経験が必要です。

次世代のセキュリティおよびネットワーク製品である Jamf Connect ZTNA は、従来の VPN と大きく異なる動作をします。このガイドは、管理者が製品の設計の基礎を理解し、計画、展開、保守、およびトラブルシューティングに役立つことを目的としています。

このガイドは Jamf の ZTNA 製品の設定方法を説明する製品ドキュメントではなく、その仕組みを説明することで、お客様の環境における製品の動作を予測し理解できるようにするものです。設定ドキュメントをお探しの場合は、Jamf Connect ZTNA ドキュメントをご参照いただくか、まず技術ビデオの概要をご覧になりたい場合は、JNUC 2021 Jamf ZTNA Deep Dive プレゼンテーションをご視聴ください。

組織内で Jamf Connect ZTNA を本番環境で使用している場合は、このガイドを読んでブックマークすることを強くお勧めします。

概要

Jamf の ZTNA 製品は、Cloud Security Alliance (CSA) の Software Defined Perimeter (SDP) アーキテクチャに準拠するように最初から設計されました。このアーキテクチャは、業界全体の Zero Trust Network Access (ZTNA) の定義の多くの原則を具体化しています。最小権限アクセス、ロールベースアクセス、多要素認証、デバイス信頼などが含まれます。製品は元々 Wandera により開発され、2021 年 7 月に Jamf セキュリティプラットフォームに買収されました。

Jamf Connect ZTNA は従来の VPN と同じ結果の多くを共有していますが (VPN インターフェイスがオンラインになるとリモートリソースが利用可能になるなど)、これらの結果をサポートする実際のメカニズムは全く異なります。これは Connect ZTNA が IP アドレッシング、DNS、およびクラウドテクノロジーを利用して、従来の VPN アーキテクチャと比べてパフォーマンス、スケーラビリティ、セキュリティの面で大きな進歩をもたらすクライアント間サーバー ルーティングを実現している方法の結果です。

それでは、Jamf SDP と従来の VPN の間で最も重要な違いの 1 つから始めましょう。接続仲介とルーティングです。

接続仲介

これをまず理解してください。VPN の動作について知っていることと想定していることをすべて一時的に脇に置いてください。最終的なパケットルーティングは従来の VPN に似ているように見えますが、接続プロセスに新しい処理要素があります。

従来の VPN

デバイスが従来の VPN に接続すると、VPN コンセントレータとのセキュアなトンネルが確立されます。このコンセントレータはオンプレミスまたはクラウドに存在し、お客様またはサービスプロバイダーが運用します。

従来の VPN トラフィックフロー

コンセントレータの場所や運用者がどこにいるかに関わらず、全般的な動作は同じです。

  1. デバイスが VPN コンセントレータで認証し、セキュアなトンネルが確立され、エンドポイント上に仮想ネットワークインターフェイスが作成されます。
  2. デバイスには、そのトンネルの有効期間中に有効な IP アドレスがコンセントレータにより動的に割り当てられます (時々 DHCP バインディングにより「静的に」再割り当てされることがあります)。
  3. 1 つ以上のルートが仮想ネットワークインターフェイス用に設定され、VPN を経由してルーティングされるべき組織が所有するネットワークサブネットが定義されます。フルトンネル VPN はデバイスからのすべてのトラフィックをコンセントレータにルーティングし、すべてのローカルネットワークアクセスを排除します。
  4. DNS ネームサーバーがデバイス上に設定されます。これは通常 VPN の反対側の顧客ネットワーク上に存在します。
  5. アプリがリソースへのリクエストを発行するたびに、DNS はIP アドレスに解決され、パケットの IP アドレスが VPN 仮想インターフェイスのルートのいずれかに該当する場合、トラフィックは VPN 経由でルーティングされます。
  6. VPN コンセントレータはパケットを顧客ネットワークにルーティングします。場合によっては、ファイアウォールアクセス制御リストがネットワーク全体に実装され、アクセス制御を制限します。

これは確かに「機能」しますが、このアーキテクチャの基本的なセキュリティ上の問題は、ルーティングされたサブネット内のすべてのリソースが本質的にデバイスで利用可能になることです。これにより、ほとんどのエンドポイントが接続するべきでない IT サービスとサーバーへの接続が可能になります。悪意のある人物がエンドポイントの脆弱性を悪用することに成功した場合、この VPN 接続を使用してファイアウォール「保護下」にあるサーバーの弱点を見つけることができます。これらのサーバーは完全にパッチされていないか、それ以外の方法で適切にロックダウンされていない可能性があります。

確かにネットワーク全体にアクセス制御ルールを実装することはできますが、それは難しく、エラーが起こりやすいものです。通常、そのようなルールは IP アドレスレイヤーで管理される必要があるため、脆く、変更するのに危険です。これにより、ネットワークレベルのセキュリティポリシーが、ネットワーク上でミッションクリティカルな新しいアプリケーションや進化するアプリケーションに必要な変更率により急速に時代遅れになります。また、ユーザーのアイデンティティとその接続を厳密に結合する方法で監視および監査報告を行う良い方法もありません。では、ほとんどの組織は何をしているのでしょうか。それを開いたままにして、インシデントが発生したときにレポートを組み立てます。

これらの課題をどのように修正するのでしょうか。SDP と「仲介された」ネットワーク接続を入力します。

SDP: 接続仲介

Jamf の ZTNA がエンドポイントデバイスに接続されると、すぐにいくつかの重要な違いがあります。

  1. ステートレスな Wireguard ネットワークインターフェイスが、エンドポイント上に非常に軽量な初期ハンドシェイクに続いて作成されます。注: ZTNA デプロイメントによっては、Apple デバイスが Wireguard の代わりに HTTP/3 を使用する場合があります。
  2. インターフェース確立の帯域外でネゴシエートされた、IPv6 ルートの単純なセットが VPN ネットワークインターフェイス用に設定されます。これらのルートは、デフォルトではお客様に属しておらず、Jamf (fd53:1c5a::/32, fddd:dddd::/128) が管理する予約済み IPv6 範囲です。VPN ネットワークインターフェイスには、帯域外でもネゴシエートされた静的 IPv6 アドレスも割り当てられます。デフォルトでは、VPN ネットワークインターフェイスに割り当てられた IPv4 アドレスまたはルートはありません。
  3. Jamf 管理の DNS ネームサーバー fddd:dddd:: がデバイスで設定されます。

*え。何ですか？*はい、ご理解の通りです。エンタープライズ側の IP アドレス、サブネット、または DNS ネームサーバーはエンドユーザーのデバイスのルートテーブルに公開されません。どの IPv4 アドレスも公開されません。これは、エンドポイントとユーザーが内部ネットワークトポロジを認識せず、試しても内部ネットワーク IP に接続できない SDP 接続仲介の重要な構成要素です。

では、デバイス上のアプリケーションが、それらの内部 IPv4 サブネットの 1 つに存在するサーバー上のアプリケーションに接続するにはどうすればよいでしょうか。ここで接続仲介が登場します。これは DNS、NAT、および Jamf ルーティングテクノロジーの魔法によって促進されます。

情報: Direct IP とサブネットアクセスに関する注記

エンドポイントに内部サブネットを公開しないこと (IPv4 アドレスなし) のセキュリティ上の利点に加えて、ユーザーが非企業管理ネットワーク (自宅、コーヒーショップなど) で経験する可能性があるネットワークセグメントの重複を回避するのにも役立ちます。これはシームレスなリモートワークをどこからでも有効にするために重要です。

ただし、IPv4 アドレスまたはサブネットを直接使用可能にする必要があり、DNS ベースの接続仲介に依存できない特定のユースケースがいくつかあります。このような状況では、Connect ZTNA は「Direct IP」アクセスの設定をサポートしています。詳細は、このガイドの「仲介された接続の例外」セクションを参照してください。

ユーザーが app.acmeinc.com という App に接続しようとしており、内部 IP アドレスが 10.0.1.22 であるとします。Jamf ZTNA 対応デバイスからその接続を促進するために何が起こるかは以下の通りです (以下の例は宛先アプリへの TCP 接続を示していますが、UDP 接続に対しても同様のフローが使用されます)。

Jamf Private Access 仲介トラフィックフロー

  1. ユーザーが選択したブラウザまたはネイティブアプリから app.acmeinc.com への接続を開始します。
  2. アプリは OS に対してそのホスト名を解決して IP アドレスを取得するよう要求します。Jamf Connect ZTNA がアクティブな場合、使用する DNS ネームサーバーは fddd:dddd:: です。これは Jamf Connect ZTNA ポリシーエンジンに結びついた仮想 IPv6 アドレスです。
  3. OS は fddd:dddd:: に対して app.acmeinc.com に対して一連の DNS リクエストを行います。タイプは A、AAAA、HTTPS を含みます。
  4. Jamf Connect ZTNA DNS ネームサーバーは FQDN の上流参照を実行し、まずカスタム DNS ゾーンがドメイン (*.acmeinc.com と権威ネームサーバー 10.0.1.10 がこの例に設定されている) に対して設定されているかどうかを確認します。カスタム DNS ゾーンが見つからない場合、サービスは一連のパブリック上流 DNS リゾルバーを使用します。
    1. 注: サービスは上流 A レコードのみをリクエストし、AAAA と HTTPS は現在のところ無視されます。これは のみ IPv6 経由でアクセス可能なサーバーに問題が生じる可能性がありますが、今日のほとんどのパブリックおよびプライベートネットワーク全体で非常にまれです。
  5. 権威サーバーから A DNS 応答を受け取ると (この場合、カスタム DNS ゾーン設定を経由して顧客の内部ネームサーバーから A 10.0.1.22)、Jamf Connect ZTNA DNS ネームサーバーはリソースをリクエストしているユーザーとデバイスを識別し、app.acmeinc.com をトラフィック一致基準として定義する一致するアクセスポリシーを探します。
    1. このアクセスポリシーはユーザーのグループメンバーシップとデバイスの健全性を評価して、リソースへのアクセスを許可するかどうかを判断します。
    2. ポリシーで定義されているのは、Jamf クラウド経由でトラフィックがどのようにルーティングされるべきかです。この場合、顧客が IPSec 相互接続ゲートウェイ を設定して、この内部アプリに到達するプライベートルートとして機能するとします。
  6. アクセスポリシーが見つかり、デバイスとユーザーがリソースへの接続に必要なすべての基準に合格していると仮定すると、Jamf Connect ZTNA ルーティングファブリックは「クラウドフローマッピング」を作成します。これは、エフェメラル IPv6 をエンドポイントに公開された予約済み IPv6 サブネット内に割り当てます (例: fd53:1c5a::aaaa:bbbb ↔ 10.0.1.22)。
    1. このフローは接続とユーザーごとに一意であり、その有効期間を超えて、または他のデバイスで再利用することはできません。
  7. この IPv6 アドレス fd53:1c5a::aaaa:bbbb はエンドポイントに AAAA DNS 応答として返されます。
    1. サービスは、デフォルトでは A または HTTPS 応答を返しません。これはトラブルシューティング用に dig などのユーティリティを使用して DNS 応答を検証する場合に非常に重要です。
  8. fd53:1c5a::aaaa:bbbb への新しいソケットが作成され、その IP は Jamf Connect ZTNA の VPN ネットワークインターフェイスに割り当てられたサブネット内に存在するため、そのソケットと後続のすべてのパケットは Wireguard トンネル経由で Jamf Security Cloud との間で転送されます。
  9. パケットを受け取ると、Jamf Connect ZTNA ルーティングファブリックは追加のセキュリティチェックを実行し、宛先 IPv6 アドレスのクラウドフローマッピングを探します。
  10. Jamf Connect ZTNA ルーティングファブリックはパケットをグローバルクラウドバックボーン全体にルーティングし、最終的にアクセスポリシーで定義された IPSec 相互接続に到達します。パケットが IPSec トンネル経由で転送される前に、クラウドフローマッピング当たり NAT64 変換が発生し、元の IPv4 アドレス (10.0.1.22) を宛先 IP として持つパケットが生成されます。
    1. パケットのソース IP は、IPSec 設定の「Jamf Security Cloud Side」で定義されたサブネット内の IP アドレスに設定されます。顧客ネットワークに送信されるすべてのトラフィックは、このサブネット内の疑似ランダム IP から発信されるように表示されます。
    2. クラウドベースの NAT エグレス用リージョナルデータセンターを使用している場合、ソース IP はそのデータセンターのグローバル IP アドレス全体で動的に負荷分散されます。
  11. すべての一致する仲介接続はユーザー、デバイス、およびアプリケーションに対してログに記録され、RADAR のアクセスイベントログおよび他のレポートで確認できます。

ご覧の通り、従来の VPN 設定にはネイティブに存在しない DNS、IP ルーティング、および NAT の密結合があります。

これらの違いにもかかわらず、Jamf Connect ZTNA はすべてのルーティングがレイヤー 3 でネイティブに発生するため、パケットを非常に効率的に処理し、VoIP およびビデオなどのリアルタイムアプリケーションを簡単にサポートします。すべてのカプセル化が超高速で効率的な Wireguard または HTTP/3 UDP カプセル化プロトコルを使用して発生するため、ロッシーネットワーク上で TCP/mTLS ベースのトンネル内で TCP 接続をルーティングする際に一般的な伝送プロトコル「崩壊」がありません。

情報: SDP、VPN、エンドツーエンドアプリ暗号化

Jamf Connect ZTNA は、最新のパケットカプセル化および暗号化テクノロジーを使用してダイナミックなソフトウェア定義ネットワーク機能を提供するように設計されており、ウェブインターフェイスで数回クリックするだけで、ほぼすべての宛先にエンドポイントからトラフィックを簡単にステアリングしてポリシーを適用できます。

ただし、トラフィックがすでに転送中のときに暗号化する VPN テクノロジーと同様に、Jamf がクライアントアプリケーションからサーバーアプリケーションへのデータの真のエンドツーエンド暗号化を提供することは不可能です。

したがって、機密データが含まれているアプリの場合は、HTTPS または TLS などのアプリレベルの暗号化テクノロジーを使用するようにそのようなアプリケーションを 常に 設定する必要があります。これは現在すべてのアプリケーションの標準的なプラクティスです。これは、Jamf または顧客ネットワーク全体のいずれの時点でも、権限のない第三者がアクセスを取得できないようにする唯一の方法です。

この接続仲介テクニックは、Jamf ZTNA プラットフォーム上でエンタープライズグレードのパフォーマンスとスケールで動作することが実証されています。すべての最新のオペレーティングシステムはネイティブに IPv6 をサポートしており (デバイスが IPv4 のみのネットワーク接続を持っている場合でも)、大多数のアプリケーションとユーザーは IPv6 をサポートしており、すべての接続に DNS を使用しています。

それらが行わないもの、つまりこれらの外れ値が Connect ZTNA を通じて機能するために特別な設定を定義する必要があります。

可用性とフェイルオーバー

Jamf ZTNA は、ネットワーク分割を考慮して設計されており、デバイスが Jamf Security Cloud に接続できないことがあります。これは複数の重複する方法を使用して行います。

デッドゲートウェイ検出

Jamf Trust は、不安全なキャプティブポータルから生じることが多い危険または不安定な接続を検出できます。これらのキャプティブポータルはトラフィックをインターセプトでき、接続の問題が生じます。

デッドゲートウェイ検出 (DGD) により、Jamf Trust アプリはエンドユーザーデバイスに現在の接続状態に関する通知を提供できます。DGD はキャプティブポータルと Web 接続チェックなどの一般的な接続チェックを使用しながら、ゼロトラストネットワークアクセス (ZTNA) エンドポイント解決を使用してデッドゲートウェイを検出します。DGD を直接サポートするために、Jamf Trust でのバイパスモードは VPN トンネルを通してトラフィックが危険にさらされることを防ぎます。これにより、エンドユーザーは VPN またはワークアプリケーションなしで安全にインターネットを閲覧できます。

負荷分散され、リージョナルな入口場所

ライブ接続を検出したとき、Jamf Trust はローカルネットワークの DNS プロバイダー (通常は DHCP により提供される) により判定されたローカル IP エンドポイントをリクエストします。これらのエンドポイントの TTL (time-to-live) は 60 秒です。これらのエンドポイントのいずれかが利用不可になった場合、それらは 60 秒以内にプールから削除されます。これにより RTO (Recovery Time Objective) が最大 60 秒となりますが、デッドゲートウェイ検出と組み合わせると、単一エンドポイント障害からの回復は即座に行われます。

ローカルポリシーキャッシング

SDP: 接続仲介で説明されているように、Jamf はローカル DNS 代理を使用してデバイストラフィックを適切なリソースにリルーティングします。これらのローカル DNS レコードは 60 秒の TTL も持っています。ポリシー変更が実行された場合 (リスクベースのポリシーが自動実行されるか、管理者の変更のいずれか)、デバイス上でポリシー更新が行われるまでの最長期間は 60 秒です。注: ポリシーはデバイスにローカルに存在しませんが、DNS キャッシングが原因で、ポリシー更新が 60 秒ごとにプッシュされているように見える場合があります。

仲介された接続の例外

ほとんどのアプリとサービスは Jamf ZTNA サービスを通じてネイティブに、特別な考慮なしで動作しますが、仲介接続アプローチでサポートされていない接続が必要な特定のユースケースとアプリケーションのクラスがあります。

DNS を使用しないアプリ/サービス

上で学んだように、アプリケーションまたはユーザーがリソースへの接続に FQDN を使用していない場合、それは単に機能しません。

DNS リクエストなしには、接続がキックオフされず、仲介 IPv6 アドレスが発行されることはないからです。宛先の IPv4 アドレスがデバイスのルートテーブルに追加されていないため、そのパケットはインターネットに進み、戻ってきません。

集計では一般的ではありませんが、FQDN/DNS を伴わない接続シナリオは次の場合に一般的です。

  • ネットワーク機器に直接接続しようとしている IT 管理者
  • DNS に登録されていない仮想インスタンスの新しいインスタンスに接続する開発者
  • IPv4 アドレス (FQDN ではなく) 経由で接続するレガシアプリケーション

このため、Jamf Connect ZTNA は、アプリケーションのアクセスポリシーで「Direct IP and Subnet」の定義をオプションでサポートしています。

エラー: セキュリティと Direct IP およびサブネット例外

リソースへのこのようなアクセスが絶対必要なユーザーとアプリケーションに対してのみ、IP ベースのアクセス設定をお勧めします。設定する場合は、定義するサブネット (例: 10.0.1.0/29) と (10.0.0.0/16) のように可能な限り狭くスコープを設定してください。

このようにブロードレベルでルーティングを確立すると、仲介ベースの接続モデルのセキュリティ上の多くの利点が実質的に無効になり、従来の VPN の動作に戻ります。これにより、組織は従来の VPN に影響を与える同じタイプの攻撃のリスクにさらされます。ネットワークリソースへの過度なアクセスを有効にしている場合です。

この方法で 1 つ以上の IP アドレスを設定すると、定義された CIDR サブネットは、そのポリシーに割り当てられているデバイスのルートテーブルに公開されます。つまり、デフォルト fd53 IPv6 サブネットに加えて、VPN ネットワークインターフェイスには、適用可能なすべてのアクセスポリシー全体で定義されたすべての IPv4 サブネットが含まれるようになります。

これらの IP アドレスで定義されたアクセスポリシーを保存すると、これらの変更がすべてのデバイスに伝播するまで最大 30 分かかることがあります。Jamf Connect ZT