Cisco の SASE｜Secure Access の構成と導入のポイント

はじめに

Cisco で SASE / SSE を検討する際、従来は Umbrella（DNS セキュリティ）や Secure Internet Gateway（SIG）など複数の製品が関わり、構成が分かりにくい面がありました。現在は、これらの機能が Cisco Secure Access という SSE サービスに統合され、Duo・ISE・Catalyst SD-WAN といった Cisco の資産と組み合わせて SASE を構成する形になっています。

つまずきやすいのは、Secure Access が Umbrella などから何を引き継いだのか、そして Cisco の既存資産とどう組み合わせるのか、という点です。本記事では、Cisco の SASE の全体像を整理したうえで、主要コンポーネントと設計ポイント、導入の流れ、よくあるトラブルまでを扱います。

なお、SASE / SSE そのものの定義や構成要素（SWG・CASB・ZTNA・FWaaS の役割や、SASE と SSE の違い）は、関連記事『SASE とは｜SSE や ZTNA との違いと構成要素のポイント』で扱っています。本記事は、その考え方を Cisco の構成に当てはめる位置づけです。

Cisco の SASE（Secure Access）の全体像

Cisco の SASE は、セキュリティ（SSE）を担う Cisco Secure Access と、ネットワークを担う Catalyst SD-WAN を中心に、Duo・ISE・ThousandEyes などを組み合わせて構成されます。まずはその関係を整理します。

Secure Access とは（Umbrella からの位置づけ）

Cisco Secure Access は、ゼロトラストを基盤としたクラウド提供型の SSE サービスです。

参考: Cisco — Cisco Secure Access Data Sheet
“Cisco Secure Access is a cloud-delivered SSE solution, grounded in zero trust”
（Cisco Secure Access は、ゼロトラストを基盤とした、クラウド提供型の SSE ソリューションである）
https://www.cisco.com/c/en/us/products/collateral/security/secure-access/secure-access-ds.html

Secure Access は、SSE の中核機能（ZTNA・SWG・CASB・FWaaS）に加え、VPNaaS（VPN-as-a-Service）・DLP・DNS セキュリティ・RBI・DEM・生成 AI 利用のガードレール・Talos の脅威インテリジェンスなどを、1 つのライセンスと管理画面に統合しています。

Umbrella からの位置づけも押さえておくと理解しやすくなります。Secure Access は、従来の Umbrella（DNS セキュリティ）や SIG の機能を引き継ぎ、SSE の各機能を 1 つのサービスに統合・拡張したものです。

Cisco エコシステムとの関係（Duo / ISE / Catalyst SD-WAN / ThousandEyes）

Cisco の SASE の特徴は、Cisco の既存資産との統合を前提にできる点です。それぞれの役割は次のとおりです。

Duo

多要素認証（MFA）とアイデンティティの確認を担います。

ISE

端末のポスチャ（状態）評価やネットワークアクセス制御を担います。

Catalyst SD-WAN（旧 Viptela）

拠点を IPsec トンネルで Secure Access へ接続し、ネットワーク側の最適経路を提供します。SD-WAN Manager の SSE ポリシーグループで設定します。

ThousandEyes

利用者の体験やネットワークの健全性を可視化する DEM を担います。

このほか、SAML 対応の各種 IdP（AD・Azure AD・Okta・Ping など）や、Splunk・XDR などとも連携します。Duo・ISE・Catalyst SD-WAN・ThousandEyes といった Cisco 資産を持つ組織では、アイデンティティ・ポスチャ・ネットワーク・可視化を一貫して組み合わせられる点が、Cisco の SASE を選ぶ際の判断材料になります。

Secure Access の主要コンポーネント

Secure Access は、SSE の中核機能を 1 つのサービスに統合しています。ここでは、Web・クラウド・通信全般を守る SWG・CASB・FWaaS と、初段の防御を担う DNS レイヤセキュリティを整理します。

SWG / CASB / FWaaS

それぞれの役割は次のとおりです。

SWG（Secure Web Gateway）

Web トラフィックをクラウドで検査し、URL フィルタリング、マルウェア検査、SSL インスペクションなどを行います。

CASB（Cloud Access Security Broker）

SaaS の利用を可視化・制御し、データ保護を行います。インラインと API ベースの両方に対応します。

FWaaS（Cloud-Delivered Firewall）

Web 以外を含むトラフィックを、ポートやプロトコルによらず制御します。

