更新日：2026.9.6
| このページの内容 |
今回の目的
 |
前回に引き続き、シナリオ2 ZTNA方式のリモートアクセスです。PC1からAWS内のAD1に通信する際、PC1がVPN経由でAD1にアクセスするのではなく、上の図の赤矢印のようにRC1に代行通信させるのがゴールです。 |
 |
で、代行通信の結果はPC1が得ることができるんだよね？ |
|
そうだね。今回はその設定を見ていきます。 |
内部DNSサーバの登録
|
まずは赤枠のところにRC（Resource Connector）を構築します。構築作業の中でRCが参照するDNSサーバを選択する工程があるので、予め内部DNSサーバ（今回はAD1がDNSサーバを兼任）を登録しておきます。 |
|
ん？RCは社内宛の通信を代行するんだよね？DNSの通信も代行するのかな？ |
|
そうだね。PC1が社内のリソースに通信するにあたっては社内のリソースの名前解決が必要だ。VPNaaS方式の場合はPC1が社内のDNSサーバへDNS queryを投げるわけだけど、ZTNA方式の場合はこのDNS queryもRCが代行して行うことになる。ということでその内部DNSサーバを登録する作業から。 |
①Connect → End User Connectivity → Manage servers → DNS Servers へ。
②+Add を押し、server nameとserver1とserver2をそれぞれ入力しSave。
RCの構築
|
それでは続いてRC本体の構築をしていきます。 |
①Connect → Network Connections → Connector Groups → +Addへ。
②Connector Group nameに任意の名前を入れます。今回はAWS-Tokyo-RC1にしました。
Region（ややこしいですがAWSのregionではなくsecure accessのregionです）
は今回はAsia Pacific（Tokyo）にしました。そしたらNext。
③Connectorをどこで建てるかを選択します。今回はAWSを選択。
その下にScaling calculatorがあります。デフォルトは図の通りRCに流れるスループット見込みが4Gbpsになっており、これを捌くために11個のc5.xlargeのインスタンスが必要と見積もられています。あくまで見積もられているだけなのでそのままNextでOKです。尚、今回は検証なのでトラフィック量も少なく、当然11個も必要ないです。1個だけ建てます。
④そのままSave。
⑤Copyを押してProvisioning Keyをメモしておく。
|
ここからAWS側の作業に移ります。 |
⑥AWSのAMIのページへアクセスしView purchase optionsへ。
⑦$0.00と書いてあります。これは契約料やライセンス料はかからないということです。
AWSのスペック利用料（トラフィック料だったりインスタンス利用料だったり）はかかります。
右下のsubscribeへ。
⑧Launch your softwareへ。
⑨RegionでAsia Pacific（Tokyo）を選択しLaunch from EC2へ。
⑩任意のインスタンス名を入力。今回はAWS-Tokyo-RC1にしました。
⑪画面を下にスクロール。Instance typeはデフォルトで選択されているc5.xlarge。
key pairは任意のものを選択。Network settingsの右側にあるeditへ。
⑫RC1を建てるVPCとSubnetを選択。インターネットへアクセスできるようにAuto-assign publicもEnableにします。
デフォルトで適用されるsecurity groupは、プライベートIP（10.0.0.0/8、172.16.0.0/12、192.168.0.0/16）
からのsshだけが許可されています。後ほど、自宅のグローバルIPからインターネット越しにsshできるよう、
security groupを編集します。
⑬Advanced network configurationを開き、Primary IPに任意のIPを設定します。今回は172.17.1.80にしました。
⑭画面を1番下のほうまでスクロールすると、User data - optionalという欄が出てきます。
ここに、KEY="xxxxxxxxxxxx"を入力します。
xxxには⑤でメモしておいたProvisioning keyを貼り付けます。
そしたらLaunch instanceへ進みVMを起動します。起動するとRCは自動的にSecure Accessへの接続を試行します。
⑮Secure Accessの画面に戻るとConfirm Connectorsというボタンが表示されているのでクリック。
⑯赤枠のとおりステータスが無事にConnectedになりました。
構築したRC1にアクセスしてみる
|
試しに構築した赤枠のRC1に管理アクセスしてみます。 |
①RC1に適用されているsecurity groupを編集するため赤枠へ。
②Edit Inbound rulesへ。
③自宅からインターネット越しにssh接続できるよう、赤枠の通り自宅のグローバルIPを送信元アドレスにした許可ルールを追加。
④Teratermを開いて、RC1の動的グローバルIPを入力しOKへ。
⑤User nameにacadmin。
Authentication methodsにUse RSA～を選択し、右のほうの赤枠を押してVM構築時に選択していたkeyを選択しOK。
⑥無事ログインできました。RCはLinuxベースです。
|
ここまで案内しておいてなんだけど、特にRCに管理アクセスしてやらなければいけないことはなかった・・・。 |
|
なんだ、無駄だったってこと？ |
|
・・・はい。なのでこの手順はカットで大丈夫です！ |
Private Resourceの設定
|
続いてPrivate Resourceを設定します。今回はAD1へのRDPと、FortiVMのport2へのHTTPSにトライします。 |
|
ういす。これってVPNaaSのときもやったやつですよね？リモートアクセス端末からのアクセス先を指定するやつ。 |
|
そうだね。まずはAD1から。 |
①Resource → Private Resources → ＋Addへ。
②Private Resource Nameに任意の名前を入力。今回はZTNA-AD1-EC2AMAZ-NLBG2L7にしました。
Internally reachable addressは、AD1のホスト名＋ドメイン名であるEC2AMAZ-NLBG2L7.naxxxx.localを入力。
ProtocolはRDPを選択。
Use internal DNS server to resolve the domainにチェックを入れ、内部DNSサーバとなっているAD1のIPアドレスを選択。
③画面を下にスクロールし、Zero-trust connectionsにチェック。画面右下のSaveをクリック。
④左下の赤枠のようにZTNA-AD1-EC2AMAZ-NLBG2L7の作成が完了し表示されている。
FortiVMのport2もZTNAの宛先にするため、再度右上の+Addへ。
⑤Private Resource Nameに任意の名前を入力。今回はZTNA-FGVM-port2にしました。
Internally reachable addressは、fg3-port2.na■■■■.localにしました。これは内部DNSサーバで名前解決すると172.17.2.226です。このFortiVMへの管理HTTPS接続用のポート番号は、通常の443ではなくカスタマイズした17443番になっているため、PotocolはAny TCPを選択しポート番号に17443と入力。
Use internal DNS server to resolve the domainには同じくチェックを入れる。
⑥画面を下にスクロールし、Zero-trust connectionsにチェック。画面右下のSaveをクリック。
ZTAにenrollするためのEntra IDとのSAML設定
|
続いてZTNA（Cisco Secure AccessにおいてはZTAと呼称）にEnrollするためのSAMLの設定をします。今回はVPNaaSを接続する時と同様、Entra IDとSAML連携して認証するようにします。 |
|
待って、難しいな。まずEnrollってなに？ |
|
これはZTAで初めてSecure Accessに接続する時に必要な手続きだ。後ほど実際に見ていくけど、今回はEntra IDの認証を通せばenroll完了となるようにする。そのためにEntra IDとSAML連携するための設定を行う必要がある。 |
|
え？Entra IDとのSAML連携は、シナリオ1のVPNaaSの接続でVPN profileを作成したときに既に設定したじゃん？ |
|
そうなんだよ。このSAML連携設定、VPNaaS用とZTA用とそれぞれ行わないといけないんだ。私も最初はややこしかった。 |
|
そういうことか。ややこいですね・・・。 |
|
まあ仕様的に仕方ないんだよね。ということで手順を見ていきます。 |
①Connect → Users,Groups,and Endpoint Devices → Configuration managementへ。
②Add SSO authenticationへ。
③SSO Authentication Nameに任意の名前を入力。今回はSAML_for_ZTA_enrollmentにしました。
User DirectoryはSCIMを設定したときのTEST_Entra_IDを選択しNext。
④Select a ProviderからEntra IDを選択。あとはそのままでNext。
⑤Download Service Provider XML fileをクリック。
Cisco_SSE_SP_Metadata.xmlというXMLファイルがダウンロードされる。
⑥Entra IDの画面に移り、Enterprise applicationsのページからNew applicationへ。
⑦Create your own applicationへ。
⑧任意のアプリ名を入力。今回はSAML_for_CSA_ZTAにしました。そしたら左下のCreateへ。
⑨Assign users and groupsへ。
⑩Add user/groupへ。
⑪このアプリをユーザに紐づけるため、None Selectedへ進む。
⑫画面右側に下の画面が表示される。今回はentra_user1～4を選択し左下のselectへ。
⑬Assignへ。
⑭Single sign-onへ。
⑮SAMLへ。
⑯Upload metadata fileをクリック。
表示された画面上でSecure AccessからダウンロードしていたCisco_SSE_SP_Metadata.xmlを選択してAdd。
⑰画面右上に新しい画面が表示されるのでSave。
⑱赤枠のDownloadをクリック。
SAML_for_CSA_ZTA.xmlというXMLファイルがダウンロードされる。
⑲Secure Accessの画面に戻り、赤枠のところで先程EntraIDからダウンロードしたXMFファイルをアップロード。
右下のDoneへ。
⑳赤枠のとおり無事追加されました。
Access policyの設定
|
続けてVPNaaSのときと同様、リモートアクセス端末からZTAでPrivate ResourceにアクセスするためのAccess policyを設定します。まずは上の図の赤矢印のように、ZTAでAD1に代行通信させるポリシーから。 |
|
これはFortigateでいうところのFirewall policy。Paloaltoでいうところのsecurity policyと同様のものだったよね？ |
|
そうだね。 |
①Secure → Access Policy → Add Rule → Private Accessへ。
②Rule nameに任意の名前を入力。今回はZTA_to_AD1にしました。
FromはEntra IDから取り込んだ4つのユーザ（entra_user1～4）を選択。
ToはPrivate Resourceで作成したZTNA-AD1-EC2AMAZ-NLBG2L7を選択。
③Zero-Trust Client-based Posture ProfileでNoneを選択。
ポスチャ―は端末のOSのバージョンが問題ないかとか、ウイルス対策ソフトが稼働しているかとかをチェックする機能です。デフォルトのprofileの場合、端末のディスクが暗号化されていないとチェックに引っかかります。検証PCは暗号化をしていないためこれに引っかかってしまうため、ポスチャ―対象外となるよう適用させるprofileをNoneにします。本来はNoneにすべきではないのですが検証ですので。
そしたら右下のNextへ。
④Save。
⑤同様の手順でZTAでFGVMのPort2へアクセスするポリシーであるZTA_to_FGVM_port2も作成。
検証PCにZTAモジュールをインストール
|
シナリオ1 リモートアクセス用のVPNaaSの設定のときに、Secure ClientのVPNモジュールをインストールしていた。今回はそれに加えてZTA用のモジュールである cisco-secure-client-win-5.1.18.5828-zta-predeploy-k9.msi をインストールします。その手順を見ていきます。 |
①インストーラ（cisco-secure-client-win-5.1.18.5828-zta-predeploy-k9.msi）を開くとウィザードが表示されるのでNext。
②acceptにチェックを入れてNext。
③Installへ。
④Duo Desktopというアプリも同時にインストールされます。
⑤Finish。
|
Duo Desktopって何のためにインストールされるんですか？ |
|
これはポスチャ―機能のためらしい。端末が正規のものかどうかを都度チェックするポスチャ―機能は、ZTNAの肝とも言える部分だ。それを実現するためのアプリというふうに捉えておけばよいと思う。 |
|
なるほど。 |
ZTAへのEnroll
|
ZTAモジュールがインストールできたら、ZTAへのEnrollを実施します。これは初回のみ必要な登録作業です。 下図の中にも Registration is required to access secure resoruces というように、登録を求めるメッセージがあります。 |
①Enrollへ。
②Entra IDのアカウントを入力しContinueへ。
③Microsoftのログイン画面が表示されたら、再度Entra IDのアカウントを入力しNext。
④PWを入力し無事に認証が通ると下図の通りEnrolledになる。
|
Enrolledになりましたね。 |
|
そうだね。そしたら動作確認を。 |
動作確認
|
まずはPC1からZTNAでAD1（ec2amaz-nlbg2l7.nxxxxu.local）にRDP接続しています。 |
AD1のFQDNを入力してConnect。無事接続できました。
secure accessのActivity Searchのログを見ると、赤枠の通り、3389番ポート宛てのRDP通信が成功しています。
内部DNSサーバであるAD1のwiresharkのログです。DNS通信（53番ポート通信）のみが表示されるようフィルタしています。
赤枠のように172.17.1.80（RCのIPアドレス）から172.17.1.90（内部DNSサーバのIPアドレス）に対してqueryが行われ、それに対して返答しています。つまり、RCがDNS通信も代行していることがわかります。
|
無事成功ですね。 |
|
そうだね。今回もとても長かったけど、読んでくれてありがとうございました。 |