Cisco Secure Access の設定｜ChatGPT の可視化

はじめに

Cisco Secure Access を拠点に導入する際、IPsec トンネルと BGP が確立していても、それだけで拠点の通信がすべて SSE を経由するとは限りません。どの通信を Secure Access へ誘導し、どのログで経由と制御を確認するかを、設定前に決めておく必要があります。

本記事では、2026 年 10 月 15 日に Cisco dCloud のラボ環境で実施した検証をもとに、拠点ルーター（Cisco C8000V）の PBR で検証端末の Web 通信を Secure Access へ誘導し、ChatGPT の通信を可視化したうえで、アプリケーション単位でブロックするまでの設定と確認方法を解説します。

結論として、今回の環境では、接続先に「Generative AI → OpenAI ChatGPT」を指定した Block ルールを、復号用の Allow ルールより上に配置することで、Google は表示したまま ChatGPT だけをブロックできました。遮断の成否は、Activity Search に記録された LAB-Block-ChatGPT による Block イベント（AC_RULE_MATCH_BLOCK）で判断します。

SASE / SSE の基本構成や Secure Access の機能の全体像は、概要編の『Cisco の SASE｜Secure Access の構成と導入のポイント』で解説しています。本記事では概要説明を省き、設定と検証結果に絞って説明します。

Cisco Secure Access の検証環境と接続確認

今回のラボでは、IPsec トンネルと eBGP はあらかじめ構成されていました。本記事で扱うのは、その状態確認と、PBR・セキュリティプロファイル・アクセスルールの設定、および動作検証です。

検証環境と実施範囲

拠点のデフォルトルートは OSPF により WAN 側を向いていたため、BGP が確立していても、拠点の通信が自動的に Secure Access へ転送される構成ではありませんでした。このため、検証端末の Web 通信だけを PBR で Secure Access 側のトンネルへ誘導しています。

本文中の IP アドレスは、公開用のサンプル値に置き換えています（検証端末は 10.0.10.71 と表記）

IPsec トンネルと BGP の確立状態を確認する

Secure Access の管理画面では、「コネクト」→「ネットワーク接続」→「ネットワークトンネルグループ」で、Network Tunnel Group（NTG）の状態を確認できます。今回の NTG は、ステータスが「接続中」、ルーティングが「動的」と表示されていました。

NTG の詳細画面では、ルーティングタイプが「ダイナミックルーティング(BGP)」であること、プライマリトンネルハブとセカンダリトンネルハブの双方にアクティブなトンネルが 1 本ずつあることを確認しました。BGP ピアは双方とも Established でした。

ルーター側で確認する場合は、次のコマンドで IPsec セッションと BGP ネイバーの状態を確認できます。Cisco IOS の BGP 設定の基本は『Cisco IOS の BGP 設定手順｜network コマンドと neighbor の基本』で解説しています。

show crypto session
show ip bgp summary

Global Routing で拠点 LAN の経路を確認する

「グローバルルーティング」画面では、Secure Access が保持している経路を確認できます。今回の環境では、拠点 LAN のサブネットが接続タイプ「NTG Dynamic」として登録されていました。拠点ルーターが eBGP で広告した経路を、Secure Access が学習していることを示す表示です。

ただし、BGP が Established で経路が登録されていても、Web 通信が正常に流れることまでは保証されません。今回のラボでも、トンネル確立後に Web 通信のタイムアウトが発生し、Tunnel MTU の変更だけでは改善せず、TCP MSS を 1000 に下げた後に改善しました。MSS 1000 は今回の環境で改善が見られた値であり、一般的な推奨値ではありません。原因の切り分けは別記事のトラブルシューティング編で扱います。MTU と MSS の関係は『MTU/MSS とは｜PPPoE・IPsec で通信が止まる原因と対策』を参照してください。

PBR で検証端末の Web 通信を Secure Access へ誘導する

今回は、拠点の通常のルーティングを変更せずに検証するため、拠点ルーターに Policy Based Routing（PBR）を設定しました。PBR は今回選択した誘導方式であり、Secure Access の導入で必ず使う構成ではありません。

今回 PBR を使用した理由

デフォルトルートを Secure Access 側へ切り替えると、拠点のインターネット通信全体が影響を受けます。PBR を使うと、送信元・宛先・ポートを条件に対象を絞れるため、検証端末の Web 通信だけを Secure Access へ送り、既存の通信を維持したまま動作を確認できます。本番環境で拠点全体の通信を誘導する場合は、ルーティング設計全体に合わせて方式を選択してください。

