---
title: "Cato SPACEアーキテクチャでのパケットフローの理解"
slug: "understanding-packet-flow-with-cato-space-architecture"
updated: 2026-07-30T01:27:45Z
published: 2026-07-30T01:27:45Z
canonical: "knowledge.catonetworks.com/understanding-packet-flow-with-cato-space-architecture"
---

> ## Documentation Index
> Fetch the complete documentation index at: https://knowledge.catonetworks.com/llms.txt
> Use this file to discover all available pages before exploring further.

# Cato SPACEアーキテクチャでのパケットフローの理解

この記事では、Catoのシングルパスクラウドエンジンアーキテクチャ（SPACE）に基づくPoPのセキュリティエンジンのパケットフローについて説明します。

## 概要

CatoのSPACEアーキテクチャは、単一サービスでトラフィックフローを調査および処理します。 このサービスには、複数のネットワークおよびセキュリティエンジンが含まれており、同時にトラフィックフローを分析および処理します。 このアーキテクチャは、複数のポイントソリューションをサービスチェーンで組み合わせることによる制限を回避します。 フローに対する単一パスは、レイテンシを最小限に抑え、全体的なネットワークパフォーマンスを向上させます。 各PoPは、CatoのすべてのSPACEサービスとエンジンを使用して、これらのネットワークおよびセキュリティの決定を行うことができます。

セキュリティおよびネットワークエンジンは、トラフィックフローに対するデータへの完全なアクセス権を持ち、同時にデータを評価し、共有コンテキストで相互に交換します。 エンジンは並行して動作し、別のエンジンよりもトラフィックを優先して評価することはありません。 エンジンは各PoPに配置されており、異なる物理位置にあるエンジンからの情報を待たずにデータを共有できます。

例えば、ファイアウォールルールがmacOSデバイスをブロックするとき、ファイアウォールエンジンは最初のパケットからこのデータを得られず、追加データを待ちます。 別のエンジンがデバイスをmacOSとして識別すると、ファイアウォールはルールのアクションに基づいてフローをブロックします。

### SPACEネットワークとセキュリティサービスの概要

このセクションでは、パケットフローの異なるフェーズに適用されるPoPのネットワークおよびセキュリティサービスとエンジンを一覧表示します。

- Catoのポリシーとエンジン
  - ファイアウォール - インターネットおよびWANファイアウォールのポリシー
  - ネットワーク - ルーティングおよびQoS優先度のためのネットワークルールのポリシー
  - IPS/SAM - IPSの保護と疑わしい活動の監視（SAM）
  - アプリ制御 - アプリケーション制御ポリシーのためのアプリ識別
    - アプリ制御gen2 - アクセスに基づいたアプリのルール：許可またはブロック
    - アプリ制御gen3 - 詳細なアクションに基づいたアプリのルール：アップロード、ダウンロード、その他
  - TLSi - HTTPSと暗号化されたトラフィックのためのTLSインスペクション
  - DLP - データ損失防止（DLP）ポリシーのためのコンテンツインスペクション
  - AM/NGAM - マルウェア対策および次世代マルウェア対策のスキャンによる添付ファイルのマルウェアスキャン
- トラフィックフローデータとプロトコル
  - アプリ識別 - セキュリティまたはネットワークポリシーのための特定アプリケーションを識別するための様々な基準
  - OS - デバイスのオペレーティングシステム（OS）、例としてデバイスポスチャまたはクライアント接続ポリシー
  - クライアントクラス - このネットワークフローを作成したオペレーティングシステム上で実行されるクライアントアプリケーションのタイプ（例：Chrome）
  - URLF - ウェブサイトURLに基づいたCatoカテゴリのURLフィルタリング
  - ファイルタイプ - CASBおよびDLPのためのアップロードまたはダウンロード方向でのファイル添付

## TCPパケットフローとSPACE

これは典型的なHTTPフローの例で、以下の項目が含まれています：