参考: Cisco — Cisco Secure Access At a Glance
“Extensive security capabilities converged in one solution (ZTNA, SWG, CASB, DLP, FWaaS, DNS security, RBI, DEM and more)”
（ZTNA・SWG・CASB・DLP・FWaaS・DNS セキュリティ・RBI・DEM などの広範なセキュリティ機能を、1 つのソリューションに統合する）
https://www.cisco.com/c/en/us/products/collateral/security/secure-access/secure-access-cloud-security-sse-aag.html

これらは 1 つのライセンスと管理画面で扱い、Talos の脅威インテリジェンスが各機能の検知を支えます。設計のポイントは、トラフィックをどの機能で検査するかの振り分け（DNS で初段確認し、Web は SWG、それ以外は FWaaS へ）と、SSL インスペクションの対象範囲を決めることです。

DNS レイヤセキュリティ（Umbrella の系譜）

DNS レイヤセキュリティは、ドメイン名の解決の段階で悪性ドメインへの接続をブロックする、軽量な初段の防御です。これは Umbrella の系譜にあたる機能で、通信を確立する前にリスクを遮断できる点が特徴です。

ローミング（社外利用）の端末では、Cisco Secure Client の Roaming Security モジュール（Umbrella 由来）により、DNS と Web の保護を継続できます。DNS セキュリティを初段に置き、安全と確認されたあとに SWG や FWaaS で検査するという多層の考え方が、Secure Access の基本的な流れです。
（参考: https://www.cisco.com/c/en/us/solutions/collateral/enterprise/design-zone-security/sase-sse-ag.html ）

ZTNA とアクセス制御

社内アプリケーションへのアクセスは、ZTNA（クライアントベース／ブラウザベース）と VPNaaS で実現します。アクセスの可否は、Duo や ISE と連携したアイデンティティ・ポスチャの評価に基づいて、セッション単位で判断されます。

Hybrid ZTNA と VPNaaS

Secure Access は、社内アプリへのアクセス方式として次の 3 つを提供します。

クライアントベース ZTNA

Cisco Secure Client（旧 AnyConnect）の Zero Trust Access モジュールを用います。アプリ単位で、全ポート・プロトコルに対応し、QUIC / MASQUE によるマイクロトンネルで接続します。

クライアントレス（ブラウザベース）ZTNA

ブラウザのみで利用でき、クライアントのインストールが不要です。Web アプリケーションに限定されますが、未管理端末や業務委託先など、クライアントを導入しにくい場面に向きます。

VPNaaS（VPN-as-a-Service）

DTLS トンネルで、インターネットと社内の通信を運びます。サーバ起点やクライアント間など、ZTNA で扱いにくいアプリケーションを補完します。

社内リソースへの接続経路としては、AWS・Azure・ESXi に配置する軽量な仮想アプライアンス（Resource Connector）や、IPsec のネットワークトンネルを用います。

アイデンティティ・ポスチャ連携（Duo / ISE）

ZTNA のアクセス可否は、アイデンティティとポスチャの評価に基づきます。認証は SAML 対応の IdP（AD・Azure AD・Okta・Ping など）で行い、Duo を組み合わせると多要素認証（MFA）を適用できます。ISE と連携すると、端末のポスチャ（OS やパッチの状態など）を条件に加えられます。

導入・設定の流れ

Secure Access はクラウドサービスのため、設定は管理ダッシュボードでの操作が中心です。大まかには「トラフィックの取り込み方式を決める → ポリシーを設計する → 段階的にロールアウトする」という流れになります。

接続方式とロールアウト（VPN からの移行）

Secure Access には、通信を取り込む（保護対象として向ける）複数の方式があります。

参考: Cisco — Troubleshooting scenarios for Cisco Secure Internet Access（Cisco Community）
“flexible connection methods including IPsec tunnels, proxy chains, PAC files”
（IPsec トンネル、プロキシチェーン、PAC ファイルなどの柔軟な接続方式）
https://community.cisco.com/t5/security-videos/troubleshooting-scenarios-for-cisco-secure-internet-access/ba-p/5368312

代表的な方式は次のとおりです。

IPsec トンネル（ネットワークトンネルグループ、IKEv2）

拠点のルータやファイアウォール、SD-WAN から接続します。Catalyst SD-WAN では、SD-WAN Manager の SSE ポリシーグループでトンネルを構成します。