ACL と Route Map の設定

設定の要点は次の 3 点です。

• ACL LAB-SSE-WEB で、検証端末から送信される TCP 80 / 443 と UDP 443 を PBR の対象にする
• プライベートネットワークとラボ管理ネットワーク宛ては、deny で PBR の対象から外す
• Route Map LAB-SSE-WEB-PBR で ACL に一致した通信を Tunnel1 へ転送し、LAN 側の GigabitEthernet4 に適用する

実機では、検証端末からプライベートネットワーク宛てとラボ管理ネットワーク宛ての通信を除外する方針で ACL を作成しました。次の設定は、この方針を公開用に書き直したサンプルです。ACL 名、Route Map 名、インターフェース名は検証時のままですが、検証端末と除外先のアドレスはサンプル値です。管理ネットワークの例（198.51.100.0/24）は、実機で除外したネットワークとプレフィックス長も異なります。

サンプル値の組み合わせで動作を確認したものではないため、除外する宛先は、自環境の拠点内ネットワークや管理ネットワークに合わせて設計してください。

ip access-list extended LAB-SSE-WEB
 deny   ip host 10.0.10.71 10.0.0.0 0.255.255.255
 deny   ip host 10.0.10.71 172.16.0.0 0.15.255.255
 deny   ip host 10.0.10.71 192.168.0.0 0.0.255.255
 deny   ip host 10.0.10.71 198.51.100.0 0.0.0.255
 permit tcp host 10.0.10.71 any eq www
 permit tcp host 10.0.10.71 any eq 443
 permit udp host 10.0.10.71 any eq 443
!
route-map LAB-SSE-WEB-PBR permit 10
 match ip address LAB-SSE-WEB
 set interface Tunnel1
!
interface GigabitEthernet4
 ip policy route-map LAB-SSE-WEB-PBR

set interface は、Route Map の match 条件に一致したパケットの転送先インターフェースを指定するコマンドです。ip policy route-map は、指定したインターフェースで受信したパケットに PBR を適用します。UDP 443 は HTTP/3（QUIC）で使われるため、TCP だけを対象にすると、ブラウザーが QUIC を使った場合にその通信が PBR の対象外となり、通常経路で WAN へ出る可能性があります。

deny は通信の遮断ではなく「PBR の対象外」

PBR 用 ACL の deny は、インターフェースに適用してパケットを拒否する ACL とは役割が異なります。Route Map の match ip address で参照した ACL の deny は「この Route Map の条件に一致しない」ことを示し、パケット自体は破棄されません。条件に一致しなかったパケットは PBR の対象外となり、通常のルーティングで転送されます。

参考: IP Routing Configuration Guide, Cisco IOS XE 17.x – Policy-Based Routing
“If the packet is not policy routed, the normal forwarding algorithm is used.”
（パケットがポリシールーティングされない場合は、通常の転送アルゴリズムが使用されます。）
https://www.cisco.com/c/en/us/td/docs/routers/ios/config/17-x/ip-routing/b-ip-routing/m_iri-pbr.html

プライベートネットワーク宛てを除外しない場合、拠点内や管理ネットワーク宛ての Web 通信までトンネルへ送られ、到達できなくなるおそれがあります。

拠点内の特定の通信を実際に拒否したい場合は、PBR 用の ACL ではなく、インターフェースに適用するアクセスリストやファイアウォール機能で別途設定します。PBR の ACL は「どの通信をトンネルへ送るか」を選ぶためのものです。

通信が SSE を経由しているか確認する方法

ルーター側では、次のコマンドで ACL のヒット数と PBR の適用状態を確認できます。

show ip access-lists LAB-SSE-WEB
show route-map LAB-SSE-WEB-PBR
show ip policy

ACL の permit 行のカウンターや Route Map の一致数が増えていれば、PBR が動作していることの目安になります。ただし、ルーター側の表示から分かるのは、トンネルへ転送したところまでです。Secure Access を経由したかどうかは、Secure Access 側のログで判断します。

PBR の切り戻し手順

設定変更の前に、戻し方も確認しておきます。検証時は、次のコマンドで LAN 側インターフェースから PBR の適用を解除しました。

configure terminal
interface GigabitEthernet4
 no ip policy route-map LAB-SSE-WEB-PBR
end

このコマンドはインターフェースへの PBR の適用を解除するもので、Route Map と ACL の設定は残ります。今回のラボでは、GigabitEthernet4 から PBR を解除すると、通常のインターネット通信が復旧しました。再び Secure Access へ誘導する場合は、ip policy route-map LAB-SSE-WEB-PBR を再設定します。

