SB C&Sの最新技術情報 発信サイト

C&S ENGINEER VOICE

SB C&S

【第3回】Cisco Secure Access リモートアクセス機能のご紹介 - 動作編

ネットワーク
2024.01.29

本ブログはSecure Accessのリモートアクセス機能紹介ブログの第3回となります。
第1回の概要編をご覧いただいていない場合は、概要編からお読みいただくのをお勧めします。

【第1回】Cisco Secure Access リモートアクセス機能のご紹介 - 概要編

第2回では設定方法について記載しておりますので、こちらもご確認ください

【第2回】Cisco Secure Access リモートアクセス機能のご紹介 - 設定編

 目次 
【第1回 概要編】
1.Cisco SASE 3製品の特長
 ・Umbrella
 ・Cisco+ Secure Connect
 ・Cisco Secure Access

2.Secure Accessでのリモートアクセスについて
 ①Browser-based ZTNA
 ②Client-based ZTNA
 ③VPNaaS

【第2回 設定編】
3.設定方法
 ステップ1:インフラ設定
  タスク1:ネットワークトンネル追加
  タスク2:ユーザ/グループ追加
  タスク3:SAML設定

 ステップ2:リソース/アクセス設定
  タスク1:プライベートリソース設定
  タスク2:デフォルトルールとグローバル設定
  タスク3:アクセスポリシー

 ステップ3:エンドユーザ接続設定
  タスク1:DNS設定
  タスク2:ゼロトラスト設定
  タスク3:VPN設定
  タスク4:インターネットセキュリティ設定

【第3回 動作編】 ←本記事
4.動作確認
 ①Browser-based ZTNA
 ②Client-based ZTNA
 ③VPNaaS
 ④ZTNAとVPNaaSでの優先度確認

今回は第3回 動作編となります。

4.動作確認

今回は第2回で設定した内容を元にリモートアクセスを行ってみます。

①Browser-based ZTNA

Browser-based ZTNAではクライアントデバイスへエージェントのインストールが不要であることが特徴です。

ではユーザはどうやってアプリケーションにアクセスするのかというと、Private Resourcesに「External URL」としてアクセス用のURLが発行されます。
このURLをユーザに通知することでユーザはブラウザから社内アプリケーションへアクセスすることが可能となります。

3-42.BB-ZTNA.png

ブラウザにコピーしたURLを貼り付けてアクセスしてみます。

3-43.BB-ZTNA.png

今回の検証ではMicrosoft Entra IDでのSAML認証を設定したため、SAML認証が実行されます。

3-44.BB-ZTNA.png

検証では社内に設置したCatalyst 9115のAPのEWCの管理画面へ接続を行いましたが、SAML認証が完了すると接続が確認できました。

3-45.BB-ZTNA.png

ではアクセスログを見ていきます。

ログは「モニタリング」内の「アクティビティ検索」より確認します。
「アクティビティ検索」はUmbrellaのデザインが踏襲されています。

Browser-based ZTNAは「ZTNA CLIENTLESS」として表示されます。

3-46.BB-ZTNA.png

ログにはポスチャで取得した情報も記録されます。

3-47.BB-ZTNA.png

設定のところでは触れませんでしたが、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が割り当てられていることが確認できます。

3-48.BB-ZTNA.png

②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」アプリケーションのインストールも求められますが、ポスチャチェックに必要となりますのでインストールしておきます。

3-49.CB-ZTNA.png

「Zero Trust Access」インストール後は「Enroll」(登録)の作業が必要となります。
「Enroll」を実行するとSAML認証が実行されます。

3-50.CB-ZTNA.png

3-51.CB-ZTNA.png

3-52.CB-ZTNA.png

SAML認証が完了すると「Enroll」が完了となり、「Zero Trust Access」モジュールがアクティブとなります。

3-53.CB-ZTNA.png

「Zero Trust Access」モジュールがアクティブの状態であれば、ユーザは社内にいるときと同じ方法で社外からも社内アプリケーションへのアクセスが可能です。