- タイムライン - トラフィックフローの異なるフェーズ
- 利用可能なフィールド - 特定のタイムラインフェーズに利用可能なデータ
- Catoエンジン - フローを分析し、適切なアクション（ブロックまたは許可）を行うことができるSPACEエンジン
- トラフィックフローデータ - 各フェーズで、トラフィックフローを評価するために使用されるデータ

![SPACE_Flow.png](https://cdn.document360.io/81d0367c-2b69-4ba8-b412-1c8f46ce677e/Images/Documentation/24275618710173.png?sv=2026-02-06&spr=https&st=2026-11-10T16%3A50%3A02Z&se=2026-11-10T17%3A50%3A02Z&sr=c&sp=r&sig=owkhFH7c4nRITAjVhKN58T42qCxG0LgSIMMiKuDypss%3D)

以下の詳細をリストで確認できます： [サンプルTCPフローの詳細](/v1/docs/understanding-packet-flow-with-cato-space-architecture#details-of-sample-tcp-flow)。

### トラフィックフローからのサンプルアプリ識別

これは、Slackアプリを含むルールのトラフィックフローの例で、各段階でどの情報が利用可能かを示しています。

1. 最初のパケット - TCP

```plaintext
送信元 - 10.10.2.107\n送信元ポート - 55477\n宛先IP - 3.68.124.168\n宛先ポート - 443\nプロトコル - TCP\nDNS応答 - 3.68.124.168 - slack.com （オプション応答）
```

このサンプルの最初のパケットに基づいて、利用可能なトラフィックフロー情報です：

TLSハンドシェイクから追加情報が得られるまで、Slackアプリの識別を完了できません。
  - 5つ組 - トラフィックがSlackアプリに接続されていることを識別できません
  - DNSレスポンス - 前のフローに基づいて、エンジンは既にこの宛先IPのdnameがslack.comであることを知っています
  - ASN - 宛先IPに基づいて、セキュリティエンジンはASNを識別できます
  - アプリ識別には以下が含まれます：tcp
2. tls_handshake

```plaintext
"TLSヘッダー"\n"sni_host": "slack.com"\n"事前定義された検査バイパス理由": "なし"\n"ja3_formatted_str": "771,4865-4866-4867-49195-49199-49196-4920"
```

このサンプルのtls_handshakeに基づいて、利用可能なトラフィックフロー情報です：
  - TLSヘッダーとサーバーポート443 - TLSプロトコルに一致
  - SNIはslack.comで、Cato Slackアプリ識別に一致します

SNIはまたURLFにも送信され、ビジネス情報、コンピュータおよびテクノロジー、ソーシャルのカテゴリに一致します
  - クライアントクラスはJA3で、TLSフィンガープリンティングに基づきクライアントをブラウザとして分類します
  - TLSインスペクションまたはバイパスアクション - クライアントクラスおよびアプリ識別に基づきます
  - アプリ識別には以下が含まれます：tcp、tls、slack
3. HTTP

```plaintext
"url" : "upload.slack.com:\n"host_name" : "slack.com"\n"Content-Type" : "application/pdf"\n"Content-Disposition" : form-data; name="file"; filename="sample-data.pdf"\n"Content-Length" : "52765"
```

このサンプルフローでは、HTTPデータに基づいて以下の情報が利用可能です：
  - アプリ識別には以下が含まれます：tcp、tls、http、slack
  - TLSインスペクションはフローを復号化し、Slackサーバーのhost_nameがslack.comであることを識別します
  - HTTPヘッダー - HTTPプロトコルに一致

これは、HTTP_hostがSNIに一致し、アプリ識別に変更が発生しない一般的な例です
  - URL - アップロードプレフィックスはより詳細で、アプリケーション制御ポリシーにおけるアップロードアクションと一致できます
  - Content-Type、Content-Disposition、Content-Length - ファイル名、サイズ、タイプに関する情報を提供します
  - アプリケーション制御ポリシーのアクション：
    - 企業のSlackテナントだけを使用するポリシーを適用します
    - ファイルタイプに基づいたファイル制御

マルウェア対策およびNGマルウェア対策は、ダウンロード方向のファイルのみをスキャンします。
4. HTTPボディ

```plaintext
"HTTPボディペイロード" : "ファイル自体"
```

例えば、DLPポリシーは、Slackメッセージでクレジットカードデータの使用を禁止します。
  - アプリ識別はSlackアプリケーションで完了しました。 これが**ソーシャル**カテゴリに属するトラフィックであると識別されます。
  - ファイルの内容が準備できたら、これらのエンジンがファイルの内容を分析します：
    - DLPエンジンはデータ制御ポリシーに基づいてコンテンツをスキャンします
    - マルウェア対策およびNGマルウェア対策は、ダウンロード方向でファイルをスキャンします

## Catoのポリシーとエンジン

このセクションでは、トラフィックフローを分析・対応するCatoのセキュリティポリシーとエンジンについて説明します。

### ファイアウォールおよびネットワークポリシー

WANファイアウォール、インターネットファイアウォール、ネットワークルールポリシーは、最初のパケットでトラフィックフローを評価できることがよくあります。 例えば、5つ組データに基づいたルールです。 しかし、AzureやSlackのような特定のアプリケーションに一致するルールについては、エンジンがフローを評価するためにトラフィックフローの追加データが必要です。 これは、エンジンがフローを評価するフェーズが特定のルールの設定に依存することを意味します。

ファイアウォールルールの種類に関する詳細については、[インターネットおよびWANファイアウォールポリシー - ベストプラクティス](/v1/docs/recommendations-for-internet-and-wan-firewall-policies)をご覧ください。

#### シンプルなネットワークルールと複雑なファイアウォールルールにおける最初のパケットの例

この例は、PoPエンジンがIPアドレスとポートを使用するシンプルなネットワークルールと、Azureアプリの複雑なファイアウォールルールでトラフィックフローをどのように異なる方法で評価するかを示しています。 ネットワークエンジンは最初のパケットに基づいてフローを評価できますが、PoPはファイアウォールエンジンが分析を完了するための追加データを待ちます。

**サンプルネットワークルール**

以下のネットワークルールは、**ソース**が上記のネットワークルールのIP範囲であり、ポート範囲が8000 - 8010で、トラフィックがロンドンPoPロケーションを経由して出力されるためのものです。

![Simple_network.png](https://cdn.document360.io/81d0367c-2b69-4ba8-b412-1c8f46ce677e/Images/Documentation/24275609657373.png?sv=2026-02-06&spr=https&st=2026-11-10T16%3A50%3A02Z&se=2026-11-10T17%3A50%3A02Z&sr=c&sp=r&sig=owkhFH7c4nRITAjVhKN58T42qCxG0LgSIMMiKuDypss%3D)

ネットワークエンジンは、5つ組に基づいてトラフィックフローのルーティング決定を評価できる。

**サンプルWANファイアウォールルール**

以下のWANファイアウォールルールは、ネットワークルールのIP範囲と同じ**ソース**で、RnDユーザーグループのメンバーであるユーザーに対するトラフィックを許可します。 加えて、このルールはHTTP(S)、TLS、FTP、およびTFTPサービスのAzureアプリケーションを対象としています。

![Azure_FW.png](https://cdn.document360.io/81d0367c-2b69-4ba8-b412-1c8f46ce677e/Images/Documentation/24275625515677.png?sv=2026-02-06&spr=https&st=2026-11-10T16%3A50%3A02Z&se=2026-11-10T17%3A50%3A02Z&sr=c&sp=r&sig=owkhFH7c4nRITAjVhKN58T42qCxG0LgSIMMiKuDypss%3D)

ファイアウォールエンジンは、ユーザーID、Azureアプリケーション、およびサービスの確認が必要なため、最初のパケットでトラフィックを評価できません。 エンジンが評価を終え、フローがすべての基準を満たした後、エンジンはフローを許可します。 PoPはまた、最初のパケットに基づいてルーティング決定を適用します。

### URLフィルタリングとCatoカテゴリ

URLフィルタリングサービスは、ウェブサイトのURLを解析し、既知または疑わしい悪意のあるサイトや不適切なウェブサイトのデータベースと比較することで機能します。 このサービスはまた、ウェブサイトの内容自体を分析して、そのカテゴリ、例えばアダルトコンテンツ、ギャンブル、ソーシャルネットワーキング、またはストリーミングメディアを決定することもあります。

カテゴリに関する詳細については、[カテゴリと働く](/v1/docs/working-with-categories)を参照してください。

### TLSインスペクション

TLSインスペクションエンジンは、パケットフローのtls_handshakeフェーズに関与します。 フローを検査するかどうかの決定は不可逆であり、2つの段階で行われます：

1. ステージ1 - クライアント_helloパケットの最初のペイロードは、TLSインスペクションエンジンがこのトラフィックフローを検査するかどうかの初期指標を提供します
2. ステージ2 - クライアント_helloは完全に解析され、TLSインスペクションポリシーアクションが適用されます（フローを検査またはバイパス）

HTTPSフローに対しては、ステージ1に基づいてパケットをブロックする決定がなされる可能性があります。 しかし、エンジンはTLS接続を確立し続け、エンドユーザーに適切なファイアウォールまたはIPSブロックページを提示します。

### IPS

IPSエンジンは、トラフィックフローの存続期間中、実行を続けます。 それは特定の項目を検査し、異なるステージで利用可能なコンテンツに基づいてIPS保護に一致するコンテンツに対処します。 IPSは、虫眼鏡のように機能し、トラフィックからの更新を常に待ち続け、フローで見られたエンジンに情報を継続的に提供します。

以下の例は、フローの異なるステージで利用可能な異なる情報を示しています：

- フローのプロトコルはHTTPです
- ペイロードに基づいて、TLSがあります
- TLS 1.3暗号スイートTLS_AES_256_GCM_SHA384を使用するクライアント_helloがあります

異なるIPS保護は、上記のいずれかの項目に一致し、そのフェーズのトラフィックフローにアクションを実行することができます。

### DNSの保護

DNSの保護はIPSエンジンの一部であり、リクエストとレスポンスのDNSフローで実行されます（トランスポートには接続されず、例えばTCPやUDP）。

DNSリクエスト中に、ドメイン名が分析され、ドメインの評価や静的フィードに基づいて評価されます。 その後、DNSレスポンス中に、解決されたIPとコンテンツが、潜在的な悪意のあるコンテンツに対して分析されます。 DNS保護ポリシーは、対応するコンテンツ（トラフィックフローをブロックまたは許可する）に適用されます。

### アプリ制御

アプリ制御エンジンは、トラフィックを検査し、アプリケーション制御ポリシーのアクションを適用し、各新しいHTTPトランザクション（リクエストと応答）で評価されます。

Gen2アプリの場合、TLSとHTTPプロキシがアプリ識別を完了するために必要です。

セキュリティおよびコンプライアンス要件を含むルールの場合：

- 他のネットワークおよびセキュリティエンジンからのコンテキストデータに基づいて、アプリ制御エンジンはtls_inspectionフェーズにおけるこれらの要件を評価できます
- エンジンはSNIから情報を取得することが可能であり、アプリの評価にTLSや完全なアプリ識別（レイヤー7 DPI）を必要としない場合もあります。

### DLP

DLPエンジンはトラフィックフローの内容を検査し、アプリ制御エンジンの拡張として機能します。 ポリシーでファイルタイプやファイルサイズが指定されている場合、エンジンはこれらのファイル特性に対するアプリのメタデータおよびペイロードを検査する必要があります：

1. エンジンはファイルタイプを評価し、コンテンツ検査のためにサポートされているファイルの一覧と一致するか確認します。
2. その後、gen3アプリ識別が完了し、特定のコンテンツ署名がストアされ検査される内容やデータのために特定されます。
3. コンテンツを検査し、定義済みのコンテンツプロファイルに一致するかどうかを確認します。

### マルウェア対策と次世代アンチマルウェア

マルウェア対策エンジンとSentinelOne 次世代アンチマルウェアエンジンは、インバウンドのトラフィック（ファイルのダウンロード）のファイルの添付を既知および未知のマルウェアに対してスキャンします。 file_typeはHTTP応答またはFTPトラフィックリクエストに基づいています。

HTTP、HTTPS、FTPアプリケーションとサービスのみがスキャンされます。

1. エンジンはアプリケーションがアンチマルウェアポリシーのルールに一致するかどうかを確認します。
2. ファイルを以下のファイル一覧に照らし合わせて一致をチェックします：
  1. Cato管理アプリケーションで設定された**許可リスト** - これらのファイルはダウンロードが許可されます。
  2. Catoセキュリティチームによって管理されるブロックリスト - これらのファイルはブロックされます。
3. ファイルは、マルウェア対策エンジンと次世代アンチマルウェアエンジンによってスキャンされ、判定として悪意のある、疑わしい、無害が返されます。
4. アンチマルウェアポリシーに応じた適切なアクションがファイルに適用されます。

## FAQ for Catoポリシーとエンジン

**URLフィルタリングはWANトラフィックに適用されますか？**

いいえ、URLフィルタリングはインターネットトラフィック専用で、WANのアカウントトラフィックには適用されません。

**ファイアウォールとIPSポリシーのためのGeo-Restriction設定の違いは何ですか？**

[WANおよびインターネットファイアウォール](/v1/docs/adding-device-conditions-to-firewall-rules)での「**デバイス**」設定により、細かいルールに対して送信元国を定義できます。 しかし、宛先国に対する制御はありません。

[IPSポリシー](/v1/docs/configuring-the-ips-policy) の「**地理的制限**」タブにより、送信元または宛先である制限付きトラフィックが定義されます。 しかし、IPSは全体のアカウントに対するグローバルポリシーですので、特定のサイトやオブジェクトに対して地理的制限設定を適用することはできません。

## サンプルTCPフローの詳細

1. タイムライン - 最初のパケット
  1. 利用可能なフィールド - 5つのタプル、ホスト名（dname）
  2. Catoエンジン - ファイアウォール、ネットワーク、IPS/SAM
  3. トラフィックフローデータ - アプリ識別、クライアントクラス、OS
2. タイムライン - tls_handshake
  1. 利用可能なフィールド - cipher_suite、ホスト名（SNI）
  2. Catoエンジン - IPS/SAM、アプリ制御gen2、TLSi、ファイアウォール、ネットワーク
  3. トラフィックフローデータ - アプリ識別、クライアントクラス、URLF
3. タイムライン - HTTP_headers
  1. 利用可能なフィールド - ヘッダ、URL、ホスト名（ホストヘッダ）
  2. Catoエンジン - アプリ制御gen3、IPS/SAM
  3. トラフィックフローデータ - File_type（アップロード）、OS
4. タイムライン - HTTP_body
  1. 利用可能なフィールド - HTTP_request、HTTP_body
  2. Catoエンジン - アプリ制御gen3、DLP、IPS/SAM
  3. トラフィックフローデータ - File_type（アップロード）、アプリ識別
5. タイムライン - HTTP_response
  1. 利用可能なフィールド - HTTP_response_headers、HTTP_response_body
  2. Catoエンジン - AM/NGAM、アプリ制御gen3、DLP、IPS/SAM
  3. トラフィックフローデータ - File_type（ダウンロード）、アプリ識別