Secure Access で ChatGPT の通信を可視化

PBR の設定後、検証端末から Google と ChatGPT にアクセスし、Secure Access の Activity Search（アクティビティ検索）で記録を確認しました。下の画面は HTTPS 復号を設定する前の時点で、Google や ChatGPT への WEB 要求が記録されています。

Activity Search で確認した項目

ChatGPT の通信では、イベントの詳細で次の項目を確認しました。

OpenAI ChatGPT の識別と SSE 経由の判断

送信元に検証用の NTG と検証端末の内部 IP アドレスが記録され、接続先の chatgpt.com がアクセスルールの評価を受けていれば、その通信は PBR で誘導され、Secure Access を経由したと判断できます。ルーター側の転送状態ではなく、Secure Access 側で端末単位の記録が残っていることが判断の根拠です。

また、カテゴリ「Generative AI」とアプリケーション「OpenAI ChatGPT」が記録されていたことから、Secure Access がこの通信を ChatGPT として識別していることも確認できました。この表示名は、後述する Block ルールの接続先を選ぶ際の手がかりになります。

復号を設定する前の段階では、HTTPS 通信の接続先は https://chatgpt.com のようにホスト名単位で表示されていました。復号を有効にした後は、今回の検証では URL のパスも Activity Search に表示されました。ただし、復号の除外対象や通信の種類によって記録される内容は変わるため、すべての HTTPS 通信の詳細を確認できるわけではありません。

HTTPS 復号と ChatGPT ブロックの設定

ChatGPT のブロックは、復号用のセキュリティプロファイル作成、ルート CA 証明書の導入、復号用 Allow ルールの作成、ChatGPT の Block ルールの作成という 4 段階で設定しました。先に、復号とルール評価の関係を整理します。

HTTPS 復号が必要になる理由

HTTPS 通信は暗号化されているため、復号しない場合、Secure Access が制御に使える情報は宛先のドメイン名などに限られます。セキュリティプロファイルの設定画面でも、復号を無効にした場合は「アクセスは、宛先のドメイン名のみに基づいて制御できます」と表示されます。Cisco の公式資料では、ブロック対象を含む HTTPS 通信の処理には、一般に復号が必要と説明されています。

参考: Cisco Secure Access Help – Add an Internet Access Rule
“In general, decryption is required to properly process HTTPS traffic, including traffic that will be blocked.”
（一般に、ブロック対象となるトラフィックを含め、HTTPS トラフィックを適切に処理するには復号が必要です。）
https://securitydocs.cisco.com/docs/csa/olh/120246.dita

また、公式資料では、1 つのルールで復号と検査を同時に行うことはできないと説明されています。このため今回は、復号を有効にする Allow ルールと、ChatGPT を判定する Block ルールを分けて作成しました。2 つのルールの配置の考え方は、手順の後で説明します。

HTTPS 復号と Block ルールの設定手順

手順

復号用のセキュリティプロファイルを作成する

「セキュリティプロファイル」からインターネットアクセス用のプロファイルを追加し、プロファイル名を LAB-Decrypt-Test としました。「復号化」で「復号化を有効にする」を選択し、復号除外リストには「システム提供の復号除外リスト」を指定しています。SSO 認証は無効とし、エンドユーザー通知はシステム提供の通知ページを使用しました。

保存直後のプロファイル一覧では、復号は「有効」ですが、関連付けられたルールは「-」と表示されます。セキュリティプロファイルは設定のまとまりであり、作成しただけでは通信に適用されません。アクセスルールに割り当てて初めて効果を持ちます。

手順

ルート CA 証明書を検証端末にインストールする

「安全性」→「設定」→「証明書」の「インターネット接続先」タブから、Secure Access のルート証明書をダウンロードし、検証用 Windows の信頼ストアにインストールしました。画面に示されているとおり、この証明書は通信の復号と、ブロック通知・警告通知の表示に使用されます。

復号では Secure Access が通信を中継して検査するため、端末がこのルート証明書を信頼していないと、ブラウザーで証明書エラーが発生します。証明書を信頼させる作業は、復号を有効にする前に済ませておきます。

手順

復号用の Allow ルールを作成する

「アクセスポリシー」でインターネットアクセスルール LAB-Decrypt-Allow を追加しました。送信元に検証端末、接続先に「任意」、アクションに「許可」を指定し、セキュリティプロファイルに LAB-Decrypt-Test を割り当て、ロギングを有効にしています。

