--- title: "サイトWebプロキシを通じたトラフィックのルーティング" slug: "routing-traffic-through-a-web-proxy" updated: 2026-10-12T23:13:39Z published: 2026-10-12T23:13:39Z canonical: "knowledge.catonetworks.com/routing-traffic-through-a-web-proxy" --- > ## 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. # サイトWebプロキシを通じたトラフィックのルーティング ## 概観 サイトWebプロキシは、Catoクライアントをインストールできないサーバー、共有キオスク、OT/IoTデバイスなどのサイト背面のデバイスへのSecure Web Gateway (SWG)保護を拡張します。これらのデバイスからHTTPおよびHTTPSトラフィックをCato Cloudへのルーティングを行い、監査およびポリシー施行を行うため、プロキシ設定を手動または標準PACファイルで構成することができます。これにより、クライアントをインストールせずにエージェントレスおよび管理されていないデバイスに既存のインターネットセキュリティポリシーを適用できます。 サイトWebプロキシにより、トラフィックは以下のように処理されます： 1. **デバイスプロキシ設定の構成**: プロキシ FQDN とポートを指すようにデバイスを設定します。推奨される方法はプロキシ自動構成 (PAC) ファイルで行うことですが、手動で設定することもできます。 2. **リクエストがプロキシに送信される:**デバイスはリクエストをサイトトンネルを介してCato PoP内のプロキシに送り、宛先に直接送信しません。 3. **(オプション) ユーザーが認証され、セキュリティポリシーが適用されます:** プロキシインスタンスは認証済みまたは未認証のトラフィックをサポート可能です。認証プロキシの場合、Kerberos はセッションをユーザーと関連付け、ユーザーにマッチするセキュリティポリシーを適用します。非認証プロキシインスタンスも Kerberos 認証をサポートしないデバイスおよびサービスのためのインターネットアクセスを提供します。 4. **(オプション) トラフィック検査：** セキュリティポリシーの設定に基づき、デバイスからのトラフィックは Cato のセキュリティエンジンによって検査されます。 5. **トラフィックが転送される:**プロキシはリクエストをインターネット宛先に転送します。 6. **応答はプロキシを通じて戻ります:** セッションはログに記録され、宛先の応答がデバイスに中継されます。 各プロキシインスタンスは選択されたサイトまたはすべてのサイトに関連付けられています。ユニークなポートを使用し、それぞれの注文されたルールベースを保持しています。 Kerberosおよび未認証プロキシインスタンスはアカウント内で共存可能ですが、サイトとポートの組み合わせは各インスタンスに対して一意である必要があります。 ### Use Case 会社ABCは規制産業で運営しており、ネットワーク上のすべてのデバイスからのアウトバウンドWebトラフィックを検査する必要があります。その環境には共有キオスク、製造サーバー、Catoクライアントを実行できないIoTデバイスが含まれます。 会社ABCはサイトWebプロキシを展開し、関連するデバイスにPACファイルを配布します。 Kerberosをサポートするデバイスは、ユーザーとトラフィックを関連付ける認証されたプロキシインスタンスを使用します。認証できないデバイスは、別の無認証プロキシインスタンスを使用します。 PAC ファイルで定義されたプロキシ設定に基づき、デバイスのブラウザはウェブトラフィックをサイト Web プロキシに送信し、そこでトラフィックが検査され、設定されたインターネットセキュリティポリシーが適用されます。これにより、Company ABCはCatoクライアントをすべてのデバイスにインストールすることなく、セキュリティとコンプライアンスのコントロールを一元化できます。 ## サイトWebプロキシの設定 サイトWebプロキシを設定するには、以下が必要です： 1. Microsoft EntraでCato SCIMアプリケーションのユーザーID属性をマッピングする（プロキシインスタンスで認証済みトラフィックにのみ必要です）。 2. プロキシインスタンスを作成 3. プロキシを介してトラフィックを管理するための注文されたネットワークルールを定義します。 4. デバイスのプロキシ設定を構成する 認証済み(Kerberos)と未認証のプロキシインスタンスはアカウント内で共存できます。各プロキシインスタンスは独自のネットワークルールセットを維持します。 ![](https://cdn.document360.io/81d0367c-2b69-4ba8-b412-1c8f46ce677e/Images/Documentation/image(53).png?sv=2026-02-06&spr=https&st=2026-11-10T16%3A55%3A21Z&se=2026-11-10T17%3A55%3A21Z&sr=c&sp=r&sig=oeOrw%2FjnLvDI7Q0bwvmB8KiJvNhvOjwYDbTgdbwdAsM%3D) ### ステップ 1: Cato SCIM アプリケーションのためのユーザー アイデンティティ属性のマッピング Entra SCIM プロビジョニングスキーマを拡張し、以下の属性を Microsoft Entra ID から Cato SCIM アプリケーションに同期します: - **onPremisesSamAccountName:** 従来の Windows ログオン名。これは、sAMAccountName 属性を必要とする Windows 認証およびレガシーアプリケーションで使用されます。 - **onPremisesDomainName:** ユーザー アカウントの関連付けられたオンプレミスの Active Directory ドメインの完全修飾ドメイン名（FQDN）。これは、Kerberos 認証中にユーザーを識別するために`onPremisesSamAccountName`と共に使用されます。 > [!NOTE] > 注記: > > - ユーザープロビジョニングが開始される前にこの設定を適用する必要があります。もしこれが不可能な場合は、設定が適用された後にCato SCIMアプリケーションに同期を実行します > - スキーマを編集する前に、JSON ドキュメントのコピーを保存することをお勧めします。これにより、エラーが発生した場合、元の設定を復元できます。 > - 非認証トラフィック用のプロキシインスタンスのみを設定している場合、このステップは不要です。 > - スキーマに表示される正確な名前は、Microsoft Entraプロビジョニングテンプレートのバージョンによって異なる場合があります。以下の例をリファレンスとして使用し、スキーマ内の対応するEntraのソース、Catoのターゲット、およびユーザープロビジョニングマッピングオブジェクトを特定します。 **ユーザー アイデンティティ属性をマップするには:** 1. [Entra 管理センター](https://entra.microsoft.com/) に移動し、**エンタープライズアプリケーション**に進みます。 2. **Cato Networks** **SCIM** アプリケーションを開きます。 3. **プロビジョニング** をクリックし、**プロビジョニングの編集**を行います。 4. **マッピング** セクションを展開し、**Azure Active Directory ユーザーのプロビジョニング** をクリックして、**詳細オプションを表示** を選択します。 5. **スキーマをここで閲覧** をクリックします。 JSON スキーマドキュメントが開きます。 6. `"name": "Microsoft Entra ID'`を検索し、Entra ソース属性をプロビジョニング マッピングに使用できるようにするために、Ctrl+F を使用して検索します。 7. `"attributes"` 配列を特定します (directories[] > "Microsoft Entra ID" > objects[] > User > attributes[])、最終的な属性オブジェクトは `onPremisesSecurityIdentifier` です。 8. 最後の属性にコンマを追加し、以下のエントリを閉じる ] の前に貼り付けます。 **Entra ソース属性を公開するためのエントリ** ```json { "anchor": false, "caseExact": false, "defaultValue": null, "flowNullValues": false, "multivalued": false, "mutability": "ReadWrite", "name": "onPremisesSamAccountName", "required": false, "type": "String", "apiExpressions": [], "metadata": [], "referencedObjects": [] }, { "anchor": false, "caseExact": false, "defaultValue": null, "flowNullValues": false, "multivalued": false, "mutability": "ReadWrite", "name": "onPremisesDomainName", "required": false, "type": "String", "apiExpressions": [], "metadata": [], "referencedObjects": [] } ``` 9. Cato SCIMスキーマに対応するターゲットSCIM拡張属性を追加するには、Catoのターゲットディレクトリを見つけます。 "name": "Cato Networks Provisioning"または"name": "CatoNetworks"を検索します。いずれも存在しない場合は、"catonetworks"を検索し、Catoユーザーオブジェクトのattributes配列を見つけます。 10. 最後の属性にコンマを追加し、以下のエントリを閉じる ] の前に貼り付けます。 **SCIM 拡張属性に対応するターゲットを追加するためのエントリ** ```json { "anchor": false, "caseExact": false, "defaultValue": null, "flowNullValues": false, "multivalued": false, "mutability": "ReadWrite", "name": "urn:ietf:params:scim:schemas:extension:catonetworks:2.0:User:sAMAccountName", "required": false, "type": "String", "apiExpressions": [], "metadata": [], "referencedObjects": [] }, { "anchor": false, "caseExact": false, "defaultValue": null, "flowNullValues": false, "multivalued": false, "mutability": "ReadWrite", "name": "urn:ietf:params:scim:schemas:extension:catonetworks:2.0:User:onPremisesDomainName", "required": false, "type": "String", "apiExpressions": [], "metadata": [], "referencedObjects": [] } ``` 11. Entra属性とCato SCIM属性間の同期マッピングを作成するには、Microsoft Entra IDからCatoへのユーザープロビジョニングマッピングを見つけます。 "Provision Azure Active Directory Users"または"Provision Microsoft Entra ID Users"を検索し、そのオブジェクトのattributeMappings配列を見つけます。 12. その配列の末尾に最後の }, を見つけて、以下のエントリを閉じる ] の前にコンマを追加して貼り付けます。 **Entra と Cato SCIM 属性間のマッピングを同期するためのエントリ** ```json { "defaultValue": "", "exportMissingReferences": false, "flowBehavior": "FlowWhenChanged", "flowType": "Always", "matchingPriority": 0, "targetAttributeName": "urn:ietf:params:scim:schemas:extension:catonetworks:2.0:User:sAMAccountName", "source": { "expression": "[onPremisesSamAccountName]", "name": "onPremisesSamAccountName", "type": "Attribute", "parameters": [] } }, { "defaultValue": "", "exportMissingReferences": false, "flowBehavior": "FlowWhenChanged", "flowType": "Always", "matchingPriority": 0, "targetAttributeName": "urn:ietf:params:scim:schemas:extension:catonetworks:2.0:User:onPremisesDomainName", "source": { "expression": "[onPremisesDomainName]", "name": "onPremisesDomainName", "type": "Attribute", "parameters": [] } } ``` 13. 「**保存**」をクリックします。スキーマテキストエディタ保存完了メッセージが表示されます。 ![](https://cdn.document360.io/81d0367c-2b69-4ba8-b412-1c8f46ce677e/Images/Documentation/image(74).png?sv=2026-02-06&spr=https&st=2026-11-10T16%3A55%3A21Z&se=2026-11-10T17%3A55%3A21Z&sr=c&sp=r&sig=oeOrw%2FjnLvDI7Q0bwvmB8KiJvNhvOjwYDbTgdbwdAsM%3D) 14. Cato Networks SCIM アプリケーションで、**プロビジョニング**の後に**プロビジョニングの編集**をクリックします。 15. **マッピング** セクションを展開し、**Azure Active Directory ユーザーのプロビジョニング** をクリックして、**詳細オプションを表示** を選択します。 16. 数分後、これらのマッピングが表示されることを確認します: - sAMAccountName → onPremisesSamAccountName - onPremisesDomainName → onPremisesDomainName ### ステップ 2: プロキシインスタンスの作成 プロキシインスタンスはサイト、エンドポイント、および認証方法を定義します。サポートされている認証オプションは次のとおりです: - **Kerberos:** プロキシはデバイスの Kerberos チケット内のアイデンティティに対して各リクエストを認証し、すべてのセッションを特定のユーザーに結び付けます。これにより、ユーザー ベースのポリシーを適用できます。 Kerberos認証を使用するには、Kerberos Key Distribution Center (KDC) で **KEYTAB** ファイルを生成します。 KEYTAB ファイルは、Cato PoP が Kerberos チケットを検証し、ユーザーのアイデンティティを確認することを可能にする秘密を含んでいます。 - **認証なし:** プロキシはユーザー認証を適用しません。ユーザーベースのポリシーは適用されません。 ![](https://cdn.document360.io/81d0367c-2b69-4ba8-b412-1c8f46ce677e/Images/Documentation/image-1783949253027.png?sv=2026-02-06&spr=https&st=2026-11-10T16%3A55%3A21Z&se=2026-11-10T17%3A55%3A21Z&sr=c&sp=r&sig=oeOrw%2FjnLvDI7Q0bwvmB8KiJvNhvOjwYDbTgdbwdAsM%3D) **プロキシインスタンスを作成するには：** 1. From the navigation menu, select **Resources > Site Web Proxy**. 2. **新規**、次に**新規プロキシ**をクリックします。 3. プロキシインスタンスの名前を追加し、プロキシに関連付けするサイトを選択します。 4. デバイスがプロキシに接続するために使用するFQDNとプロキシインスタンス用のポートを入力します。**注:** DNS解決のための**対応するIP**が表示されます。 ![](https://cdn.document360.io/81d0367c-2b69-4ba8-b412-1c8f46ce677e/Images/Documentation/image(67).png?sv=2026-02-06&spr=https&st=2026-11-10T16%3A55%3A21Z&se=2026-11-10T17%3A55%3A21Z&sr=c&sp=r&sig=oeOrw%2FjnLvDI7Q0bwvmB8KiJvNhvOjwYDbTgdbwdAsM%3D) 5. **認証方法**を選択します。 ![](https://cdn.document360.io/81d0367c-2b69-4ba8-b412-1c8f46ce677e/Images/Documentation/image(68).png?sv=2026-02-06&spr=https&st=2026-11-10T16%3A55%3A21Z&se=2026-11-10T17%3A55%3A21Z&sr=c&sp=r&sig=oeOrw%2FjnLvDI7Q0bwvmB8KiJvNhvOjwYDbTgdbwdAsM%3D) 6. **Kerberos** が **認証方法** として選択された場合、KEYTAB ファイルをアップロードします。非認証プロキシインスタンスを作成する場合は、このステップは不要です。 7. **適用してルールを作成**をクリックします。 プロキシインスタンスが作成されました。 ### ステップ 3: ネットワークルールの定義 プロキシインスタンスが作成されたら、ネットワークルールを定義します。各ルールはソース、宛先、およびアクションから構成されています。利用可能なアクションはプロキシインスタンスの**認証方法**に依存します。 - Kerberosプロキシインスタンスは以下のアクションをサポートします： - **認証:** トラフィックは Kerberos 認証を必要とします - **許可:** トラフィックは認証なしで許可されます。特定のデバイス、サービス、または宛先が認証をバイパスできるときは、**許可**ルールを使用します。**許可する**ルールは、すべての**認証**ルールの上に配置する必要があります。 **注:** **許可**アクションは Kerberos 認証を指します。非認証トラフィックはセキュリティエンジンによって検査され、セキュリティポリシーによってブロックされる可能性があります。 - 非認証プロキシインスタンスの場合、許可アクションのみが利用可能です サイトWebプロキシルールベースのいずれのルールにも一致しないトラフィックは、最終システムルールによってブロックされます。 ![](https://cdn.document360.io/81d0367c-2b69-4ba8-b412-1c8f46ce677e/Images/Documentation/image(55).png?sv=2026-02-06&spr=https&st=2026-11-10T16%3A55%3A21Z&se=2026-11-10T17%3A55%3A21Z&sr=c&sp=r&sig=oeOrw%2FjnLvDI7Q0bwvmB8KiJvNhvOjwYDbTgdbwdAsM%3D) **ネットワークルールを定義するには：** 1. From the navigation menu, select **Resources > Site Web Proxy**. 2. **新規**、次に**新規プロキシルール**をクリックします。新しいプロキシルールパネルが開きます。注: プロキシインスタンスを作成した直後にネットワークルールを定義する場合、新しいプロキシルールパネルが自動的に表示されます。 3. ルールの**名前**を入力し、ルールが適用される**プロキシ**を選択し、ルールベース内のルールの**位置**を選択します。 4. ルールで施行される**ソース**を追加します。サポートされているソースは IPアドレスまたはネットワーク サブネットです。 **注:** すべてのソースにルールを適用するには、このセクションを空白のままにします。 5. ルールが適用される**宛先**を定義します。**注:** ルールをすべての宛先に適用する場合、このセクションを空白のままにします。 6. ルールによって適用される**アクション**を選択します。 7. **適用** をクリックします。 8. **公開**をクリックします。 9. **サイトWebプロキシ**トグルを**有効**に設定します。 ### ステップ 4: デバイスのプロキシ設定を構成する デバイスのプロキシ設定を構成して、Web トラフィックをサイト Web プロキシに送信します。推奨される方法は PAC ファイルを使用することですが、手動でも行うことができます。 **デバイスのプロキシ設定を構成するには:** ![](https://cdn.document360.io/81d0367c-2b69-4ba8-b412-1c8f46ce677e/Images/Documentation/image(64).png?sv=2026-02-06&spr=https&st=2026-11-10T16%3A55%3A21Z&se=2026-11-10T17%3A55%3A21Z&sr=c&sp=r&sig=oeOrw%2FjnLvDI7Q0bwvmB8KiJvNhvOjwYDbTgdbwdAsM%3D) 1. デバイスの FQDN を、プロキシインスタンスを作成したときに設定したプロキシ FQDN に設定します。これはプロキシインスタンスの**プロキシ FQDN**列に記載されています。 2. DNS サーバーを設定して FQDN を Cato の IP アドレスに解決します。これはプロキシインスタンスの**プロキシ FQDN**列に記載されています。デフォルトでは、プロキシ IP アドレスは **10.254.254.7** です。 ## 既知の制約 - Microsoft Active Directory と Microsoft Azure で Kerberos 認証がサポートされています - リモートブラウザ分離 (RBI) をサポートするためには、プロキシから http://rbi.catonetworks.com をスキップするために PAC ファイルでの追加設定が必要です。詳細については、[ブラウジングセッション用RBIサービスの設定](/v1/docs/configuring-the-rbi-service-for-browsing-sessions)を参照してください. - サイト Web プロキシのアクティビティは、成功したプロキシ接続を識別するインターネット ファイアウォール イベントを使用して追跡されます。専用のサイト Web プロキシイベント タイプは現在利用できません