本ブログはSecure Accessのリモートアクセス機能紹介ブログの第3回となります。
第1回の概要編をご覧いただいていない場合は、概要編からお読みいただくのをお勧めします。
【第1回】Cisco Secure Access リモートアクセス機能のご紹介 - 概要編
第2回では設定方法について記載しておりますので、こちらもご確認ください
【第2回】Cisco Secure Access リモートアクセス機能のご紹介 - 設定編
今回は第3回 動作編となります。
4.動作確認
今回は第2回で設定した内容を元にリモートアクセスを行ってみます。
①Browser-based ZTNA
Browser-based ZTNAではクライアントデバイスへエージェントのインストールが不要であることが特徴です。
ではユーザはどうやってアプリケーションにアクセスするのかというと、Private Resourcesに「External URL」としてアクセス用のURLが発行されます。
このURLをユーザに通知することでユーザはブラウザから社内アプリケーションへアクセスすることが可能となります。
ブラウザにコピーしたURLを貼り付けてアクセスしてみます。
今回の検証ではMicrosoft Entra IDでのSAML認証を設定したため、SAML認証が実行されます。
検証では社内に設置したCatalyst 9115のAPのEWCの管理画面へ接続を行いましたが、SAML認証が完了すると接続が確認できました。
ではアクセスログを見ていきます。
ログは「モニタリング」内の「アクティビティ検索」より確認します。
「アクティビティ検索」はUmbrellaのデザインが踏襲されています。
Browser-based ZTNAは「ZTNA CLIENTLESS」として表示されます。
ログにはポスチャで取得した情報も記録されます。
設定のところでは触れませんでしたが、Browser-based ZTNAのポスチャでチェックできる項目は
・Operating System
・Browser
の2つとなります。
Operating SystemではWindowsは許可、iOSは拒否のような設定や、iOS/Androidではバージョンによる制御も可能です。
BrowserではChromeは許可、Microsoft Edgeは拒否のような設定が可能です。
最後にアクセス先アプリケーションとなるEWCのコンソールにてアクセス元のIPアドレスを確認したところ100.64.0.0/10のCG-NATが割り当てられていることが確認できます。
②Client-based ZTNA
Client-based ZTNAは名前の通りクライアントデバイスにエージェントのインストールが必要となります。
インストールするのはCisco Security Client(旧AnyConnect)となります。
Secure Clientはモジュール式となっており、インストール時にモジュールを指定してインストールを行います。
Client-based ZTNAで利用するのは「Zero Trust Access」となります。
また「Core & AnyConnect VPN」が基本のモジュールとなりますが、こちらはVPNaaSで利用しますのでインストールしておきます。
「Zero Trust Access」のインストールを行うと「Duo Desktop」アプリケーションのインストールも求められますが、ポスチャチェックに必要となりますのでインストールしておきます。
「Zero Trust Access」インストール後は「Enroll」(登録)の作業が必要となります。
「Enroll」を実行するとSAML認証が実行されます。
SAML認証が完了すると「Enroll」が完了となり、「Zero Trust Access」モジュールがアクティブとなります。
「Zero Trust Access」モジュールがアクティブの状態であれば、ユーザは社内にいるときと同じ方法で社外からも社内アプリケーションへのアクセスが可能です。
Browser-based ZTNAの試験時に利用したCatalyst 9115へのSSHアクセスを許可しているので接続してみます。
宛先を一部マスクしてしまっていますが、IPアドレスによるSSHアクセスを行っています。
ステップ2のタスク3のアクセスポリシーの設定で「User Authentication Requirements」の設定で再認証間隔を設定していた場合、アクセスのタイミングで「Zero Trust Access」からSAML認証が求められる場合もあります。
次にアクセスログを確認してみます。
Client-based ZTNAは「ZTNA CLIENT-BASED」として表示されます。
ポスチャ情報も確認してみます。
前述の通りClient-based ZTNAではDuo Desktopによるポスチャチェックを行っています。
チェック項目は以下となります。
・Operating System
・Firewall
・Endpoint security agents
・System password
・Disk excryption
Browser-based ZTNAと同様にアクセス元のIPアドレスは100.64.0.0/10のCG-NATアドレスにNATされています。
※別アプリケーションとしてRDP接続を行った際の確認画面となります。
③VPNaaS
VPNaaSもクライアントデバイスにエージェントのインストールが必要となりますが、Client-based ZTNAの際にインストールしたCisco Security Clientの「Core & AnyConnect VPN」モジュールを利用します。
接続先等の設定はSecure AccessよりダウンロードしたXMLファイルをクライアントデバイスの特定のフォルダへ配置することで完了します。
ステップ3のタスク3で設定したVPN Profile画面よりXMLファイルをダウンロードします。
Windowsの場合、ダウンロードしたsecure_client.xmlを「%Program Data%\Cisco\Cisco Secure Client\VPN\Profile」に保存します。
ステップ3のタスク3のVPN Profileの設定でProtocolをTLS/DTLSとIKEv2を選択した場合にはユーザ側で選択が可能ですが、選択後に「接続」をクリックします。
初めにポスチャチェックが行われます。
本検証では認証方式をSAMLに設定したので、SAML認証が実施されます。
認証が完了すると接続が完了します。
Client-based ZTNA同様にVPNaaSでもVPN接続してしまえば、ユーザは社内にいるときと同じ方法で社外からも社内アプリケーションへのアクセスが可能です。
接続画面のキャプチャが無いのですがRDPでの接続試験を実行したので、アクセスログを確認してみます。
VPNaaSでの通信は「FW」として表示されます。
VPNaaSの場合、アクティビティ検索ではポスチャチェックの内容は確認できず、「モニタリング」内の「リモートアクセスログ」にて接続状態やポスチャチェックした際の結果が確認できるのですが、ポスチャの情報は現時点ではOSタイプ/バージョンとSecure Clientのバージョンのみしか確認できませんでした。
ここはアップデートにて全項目が確認できることを期待したいです。
VPNaaSの場合のポスチャチェックは以下の項目が設定可能です。
Client-based ZTNAよりもチェック内容が多いですが、Client-based ZTNAではDuo Desktopによるポスチャチェックを行っているのに対して、VPNaaSではSecure ClientのHostScanの機能で行っているためチェック内容が異なります。
・Operating System
・Endpoint security agent
・Windows registry entries
・Firewall
・Disk encryption
・File(特定のパスに特定のファイルが含まれていないか)
・Processes(特定のプロセスが稼働しているか)
・Certificate
最後にアクセス元のIPアドレスを確認しますと、ステップ3のタスク3で設定した「Manage IP Pools」のIPアドレスレンジより払い出されていることが確認できます。
④ZTNAとVPNaaSでの優先度確認
ステップ2のタスク1でプライベートリソースを作成した際に記載しましたが、1つのアプリケーションに対して複数の接続方式の指定が可能です。
個人的に興味があったのでClient-based ZTNAとVPNaaSを設定した場合どちらの接続方式が優先されるのかを試してみました。
社内に設置したルータへのTelnetアクセスで接続方式にClient-based ZTNAとVPNaaSを設定しました。
VPN接続済みで「Zero Trust Access」モジュールがアクティブ状態です。
結果としては「ZTNA CLIENT-BASED」(Client-based ZTNA)で接続されていることが確認できました。
VPNaaSよりClient-based ZTNAが優先されることが確認できました。
VPNaaSを利用するシチュエーションは前述の通り、社内のデバイスから社外のリモートアクセスユーザ宛の通信を行うアプリケーションが存在する場合などです。
このようなアプリケーションが存在するユーザ環境では、ユーザ側でアプリケーションごとにClient-based ZTNAでの接続なのかVPNaaSでの接続なのかを意識させないためには、基本的に社外に出た際にはVPNaaSが常に接続状態であることが望ましいと考えます。
接続方式の選択はSecure Access側で判断するため、ユーザは社外にいても社内にいるのと同じ状況で業務を行うことが可能となります。
基本はClient-based ZTNAを利用し、Client-based ZTNAでは対応できないアプリケーションをVPNaaSを利用するというのが検証時の動作からも確認できました。
さて気付けば大変長くなってしまいましたが、Secure Accessのリモートアクセスに関するブログも以上で終了となります。
今回は新機能となるリモートアクセス部分に焦点を当ててのブログでしたが、機会があればSWG/CASB等のSIAの機能についても紹介できればと思っています。
最後までお読みいただきましてありがとうございました。
他のおすすめ記事はこちら
著者紹介
SB C&S株式会社
技術統括部 第2技術部 1課
藤ノ木 俊
