【SSE】[Zscaler] [ZIA] [設計] [個別] [インライン] [+α] NAT Control / DNS Control

はじめに

これまで紹介してきたインラインプロセスでは、

• Firewall Control
• SSL Inspection
• Cloud Application Control
• URL Filtering
• File Type Control
• Data Loss Prevention（DLP）

といったセキュリティ機能を中心に紹介してきました。

一方で、ZIAにはこれらのセキュリティ機能を支えるネットワーク系の機能も存在します。

• NAT Control
• DNS Control

どちらもDNS通信や非Web通信を適切に処理するためのネットワーク機能という位置付けになります。

インラインプロセスでの処理順番

なお本記事で紹介するNAT ControlとDNS Controlは、インラインプロセスの中では

Firewall Controlの直後、Cloud Application Controlより前で実行されるネットワーク系の機能です。

HTTPやHTTPS通信だけでなく、DNSやその他の非Web通信を支える重要な役割を担っています。

NAT Controlとは

NAT Controlは、Destination NAT（宛先NAT）を実施する機能です。

送信元端末がアクセスしようとしている宛先IPアドレスを書き換え、別の宛先へ転送できます。

Cloud Application Controlのようにアプリケーションを認識する機能ではなく、

IPアドレスやポート番号を利用したL3/L4レベルのネットワーク制御になります。

Zscaler Trusted DNS Resolver

NAT Controlで最も利用されるのが、Zscaler Trusted DNS Resolverという定義済みルールです。

このルールでは、ユーザーが任意のDNSサーバへ送信したDNS問い合わせを、

Zscalerが提供するTrusted DNS ResolverへDestination NATします。

例えば、8.8.8.8 → Zscaler Trusted DNS Resolverというように、

宛先を書き換えることで、企業として利用させたいDNSサーバへ統一できます。

通常は、この定義済みルールを利用するケースがほとんどでしょう。

なぜ宛先を書き換えるのか

このルールが役立つ代表的なシーンが、リモートワークや公衆Wi-Fiなどの社外ネットワークです。

例えば、ホテルやカフェ、フリーWi-Fiでは、DHCPによって払い出されたDNSサーバをそのまま利用することになります。

しかし、そのDNSサーバが必ずしも信頼できるとは限りません。

悪意のあるDNSサーバであれば、

www.example.com → 本来のIPアドレス

ではなく、

www.example.com → 攻撃者が用意したサーバ

を返し、利用者をフィッシングサイトやC2サーバへ誘導することも可能です。

このようなリスクを防ぐため、Z-Tunnel 2.0などでDNS通信もZIAへ転送し、

NAT ControlによってZscaler Trusted DNS ResolverへDestination NATすることで、

利用するネットワークに依存せず、常に信頼できるDNSサーバによる名前解決を利用できます。

また、企業全体でDNS基盤を統一できるため、DNS ControlやZscaler Threat Intelligenceとも連携しながら、

一貫したDNSセキュリティを実現できます。

DNS Controlとは

DNS Controlは、DNS通信専用のポリシーエンジンです。

Firewall ControlでDNS通信が許可された後、DNS問い合わせに対して追加の制御を実施できます。

例えば、

• DNS問い合わせの許可・拒否
• DNSトンネルの検知
• ZPAとの連携
• SIPAに必要なDNS制御

などが代表的な利用例になります。

インターネットアクセスだけでなく、ZPAやSIPAを支える基盤としても重要な機能です。

DNS問い合わせの許可・拒否

DNS Controlでは、DNS問い合わせ先や問い合わせ内容に応じて、DNS通信を許可・拒否できます。

例えば、

• 企業で利用を許可していないDNSサーバへの問い合わせ
• マルウェアが利用する悪意のあるドメインの名前解決
• 社内ポリシーで利用を禁止しているドメイン

などへのDNS問い合わせを遮断できます。

一般的なWebフィルタリングでは、「接続しようとした通信」をブロックします。

一方、DNS Controlでは、名前解決の段階で通信を止めることができます。

つまり、不要な通信そのものを発生させないことが大きなメリットです。