Browser-based ZTNAの試験時に利用したCatalyst 9115へのSSHアクセスを許可しているので接続してみます。
宛先を一部マスクしてしまっていますが、IPアドレスによるSSHアクセスを行っています。

ステップ2のタスク3のアクセスポリシーの設定で「User Authentication Requirements」の設定で再認証間隔を設定していた場合、アクセスのタイミングで「Zero Trust Access」からSAML認証が求められる場合もあります。

3-54.CB-ZTNA.png

次にアクセスログを確認してみます。

Client-based ZTNAは「ZTNA CLIENT-BASED」として表示されます。

3-55.CB-ZTNA.png

ポスチャ情報も確認してみます。

3-57.CB-ZTNA.png

前述の通りClient-based ZTNAではDuo Desktopによるポスチャチェックを行っています。
チェック項目は以下となります。

・Operating System
・Firewall
・Endpoint security agents
・System password
・Disk excryption

3-58.CB-ZTNA.png

Browser-based ZTNAと同様にアクセス元のIPアドレスは100.64.0.0/10のCG-NATアドレスにNATされています。
※別アプリケーションとしてRDP接続を行った際の確認画面となります。

3-59.CB-ZTNA.png

③VPNaaS

VPNaaSもクライアントデバイスにエージェントのインストールが必要となりますが、Client-based ZTNAの際にインストールしたCisco Security Clientの「Core & AnyConnect VPN」モジュールを利用します。

接続先等の設定はSecure AccessよりダウンロードしたXMLファイルをクライアントデバイスの特定のフォルダへ配置することで完了します。

ステップ3のタスク3で設定したVPN Profile画面よりXMLファイルをダウンロードします。

3-60.CB-ZTNA.png

Windowsの場合、ダウンロードしたsecure_client.xmlを「%Program Data%\Cisco\Cisco Secure Client\VPN\Profile」に保存します。

3-61.CB-ZTNA.png

ステップ3のタスク3のVPN Profileの設定でProtocolをTLS/DTLSとIKEv2を選択した場合にはユーザ側で選択が可能ですが、選択後に「接続」をクリックします。

3-62.CB-ZTNA.png

初めにポスチャチェックが行われます。

3-63.CB-ZTNA.png

本検証では認証方式をSAMLに設定したので、SAML認証が実施されます。

3-64.CB-ZTNA.png

認証が完了すると接続が完了します。

3-65.CB-ZTNA.png

Client-based ZTNA同様にVPNaaSでもVPN接続してしまえば、ユーザは社内にいるときと同じ方法で社外からも社内アプリケーションへのアクセスが可能です。

接続画面のキャプチャが無いのですがRDPでの接続試験を実行したので、アクセスログを確認してみます。

VPNaaSでの通信は「FW」として表示されます。

3-66.CB-ZTNA.png

VPNaaSの場合、アクティビティ検索ではポスチャチェックの内容は確認できず、「モニタリング」内の「リモートアクセスログ」にて接続状態やポスチャチェックした際の結果が確認できるのですが、ポスチャの情報は現時点ではOSタイプ/バージョンとSecure Clientのバージョンのみしか確認できませんでした。
ここはアップデートにて全項目が確認できることを期待したいです。

3-67.CB-ZTNA.png

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アドレスレンジより払い出されていることが確認できます。

3-68.png

④ZTNAとVPNaaSでの優先度確認

ステップ2のタスク1でプライベートリソースを作成した際に記載しましたが、1つのアプリケーションに対して複数の接続方式の指定が可能です。

個人的に興味があったのでClient-based ZTNAとVPNaaSを設定した場合どちらの接続方式が優先されるのかを試してみました。

社内に設置したルータへのTelnetアクセスで接続方式にClient-based ZTNAとVPNaaSを設定しました。

3-69.png

VPN接続済みで「Zero Trust Access」モジュールがアクティブ状態です。

3-70.png

結果としては「ZTNA CLIENT-BASED」(Client-based ZTNA)で接続されていることが確認できました。
VPNaaSよりClient-based ZTNAが優先されることが確認できました。

3-71.png

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課
藤ノ木 俊