1.はじめに
Microsoft Entra Global Secure Accessは、Microsoft Entra Internet AccessとMicrosoft Entra Private Accessの2つのネットワークセキュリティを提供しています。
今回は、ZTNA型のリモートアクセスの機能を提供するMicrosoft Entra Private Access編です。
ちなみに、前回の記事のインターネットアクセス編は、以下となります。
2.現状のまとめ
Microsoft Entra Private Accessは、ZTNA型のリモートアクセスを実現します。
2-1.ZTNAとは
ZTNAとは、ゼロトラストネットワークアクセスの略称であり、アタックサーフェス（攻撃対象領域）がない状態で、リモートアクセスをすることができます。
以下図のように、VPN型のアクセスの場合は、内部ネットワークのDMZ上に、グローバルIPを保有することで、外部ネットワークからのアクセスを実現することができます。
このとき、内部ネットワークとつながるグローバルIPが、インターネット上に露出します。そのため、VPN装置の脆弱性を狙われて攻撃を受ける恐れがあります。
対して、ZTNA型の場合は、内部ネットワーク上にあるコネクタから、内から外方向への通信のみで、リモートアクセスを実現します。このため、内部ネットワークとつながる攻撃表面がありません。
ただし、VPN型は、宛先をネットワークセグメント(例：192.168.0.0/24)のように設定することができ、ネットワークを拡張するような使い方ができますが、ZTNA型は、明示的に、特定のアプリ（IPアドレス/FQDN/ポート)を指定する必要がありますので、導入における一定のハードルがあります。
ランサムウェア被害の傾向について
警察庁が提供している情報に、「サイバー空間をめぐる脅威の情勢等」というデータがあります。
これはインターネット上での脅威（犯罪）を統計的にまとめたものとなります。
参考：警察庁「サイバー空間をめぐる脅威の情勢等」
https://www.npa.go.jp/publications/statistics/cybersecurity/
このデータに、ランサムウェアの被害にあった原因に関する記載があります。
令和５年時点でも、ランサムウェアの感染経路として、VPN機器から侵入された事例が最も多く報告されています。
これは、先ほどVPN型の図で説明したVPN装置のグローバルIPが、攻撃表面となり、脆弱性からクラッキングされたことが伺われます。
引用：P28「ランサムウェアの感染経路」
https://www.npa.go.jp/publications/statistics/cybersecurity/data/R5/R05_cyber_jousei.pdf
2-2.構成
Entra Private Accessを利用するには、以下図のように、
- アクセスしたいアプリがあるネットワーク上に、「プライベートネットワークコネクタ」を設置
- Entra管理センター上で、転送プロファイルの有効化、宛先となるアプリの設定
- 条件付きアクセスの設定（オプション）
- エンドポイントにGlobal Secure Access クライアントのインストール
を実施することで、実現できます。
2-3.サポートされるエンドポイント
Global Secure Access クライアントをインストール可能なOSは、WindowsとAndroidとなります。
ただし、Windowsにおいては、以下前提条件があり、Entra JoinedやEntra Hybrid Joinedという観点は、導入のハードルになりやすいかと思います。
- Windows 11 または Windows 10
- Azure Virtual Desktop シングルセッション、Windows 365
※Azure Virtual Desktop のマルチセッションはサポートされていません - Microsoft Entra 参加済みまたは Microsoft Entra ハイブリッド参加済み
※Microsoft Entra 登録済みデバイスはサポートされていません。
2-4.プライベートネットワークコネクタ
プライベートネットワークコネクタは、Windows Server 2012 R2 以降のWindows Serverにインストールすることで、利用できるエージェントです。
ZTNA型となるため、インバウンドの穴あけは不要で、ポート80,443のアウトバンド通信が可能であれば利用できます。なお、可用性のため、複数のエージェントを用意することが推奨されます。
加えて、ドメインに参加していないマシンで実行することができます。
ただし、統合 Windows 認証 (IWA) を使用するアプリケーションへのシングル サインオン (SSO) が必要な場合は、ドメイン参加済みマシンで、プライベートネットワークコネクタを構築する必要があります。
2-5.POP
現在提供されているPOPは、以下となり、日本では東京と大阪にロケ―ションがある模様です。
2-6.ログの保持期間
トラフィックログに関しては、30日間保持されます。
監査ログに関しては、Entra ID P1/P2の場合は、30日間保持されます。
ログのエクスポートに関しては、診断設定機能から実現することができます。
2-7.未提供機能(2024年7月時点)
ICMPやDNS over HTTPS、IPv6は、サポートされません。
また、Learn上では、UDPもサポートされていないようですが、アプリケーションセグメントにUDPの設定もできる模様です。
たぶんQUICなど利用できないものがあるため、まだ限定的なサポートかもしれません。
内部アプリ（FQDN）の名前解決
宛先として登録済みのエンタープライズアプリケーション（FQDN）の名前解決（DNS）は、可能でした。
例えば、宛先に、web.example.localのようなFQDNを利用することができます。
しかし、ポート53番のDNSに関しては、プライベートネットワークコネクタが代理応答するため、期待される結果とならないことがあります。これはZTNA型のリモートアクセスの場合、いったんEntra Global Secure Access側のPOPに接続した後、宛先のプライベートネットワークに到達するため、Entra Global Secure Access側のグローバルIP情報が必要となるためと考えられ、アプリ側のプライベートAレコードを設定しても、Entra Global Secure Access側のグローバルIPが返されるようです。
3.環境準備
それでは、動作確認をしていきます。
利用するユーザに関しては、ライセンス割り当て済みであることを前提とします。
2024年7月末時点の検証での確認結果となります。
そのため、記載内容を保証するものではなく、テスト環境ならびに設定値によって、異なる結果となる場合がございます。
掲載内容に問題がある場合は、ご指摘いただければ修正させていただきます。
3-1.構成
今回のテスト構成は、以下となります。
特徴としては、PCを２台用意し、それぞれHyper-Vを有効化しています。
片方のPC Aには、Windows 11 PCを仮想的に作っており、もう片方のPC Bには、Windows Server 2022とWindows Server 2025 Previewを仮想的に作っています。
そして、PC B上のWindows Server 2025 Previewには、DNSも有効化しており、アプリのFQDNを名前解決できるようにしています。このDNSをプライベートネットワークコネクタは、登録済みアプリの名前解決に利用しています。
アクセス回線には、IPv6を使っております。ただし、DS-Lite（Dual-Stack Lite）と呼ばれている技術で、IPv6のみの通信環境でも、IPv4 over IPv6技術を利用し、IPv4での通信も可能にしています。特徴としては、混雑しがちなIPv4ネットワークを避けて、IPv6のアクセスを利用できる点となります。
Windows 11の仮想マシン上で、nperfというサイトで、スループットを測定すると以下のようになりました。
無線区間が、802.11acとなり、ボトルネックになっていますので、下りは、209.4Mbps、上りは122.1Mbps、遅延は6msという結果です。
後ほど、このアクセス回線を利用して、ctsTraffic.exeというツールを使いスループットを測定してみます。
3-2.転送プロファイルの有効化（初回のみ）
本セクションは、初回作業時のみです。
Microsoft Entra 管理センターに移動し、「セキュリティで保護されたグローバルアクセス > 接続 > トラフィック転送」に移動します。
ここで、今回利用するプロファイルとなる「プライベート アクセス プロファイル」を有効化します。
3-3.クライアントアプリの展開
Global Secure Access クライアントアプリをIntuneで展開します。
なお、インターネットアクセスとプライベートアクセスは、同じクライアントを利用しますので、前回の記事で、既に展開自体は完了しています。
3-4.各種制限の適用
各種制限の適用も、前回の記事で実施済みです。
特に、DNS over HTTPSは、プライベートアクセスにおいて、FQDNを利用する場合は影響を受けると思います。
理由ですが、DNS通信が暗号化されている場合は、通信途中で、プライベートネットワークコネクタがDNSの代理応答ができなくなると思われるためです。（たぶん）
3-5.プライベートネットワークコネクタのインストール
リモートアクセスしたいアプリとIP到達性があるネットワークセグメントにWindows Server (2012 R2以降)を構築します。
インストーラーは、「接続 > コネクタ」から、「コネクタサービスのダウンロード」を選択し、「規約に同意してダウンロード」からダウンロードすることが可能となります。
このインストーラを対象となるWindows Serverにインストールしましたら、完了です。
コネクタグループにまとめることで、 同じコネクタ グループに属するコネクタが、高可用性と負荷分散のために単一のユニットとして動作することが可能となります。そのため、少なくとも２つのコネクタを同一のグループに割り当てることが推奨されます。
3-6.プライベートアクセス用のエンタープライズアプリケーションの登録と設定
それでは、いよいよプライベートアクセス用のエンタープライズアプリケーションの登録と設定をしていきます。
「エンタープライズアプリケーション」に移動し、「＋新しいアプリケーション」をクリックします。
すると、ネットワークアクセスのプロパティの画面になります。
ここで、コネクタグループ（複数のプライベートネットワークコネクタを束ねるグループ）を設定し、宛先となるアプリケーションセグメントを設定します。
既に設定済みなので、以下図のように設定しました。FQDNやIPなどは、実際の環境に置き換えましょう。
ポートの書き方
ネットワークアクセスプロパティにおけるポートの書き方ですが、コンマ[,] で区切ることもできますし、ハイフン[-] でレンジを指定することもできる模様です。
例えば、HTTP,HTTPSを対象にしたい場合は、80,443と記載したり、ポートを気にせず、IPだけ考慮したい場合は、0-65535のようにレンジで指定することも可能となります。
ちなみに、「＋アプリケーションセグメントの追加」をクリックすると、以下のような画面で、設定することができます。
Public Previewのときはできなかった完全修飾ドメイン名やUDPが追加されていますね。
「ユーザとグループ」もありますので、利用ユーザまたはグループを登録しておきます。
最後は、条件付きアクセスへの適用です。
ターゲットのところに、先ほど作成したエンタープライズアプリケーションとなっているプライベートアプリを選択します。
特に、Entra Private Accessの特殊な要素はないですね。
4.動作確認
動作確認をした結果としては、SSH, HTTP, HTTPS, SMB, RDP,FTPに関して、正常に動作することが確認できました。
| ポート | 説明 | 結果 |
|---|---|---|
| 22 | SSH | 成功 |
| 80,443 | HTTP,HTTPS | 成功 |
| 445 | SMB | 成功 |
| 3389 | RDP | 成功 |
| 4444 | テスト用ポート | 成功 |
| 21,エフェメラルポート | FTP パッシブモード | 成功 |
FTP通信
FTPに関しては、アクティブモードの場合は、サーバ発通信が発生することから、ZTNA型としては上手く動作させられないようです。
パッシブモードの場合は、データコネクションのポートがエフェメラルポートとなってしまうので、広くポートを開ける必要があります。
4-1.PsPing
ICMPは利用できないので、TCPによる疎通確認を実施します。
以下URLより、クライアントにPsPingをダウンロードします。
以下のように、クライアントからPsPingを実行します。
.\psping.exe -n 5 [serverip]:[port]
実行結果は以下となり、正常に疎通しているように見受けられます。
PS C:\work> .\psping.exe -n 5 10.10.20.42:4444
PsPing v2.12 - PsPing - ping, latency, bandwidth measurement utility
Copyright (C) 2012-2023 Mark Russinovich
Sysinternals - www.sysinternals.com
TCP connect to 10.10.20.42:4444:
6 iterations (warmup 1) ping test:
Connecting to 10.10.20.42:4444 (warmup): from 172.23.249.32:50372: 10.80ms
Connecting to 10.10.20.42:4444: from 172.23.249.32:50373: 21.80ms
Connecting to 10.10.20.42:4444: from 172.23.249.32:50374: 25.90ms
Connecting to 10.10.20.42:4444: from 172.23.249.32:50375: 15.84ms
Connecting to 10.10.20.42:4444: from 172.23.249.32:50376: 17.87ms
Connecting to 10.10.20.42:4444: from 172.23.249.32:50377: 19.62ms
TCP connect statistics for 10.10.20.42:4444:
Sent = 5, Received = 5, Lost = 0 (0% loss),
Minimum = 15.84ms, Maximum = 25.90ms, Average = 20.21ms
4-2.SSH
SSHのテストには、以下URLを参考に、宛先となるWindows ServerにOpenSSHの設定をしています。
SSHサーバの設定が完了しましたら、クライアントからssh [username]@[ssh server fqdn]を入力し、アクセスを実施します。
すると、無事アクセスでき、プロンプトが[username]@[hostname]になりました。
4-3.HTTP,HTTPS
HTTP,HTTPSに関しては、宛先となるWindows Serverに、IISの設定をしています。
なお、HTTPSに関しては自己証明書を使う簡易構成となっていますので、httpsのところが赤くなり、セキュリティ保護なし、となりました。これは証明書の問題なので、いったんOKとしています。
4-4.SMB
SMBについては、宛先となるWindows ServerのCドライブ配下にshareというフォルダを作り、共有設定をします。
そして、クライアントからフォルダが見えるかの確認を実施します。
フォルダパスに、\\10.10.20.42\shareと入力すると、対象フォルダのファイルを閲覧や編集することができました。
4-5.RDP
RDPについては、宛先となるWindows Serverで、RDPの許可（システム > リモートデスクトップ）し、対象となるユーザを許可します。
そして、クライアントから「mstsc.exe」を実行することで、リモートデスクトップ可能となりました。
4-6.FTP
FTPについては、宛先となるWindows Serverで、FTPを有効化しておきます。
暗号化も適用しているため、以下サイトの手順を利用すると良いかもしれません。
加えて、クライアントソフトとしては、WinSCPを利用し、明示的なTLS/SSL暗号化によるFTPを実施しています。WinSCPに関しても、下記URLからダウンロードすることが可能です。
こちらも、SMBと同様のフォルダを見ることができ、クライアントにファイルをダウンロードしたりすることができました。
4-7.ctsTrafficによるテスト
最後は、ctsTrafficによるスループットテストを実施します。
以下URL先にあるリンクからGitHubに移動し、ctsTraffic.exeをダウンロードします。
サーバIPは適切に置き換えて頂き、以下コマンドを実行します。
指定がない場合は、ポート4444で、TCP通信によるスループットを測定できます。
#サーバー
.\ctsTraffic.exe -listen:* -consoleverbosity:1
#クライアント
.\ctsTraffic.exe -target:[サーバーIP] -consoleverbosity:1
実行結果は、以下で、速度は約86Mbpsでした。
無線区間を2回通過しており、上りが約100Mbpsのアクセスを利用していることを考えると期待通りかもしれません。また、NetErrorや、DataErrorも特に出ておらず、良好な結果と思われます。
#実行結果
PS C:\work> .\ctsTraffic.exe -listen:* -consoleverbosity:1
Configured Settings
-----------------------
Protocol: TCP
Options: KeepAlive InlineIOCP MsgWaitAll
IO function: Iocp (WSASend/WSARecv using IOCP)
IoPattern: Push <TCP client send/server recv>
PrePostRecvs: 1
PrePostSends: 1
Level of verification: Connections & Data
Port: 4444
Buffer used for each IO request: 65536 [0x10000] bytes
Total transfer per connection: 1073741824 bytes
Accepting connections on addresses:
0.0.0.0:4444
[::]:4444
Server-accepted connections before exit : 0xffffffffffffffff
Legend:
* TimeSlice - (seconds) cumulative runtime
* Send & Recv Rates - bytes/sec that were transferred within the TimeSlice period
* In-Flight - count of established connections transmitting IO pattern data
* Completed - cumulative count of successfully completed IO patterns
* Network Errors - cumulative count of failed IO patterns due to Winsock errors
* Data Errors - cumulative count of failed IO patterns due to data errors
TimeSlice SendBps RecvBps In-Flight Completed NetError DataError
0.001 0 0 0 0 0 0
5.001 59 6383206 8 0 0 0
10.004 0 6300782 8 0 0 0
15.009 0 9008744 8 0 0 0
20.005 0 9444739 8 0 0 0
25.006 0 10693336 8 0 0 0
30.010 0 10686925 8 0 0 0
35.007 0 13206874 8 0 0 0
40.004 0 12931458 8 0 0 0
45.016 0 11938221 8 0 0 0
50.013 0 13980663 8 0 0 0
55.007 0 10511480 8 0 0 0
60.000 0 13860608 8 0 0 0
**** ctrl-break hit -- shutting down ****
Historic Connection Statistics (all connections over the complete lifetime)
-------------------------------------------------------------------------------
SuccessfulConnections [0] NetworkErrors [0] ProtocolErrors [0]
Total Bytes Recv : 653787136
Total Bytes Sent : 296
Total Time : 60825 ms.
PS C:\work>
PS C:\work> 653787136 / 60.825 *8 / 1000000
85.989265729552
5.おわりに
昔のAzure AD Application Proxyは、HTTP/HTTPS通信が対象でしたが、Microsft Entra Global Secure Accessでは、TCP（＋設定としてはUDPも可能）まで拡張され、さらに、宛先にFQDNも利用できるようになってました。
さらに、iPhoneからも利用できるようになったら、便利ですね。
次回は、GSAのMicrosoft トラフィック編です。