オフィスでエージェントレスおよびエージェントベースの ZTNA を使用する

オフィス内で、エージェントレス ZTNA または ZTNA エージェント使って、社内アプリケーションにアクセスできます。

オフィスでエージェントレス ZTNA を使用する

オフィス内のユーザーは通常、FQDN によって社内アプリケーションにアクセスするため、リクエストは内部の DNS サーバーに送信されます。

内部の DNS サーバーには社内アプリケーションのレコードがあるため、ユーザーは直接そのアプリケーションに移動します。そのため、ZTNA ゲートウェイを経由しません。

ユーザーに ZTNA を経由させるには、次の手順を実行します。

ネットワーク構成の例を以下に示します。次の例は、このネットワーク設定に基づいています。

ユーザーが ZTNA を確実に経由するようにする最も簡単な方法は、ユーザーのデバイスが常に外部の DNS サーバーの IP アドレスをポイントするように設定することです。

ユーザーが内部リソースにアクセスしたときの処理の流れは次のようになります。

ユーザーを内部の DNS サーバーの IP アドレスにポイントする場合は、DNS サーバーに次の DNS レコードがあることを確認してください。

社内アプリケーションの外部 FQDN を、ZTNA ゲートウェイの FQDN にポイントする CNAME レコード。例: help.ABC.com が ZTNA.ABC.com に解決されます。
アプリケーションの内部 FQDN と外部 FQDN が同じである場合は、内部 FQDN を変更し、Sophos Central のリソース設定を更新する必要があります。たとえば、内部 FQDN と外部 FQDN が両方とも help.ABC.com である場合は、内部 FQDN を help.in.ABC.com に変更します。リソースレコードの作成方法については、リソースの追加を参照してください。

ユーザーが内部リソースにアクセスしたときの処理の流れは次のようになります。

ユーザーが、社内アプリケーション help.ABC.com にブラウザ経由でアクセスしようとします。
DNS リクエストが、内部の DNS サーバー DNS.ABC.com に送信されます。
内部の DNS サーバーが、アプリケーション help.ABC.com を ZTNA ゲートウェイ ZTNA.ABC.com に解決します。
ZTNA ゲートウェイが、2つ目の A レコードエントリ help.in.ABC.com を使用して、アプリケーションへのリクエストを転送します。これにより、ループ (help.ABC.com → ZTNA.ABC.com → help.ABC.com) が回避されます。
ユーザーが ZTNA ゲートウェイに接続して、社内アプリケーションにアクセスできるようになります。

オフィス内のユーザーは通常、FQDN によって社内アプリケーションにアクセスするため、リクエストは内部の DNS サーバーに送信されます。

ただし、ユーザーのエンドポイントデバイスに ZTNA エージェントがインストールされている場合、ZTNA エージェントが DNS リクエストをインターセプトし、ZTNA ゲートウェイに送信します。

ユーザーがブラウザに IP アドレスを入力して内部リソースにアクセスしようとすると、ZTNA をバイパスして直接リソースにアクセスすることになります。ユーザーが FQDN によって内部リソースにアクセスするようにするには、ファイアウォールルールを追加します。

こちらは、Sophos Firewall で設定したファイアウォールルールの例です。

このルールは、ユーザーが任意のゾーンから ZTNA ゲートウェイにアクセスできるようにする一方で、他のアプリケーションサーバーへのアクセスを拒否しています。つまり、リソースをホストするアプリケーションサーバーにアクセスするには、ZTNA を経由する必要があります。

このルールは、ユーザーが IP アドレスを使ってリソースに直接アクセスしようとしたときに、エージェント利用またはエージェントレスの両方のケースに適用されます。