Cisco Secure Client のモジュール

Web Roaming（ポート 80 / 443）、ZTA（全ポート・プロトコル、QUIC）、VPN を、端末の利用形態に合わせて使い分けます。

プロキシチェーン / PAC ファイル

既存のプロキシ構成から段階的に向ける場合に用います。

社内アプリへの接続

Resource Connector（AWS・Azure・ESXi の仮想アプライアンス）や IPsec トンネルを用います。

VPN からの移行は、段階的に進めるのが現実的です。まず DNS セキュリティから始め、次に SWG / FWaaS でインターネット通信を保護し、その後 ZTNA を対象アプリから順に導入して VPN を縮小する、という順序が無理がありません。 ZTNA で扱いにくいアプリは VPNaaS で残します。Umbrella（DNS / SIG）からは自動アップグレードツールで移行でき、ポリシーは適用前にテストする機能（Proactive policy testing）も利用できます。

よくあるトラブルと対処

Secure Access のトラブルは、設定値そのものより、トラフィックの取り込みや上流への到達性、ポリシーの同期に原因があることが少なくありません。まず「どの方式でトラフィックを取り込んでいるか」を把握すると、切り分けが進めやすくなります。

接続・名前解決・ポリシーの確認ポイント

代表的な確認の観点は次のとおりです。

• 取り込み方式の確認: どのモジュール（Web Roaming / ZTA / VPN）やトンネルが有効かを確認します。意図した方式で取り込めていないと、保護が適用されません。
• 接続（上流への到達性）: Roaming のモジュールが「Cloud Service Unavailable」や「Unprotected」になる場合、多くは境界のファイアウォールが上流への通信をブロックしています。

参考: Cisco — Troubleshoot Secure Access Roaming Module
“most probably perimeter firewall device is blocking egress DNS traffic to OpenDNS servers”
（多くの場合、境界のファイアウォールが OpenDNS サーバ宛ての DNS 通信をブロックしている）
https://www.cisco.com/c/en/us/support/docs/security/secure-access/222351-troubleshoot-secure-access-roaming-modul.html

この場合、上流（Ingress IP）への通信が許可されているかを確認します。なお、上流へ到達できないとフェイルオープンとなり、Web 通信が保護されないまま直接インターネットへ抜けることがある点に注意します。切り分けの際は、別のネットワーク（境界ファイアウォールのない回線）で再現するかを確認すると、原因が経路側かを判断しやすくなります。

名前解決（DNS）

FQDN で定義した社内アプリは、DNS 解決が前提になります。社内でのみ解決できるアプリでは、内部 DNS サーバの指定が必要です。

ポリシー（同期・不一致）

ポータルでの変更は端末へ定期的に同期されるため、即時には反映されない場合があります。反映待ちかを確認し、評価内容は Policy Debug で確認します。

確認には、ローカルのクライアントログ（DART バンドル）、HAR ファイル、Experience Insights（Cisco Secure Client に組み込まれた ThousandEyes）が役立ち、エンドポイント・ISP・アプリのどこに原因があるかを切り分けられます。上流への到達性をパケットレベルで確認したい場合は、関連記事「Wireshark の表示フィルタの使い方」も参考になります（URL は実際のパーマリンクに差し替え）。切り分けは「取り込み方式 → 上流への到達性 → 名前解決 → ポリシーの同期」の順に進めると、原因を絞り込みやすくなります。

まとめ

• Cisco の SASE は、SSE を担う Cisco Secure Access と、ネットワークを担う Catalyst SD-WAN を中心に構成します。
• Secure Access は、ゼロトラスト基盤のクラウド型 SSE で、SWG・CASB・FWaaS・DNS セキュリティ・ZTNA・VPNaaS などを 1 つに統合します。
• DNS レイヤセキュリティは Umbrella の系譜で、軽量な初段の防御を担います。
• 社内アプリへのアクセスは、クライアント／ブラウザベースの ZTNA と VPNaaS（Hybrid ZTNA）で使い分けます。
• アクセス可否は Duo（MFA）や ISE（ポスチャ）と連携し、セッション単位で検証します。
• 導入は DNS → SWG / FWaaS → ZTNA の順に段階移行し、ZTNA 非対応アプリは VPNaaS で補完します。
• 効かないときは「取り込み方式 → 上流への到達性 → 名前解決 → ポリシー同期」を確認します。

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