前回の更新から1年ほど間が空いてしまいましたが、Secure Accessが順調にアップデートされていて、多くの機能が追加されています。
今回はアップデートの中から3つの機能をピックアップしてご紹介させていただきます。

　目次　

1.はじめに
2.AndroidデバイスのZero Trust Access
3.Browser-based ZTNAでのSSH/RDPサポート
4.インターネット上の宛先へのZero Trust Access

1.はじめに

機能アップデートの前にSecure Accessのアップデートが掲載されるコミュニティサイトがオープンされており、最新のアップデート情報が確認できます。

Secure Access Announcements

今回はこの中から3つの機能をご紹介します。

2.AndroidデバイスのZero Trust Access

・Announcements
Zero Trust Access client support for generic Android devices

・Documents
Set up the Zero Trust Access App for Android Devices

Androidデバイス向けのZTNAはSamsungデバイスのKnoxを利用した限定的な提供でしたが、その他のAndroidデバイス向けに「Cisco Zero Trust Access」アプリがリリースされ、Androidバージョン「14」以上のデバイスで利用可能となりました。

Cisco Zero Trust Access(Google Playストア)

実際にインストールしてZTNAで接続してみました。
Android14のGoogle Pixelデバイスを利用して検証しています。

「図2-1」の通りインストール後の初期セットアップではウィザードに従って進めていきます。
まずは通知関連の許可が求められるので、許可をします。

図2-1：初期設定

次に「図2-2」の通りEnrollを行いますが、この辺りはPCのSecure ClientのZTAモジュールでのEnrollと同様となり、SAMLによる認証が行われます。
今回の検証環境ではMicrosoft EntraIDを利用しています。

図2-2：Enroll

SAML認証が完了すると、VPNの接続リクエストが行われるので許可します。
ローカルVPN(自身のデバイス内へのVPN接続)が行われるようです。
Enrollが完了すると3つ目の画像の通りステータスバーに鍵アイコンが表示されます。
また「You're enrolled」を選択するとより詳細が確認できます。

図2-3：セットアップの完了

では実際にプライベートアプリケーションへZTNAで接続してみます。
「図2-4」では、1枚目はWEBアプリケーションとしてCisco EWCへのアクセス、2枚目はAndroidのRemote Desktopアプリケーションを利用して社内のPCへRDP接続しています。
ZTNAで接続を行うと3枚目の画像の通りZero Trustの通知が発行され、ステータスバーにもZero Trustアイコンが表示されます。

図2-4：ZTNA接続

Secure Accessのダッシュボード側で「Monitor」→「Activity Search」からRDPのログ(アクティビティ検索)を確認してみます。
ZTNAの要求でOSが「generic-android」として記録されています。

図2-5：RDPアクセスログ

「Secure」→「Endpoint Posture Profiles」の「Zero Trust Connection」のPosture Profileを確認すると、ポスチャチェックとしては「図2-6」の通り現状(2025年2月)はAndroidバージョンのチェックのみで、「図2-7」のSystem Password等はWindows/Mac OS Xのみの対応でした。

図2-6：ポスチャチェック(Androidバージョン)

図2-7：ポスチャチェック(その他)

アクティビティ検索の詳細で確認できるポスチャチェック状況は「図2-8」の通りでした。

図2-8：ポスチャチェック内容

以上がAndroidデバイスでのZero Trust Accessとなります。

3.Browser-based ZTNAでのSSH/RDPサポート

・Announcements
Browser-Based SSH and RDP support

・Documents
Allow SSH and RDP Access to Private Resources

Browser-based ZTNAではWEBプロトコル(ポート80/443)での利用に限られていましたが、新たにSSHとRDPにも対応しました。

エージェントを必要としないBrowser-based ZTNAでは、協力会社の社員などデバイスにエージェントのインストールを強制できない環境においてブラウザを利用したZTNAを提供できる機能ですが、新たにSSHとRDPに対応したことでより幅広いニーズに対応できるようになるかと思います。

ダッシュボードの「Resources」→「Private Resources」で「Add a Private Resource」で設定します。
「図3-1」の通りTCP ProtocolにTCP-(HTTP/HTTPS) onlyのほかにTCP-RDP/TCP-SSHが追加されています。

図3-1：Private Resources Protocol

今回の記事にて詳細は触れませんが、Browser-based connectionではアップデートにより「図3-2」の通りアクセスURLにカスタムドメインを指定することが可能になっています。

図3-2：Browser-based connection

作成したPrivate ResourcesをAccess Policyに割り当てる必要がありますが、この部分の手順は以前より変更はありませんので割愛します。
過去の投稿でも設定方法を取り上げていますので、ご参照ください。

では実際にアクセスを実行してみます。
「Resources」→「Private Resources」でアクセス先のURLを「External URL」でコピーします。

図3-3：External URL

コピーしたURLをブラウザに貼り付けてアクセスすると、SAMLによるユーザー認証が実行されます。

図3-4：SAML認証

RDPプロトコルの場合、SAML認証が完了するとRDPのクレデンシャル情報の入力が求められます。

図3-5：RDPクレデンシャル

ログインが完了するとブラウザ上でのRDPが実行可能となります。

図3-6：ブラウザ上のRDP

SSHでも試してみましたが、SSHの場合「upload private key」を利用して鍵認証も実行可能です。

図3-7：SSHクレデンシャル

SSHの場合もRDP同様にブラウザ上でターミナルを操作します。

図3-8：ブラウザ上のSSH

以上がBrowser-based ZTNAでのSSH/RDPとなります。

4.インターネット上の宛先へのZero Trust Access