このルールは、検証端末の通信を許可するだけでなく、HTTPS 通信を復号する役割を担います。

手順

ChatGPT の Block ルールを作成し、上位に配置する

ルール LAB-Block-ChatGPT を追加し、接続先の入力欄に「openai cha」などと入力して、アプリケーションカテゴリ「Generative AI」配下の「OpenAI ChatGPT」にチェックを入れます。下の画面はチェックを入れる前の状態です。

アクションは「ブロック」、送信元は検証端末、セキュリティプロファイルは LAB-Decrypt-Test とし、ロギングを有効にしました。保存後、ルールの順序を LAB-Decrypt-Allow より上へ移動します。

ChatGPT の Block ルールと最終的なルール順序

ブロックに成功した最終的な設定は次のとおりです。

最終的なアクセスルールの順序は次のとおりです。

1. DNS Inbound（既存）
2. LAB-Block-ChatGPT
3. LAB-Decrypt-Allow
4. All Internet access（デフォルトルール）

アクセスルールは上から評価され、最初に一致したルールが適用されるのが基本です。

参考: Cisco Secure Access Help – Edit the Order of the Rules in Your Access Policy
“Traffic is handled by the first rule in the list that matches the traffic.”
（トラフィックは、リスト内でそのトラフィックに一致する最初のルールによって処理されます。）
https://docs.sse.cisco.com/sse-user-guide/docs/edit-rule-order

ただし、暗号化された通信では、評価が 1 回で終わらない場合があります。Cisco の公式資料では、URL を接続先とするルールを例に、次の流れが説明されています。

1. 復号前の情報では URL を判定できないため、上位の URL ルールには一致しない
2. 下位にある、復号を有効にした広いルールに一致し、復号によって URL が判明する
3. URL の情報をもとにルールが上から再評価され、上位の URL ルールが一致する

参考: Cisco Secure Access Help – Ensure Rule Matching for Encrypted Internet Traffic
“The rules are then re-run, top down, with the URL information.”
（その後、URL の情報を使ってルールが上から順に再評価されます。）
https://securitydocs.cisco.com/docs/csa/olh/120280.dita

同じ資料では、下位の広いルールで復号が無効になっている場合、URL ルールは一致せず、下位のルールが適用されるとも説明されています。

今回の配置は、この考え方に沿ったものです。LAB-Decrypt-Allow は接続先が「任意」のため、検証端末の通信はこのルールに一致し、復号されます。LAB-Block-ChatGPT をその上に置くことで、復号後の再評価では Block ルールが先に評価されます。反対に Block ルールを下に置くと、再評価でも接続先「任意」の Allow ルールが先に一致するため、Block ルールは適用されません。

なお、公式資料の例は URL を接続先とするルールであり、アプリケーションを接続先とする場合に同じ流れで評価されるかまでは明記されていません。今回の結果は、この配置でブロックを確認できたという検証環境での事実として扱ってください。

Google と ChatGPT の動作比較と Block ログによる確認

ルール適用後に検証端末からアクセスした結果は次のとおりです。

Activity Search では、ChatGPT への通信に対して次の Block イベントが記録されました。

アクション

ブロック

イベントブロックの理由

AC_RULE_MATCH_BLOCK

ルール名

LAB-Block-ChatGPT

接続先

https://chatgpt.com

ルール名とブロック理由がそろって記録されていることで、ブラウザー側の接続エラーではなく、設定したアクセスルールによる遮断であると確認できます。

この画面の一覧には、別の時点で実施した試験のイベントも含まれています。本記事で結果として扱うのは、右側に詳細を表示している chatgpt.com の Block イベント（ルール名 LAB-Block-ChatGPT、ブロック理由 AC_RULE_MATCH_BLOCK）のみで、一覧にある Google などのイベントは今回の結果に含みません。また、今回の環境では、このイベントの要求種別は「FW」と表示されていました。要求種別でログを絞り込む場合は、WEB だけでなく FW も含めて確認することをおすすめします。

当初ブロックできなかった構成と切り分け

検証中、当初はアプリケーションを指定しても ChatGPT がブロックされませんでした。切り分けで確認した内容は次のとおりです。

最終構成では、接続先を Generative AI → OpenAI ChatGPT に変更し、Block ルールに復号プロファイルを適用したうえで、復号用 Allow ルールより上に配置しています。ただし、これらの条件は 1 つずつ独立して比較したものではありません。そのため、「特定のオブジェクト名の違いだけが原因だった」とも、「すべての Block ルールに復号が必要」とも断定できません。公式資料で確認できるのは、HTTPS の処理には一般に復号が必要であることと、URL 条件の例で示された再評価の考え方までです。

