HPE Aruba Networking SSEの紹介ブログの2回目となる今回はZTNAについて紹介させていただきます。
第1回をご覧いただいていない方は、第1回の概要/準備編を事前にお読み頂くと、より理解しやすいかと思います。
【第1回】HPE Aruba Networking SSEのご紹介 - 概要/準備編
今回はエージェントレスZTNAとエージェントZTNAに分けてご紹介させていただきます。
5.エージェントレスZTNA
Networking SSEではエージェントレスZTNAとエージェントZTNAの2つの形式でZTNAを提供しています。
冒頭でもお話ししましたがNetworking SSEではエージェントレスZTNAに力を入れており、本製品の特徴ともなっております。
エージェントレスZTNAとは名前の通りで、クライアントデバイスにエージェントのソフトウェアをインストールすることなくZTNAの機能が利用可能です。
例えば協力会社の社員が利用するPCなどエージェントのインストールを強要できない環境などで有効な機能です。
ですが今回検証をしてみて気づいた点として、80/443のWebアプリケーション以外にもRDPやSSHなどのアプリケーションにも対応しており、私のようにネットワークエンジニアとして自宅から社内の検証環境にアクセスしつつ検証を行う用途では十分な機能を提供していると感じました。
5-1.対応アプリケーション
ZTNAを利用するためにはアプリケーションの登録が必要となります。
図5.1：アプリケーションの登録
アプリケーションの登録画面から対応するアプリケーションの確認ができますが、図5.1で「Agentless Supported」の記載があるものがエージェントレスでのアクセスに対応したアプリケーションとなります。
左上のSelf-Hosted Web Applicationが80/443ポートを利用するWebアプリケーションとなりますが、それ以外にRDPやSSH等もエージェントレスZTNAの対象となっています。
一例としてRDPのアプリケーションを作成してみます。
図5.2：アプリケーション：RDP 基本設定
まずは基本設定として以下を入力します。
・Name：任意の名称で設定するアプリケーション名
・Domain/IP Address：接続先となるRDPサーバーのアドレス
・Port：デフォルトの「3389」より変更も可能
・Server type：旧バージョンのRDPやLinux向けのXRDPも選択可能
図5.3：アプリケーション：RDP Connector Zone設定
次にConnector Zoneを設定します。
複数拠点に社内アプリケーションが存在していて拠点毎にConnector Zoneを構築している場合に、アプリケーション(この例ではRDPサーバー)がどの拠点に存在しているかを定義する設定となります。
Connectorに関しては第1回のブログで紹介しています。
図5.4：アプリケーション：RDP クレデンシャル設定
RDPの場合、オプションでログイン用のクレデンシャルを保存しておくことで、ユーザーがRDP接続を行う際にクレデンシャルの入力が不要となります。
図5.5：アプリケーション：RDP IdP設定
IdPの選択画面です。
ここでは登録したIdPの中からの選択制となりますが、今回の検証ではMicrosoft Entra IDを利用しています。
IdPについても第1回のブログで紹介しています。
図5.6：アプリケーション：RDP Tags設定
最後にタグの設定となります。
作成したアプリケーションにタグ付けを行うことで、アプリケーションをグルーピングすることが可能です。
これはアクセスルールの設定時にタグを指定することで、ルールの簡素化が可能となります。
後ほどのルール設定でも説明させていただきます。
以上でアプリケーションの作成は完了となります。
ZTNAの導入時の障壁として、多数あるアプリケーションの登録作業が挙げられます。
図5.7：CSVによるアプリケーションの一括登録
Networking SSEではCSVによるアプリケーションの一括登録にも対応しています。
またZscaler ZPAからのアプリケーションの移行用に変換ツールが用意されており、ZPAからCSVでダウンロードしたファイルをツールで変換して、Networking SSEにインポートすることも可能です。
※2024年3月時点では変換ツールの入手にはサポートへの連絡が必要となります。
Migrating Applications from Zscaler ZPA to Axis
5-2.ルールの構成要素の作成
Networking SSEでの通信許可/拒否設定はすべてルールにて定義します。
ルールの作成の前にルールで使用する各構成要素を作成します。
この項番は必須ではなく、デフォルト値を使用することも可能ですが、詳細な制御のためには必要な設定項目となります。
第1回の項目2でプロビジョニングしたユーザーや項目5-1で設定したアプリケーションもルールの構成要素の一つとなっています。
要素としては主に以下のものがあります。
・IP Ranges：IPアドレスレンジ(サブネット)単位で通信制御を行う際に使用
・Locations：拠点のルータ等からIPsecトンネル構成を利用する場合に使用
・Device Posture：ポスチャの設定をカスタマイズする際に使用
・Time Ranges：ルールの有効時間(平日の9-17時のみ等)を設定する際に使用
・Block Page：ブロックページのカスタマイズの際に使用
・Profiles：項番3-1で作成したアプリケーションのセッションタイムアウト等の詳細設定に使用
ここでは2つを抜粋して説明させていただきます。
・Device Posture
エージェントレスZTNAの場合、ポスチャチェックで利用可能なのはクライアント証明書のインストールチェックのみです。
有効にすると指定のクライアント証明書をインストールしたデバイスのみがリソースへのアクセスが可能となります。
図5.8：Device Posture Client Certificate
設定するにはNetworking SSE側に証明書のアップロードが必要となります。
・Profiles
ここではRDPアプリケーションを例にとって説明します。
図5.9：RDPプロファイル
RDPではブラウザによる接続と、OS標準のリモートデスクトップクライアントソフトでの接続可否の設定が可能です。
その他クリップボードの利用可否や、セッションタイムアウトの設定もここで行います。
「RDP file reauthentication time」ではリモートデスクトップクライアントソフトでの接続時の「.rdp」ファイルの有効時間を設定します。
5-3.ルールの作成
Networking SSEでの通信許可/拒否設定はすべてルールにて定義します。
ZTNAだけでなく、SWG/CASB/DLPも全て同じルールの設定から行います。
SASE製品の中にはZTNA用、SWG用...とそれぞれに別々のルール設定項目が設けられている製品もありますが、Networking SSEでは全ての機能を統一されたルール設定で行うことが特徴の一つです。
ルールは大きく3つの項目から成り立っています。
①Conditions
②Action
③Profiles
①Conditions
図5.10：ルール：Conditions設定
Conditionsはさらに細分化されて以下の5項目の設定が可能です。
・Identity
ユーザーを選択します。
デフォルトはanyとなりますが、各IdPに登録されたユーザーより選択することが可能です。
・Source
以下の項目を設定可能です。
IP Ranges：項目5-2で設定した場合に選択
Countries：ジオロケーションによる国設定
Locations：項目5-2で設定した場合に選択
・Device Posture
項目5-2で設定したDevice Postureのプロファイルから選択可能です。
・Time Range
項目5-2で設定したTime Rangeのプロファイルから選択可能です。
・Destination
項目5-1で設定したアプリケーションから選択可能です。
②Action
図5.11：ルール：Action設定
ルールで設定できるアクションは
・Allow
・Block
の2つのみとなります。
またブロックページは項目5-2で設定したブロックページ設定から選択が可能です。
ブロックページについてはSWGの機能紹介時に説明させていただきます。
③Profiles
図5.12：ルール：Profiles設定
項目5-2で設定したアプリケーションのプロファイルから選択可能です。
1つのルールに複数のアプリケーションを登録することができるため、各種アプリケーション(RDP/SSH等)用のプロファイルが設定可能です。
また各機能の項目で説明しますが、インターネットアクセス用のWebプロファイルやDLP用のプロファイルもここで設定します。
以上がルール設定となります。
5-4.動作確認
それでは実際にエージェントレスZTNAを利用してRDP接続を行ってみます。
まずそもそもユーザーはどのようにしてアプリケーションにアクセスするのかという点が疑問となるかと思いますが、ユーザーはユーザーポータルにアクセスすることで各アプリケーションへのアクセスが可能となります。
図5.13：ユーザーポータルアドレス
ユーザーポータルのアドレスは管理者ポータルにて確認が可能です。
図5.13の通りIdP毎にアドレスが発行されます。
管理者はこのアドレスをユーザーに通知する必要があります。
図5.14：ユーザーポータルへのログイン
ユーザーはユーザーポータルのアドレスへアクセスしログインを実行します。
図5.15：SAML認証
ログイン時にSAML認証が実行されます。
またDevice Postureを設定している場合はこのタイミングでポスチャチェックが行われます。
エージェントレスZTNAの場合、SAML認証とポスチャチェックはユーザーポータルへのログイン時にのみ実行されます。
図5.16：ユーザーポータルアプリケーション一覧
ログインするとルールによってユーザーに許可されたアプリケーションが一覧で表示されます。
ユーザーはユーザーポータルからアクセスしたいアプリケーションを選択してアクセスします。
RDPを選択すると以下の画面が表示されます。
図5.17：RDP接続方法選択
項目5-2でRDPのProfilesを設定しましたが、有効にしている場合はブラウザによるアクセスとリモートデスクトップクライアントソフトによるアクセスの選択が可能です。
図5.18/5.19：RDPブラウザアクセス
「Open Web RDP in your browser」を選択した場合、ユーザーポータルにアクセスしているブラウザからRDP接続を実行します。
簡易的に利用する分には良いですが、ブラウザでのRDPはあまり操作性が良くないので、OS標準のリモートデスクトップクライアントソフトによるアクセスも可能です。
図5.20：RDPファイルのダウンロード
「Download an RDP launcher file」を選択するとRDPの設定ファイルの「.rdp」ファイルがダウンロードされます。
ユーザーはダウンロードしたrdpファイルをダブルクリックすることで、OS標準のリモートデスクトップクライアントソフトにてRDP接続が可能です。
このrdpファイルは項目4-2のRDP Profilesの「RDP file reauthentication time」にて設定した時間を超過すると無効化されるため、再度rdpファイルをダウンロードしなおす必要があります。
では次に管理者ポータルにてアクセスログを確認してみます。
ZTNAでの接続はユーザー観点かアプリケーション観点かのどちらかで確認できます。
図5.21：ZTNAログ ユーザー観点
以下の点がログに記録され、時系列(下にスクロールするほど古い)で表示されます。
・送信元のユーザー名
・宛先のアプリケーション名
・アクセス元デバイスのOS情報
・送信元のIPアドレス(マスクしています)
・接続時間
・ルール名
ログに関しては項目が少ない印象を受けました。
例えばログからはエージェントレスでのアクセスなのかエージェントからのアクセスなのかは判別出来ないようです。
図5.22：ZTNAログ アプリケーション観点
アプリケーション観点のログもアプリケーションに対してどのユーザーがいつアクセスしたかの表示となりますが、内容的にはユーザー観点と変わりはありません。
図5.23：ZTNAログ 時間設定
ZTNAのログは過去1週間、過去1ヶ月を設定して確認することが可能です。
6.エージェントZTNA
エージェントソフトウェアをクライアントデバイスにインストールして利用するエージェントZTNAに関しても、ルール設定等はエージェントレスZTNAと同様となります。
ここではエージェントレスZTNAとの差異部分について説明させていただきます。
6-1.エージェントのインストール
エージェントZTNAを利用する場合はAtmos Agentと呼ばれるエージェントのインストールが必要となります。
エージェントは管理者ポータルからのダウンロードも可能ですが、エージェントレスZTNAで利用したユーザーポータルからもダウンロードが可能です。
そのためユーザーポータルにアクセスしてエージェントのダウンロード/インストールをユーザー自身に実行させることも可能です。
図6.1：ユーザーポータルからのエージェントダウンロード
ユーザーポータルからのダウンロードの場合はダウンロードしたデバイスのOSに適したインストーラーがダウンロードされます。
図6.2：管理者ポータルからのエージェントダウンロード
管理者ポータルでは各OS用のインストーラーがダウンロード可能です。(モバイル用は各ストアへのリンクとなっています。)
図6.3：Atmos Agentへのログイン
Windowsでの動作となりますが、インストール後はAtmos Agentへのログインが必要となります。
ログイン時にSAML認証が実行されます。
Atmos Agentはデフォルトでデバイスの起動時に自動で起動します。
図6.4：Atmos Agentインストール後のデバイスのIPアドレス
Atmos AgentをインストールしたデバイスにはAtmos Agentの仮想ネットワークインターフェースが追加され、CG-NATのアドレスレンジ(10.64.0.0/10)からIPアドレスとDNSサーバーが割り当てられます。
DNSの名前解決はAtmos Agentで設定されたDNSサーバーに対して行われ、Atmos Agentで設定されたIPアドレスを返します。
そのためトラフィックはAtmos Agentへ転送され、Atmos AgentがNetworking SSEクラウドへとトラフィックを転送します。
文字だけではわかりづらいかと思いますが、下記のドキュメントに詳細なシーケンスの解説があります。
Atmos Agent: Routing Traffic to the Atmos Cloud
6-2.対応アプリケーション
エージェントZTNAではエージェントレスと比べて対応するアプリケーションも多くなります。
図6.5 エージェントZTNA 対応アプリケーション
エージェントレスZTNAで利用可能なアプリケーションに加えて、以下の3つが追加となります。
・SSH Range
・Network Range
・Active Directory
ここでは「Network Range」について説明させていただきます。
図6.6：Network Range アドレス指定
Network Rangeでは名前の通り宛先のアプリケーションをIPアドレスレンジやドメインのワイルドカードで広い範囲で指定が可能です。
図6.7：Network Range ポート番号指定
またプロトコルとしてはTCP/UDPを指定可能で、ポート番号もレンジで設定が可能です。
ICMPをオプションで有効にすることでpingによる疎通確認も可能となります。
ZTNAの観点としてはネットワークレンジ単位でのアプリケーションへのアクセス許可は好ましくないかもしれませんが、導入当初はネットワークレンジ単位でのアクセス許可を行い、徐々にアクセス可能なアプリケーションの範囲を絞っていくような利用が可能です。
また後述しますが、Network Rangeでは社内サーバー側からリモートアクセスクライアントに対しての通信が可能な、「Server Initiated Flow」にも対応しています。
6-3.Device Posture
エージェントレスZTNAとの大きな差異として、Device Postureがあげられます。
エージェントをインストールしたデバイスはDevice Postureでより多くの情報を取得/制御が可能です。
Device Postureの設定は項目5-2のDevice Postureから行います。
図6.8：Device Posture Windowsバージョン
図6.8ではWindowsの例ですが、メインバージョンの選択が可能です。
例えば「Windows 10 and above」に設定しルール上で有効にした場合は、Windows10未満のデバイスは宛先リソースへの接続ができなくなります。
図6.9：Device Posture Windows Conditions
Conditionsではより詳細な項目での制御が可能です。
Windowsの場合は以下の設定が可能です。
Firewall：Windowsファイアウォールの有効/無効
Disk Encryption：BitLockerでの暗号化実施有無
Domain Joined：ADドメインの参加有無
Client Certificate：特定のクライアント証明書のインストール有無
Registry：特定のレジストリキーの有無
File Path：特定のファイルパスの有無
Processes：特定のプロセスの実行有無
Windows Patches：特定のパッチの適用有無
Antivirus：アンチウィルスソフトウェアの有効/無効
Trusted Processes：特定のプロセスの実行有無
図6.10：ポスチャチェック
ポスチャで取得した内容は管理者ポータルのEnrolled Agentsから確認が可能です。
Device Postureで有効にしたConditionsは取得されチェックされますが、有効にしていないConditionsは「Not Monitored」となり取得自体が行われません。
6-4.Server Initiated Flow
一般的なZTNAの場合、社内のサーバーから社外のリモートアクセスクライアントに対しての通信ができず、VoIPのようなP2Pの通信や、パッチ配布、リモートアシスタンスといったアプリケーションを利用しているユーザーは完全にZTNAに移行ができず、一部リモートアクセスVPNを利用しなければならないといったケースが見られました。
Networking SSEでは「Server Initiated Flow」の機能を利用することで、上記の通信をZTNAにて利用することが可能となります。
図6.11：Server Initiated Flow
図6.11が実現方法となりますが、ConnectorにNAT Poolを設定し、リモートアクセスクライアントに対してNAT poolからIPアドレスを払い出します。
社内のアプリケーション(サーバー)はリモートアクセスクライアント宛の通信をConnectorのNAT poolから払い出されたIPアドレス宛に行います。
その通信を受け取ったConnectorはトラフィックをリモートアクセスクライアントへ転送します。
図6.11の例だとNAT poolが192.168.20.0/24となりますので、社内のルーティングで192.168.20.0/24宛の通信はConnectorのIPアドレスである192.168.10.1宛に向ける必要があります。
・ConnectorのNAT pool設定
図6.12：Connector IP Pool Settings
Server Initiated Flowの設定手順として、まずはConnectorにNAT poolを設定していく必要がありますが、2024年2月の検証時点ではNAT pool設定のための機能開放をサポートに依頼する必要がありました。
機能が解放されますと図6.12の通りConnectorの設定に「IP Pool Settings」が追加されます。
図6.13：Connector IP Pool
今回は設定方法は割愛しますが、実際のNAT poolの設定はConnectorにSSH等でログインしてCLIで実行する必要があります。
poolの設定が完了すると図6.13の通り設定したIP Poolの値が確認できます。
次にサーバーのゲートウェイとなるルータ等で宛先をConnectorのNAT poolアドレスとして、ネクストホップがConnectorのIPアドレス宛にルーティングを追加します。
こちらも環境に依存する設定となりますので、手順は割愛します。
・宛先アプリケーション作成
Server Initiated Flowを有効にできるのは「Network Range」で作成したアプリケーションのみとなります。
まずは宛先となるリモートアクセスクライアントのNetwork Rangeアプリケーションを作成します。
今回の設定では
送信元：社内サーバー
宛先：リモートアクセスクライアント
としてNetwork Rangeアプリケーションを設定します。
例としてRDP用のアプリケーションを作成します。
図6.14：Network Range リモートアクセスクライアント側アプリケーション
IP rangeに設定するのはConnectorのNAT poolに設定したIPアドレスとなります。
今回の社内サーバーからリモートアクセスクライアント方向のRDPとは関係ないのですが、リモートアクセスクライアント間のRDPについての話となります。
少しややこしい話になりますが、リモートアクセスクライアント間の通信を行う場合、ここで設定するアプリケーションは宛先以外に送信元としての役割も兼ねます。
Allowed Ports and Protocolで指定するプロトコルとポート番号ですが、社内のサーバーからリモートアクセスクライアント向けの通信には影響を及ぼさないのですが、リモートアクセスクライアント間の通信を行う場合には送信元の設定として送信元のポート番号を指定する必要があります。
RDPの場合送信元のポート番号はランダムとなりますので、ウェルノウンポート以外を指定しました。
例えば1024だけをポート番号で指定すると、社内サーバーからリモートアクセスクライアント向けのRDPは成功しますが、リモートアクセスクライアント間のRDPは失敗しました。
また話を元に戻します。
図6.15：Network Range リモートアクセスクライアント側Server Initiated Flowオプション
次にServer Initiated Flowを有効化します。
Port RangeにはServer Initiated Flowで宛先となる際の受信ポート(社内サーバーからリモートアクセスクライアントにアクセスする際の宛先ポート)を指定します。
クライアントのエージェントがこのポートでリッスンします。
RDPのためTCP/UDPの3389番を指定します。
以降は通常のアプリケーションの作成方法と同様です。
・送信元アプリケーション作成
次にServer Initiated Flowでは送信元となる社内サーバー側もNetwork Rangeアプリケーションとして作成します。
図6.16：Network Range 社内サーバー側アプリケーション
IP rangeに設定するのは社内サーバー側のIPアドレスとなります。
Allowed Ports and Protocolで指定するプロトコルとポート番号は送信元のポート番号を指定する必要があります。
前述の通りですがRDPの場合送信元のポート番号はランダムとなりますので、ウェルノウンポート以外を指定しました。
図6.17：Network Range 社内サーバー側Server Initiated Flowオプション
次に送信元となる社内サーバー側アプリケーションでもServer Initiated Flowを有効化します。
感覚的には送信元のためServer Initiated Flowオプションは不要と感じられますが、有効にしてポート番号を指定しないとRDPでの接続ができませんでした。
ポート番号として3389を指定していますが、ここのポート番号は動作に影響は及ぼさないようです。
試しにポート番号を1024に指定してもRDPでの接続は成功しました。
こちらも以降は通常のアプリケーションの作成方法と同様です。
・ルール作成
最後にルールの作成方法となります。
図6.18：Server Initiated Flow ルール設定
基本的には通常のルール設定と同様となりますが、特筆すべきはNetwork Rangeで作成したリモートアクセスクライアント側アプリケーションと社内サーバー側アプリケーションの双方をDestinationに設定します。
このルールの設定で社内サーバーからリモートアクセスクライアント向けのRDPが可能となりますが、同様にリモートアクセスクライアント間のRDPも実現できます。
6-5.動作確認
Network Rangeで作成したServer Initiated Flowを動作確認してみます。
社内サーバーからリモートアクセスクライアント向けのRDPを試してみます。
図6.19：リモートアクセスクライアントのAssigned Static IP
リモートアクセスクライアントにアサインされるIPは管理者ポータルから確認が可能です。
社内サーバー側アプリケーションに登録したIPレンジ内のWindows PCからリモートアクセスクライアントのAssigned Static IPに対してPingを実行します。
図6.20：リモートアクセスクライアント向けPing
Network RangeアプリケーションでICMPオプションを有効にしているため、Pingが成功します。
図6.21：リモートアクセスクライアント向けRDP
RDPに関しても接続は成功します。
ではアクセスログを確認してみます。
図6.22：アクセスログ リモートアクセスクライアント側アプリケーション
Server Initiated Flowを有効にした場合、エージェントをインストールしたデバイスでエージェントにログインすると、リモートアクセスクライアント側アプリケーションがログに記録されます。
図6.23：アクセスログ 社内サーバー側アプリケーション
RDPを実行した際のログは社内サーバー側アプリケーションへのアクセスとしてログに記録されます。
大変長くなってしまいましたが、今回のZTNA編は以上となります。
Networking SSEではエージェントレスZTNAの機能が充実しており、エージェントを導入することで社内サーバー発の通信にも対応できるといったメリットもあり、他社製品との差別化要因となり得る部分を感じ取っていただけたら幸いです。
次回はSWGやCASBといったインターネット向けアクセスに関するセキュリティ機能のお話です。
他のおすすめ記事はこちら
著者紹介
SB C&S株式会社
技術本部 技術統括部 第2技術部 1課
藤ノ木 俊
