エンジニアが現場のデバイスにSSH接続を試みる。接続はタイムアウトする。IPアドレスは一晩で変わり、キャリアはインバウンドトラフィックを遮断し、デバイスはちょうどWi-Fiからセルラーに切り替わったところだった。心当たりはありませんか。この状況は、分散インフラストラクチャを管理する企業で日常的に起きています。
問題は接続の不安定さよりもはるかに根深いところにあります。現代のネットワークは、従来のセキュアなリモートアクセスツールが前提としてきた条件を根本から覆してしまいました。CGNAT、5Gのモビリティ、そして分散したデバイス配備は、従来型のアプローチが安定して機能し得ない環境を生み出しています。
本ガイドでは、こうした障害がなぜ起きるのか、そしてチームとして何ができるのかを具体的に説明します。接続不良の技術的な根本原因、これらの課題を実際に解決するアーキテクチャ上のアプローチ、そしてネットワークの変化に耐えるリモートアクセス基盤の構築方法をご理解いただけます。
要点：CGNATネットワークでセキュアなリモートアクセスツールが機能しない理由
-
CGNATとキャリアネットワークは数千台のデバイスでIPアドレスを共有するため、インバウンド接続を正しくルーティングすることが不可能になります。
-
従来のリモートアクセスツールは、安定したIPアドレスと開放されたインバウンドポートを前提としていますが、現代の分散ネットワークではそのどちらもほとんど得られません。
-
5Gおよび衛星ネットワークはデバイスのIPアドレスを絶えず再割り当てするため、セッションが切断され、アクセス設定が数分で無効になります。
-
Remote.Itはアウトバウンド専用の接続とサービスレベルのアクセス制御を採用しており、あらゆるネットワーク環境の背後でも確実に機能します。
-
IPアドレスではなくアイデンティティを検証するゼロトラストアーキテクチャは、デバイスがネットワーク間を移動してもセキュリティを維持します。
CGNATとは何か、そしてなぜリモートアクセスを破綻させるのか
キャリアグレードNAT（CGNAT）は、モバイルキャリアやISPがIPv4アドレスを節約するために用いるネットワークアーキテクチャです。各顧客に固有のパブリックIPを割り当てる代わりに、キャリアは1つのパブリックアドレスを数百から数千の加入者で共有します。
デバイスはキャリアからプライベートIPを受け取ります。トラフィックがネットワークから外に出るとき、CGNATはキャリア側の上流でアドレス変換を行います。この変換はお客様の管理外にある、設定不可能な機器の上で実行されます。
リモートアクセスにとって、これは克服しがたい問題を生みます。インバウンド接続には、安定していてパブリックにルーティング可能なIPアドレスと、利用可能なポートが必要です。CGNATはその両方を奪います。デバイスに到達しようとする外部のシステムからは、キャリアの共有IPしか見えず、変換層の背後にある特定のデバイスへトラフィックをルーティングする手段がありません。
デバイスがCGNATの背後にあるかを確認する方法
デバイス上で2つのコマンドを実行します。まず、ネットワーク接続に割り当てられたローカルインターフェースのアドレスを確認します。次に外部サービスに問い合わせ、インターネット側から自分のトラフィックがどのパブリックIPとして見えているかを確認します。
これらのアドレスが一致しない場合、デバイスは少なくとも1つのNAT層の背後にあります。パブリックIPがキャリアの共有レンジに属している場合、そのデバイスへのインバウンドSSH接続はまったく到達できません。変換がキャリア側で行われるため、ご自身の側でどれだけ設定を行っても解決できません。
従来のリモートアクセスツールが誤った前提に立っている理由
SSH、リモートデスクトッププロトコル、そして従来型のアクセスソリューションは、エンジニアが管理下に置くネットワークを想定して設計されました。安定したIPを持つサーバー、インバウンド接続を許可するネットワーク、一貫したトランスポート層の上にあるデバイスを前提としています。こうした前提は、企業のデータセンターやオフィスネットワークでは理にかなっていました。
しかし、デバイスが移動式発電機のセンサーであったり、高速道路沿いの充電器であったり、顧客の倉庫にあるエッジコンピューティング機器であったりする場合、これらの前提はまったく成り立ちません。こうした環境では、3つの根本的な前提が崩れます。
前提1：安定したIPアドレス
従来のツールはIPアドレスをデバイスの識別子として扱います。資産管理台帳はアドレスの一覧表になり、アクセス制御リストはIPレンジを参照し、エンジニアはどのIPがどの拠点に対応するかを記憶してデバイスを探します。
キャリアが何の通知もなくIPを再割り当てすると、この仕組みは即座に破綻します。昨日は問題なく接続できたデバイスが、今日はまったく別のアドレスになっているかもしれません。ファイアウォールのルール、アクセスリスト、ドキュメントは瞬時に陳腐化します。
前提2：インバウンドポートの利用可能性
標準的なリモートアクセスでは、リモートデバイスがポートで待ち受け、着信接続を待つ必要があります。このモデルはデバイスを、外部クライアントが接続しに来るサーバーとして扱っています。
CGNATはこれを不可能にします。ポートフォワーディングには、変換を行っているNAT機器へのアクセスが必要です。キャリアグレードNATでは、その機器にアクセスできません。管理しているのはキャリアであり、同じパブリックIPを共有する数千台の中から特定のデバイスへ特定のポートを転送する仕組みは提供されていません。
前提3：一貫したネットワークトランスポート
トンネルベースの接続は特定のネットワークインターフェースに紐づきます。デバイスがセルラーからWi-Fiに切り替わったり、ある基地局から別の基地局へ移ったりすると、そのハンドオフによって確立済みの接続は切断されます。それに依存していたセッションは警告なく終了します。
セルラーと衛星のバックアップトランスポートを併用するデバイスでは、問題はさらに複雑になります。セルラーはパブリックなエンドポイントに到達できますが、衛星接続はプライベートアドレスに制限されることが少なくありません。これらのトランスポートを切り替えるデバイスは、その都度まったく新しい接続基盤を必要とします。
5GとStarlinkのネットワークが状況をさらに悪化させる理由
5Gネットワークはほぼ例外なくCGNATの背後で運用されています。キャリアはすべてのモバイルデバイスにパブリックIPv4アドレスを割り当てられないため、大規模にアドレス変換を行います。5Gに接続されたデバイスは、他の数千の加入者とIPアドレスを共有しています。
5Gに本質的に備わるモビリティが、課題をさらに大きくします。デバイスは基地局間を移動し、ネットワークは絶えず接続をハンドオフし、キャリアはいつでもデバイスのアドレスを再割り当てできます。数時間以上安定して維持されるIPアドレスは稀です。
Starlinkと衛星ネットワークの課題
衛星インターネットはさらなる制約をもたらします。Starlinkや同様のサービスはデフォルトでCGNATを使用します。また、衛星が上空を通過するのに合わせて異なる地上局経由でトラフィックをルーティングするため、レイテンシの変動やセッション中のIPアドレス変更が発生し得ます。
遠隔地に配備されたデバイスは、衛星を唯一の接続手段としていることがよくあります。こうしたデバイスは複数のNAT層の背後に位置し、インバウンド接続の可能性はまったくありません。従来のリモートアクセスツールは、この環境では機能しません。
混在トランスポート環境が問題を増幅させる理由
冗長性を確保するために複数のネットワーク種別を使う配備は少なくありません。あるデバイスは通常はセルラーで接続し、セルラーが利用できないときは衛星にフェイルオーバーするかもしれません。利用できる場合は顧客のWi-Fiに接続することもあるでしょう。
ネットワークの種別ごとにNATの特性、IPアドレスの割り当て挙動、ファイアウォールの制限が異なります。あるトランスポートで機能する認証情報や設定が、別のトランスポートでは失敗することがあります。フリート規模でこの複雑さを手作業で管理することは、運用上不可能になります。
顧客のファイアウォールがもたらすもう一段階の障害
顧客環境に配備されたデバイスは、CGNAT以外のネットワーク制限にも直面します。倉庫、小売店舗、現場のオペレーションセンターは、それぞれ独自のファイアウォールを運用しています。そのセキュリティポリシーは通常、外部ベンダーからの恒常的なインバウンド接続を禁止しています。
協力的な顧客であっても、運用上の負担は生じます。新しい拠点ごとに、特定のポートとプロトコルを設定してもらうため、先方のIT部門との調整が必要になります。この調整は先方の優先順位では最下位に置かれがちです。そしてようやくルールが設定されても、次の接続試行が失敗するまで正しさを検証する手段がありません。
拠点ごとの設定作業という負担
顧客の拠点はどれも固有のネットワーク構築案件になります。先方のファイアウォールポリシーを把握し、ポートの開放を交渉し、設定を文書化し、接続性をテストする。この作業が配備場所の数だけ繰り返されます。
サポートの負担は顧客数に比例して増えていきます。50拠点であれば、拠点ごとの設定管理はエンジニアリング工数を相当に消費します。500拠点になれば、ネットワーク専任のスタッフなしでは立ち行かなくなります。
スプリットトンネリングの設定に関する問題
顧客が自社ネットワーク経由のアクセスを許可する場合、特定のルーティング設定を求められることがよくあります。内部リソース宛てのトラフィックは一方向へ、一般的なインターネットトラフィックは別方向へ流す必要があります。
これを誤って設定すると、顧客のトラフィックが不適切に自社ネットワークを経由してしまうか、デバイスが動作に必要なローカルリソースから切り離されてしまいます。設定ミスのたびに、こちらのデバイス要件を理解していないかもしれない顧客のIT担当者とトラブルシューティングの通話を重ねることになります。
接続がインバウンドではなくアウトバウンドで流れるべき理由
CGNAT、顧客のファイアウォール、トランスポートの切り替えに対する解決策は、接続の方向を完全に逆転させることです。到達できないかもしれないデバイスに到達しようとするのではなく、デバイスの側から自社が管理する基盤に接続させるのです。
このアプローチでは、デバイスからプロキシまたはリレーサービスへのアウトバウンド接続を使用します。ほぼすべてのネットワークが、ポート443でのアウトバウンドHTTPSトラフィックを許可しています。接続をアウトバウンドで開始することで、デバイスはあらゆるインバウンド制限を回避します。ポートフォワーディングは不要です。パブリックIPも不要です。顧客のファイアウォールに関する交渉も不要です。
アウトバウンド専用アーキテクチャの仕組み
デバイス上のエージェントが、クラウド上のリレーに対する恒常的なアウトバウンド接続を維持します。この接続はキープアライブメッセージによって維持されます。エンジニアがデバイスにアクセスする必要が生じたとき、そのセッションは既存のアウトバウンドトンネルを経由してルーティングされます。
デバイスが待ち受けポートを公開することは一切ありません。外部のスキャナーはそれを検出できません。攻撃者はデバイスに対して接続を開始できません。デバイスに至る唯一の経路は、自社が管理する基盤上の認証されたチャネルを通ります。
ネットワークのハンドオフを乗り切る
デバイスがネットワークを切り替えると、アウトバウンド接続はキープアライブの失敗によって切断を検知します。エージェントは直ちに、その時点で利用可能なネットワークインターフェース上で新しいアウトバウンド接続を確立します。
この再接続はエンジニアの介入なしに自動で行われます。ハンドオフ中にセッションが一時的に停止することはありますが、接続が回復すれば再開されます。ネットワークが何度変わろうと、現在どのIPアドレスを保持していようと、デバイスは到達可能なまま維持されます。
分散デバイスにとってゼロトラストネットワークアクセスとは何か
ゼロトラストアーキテクチャは、「すべてを検証し、デフォルトでは何も信頼しない」というシンプルな原則に基づいて動作します。これは接続がどこから発生したかに関わらず適用されます。自社ネットワーク内のデバイスも、カフェから接続してくるデバイスと同じ精査を受けます。
分散したデバイスフリートにとって、ゼロトラストとはIPベースのアイデンティティを完全に手放すことを意味します。デバイスは登録時に暗号学的なアイデンティティを受け取り、それはネットワークの変化に関わらず維持されます。アクセスの判断は、絶えず変化するIPアドレスではなく、このアイデンティティを参照します。
ネットワークレベルではなくサービスレベルのアクセス
従来のネットワークアクセスは広範な権限を与えます。いったん接続すれば、ユーザーはそのネットワークセグメント上のあらゆるリソースに到達を試みることができます。この全か無かのモデルは過剰なアクセスを生み、コンプライアンスのフレームワークはこれを次第に禁止するようになっています。
サービスレベルのアクセスは、特定のサービスに対してのみ権限を与えます。エンジニアはあるデバイスへのSSHアクセスを持ちながら、そのデータベースサービスへのアクセスは持たない、といった形です。監視システムはテレメトリのエンドポイントに問い合わせはできても、コマンドの実行はできません。それぞれの権限は、一般的なネットワーク上の存在ではなく、特定の機能に対応づけられます。
Remote.Itはこのサービスレベルのモデルをネイティブに実装しています。各デバイス上で個別のサービスを定義し、その特定のサービスへのアクセスを許可されたユーザーと共有できます。SSHアクセスを持つ人物が、明示的な承認なしに他のサービスや他のデバイスへ横展開することはできません。
IPベースのアクセス制御が破綻する理由
IPレンジに基づいて構築されたアクセス制御リストは、動的な環境では保守の悪夢になります。IPが変わるたびに、それを参照していたすべてのファイアウォールルールとアクセスポリシーが誤ったものになります。
フリート規模では、どのIPがどのデバイスに属するかを追跡するために、絶え間ない手作業の更新が必要になります。エンジニアはどのアドレスレンジがどの配備拠点に対応するかという属人的な知識を蓄えていきますが、その知識は担当者が退職すれば失われます。
アイデンティティベースのアクセス制御は、この問題を取り除きます。ポリシーはネットワークアドレスではなく、デバイスのアイデンティティとメタデータのラベルを参照します。特定の配備におけるデバイスへのアクセスを許可するポリシーは、その配備内のすべてのデバイスが同時にIPを変更したとしても、正しく機能します。
Remote.ItがCGNATと分散ネットワークの課題を解決する方法
Remote.Itは、従来のリモートアクセスが機能しない環境のために設計されました。インバウンド接続もパブリックIPアドレスも一切必要としないため、CGNAT、5G、Starlink、その他あらゆるネットワークトポロジーの背後で動作します。
Remote.Itエージェントを実行しているデバイスは、Remote.Itクラウドへのアウトバウンド接続を維持します。デバイスにアクセスする必要が生じたとき、セッションはこの既存の基盤を経由してルーティングされます。デバイス自体はパブリックインターネットからは見えないままです。
攻撃対象領域を露出しない
従来のリモートアクセスツールでは、デバイスが接続を待ち受けるポートを開いている必要があります。待ち受けポートは一つひとつが、攻撃者による探索、スキャン、悪用の試みの入口になります。
Remote.Itのデバイスには、インターネットに面した待ち受けポートが1つも存在しません。インバウンド接続が不可能であることは、インバウンドの攻撃経路が存在しないことを意味します。ポートスキャナーは何も見つけられません。脆弱性スキャナーには標的がありません。デバイスはネットワーク上に存在しながら、探索からは隠されたままです。
ネットワーク変化をまたいだ自動再接続
ネットワークが変化しても、Remote.Itの接続は自動的に再確立されます。セルラーから衛星への切り替え、基地局間の移動、電源再投入後の再接続のいずれの場合も、手作業の介入なしに接続が復旧します。
この自動化により、動的なネットワークを管理する運用上の負担がなくなります。チームは自らの管理が及ばないネットワークの変化に起因する接続トラブルの対応ではなく、本来やるべき業務に集中できます。
サービスレベルでのきめ細かなアクセス
Remote.Itのアクセス権限は個々のサービス単位で機能します。HTTPアクセスを与えずにSSHアクセスだけを与える。管理コマンドの実行を許可せずに監視のためのクエリだけを許可する。各ユーザーは、その役割に必要な分だけのアクセスを正確に受け取ります。
このきめ細かさは、過剰な権限を禁じるコンプライアンス要件に対応します。アクセスモデルが最小権限の原則を構造的に強制しているため、監査担当者はアクセスがその原則に従っていることを検証できます。
ゼロトラストのリモートアクセスソリューションで確認すべきこと
「ゼロトラスト」と銘打たれたソリューションのすべてが、実際にゼロトラストの原則を実装しているわけではありません。真のゼロトラストがどのようなものかを理解することが、選択肢を的確に評価する助けになります。
アウトバウンド専用の接続性
分散デバイスにおける真のゼロトラストには、アウトバウンド専用の接続モデルが必要です。インバウンドポートやパブリックIPを必要とするソリューションは、CGNATの背後で安定して機能することも、攻撃対象領域を効果的に最小化することもできません。
そのソリューションがキャリアグレードNATの背後でどのように機能するのかを、ベンダーに明確に尋ねてください。接続アーキテクチャを説明する技術文書を求めてください。明快に答えられないソリューションは、従来型のインバウンドモデルに依存している可能性が高いといえます。
暗号学的なデバイスアイデンティティ
デバイスは、識別のためにネットワークアドレスに依存するのではなく、登録時に暗号学的なアイデンティティを受け取るべきです。このアイデンティティは、再起動、ネットワークの変化、設置場所の移動をまたいで維持される必要があります。
アクセスポリシーは、このアイデンティティと関連するメタデータを参照すべきです。特定の配備におけるデバイスへのアクセスを許可するポリシーは、その配備内のすべてのデバイスが同時にIPを変更しても、正しく機能しなければなりません。
サービス単位の権限
アクセスは、ネットワーク上の一般的な存在ではなく、特定のサービスに対する権限を与えるべきです。SSHアクセスを与えられたユーザーが、そのデバイス上で動作する他のすべてのサービスへのアクセスを自動的に得るようなことがあってはなりません。
このきめ細かさを実現するには、ソリューションが個々のサービスを認識し、それらの境界を強制できる必要があります。特定のサービスではなく「デバイス」に対してアクセスを与えるネットワーク層のソリューションでは、この保護は得られません。
スケールするリモートアクセス基盤の構築
10台のデバイスでうまくいくアプローチが、1,000台になると壊滅的に破綻することはよくあります。最初からスケールを見据えて計画することで、後の痛みを伴う移行を避けられます。
一元的な管理と可視性
すべてのデバイス、その接続状態、そしてアクセス権限を一望できる画面が必要です。個別の設定を通じてデバイスを管理する方法は、小規模な配備を超えるとスケールしません。
Remote.Itは、デバイスフリート全体を表示する一元化されたダッシュボードを提供します。デバイスの状態、接続履歴、アクセスログが1か所に集約されます。1台ずつ個別に確認することなく、数千台のデバイスを検索、絞り込み、管理できます。
APIによる自動化
手作業でのデバイス登録と設定は、フリートの成長に伴ってボトルネックになります。プロビジョニング、アクセス管理、監視を自動化するAPIは、不可欠な基盤となります。
既存のツールやワークフローとの連携は、運用上のオーバーヘッドを削減します。デバイスは製造時に自己登録できます。アクセスは従業員の役割変更に応じて自動的にプロビジョニングできます。監視システムは独自の連携開発なしにデバイスの状態を照会できます。
成長を支える料金モデル
デバイス単位の料金モデルは、規模が大きくなると負担が過大になり得ます。フリートの拡大に伴ってコストがどう増えるかを把握してください。利用量ベースや段階制の料金モデルは、大規模な配備においては単純なデバイス単価よりも適していることがよくあります。
ライセンス費用以外の運用コストも考慮に入れてください。保守やトラブルシューティングに多くの人員の時間を要するソリューションは、介入なしに確実に動作するより高価な選択肢よりも、総額では高くつく可能性があります。
セキュアなリモートアクセスを導入する際によくある失敗
分散デバイス向けのリモートアクセスを導入する組織は、しばしば予測可能な失敗を繰り返します。こうしたパターンを理解しておくことが、失敗を避ける助けになります。
ネットワークの多様性を過小評価する
パイロット導入は、従来型の企業環境に近い、よく管理されたネットワークで行われがちです。そして本番配備では、デバイスがCGNAT、厳格なファイアウォール、モバイルネットワークに直面した途端に失敗します。
導入を決める前に、配備先の中で最も厳しいネットワークでソリューションをテストしてください。デバイスがセルラー上で動作するのであれば、セルラーでテストする。顧客が厳格なファイアウォールを運用しているのであれば、同様の制限の背後でテストする。
現在の規模を基準にソリューションを選ぶ
小規模な配備でうまく機能するツールが、2年後に必要となる規模を支えられるとは限りません。リモートアクセスソリューションの移行は業務を混乱させ、多大なエンジニアリング投資を必要とします。
現在の配備規模ではなく、想定される将来の規模を基準にソリューションを評価してください。同等かそれ以上の規模の導入事例を確認してください。現在のベンダーの階層上限を超えて成長したときに何が変わるのかを把握してください。
認証情報のライフサイクル管理を軽視する
自律的に動作するデバイスには、人手の介入なしに再起動をまたいで維持される認証情報が必要です。こうした長期間有効な認証情報は、適切に管理されなければセキュリティリスクを生みます。
ソリューションが認証情報の自動ローテーションに対応していることを確認してください。デバイスを廃止する際に認証情報がどのように失効されるかを把握してください。有効な認証情報を保持したまま盗まれたデバイスは、誰かが手作業でアクセスを失効させるまで、ネットワークにアクセスできてしまいます。
まとめ：現代のネットワークに耐えるリモートアクセスを構築する
従来のリモートアクセスツールは、今日デバイスが動作しているネットワークを想定して設計されたものではありません。CGNAT、5Gのモビリティ、Starlink、そして顧客が管理するファイアウォールは、IPの安定性とインバウンド接続性に関する根本的な前提を覆してしまいました。
その解決には、設定の微調整ではなくアーキテクチャの変更が必要です。アウトバウンド専用の接続、暗号学的なデバイスアイデンティティ、サービスレベルのアクセス制御は、症状ではなく根本原因に対処します。これらのアプローチは、現代のネットワークが保証できない条件に依存しないため、ネットワークトポロジーに関わらず機能します。
Remote.Itは、これらのアーキテクチャ原則を本番運用可能なプラットフォームとして実装しています。デバイスはCGNATの背後でも確実に接続します。インターネットからのスキャンには見えないままです。アクセスはユーザーが必要とする権限だけを過不足なく与えます。チームはネットワーク接続の問題と格闘するのではなく、生産的な業務に集中できます。
デバイスが動作するネットワークは、これからも変化し続けます。5Gの普及は加速します。衛星接続は主流になります。IPv4の枯渇は、より多くのネットワークをCGNATへと押しやります。こうした変化に耐える原則の上にリモートアクセス基盤を構築することが、投資と業務を守ることにつながります。
よくあるご質問：CGNATネットワークでセキュアなリモートアクセスツールが機能しない理由
CGNATとは何ですか。なぜ従来のリモートアクセスツールを破綻させるのですか。
CGNAT（キャリアグレードNAT）は、1つのパブリックIPアドレスを数千台の加入者デバイスで共有します。従来のツールは、デバイスに到達するために固有のIPとインバウンド接続を必要とします。CGNATはお客様の管理外にあるキャリア側でアドレス変換を行うため、インバウンドトラフィックを特定のデバイスへルーティングできません。
ポートフォワーディングを設定してCGNATを回避できますか。
いいえ。ポートフォワーディングには、変換を行っているNAT機器へのアクセスが必要です。CGNATでは、その機器を所有・運用しているのはキャリアです。各IPアドレスを共有する数千の加入者の中から個別の加入者のためにポートを転送する仕組みは提供されていません。
Remote.ItはCGNATや5Gネットワークの背後でどのように機能しますか。
Remote.Itは、デバイスからクラウド基盤へのアウトバウンド専用接続を使用します。デバイスはインバウンド接続を待つのではなく、自ら外向きに接続を開始します。アウトバウンドトラフィックは事実上すべてのネットワークで許可されているため、このアプローチはあらゆる種類のNATの背後で機能します。
デバイスのネットワークやIPアドレスが変わったときはどうなりますか。
従来のツールではセッションが切断され、アクセス設定は無効になります。Remote.Itは接続の喪失を自動的に検知し、新しいネットワーク上で接続を再確立します。デバイスのアイデンティティはIPアドレスとは独立して維持されるため、ネットワークが変化してもアクセスポリシーは有効なままです。
サービスレベルのアクセスがネットワークレベルのアクセスより安全なのはなぜですか。
ネットワークレベルのアクセスは、接続されたネットワークセグメント上のあらゆるサービスに到達する権限を与えます。サービスレベルのアクセスは、許可した特定のサービスに対してのみ権限を与えます。認証情報が漏洩した場合でも、攻撃者はネットワーク全体ではなく、その認証情報が許可する特定のサービスにしかアクセスできません。
ゼロトラストの原則は分散デバイスにどのように適用されますか。
ゼロトラストは、発信元に関わらずすべてのアクセス要求を検証します。分散デバイスにおいては、暗号学的なアイデンティティの検証、サービスレベルの権限、そして継続的な検証を意味します。デバイスがネットワーク上の位置を根拠に信頼を得ることはありません。Remote.Itはこれらの原則をデフォルトで適用します。
Remote.Itはどのような種類のネットワークに対応していますか。
Remote.Itは、アウトバウンドのインターネットアクセスがあるあらゆる種類のネットワークで動作します。これにはCGNAT、5Gセルラー、Starlink衛星、顧客が管理するファイアウォール、多層NAT環境が含まれます。アウトバウンド専用のアーキテクチャにより、特定のネットワーク構成への依存がなくなります。