実務では、Activity Search に記録された分類（今回は Generative AI / OpenAI ChatGPT）と一致する接続先を選び、復号の適用状態とルール順序をあわせて確認することをおすすめします。

運用前に確認したいポイント

ラボで動作を確認した構成を本番環境へ展開する前に、次の点を確認しておくことをおすすめします。

PBR の適用範囲と冗長性

今回の PBR は、検証端末 1 台の Web 通信だけを Tunnel1 へ転送する構成です。対象を拠点全体へ広げる場合は、拠点内や管理ネットワークなど、Secure Access を経由させない宛先を ACL に反映します。DNS など ACL の対象外とした通信は通常経路を使うため、名前解決の経路も含めて設計してください。

Cisco のコマンドリファレンスでは、set interface に複数のインターフェースを指定でき、先頭のインターフェースがダウンしている場合は後続のインターフェースが順に試されると説明されています。今回は Tunnel1 の障害時の動作を検証していないため、Secondary トンネルを含めた冗長性は別途確認が必要です。

HTTPS 復号と証明書の管理

• 本番環境では、ルート CA 証明書を端末ごとに手作業で導入するのではなく、グループポリシーによる配布や MDM などの方法を検討します。手作業での導入手順は「Manually Install the Cisco Secure Access Root Certificate」に記載されています。
• Firefox はバージョン 120 以降、OS の証明書ストアに追加された第三者のルート証明書を自動的に信頼する機能を備えており、この機能は既定で有効です（Mozilla の公式資料）。古いバージョンを使っている場合や、企業ポリシーで証明書の設定を管理している場合は、Firefox でも証明書エラーが出ないかを確認します（企業向けの設定）。
• 復号すると URL のパスなど通信の詳細がログに残るため、プライバシーや社内規程、地域の規制を踏まえて復号の対象範囲を決めます。
• Cisco の公式資料では、システム提供の Do Not Decrypt リストは初期状態では空であると説明されています。復号を避けるべき宛先は、自組織で除外先として追加します（Important Information About Do Not Decrypt Lists）。

ルール優先順位とアプリケーション識別

復号用の広い Allow ルールを追加すると、その下にある既存ルールに一致していた通信が、先に Allow ルールに一致するようになる可能性があります。ルールを追加する際は、既存ルールとの位置関係を確認してください。

また、接続先の選択画面には、名称が似たアプリケーションのオブジェクトが複数表示される場合があります。今回のように、選んだ項目とログ上の表示が異なると期待どおりに一致しないことがあるため、事前に Activity Search で対象アプリケーションの表示名を確認してからルールを作成することをおすすめします。アプリケーションの指定方法は「Select Applications with Objects or Groups on Rules」も参照してください。

ポリシー変更時の影響確認

ルールの追加や並べ替えの後は、ブロック対象のサービスと、ブロック対象外の業務サービスの両方にアクセスし、Activity Search で一致したルール名とアクションを確認します。今回のように送信元を検証端末に限定したルールで動作を確認してから、段階的に適用範囲を広げる進め方をおすすめします。

ChatGPT を禁止せずに入力内容を制御する場合

ChatGPT の利用自体を禁止するのではなく、機密情報を含む入力だけを制御する方法もあります。AI Guardrails を使ったプロンプト検査や機密情報の Monitor / Block は、別記事の DLP 編で扱う予定です。

まとめ

Cisco Secure Access で ChatGPT を制御するには、通信を SSE へ誘導し、ログで経由と識別を確かめたうえで、復号とルール順序をそろえることが重要です。今回の検証では、PBR による誘導、OpenAI ChatGPT を指定した Block ルール、その下の復号用 Allow ルールの組み合わせで、Google を表示したまま ChatGPT だけを遮断できました。

• IPsec と BGP の確立だけでは、Web 通信の正常性までは保証されません。
• PBR を使うと、既存の経路を変えずに対象端末の通信だけを誘導できます。
• PBR 用 ACL の deny は遮断ではなく、通常経路での転送を意味します。
• SSE 経由の判断は、Activity Search の送信元と適用ルールで行います。
• セキュリティプロファイルは、ルールに割り当てて初めて適用されます。
• ChatGPT の Block ルールは、復号用の Allow ルールより上に配置します。
• 接続先のアプリケーションは、ログ上の分類と一致する項目を選びます。

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