こんにちは、SCSKの中山です。
Cato SASEを導入・運用していく中で、お客様からよくご質問をいただく機能があります。 それは、BypassやOff-Cloudといった、一見すると「Catoを経由させないの?」と思えるような機能群です。また、同じ「Bypass」という名前が別の設定で出てきたり、機能が似ていて混同しやすかったりすることもあるかと思います。
そこで今回は、これらの「Catoを迂回する」ように見える機能について、それぞれの役割と違い、適切な使い分けを分かりやすく整理してみたいと思います。
今回整理するのは、以下の4つの機能です。
- Bypass(ローカルブレイクアウト)
- Off-Cloud
- Split Tunnel
- Bypass (TLS Inspection)
これらの機能を正しく理解することで、より柔軟で最適なネットワーク設計が可能になります。それでは、一つずつ見ていきましょう。
機能の整理:まずは大きな枠組みで理解しよう
今回ご紹介する機能は、大きく2つのカテゴリに分けることができます。
- 通信「経路」を迂回させる機能:通信トラフィックそのものをCatoのクラウド(Cato PoP)を経由させないようにするものです。
- Bypass(拠点からの通信)
- Off-Cloud(拠点間の通信)
- Split Tunnel(リモートアクセス端末からの通信)
- 特定の「セキュリティ機能」を迂回させる機能:通信経路はCatoを経由させつつ、特定のセキュリティ処理だけをスキップさせるものです。
- Bypass (TLS Inspection)
この分類を頭に入れておくと、各機能の役割がイメージしやすくなります。それでは、まずは通信「経路」を迂回させる機能から解説します。
1. Bypass(拠点):拠点からインターネットへの直接通信
こちらは、拠点(Site)から特定のインターネット通信を、Cato PoPを経由させずに直接アクセスさせるための機能です。一般的に「ローカルブレイクアウト」と呼ばれるものです。
【通常の通信】 通常、Catoを導入した拠点からのインターネット通信は、すべて最寄りのCato PoPを経由し、そこでセキュリティチェックを受けた上でインターネットに出ていきます。
【Bypass機能を使った通信】 Bypass機能を使うと、指定した宛先への通信だけ、Cato PoPを経由せず、拠点のCato Socketから直接インターネットへアクセスさせることができます。
■ なぜこの機能が必要?(ユースケース)
- 特定のSaaSアプリケーションの通信最適化:Microsoft 365やZoomなど、信頼性が高く、大量の通信を発生させるSaaSへのアクセスを直接行わせることで、Cato PoPでの処理遅延を回避し、パフォーマンスを向上させたい場合に必要です。
(契約されている帯域にもよりますが、Catoバックボーン経由で接続した方が早い場合があるので、検証が必要です。) - Catoとの互換性問題の回避:非常に稀ですが、特定のアプリケーションがCatoを経由すると正常に動作しない場合の回避策としてご利用可能です。
■ 注意点 Bypassを設定した通信は、Catoの持つ高度なセキュリティ機能(IPS/IDS、次世代アンチマルウェア、サンドボックスなど)が一切適用されません。そのため、通信先の安全性が十分に確認できている信頼済みの宛先にのみ、限定的に利用することが強く推奨されます。なんでもかんでもBypassの対象にするのは避けましょう。
2. Off-Cloud:拠点間のプライベートな直接通信
こちらは、Catoを導入している拠点(Site)間の通信を、Cato PoPを経由せずに直接行わせるための機能です。
【通常の拠点間通信】 通常、拠点Aから拠点Bへ通信する場合、それぞれの拠点からCato PoPへ接続し、Catoのグローバルバックボーンネットワークを経由して通信が行われます。
【Off-Cloud機能を使った通信】 Off-Cloud機能を使うと、各拠点に設置されたCato Socket同士が直接IPsecトンネルを構築し、Cato Cloudを経由しないプライベートな通信路を確立します。
■ なぜこの機能が必要?(ユースケース)
- 大容量の拠点間データ転送:本社とデータセンター間での夜間バックアップなど、非常に大きなデータをやり取りする際に、Cato Cloudの帯域を消費せずに行いたい場合に必要な機能になります。
■ 注意点 Bypass機能と同様に、Off-Cloudで設定された通信もCatoのセキュリティ機能は適用されません。拠点間の信頼できる通信に限定して利用する機能となります。
3. Split Tunnel(リモートアクセス):リモートアクセスユーザーのためのローカルブレイクアウト
こちらは、Cato Client(SDPユーザー)を利用しているリモートアクセス版のローカルブレイクアウト機能です。
【通常のCato Client接続】 ノートPCなどでCato Clientを有効にすると、デフォルトではPCからのすべての通信(インターネット向け、社内向け)がCato Cloudに送られます。これにより、社外にいても社内にいるのと同じセキュリティポリシーが適用されるわけですが、一つ不便な点があります。それは、自宅のプリンターやNASといったローカルネットワーク上の機器にアクセスできなくなることです。
※プリンターへの通信もCato側へ行こうと仕様としてしまいます。
【Split Tunnel機能を使った通信】 Split Tunnelを設定すると、特定の通信をCatoのトンネルから除外(スプリット)できます。これにより、社内リソースへのアクセスはCato経由、自宅プリンターへのアクセスや特定のインターネット通信は自宅の回線から直接、といった使い分けが可能になります。
■ なぜこの機能が必要?(ユースケース)
- ローカルデバイスへのアクセス:在宅勤務やオフィス内でClient接続していて、プリンターで印刷したり、NASにアクセスしたりする場合に必要になります。
4. Backhauling:特定の拠点からインターネットへ出る「折り返し」通信
こちらは、一度Cato Cloudを経由した通信を、Cato PoPからではなく、指定した特定の拠点(サイト)からインターネットへアクセスさせるための機能です。「バックホール(引き戻す)」という名前の通り、通信を特定の拠点に引き戻してから外に出す、というイメージです。
【通常のインターネット通信】 これまでと同様に、通常は拠点やリモートユーザーからのインターネット通信は、最寄りのCato PoPを経由して、そのままインターネットに出ていきます。
【Backhauling機能を使った通信】 Backhauling機能を使うと、対象の通信は一度Cato Cloudでセキュリティチェックを受けた後、PoPから直接インターネットに出るのではなく、指定された本社などの拠点へ転送されます。そして、その拠点のインターネット回線を使ってインターネットへアクセスします。
■ なぜこの機能が必要?(ユースケース)
- 送信元IPアドレスを固定したい場合:取引先のWebサイトや特定のSaaSが、アクセス元のグローバルIPアドレスで接続制限をかけているケースがあります。Cato PoPのIPアドレスは複数あるため、このような場合にBackhaulingを使い、特定の拠点が持つ固定のIPアドレスからアクセスさせることができます。
- 既存セキュリティ機器との段階的な移行:Catoへの移行期間中に、既存のFirewallが持つ詳細なポリシーを一部の通信にだけ適用し続けたい、といった場合に、通信を一度既存Firewallに戻して処理させることができます。
■ 他の機能との違い(特にBypassとの違い) Backhaulingは、Bypass(ローカルブレイクアウト)と混同されやすいですが、決定的な違いがあります。
- Bypass:Cato Cloudを全く経由しない。そのため、Catoのセキュリティ機能は適用されません。
- Backhauling:一度Cato Cloudを必ず経由します。そのため、Catoのセキュリティ機能(IPS/IDS、次世代アンチマルウェアなど)が適用された上で、指定の拠点からインターネットに出ていきます。
安全を確保しつつ、出口だけをコントロールしたい場合に非常に有効な機能です。 より詳しい設定方法や2つのモード(Internet Breakout / Local gateway IP)の違いについては、別の記事で詳しく解説します。
5. Bypass (TLS Inspection):特定のセキュリティ”処理”をスキップ
最後に登場するのが、これまでとは少し毛色の違う「Bypass」です。これはTLS Inspectionポリシーの中に出てくる用語で、通信経路ではなく、特定のセキュリティ”処理”を対象外にするための設定です。
■ TLS Inspectionとは? まず、TLS Inspection(SSLインスペクションとも呼ばれます)は、HTTPSなどで暗号化された通信の中身をCatoが一旦復号し、脅威が含まれていないかをチェックする非常に重要なセキュリティ機能です。
■ Bypass (TLS Inspection)の役割 TLS Inspectionポリシーのアクションには「Inspect(検査する)」と「Bypass(検査しない)」の2つがあります。ここで「Bypass」を選択すると、その宛先との通信はCato PoPを経由するものの、TLS Inspectionの処理だけをスキップします。つまり、暗号化された通信の中身をチェックせずに、そのまま通過させます。
■ なぜこの機能が必要?(ユースケース)
- アプリケーションや通信先の互換性維持:「証明書ピニング」という技術を使っている一部のアプリケーションやWebサイトは、TLS Inspectionを行うと中間者攻撃と誤認して通信が失敗することがあります。このような場合に、その宛先をBypass設定することで正常な通信を確保します。(金融機関のサイトなどが該当する場合が多いです。)
■ 他のBypassとの決定的な違い 「通信経路そのものをCatoから外す」BypassやSplit Tunnelとは異なり、こちらは「Catoの経路上で、特定の処理だけを行わない」という点が大きな違いです。混同しやすいポイントなので、しっかり区別して覚えておきましょう。
まとめ:各機能の違いが一目でわかる比較表
最後に、今回ご紹介した4つの機能の違いを表にまとめました。
機能名 | 対象スコープ | 通信の向き先 | Cato Cloudの経由 | セキュリティ機能 | 主な目的 |
---|---|---|---|---|---|
Bypass | 拠点(Site) | インターネット | しない | 適用外 | 特定SaaSへの通信最適化 |
Off-Cloud | 拠点(Site) | 他の拠点(Site) | しない | 適用外 | 大容量・低遅延の拠点間通信 |
Split Tunnel | リモートユーザー(Client) | ローカル | しない | 適用外 | ローカルデバイスの利用 |
Bypass(TLS) | 拠点/リモートユーザー | すべて | する | TLS検査のみ適用外 | 通信先との互換性 |
このように整理すると、それぞれの役割と違いが明確になったのではないでしょうか。
Cato SASEの基本は、すべてのトラフィックをCato Cloudに集約し、一貫したセキュリティポリシーを適用することです。今回ご紹介した機能は、パフォーマンス上の要件や互換性の問題など、特別な理由がある場合に利用する「例外設定」と位置づけるのが良いでしょう。
これらの機能を適切に使いこなし、より安全で快適なネットワーク環境を構築していきましょう。