・Announcements
Zero Trust Access for Defined Internet Destinations

・Documents
Zero Trust Access to Internet Destinations

タイトルは英語の直訳なのでわかりづらくなっていますが、リモートデバイスのエージェントであるSecure ClientのZero Trust Accessモジュールと、拠点に設置したResource Connectorを利用したインターネットアクセスを提供する機能となります。

今まではインターネットアクセスはSecure ClientのUmbrellaモジュールか、VPNモジュールを利用したVPNaaS経由でのアクセスのどちらかでした。
この機能ではZero Trust Accessモジュールを利用して、Resource Connector経由でのインターネットアクセスが可能となります。

この機能による最大の利点は、インターネットアクセス時に送信元IPがResource Connectorを設置した拠点のグローバルIPアドレスとなることとなります。
(機能の仕組み上、送信元IPアドレスを固定化するには拠点側で利用しているグローバルIPアドレスが固定IPプランである必要があります)

Secure Accessでは送信元IPを固定するReserved-IPの機能が、2025年2月現在まだLimited Availabilityの状況ですが、こちらの機能によって送信元IPアドレスの固定化が可能となります。
またSPA(Secure Private Access)を契約いただいているお客様であれば無償で機能が提供されます。

両者では送信元IPアドレスの固定化の提供方法が異なり、Reserved-IP機能ではSecure Accessのクラウド側でNAT変換されるIPアドレスを固定化する機能ですが、こちらの機能はお客様の拠点のグローバルIPアドレスをそのまま利用する方式となります。

図4-1：Zero Trust Access to Internet Destinations

ここからは実際の設定方法に移りますが、まずは機能が有効化されていない状態で送信元IPアドレスを確認しています。

自身の利用するIPアドレスが確認できる「https://checkip.amazonaws.com」にアクセスしてみます。

画像では一部をマスクしていますが、「151.186.176.0/20」の範囲内よりIPアドレスが割り当てられていました。
こちらはSecure Accessが確保しているIPアドレスレンジとなります。

参考
Secure Access NAT as a Service

図4-2：事前IPアドレス確認

アクセスログを確認すると要求が「WEB」となっておりSecure ClientのUmbrellaモジュールを利用して上記のIPアドレス確認サイトにアクセスしていることがわかります。
またUmbrellaモジュールでのアクセスのためポスチャチェックには対応していません。

図4-3：事前アクセスログ

では実際に機能を設定していきます。

本機能は全ての宛先に対して適用するものではなく、特定の宛先に対して適用します。
そのため送信元IPアドレスを制限するようなサイト向けの通信に対して、本機能を適用します。

今回は先ほど利用したIPアドレス確認サイト向けの通信に対して適用する設定を行います。

設定における1つ目のポイントとして、宛先を「Private Resources」として登録します。
「Internet and SaaS Resources」ではない点に注意が必要です。

ダッシュボードの「Resources」→「Private Resources」で「Add a Private Resource」を実行します。
「Internally reachable address」に先ほどのIPアドレス確認サイトのドメインを登録し、プロトコルとポートをTCP/443に設定します。

図4-4：Internally reachable address設定

Endpoint Connection Methodsで「Zero-trust connections」を選択し、「Client-based connection」を有効化します。
設定は任意ですが、宛先への接続がWEBプロトコルのため「Browser-based connection」で利用することも可能です。

「Browser-based connection」を有効にした場合は、Browser-based ZTNAでのアクセス時にも送信元のIPアドレスを拠点のIPアドレスとすることが可能です。

図4-5：Endpoint Connection Methods設定

2つ目のポイントとして、「Resource Connector Groups」でConnectorを選択します。
このConnectorを経由したインターネットアクセスが実行され、Connectorが設置されている拠点のグローバルIPアドレスが送信元のIPアドレスとなります。

また3つ目のポイントでSecure Accessではプライベートアプリケーションへのアクセス時に復号化してのIPS機能を提供していますが、本機能ではIPSをサポートしていません。
そのため「Decryption」(復号化)設定は無効化しておく必要があります。

図4-6：Resource Connector Groups設定

次に「Secure」→「Access Policy」からポリシーの設定を行います。

宛先を「Private Resources」で登録しているので、ポリシーは「Private Access」を選択します。
「Destinations」に先ほど設定した「Private Resources」を選択し、「Action」を「Allow」にします。

図4-7：Access Policy一般設定

また3つ目のポイントとしての説明の通りIPSをサポートしないため、IPS機能を無効のままとしておく必要があります。

図4-8：Access Policy IPS設定

以上で設定自体は完了となるので、事前確認と同様にIPアドレス確認サイトへアクセスしてみます。

こちらもマスクしているため少しわかりづらいですが、Secure Accessが提供するNATアドレスレンジ外のIPアドレスとなっています。
こちらは弊社の検証環境でResource Connectorを設置した拠点で契約している固定IPアドレスとなります。

図4-9：設定後IPアドレス確認

アクセスログを確認してみますと要求が「ZTNA CLIENT-BASED」に変わっており、事前状態と異なりSecure ClientのZero Trust Accessモジュールを利用して通信をしていることが確認できます。

図4-10：設定後アクセスログ

Zero Trust Accessモジュールからのアクセスのため以下の通りポスチャチェックにも対応しています。

図4-11：ポスチャチェック

今回ご紹介する機能は以上となります。
Secure Accessは頻繁な機能追加が行われていますので、Communityサイトでの定期的なアップデート情報の確認をお勧めします。

また気になる機能がありましたら本ブログにて検証結果とともにお知らせしたいと思います。

最後までお読みいただきましてありがとうございます。