DNSトンネルとは

DNSトンネル（DNS Tunneling）とは、本来は名前解決に利用するDNS通信へ、データを埋め込んで送受信する攻撃手法です。

例えば、マルウェアが社内へ侵入した場合、HTTPやHTTPS通信はFirewall ControlやSSL Inspectionによって検査されるため、

外部との通信が困難になるケースがあります。

そこで攻撃者は、一見すると普通のDNS問い合わせに見える通信へデータを埋め込み、情報を外部へ送信しようとすることがあります。

DNS通信は企業ネットワークでも許可されていることが多いため、攻撃者に悪用されやすい通信の一つです。

DNS Controlでは、

• 不自然に長いサブドメイン
• TXTレコードなどを悪用した問い合わせ
• DNSトンネル特有の通信パターン

などを検知し、不正なDNS通信をブロックできます。

つまり、DNS通信を単なる名前解決ではなく、情報漏えいやマルウェア通信の経路として悪用されないよう保護する

こともDNS Controlの重要な役割です。

DNS Controlで利用される定義済みルール

DNS Controlには、用途ごとに定義済みルールが用意されています。

代表的なものとして、以下があります。

• UCaaS One Click Rule
• ZPA Resolver for Locations
• ZPA Resolver for Road Warrior

特に、ZPA Resolver for Road Warriorは、リモートワーク環境からZPAやSIPAを利用する際に重要となるルールです。

このルールは、DNS Control Policyに用意されている定義済みルールであり、

SIPAで非Web通信を利用する場合に有効化が必要となります。

非Web通信では、HTTP Host HeaderやTLS SNIのようなドメイン情報を取得できません。

そのため、DNS問い合わせの段階でSIPA対象通信を判定します。

SIPA対象となるドメインへのDNS問い合わせは、ZIAからZPAへ転送され、App Connector経由で名前解決が行われます。

その結果、通常の宛先IPアドレスではなく、ZPA Resolver IPがクライアントへ返却されます。

クライアントはそのResolver IP宛に通信を開始し、ZIAはDNS問い合わせ時の情報を利用して、

その通信を適切なApp Connectorへ転送します。

一方、SIPA対象ではないDNS問い合わせについては、通常どおり実際の宛先IPアドレスが返却され、

通常のインターネット通信として処理されます。

つまり、非Web通信におけるSIPAは、DNS問い合わせの段階から特別な制御が始まっているということです。

設計で重要なのは「DNS」を理解すること

インラインプロセスというと、HTTPやHTTPS通信をイメージしがちですが、

実際には多くの通信がDNS問い合わせから始まります。

そのため、DNSを適切に制御することは、インターネットアクセスだけでなく、

ZPAやSIPAなどの各種機能を正常に動作させるためにも重要になります。

一方、NAT Controlについては、特別な要件がない限り、

Zscaler Trusted DNS Resolverの定義済みルールを利用するケースがほとんどです。

設計時には、まずDNS Controlの役割を理解し、必要に応じてNAT Controlと組み合わせるという考え方で十分でしょう。

おわりに

NAT ControlとDNS Controlは、Firewall ControlやCloud Application Controlのような目立つ機能ではありません。

しかし、DNS通信や非Web通信を支えるネットワーク機能として、ZIAでは重要な役割を担っています。

特に、ZPAやSIPAではDNS Controlとの連携が前提となるケースも多く、

インラインプロセス全体を理解するうえでも押さえておきたい機能です。

通常のインターネットアクセスでは定義済みルールを利用することが多いため、

設計者としては、

• NAT Controlは「どこへ送るか」を決める
• DNS Controlは「DNS問い合わせをどう扱うか」を決める

という役割の違いを理解しておけば十分でしょう。

➡【次の記事へ】【SSE】[Zscaler] [ZIA] [設計] [個別] [インライン] [+α] ENAT

管理人

自称SASEエンジニアです。 2児の父親をやりながら、日々エンタープライズ向けの次世代ネットワークインフラと格闘しています。一日一投稿を目標に投稿頑張りますので、是非読んでください！