Autorisierung mit Service Extensions delegieren

Auf dieser Seite erfahren Sie, wie Sie die Autorisierung für Agent Gateway mithilfe von Service Extensions an Identity-Aware Proxy, Model Armor und andere benutzerdefinierte Autorisierungs-Engines delegieren.

Autorisierungsrichtlinien und ‑erweiterungen

Mit Autorisierungsrichtlinien können Sie zentralisierte Zugriffssteuerungs- und Governance-Richtlinien für Traffic erzwingen, der Endpunkte durchläuft, die vom KI-Agenten-Gateway veröffentlicht werden. Um komplexe Entscheidungen zu Zugriffssteuerung, Inhaltssicherheit und Governance zu treffen, können Sie mit Agent Gateway Autorisierungsrichtlinien mit Autorisierungserweiterungen konfigurieren. Damit können Sie Autorisierungs- und Inhaltssicherheitsentscheidungen an die von Ihnen ausgewählten Autorisierungs-Engines delegieren.

Eine Autorisierungserweiterung fängt Anfragen ab, die eine Agent Gateway-Bereitstellung durchlaufen, und führt einen gRPC-Echtzeitaufruf an den angegebenen Autorisierungsdienst aus. So kann der Dienst den Traffic prüfen, ändern oder blockieren, bevor er an sein Ziel weitergeleitet wird. Sie können die Autorisierung an Cloud de Confiance -Dienste wie Identity-Aware Proxy, Model Armor und semantische Governance-Richtlinien oder an eine beliebige benutzerdefinierte Autorisierungs-Engine delegieren.

In Autorisierungsrichtlinien werden Richtlinienprofile verwendet, um den Typ der Trafficdaten zu bestimmen, die an die Autorisierungserweiterung gesendet werden:

• Anfragebasierte Autorisierung (REQUEST_AUTHZ): HTTP-Anfrageheader werden ausgewertet, bevor eine Anwendungsnutzlast verarbeitet wird. Dieses Profil wird zur Identitätsüberprüfung und Zugriffssteuerung verwendet, z. B. zum Delegieren der Autorisierung an Identity-Aware Proxy.
• Inhaltsbasierte Autorisierung (CONTENT_AUTHZ): Hier werden die vollständigen HTTP-Anfrage- und Antwortnutzlasten ausgewertet. Dieses Profil wird für die detaillierte Inhaltsprüfung und KI-Sicherheit verwendet, z. B. für die Delegierung an Model Armor für die Prompt- und Antwortsicherheit oder an semantische Governance-Richtlinien für die Durchsetzung von Einschränkungen in natürlicher Sprache.

Benutzerdefinierte Autorisierungs-Engines können je nachdem, ob sie Header oder vollständige Anwendungsnutzlasten prüfen, entweder REQUEST_AUTHZ- oder CONTENT_AUTHZ-Erweiterungen verwenden.

Sie können Autorisierungserweiterungen separat für anfragebasierte und inhaltsbasierte Richtlinien konfigurieren oder beide auf einem Gateway für umfassende Sicherheit kombinieren. Empfohlene Konfigurationen finden Sie unter Empfohlene Konfiguration für eingehenden und ausgehenden Traffic.

Weitere Informationen zu Autorisierungsrichtlinien, Richtlinienprofilen und ihren Anwendungsfällen finden Sie unter Autorisierungsrichtlinien – Übersicht.

Empfohlene Konfiguration für ein- und ausgehenden Traffic

Für umfassende Sicherheit über den gesamten Lebenszyklus von KI-Agenten hinweg empfehlen wir das folgende Architekturmuster mit mehreren Gateways:

• Client-to-Agent-Gateways:Client-to-Agent-Gateways (eingehend) unterstützen nur eine einzelne CONTENT_AUTHZ-Richtlinie. Das bedeutet, dass Sie Model Armor und Richtlinien zur semantischen Governance nicht gleichzeitig für eingehende Anfragen verwenden können. Wir empfehlen dringend, eine Model Armor-CONTENT_AUTHZ-Richtlinie zu verwenden, um sich vor Prompt-Injection-Angriffen zu schützen. Wenn Sie stattdessen eine Erweiterung für semantische Governance-Richtlinien verwenden möchten, muss Model Armor auf dem Gateway deaktiviert sein. Andere Arten von Dienst-Extensions werden für Ingress-Gateways nicht unterstützt.

• Agent-to-Anywhere-Gateways:Agent-to-Anywhere-Gateways (ausgehender Traffic) unterstützen bis zu vier Autorisierungsrichtlinien. Egress-Gateways unterstützen sowohl REQUEST_AUTHZ- als auch CONTENT_AUTHZ-Richtlinienprofile. Sie können mehrere Richtlinien jedes Typs innerhalb dieses Limits konfigurieren.

  Wir empfehlen die folgende Konfiguration:

  • Eine REQUEST_AUTHZ-Richtlinie, die Identity-Aware Proxy (IAP) delegiert, um die Identität des Agents zu autorisieren.
  • Eine oder mehrere CONTENT_AUTHZ-Richtlinien, die weitere Entscheidungen an Model Armor oder semantische Governance-Richtlinien delegieren, um vor Datenpannen zu schützen und Einschränkungen in natürlicher Sprache für ausgehende Tool-Aufrufe und Antworten zu erzwingen.

  Weitere Informationen zur Auswertung von Richtlinien finden Sie unter Richtlinienauswertung bei ausgehendem Traffic.

Diese Multi-Gateway-Topologie sorgt dafür, dass Model Armor eingehende Prompts prüft, während IAP-, Model Armor- und Richtlinien zur semantischen Governance ausgehende Antworten prüfen.

Richtlinienbewertung für ausgehenden Traffic

Wenn in einem Egress-Gateway mehrere Autorisierungsrichtlinien konfiguriert sind, werden sie sequenziell entsprechend ihrem Richtlinienprofiltyp ausgewertet:

1. REQUEST_AUTHZ-Richtlinien (headerbasiert): Diese Richtlinientypen werden zuerst ausgewertet. Eine IAP-Erweiterung prüft beispielsweise die mTLS-Identität des aufrufenden Agents und validiert seine IAM-Zulassungsrichtlinien, bevor Inhalte verarbeitet werden. Wenn die Anfrage diese Prüfung nicht besteht, wird sie sofort abgelehnt.
2. CONTENT_AUTHZ-Richtlinien (inhaltsbasiert): Diese Richtlinientypen werden als Nächstes ausgewertet. Wenn die Anfrage die headerbasierte Prüfung besteht, wird die Nutzlast an die inhaltsbasierte Autorisierungserweiterung (z. B. die semantische Richtlinien-Engine) gestreamt, um den Inhalt eingehend zu prüfen und die Compliance zu bewerten.

Hinweis

Prüfen Sie vor Beginn, ob die folgenden Anforderungen erfüllt sind:

• Das Agent Gateway wird bereitgestellt. KI-Agenten-Gateway konfigurieren

• Sie benötigen die IAM-Berechtigung networkservices.agentGateways.use für die bereitgestellte Agent Gateway-Ressource, um Autorisierungsrichtlinien an das Gateway anzuhängen.

Autorisierungsrichtlinien mit Erweiterungen konfigurieren

In diesem Abschnitt erfahren Sie, wie Sie Autorisierungsrichtlinien konfigurieren, mit denen Autorisierungs- und Content-Safety-Entscheidungen an Identity-Aware Proxy, Model Armor und andere benutzerdefinierte Dienste delegiert werden.

Autorisierung an IAP delegieren

Sie können eine Erweiterung für die Anforderungsautorisierung konfigurieren, um Zugriffsentscheidungen für Autorisierungsrichtlinien an IAP zu delegieren.

In den folgenden Schritten wird beschrieben, wie Sie eine Autorisierungserweiterung mit einer Autorisierungsrichtlinie für eine Agent Gateway-Instanz konfigurieren.

1. Vorbereitung: Deaktivieren Sie die Erzwingung für die verwaltete Organisationsrichtlinieneinschränkung Disable binding access policy to resource (constraints/iam.managed.disableAccessPolicyBindings). Standardmäßig ist diese boolesche Einschränkung für neue Organisationen aktiviert. Sie verhindert, dass Sie eine IAM Unified Access-Richtlinie an eine Ressource binden. Weitere Informationen finden Sie unter Richtlinien mit booleschen Regeln aktualisieren.

2. Erstellen Sie die erforderlichen IAM-Richtlinien für ausgehenden Traffic für Ihre KI-Agenten und Tools. Weitere Informationen finden Sie unter IAM-Agent-Richtlinien erstellen.

3. Unter Agenten-Gateway im Agent-to-Anywhere-Modus (Egress) konfigurieren finden Sie Informationen zum Aktivieren von IAP beim Erstellen des Agenten-Gateways (mit dem Parameter Zugriffsberechtigung).

4. Eine Autorisierungserweiterung für IAP konfigurieren

   1. Definieren Sie die Erweiterung in einer YAML-Datei. Verwenden Sie die bereitgestellten Beispielwerte. Wenn Sie die Erweiterung im Probelauf-Modus bereitstellen möchten, um die Autorisierungsrichtlinie zu testen, ohne sie zu erzwingen, können Sie das Feld iamEnforcementMode im Block metadata angeben.

      cat >iap-request-authz-extension.yaml <<EOF
      name: my-iap-request-authz-ext
      service: iap.googleapis.com
      failOpen: false
      timeout: 1s
      metadata:
        iapPolicyVersion: "V2"
      EOF
      

      Wenn Sie die Erweiterung im reinen Audit-Modus bereitstellen möchten, um die Autorisierungsrichtlinie zu testen, ohne sie zu erzwingen, können Sie das Feld iamEnforcementMode im Block metadata angeben. So können Sie Ihre Richtlinie überprüfen und das Risiko von Traffic-Unterbrechungen aufgrund von Konfigurationsfehlern minimieren:

      cat >iap-request-authz-extension.yaml <<EOF
      name: my-iap-request-authz-ext
      service: iap.googleapis.com
      failOpen: false
      timeout: 1s
      metadata:
        iapPolicyVersion: "V2"
        iamEnforcementMode: "DRY_RUN"
      EOF
      

      Entfernen Sie das Feld „iamEnforcementMode: "DRY_RUN"“ aus dem Block „metadata“, wenn Sie bereit sind, Richtlinien zu erzwingen.

   2. Importieren Sie die Autorisierungserweiterung. Verwenden Sie den Befehl gcloud service-extensions authz-extensions import mit den folgenden Beispielwerten.

      gcloud service-extensions authz-extensions import my-iap-request-authz-ext \
          --source=iap-request-authz-extension.yaml \
          --location=LOCATION
      

5. Konfigurieren Sie im selben Projekt eine Autorisierungsrichtlinie, die die Entscheidung an die Erweiterung delegiert.

   1. Definieren Sie eine Autorisierungsrichtlinie, die die Erweiterung my-iap-request-authz-ext mit Ihrem Gateway verknüpft. Verwenden Sie die bereitgestellten Beispielwerte.

      cat >iap-request-authz-policy.yaml <<EOF
      name: my-iap-request-authz-policy
      target:
        resources:
          - "projects/PROJECT_ID/locations/LOCATION/agentGateways/AGENT_GATEWAY_NAME"
      policyProfile: REQUEST_AUTHZ
      action: CUSTOM
      customProvider:
        authzExtension:
          resources:
            - "projects/PROJECT_ID/locations/LOCATION/authzExtensions/my-iap-request-authz-ext"
      EOF
      

      Ersetzen Sie dabei PROJECT_ID durch Ihre Projekt-ID.

   2. Importieren Sie die Autorisierungsrichtlinie in das Projekt. Verwenden Sie den Befehl gcloud network-security authz-policies import mit den folgenden Beispielwerten.

      gcloud network-security authz-policies import my-iap-request-authz-policy \
          --source=iap-request-authz-policy.yaml \
          --location=LOCATION
      

Autorisierung an Model Armor delegieren

Sie können eine Autorisierungserweiterung konfigurieren, um Entscheidungen zur Inhaltssicherheit für Autorisierungsrichtlinien an Model Armor zu delegieren.

Im folgenden Beispiel wird gezeigt, wie Sie eine solche Autorisierungserweiterung mit einer Autorisierungsrichtlinie für Agent Gateway konfigurieren.

Autorisierung an benutzerdefinierte Autorisierungserweiterungen delegieren

Sie können benutzerdefinierte Autorisierungserweiterungen konfigurieren, um Entscheidungen an benutzerdefinierte Dienste zu delegieren. Diese benutzerdefinierten Erweiterungen können nur auf voll qualifizierte Domainnamen (FQDNs) ausgerichtet werden.

Wenn Sie FQDN-Ziele verwenden, verwendet die Erweiterung das HTTP2-Protokoll mit TLS-Verschlüsselung für die Kommunikation mit Endpunkten auf Port 443. Das Serverzertifikat wird von der Erweiterung jedoch nicht validiert. Aus Sicherheitsgründen müssen Sie daher dafür sorgen, dass sich die aufgelösten Endpunkte im VPC-Netzwerk befinden. Achten Sie außerdem darauf, dass DNS-Peering zwischen dem Agent Gateway-Projekt und Ihrem VPC-Netzwerk eingerichtet ist.

1. Wenn Sie eine Autorisierungserweiterung mit einer Autorisierungsrichtlinie für einen bestimmten FQDN wie mycustomauthz.internal.net konfigurieren möchten, geben Sie ihn in der YAML-Datei der Erweiterung als Wert für service an, wie im folgenden Beispiel gezeigt. In diesem Beispiel wird davon ausgegangen, dass Sie einen Server in Ihrem VPC-Netzwerk bereitgestellt haben, der das ext_proc-Protokoll im FULL_DUPLEX_STREAMED-Body-Verarbeitungsmodus implementiert.

   cat >custom-authz-extension.yaml <<EOF
   name: my-custom-authz-ext
   service: mycustomauthz.internal.net
   failOpen: false
   timeout: 1s
   EOF
   

2. Erstellen Sie die Autorisierungserweiterung, die auf den benutzerdefinierten Dienst verweist.

   gcloud beta service-extensions authz-extensions import custom-authz-extension \
     --source=custom-authz-extension.yaml \
     --location=LOCATION
   

3. Nachdem Sie die Erweiterung erstellt haben, konfigurieren Sie eine CUSTOM-Autorisierungsrichtlinie, die Entscheidungen an die Autorisierungserweiterung delegiert.

     cat >authz-policy.yaml <<EOF
     name: authz-with-extension
     target:
       resources:
         - "projects/PROJECT_ID/locations/LOCATION/agentGateways/AGENT_GATEWAY_NAME"
     policyProfile: CONTENT_AUTHZ
     action: CUSTOM
     customProvider:
       authzExtension:
         resources:
           - "projects/PROJECT_ID/locations/LOCATION/authzExtensions/custom-authz-extension"
     EOF
   

4. Erstellen Sie die Autorisierungsrichtlinie.

   gcloud network-security authz-policies import authz-policy-with-extension \
   --source=authz-policy.yaml \
   --location=LOCATION
   

Wenn eine Autorisierungserweiterung mit einer Autorisierungsrichtlinie über das CONTENT_AUTHZ-Profil verknüpft ist, wie in diesem Beispiel gezeigt, ruft das Gateway die Erweiterung für Anfrage- und Antwortnutzlasten (Header und Textkörper) auf. So können Sie eine detaillierte Inhaltsprüfung, Aufforderungs-Guardrails und Datenbereinigung für Ihren Agent-Traffic durchführen. Standardmäßig verwenden CONTENT_AUTHZ-Richtlinien das Envoy-Protokoll ext_proc im Modus FULL_DUPLEX_STREAMED, um Body-Ereignisse zu verarbeiten.

IAP-Autorisierung mit Model Armor-Schutzmaßnahmen kombinieren

Für umfassende Sicherheit empfehlen wir, eine CUSTOM-Autorisierungsrichtlinie mit einem REQUEST_AUTHZ-Richtlinienprofil und eine weitere CUSTOM-Autorisierungsrichtlinie mit einem CONTENT_AUTHZ-Richtlinienprofil einzurichten.

Im folgenden Beispiel wird IAP als zentrales System zur Autorisierung von Anfragen und Model Armor für KI-Schutzmaßnahmen verwendet. Wie in den vorherigen Beispielen gezeigt, können Sie jede dieser Optionen durch Dienstextensions ersetzen, um Ihre eigenen benutzerdefinierten Lösungen zu verwenden.

1. Konfigurieren Sie eine REQUEST_AUTHZ-Autorisierungserweiterung, die an IAP delegiert, und eine Autorisierungsrichtlinie, die auf die Erweiterung verweist.

   1. Autorisierungserweiterung definieren Das Feld iapPolicyVersion unter metadata ist ein Pflichtfeld.

      cat >iap-extension.yaml <<EOF
      name: iap-extension
      service: iap.googleapis.com
      failOpen: false
      timeout: 1s
      metadata:
        iapPolicyVersion: "V2"
      EOF
      

   2. Erstellen Sie die Autorisierungserweiterung.

      gcloud service-extensions authz-extensions import iap-extension \
      --source=iap-extension.yaml \
      --location=LOCATION
      

      Ersetzen Sie LOCATION durch die Region der Erweiterung.

   3. Konfigurieren Sie die REQUEST_AUTHZ-Autorisierungsrichtlinie, die an die Erweiterung delegiert wird.

      cat >authz-policy-request-authz.yaml <<EOF
      name: authz-iap
      target:
        resources:
        - "projects/PROJECT_ID/locations/LOCATION/agentGateways/AGENT_GATEWAY_NAME"
      policyProfile: REQUEST_AUTHZ
      action: CUSTOM
      customProvider:
        authzExtension:
          resources:
          - "projects/PROJECT_ID/locations/LOCATION/authzExtensions/iap-extension"
      EOF
      

      Ersetzen Sie Folgendes:

      • PROJECT_ID: Ihre Projekt-ID.
      • LOCATION: Der Speicherort der Ressourcen.
      • AGENT_GATEWAY_NAME: Der Name des Agent-Gateways.

   4. Erstellen Sie die Autorisierungsrichtlinie.

      gcloud network-security authz-policies import authz-iap \
      --source=authz-policy-request-authz.yaml \
      --location=LOCATION
      

2. Konfigurieren Sie eine CONTENT_AUTHZ-Autorisierungserweiterung, die an Model Armor delegiert, und eine Autorisierungsrichtlinie, die auf die Erweiterung verweist.

   1. Definieren Sie die Erweiterung.

      cat >ma-extension-file.yaml <<EOF
      name: ma-extension
      service: modelarmor.LOCATION.rep.googleapis.com
      metadata:
        model_armor_settings: '[
          {
          "response_template_id": "projects/MODEL_ARMOR_PROJECT_ID/locations/LOCATION/templates/RESPONSE_TEMPLATE_ID",
          "request_template_id": "projects/MODEL_ARMOR_PROJECT_ID/locations/LOCATION/templates/REQUEST_TEMPLATE_ID"
          }
        ]'
      failOpen: false
      timeout: 1s
      EOF
      

      Ersetzen Sie Folgendes:

      • LOCATION: Die Region, in der sich Ihre Model Armor-Vorlagen befinden.
      • MODEL_ARMOR_PROJECT_ID: Die Projekt-ID, die die Model Armor-Vorlagen enthält.
      • RESPONSE_TEMPLATE_ID: Die ID der Antwortvorlage.
      • REQUEST_TEMPLATE_ID: Die ID der Anfrageschablone.

   2. Erstellen Sie die Autorisierungserweiterung.

      gcloud service-extensions authz-extensions import ma-extension \
      --source=ma-extension-file.yaml \
      --location=LOCATION
      

   3. Konfigurieren Sie die CONTENT_AUTHZ-Autorisierungsrichtlinie, die an die Erweiterung delegiert wird.

      cat >authz-policy-content-authz.yaml <<EOF
      name: authz-ma
      target:
        resources:
        - "projects/PROJECT_ID/locations/LOCATION/agentGateways/AGENT_GATEWAY_NAME"
      policyProfile: CONTENT_AUTHZ
      action: CUSTOM
      customProvider:
        authzExtension:
          resources:
          - "projects/PROJECT_ID/locations/LOCATION/authzExtensions/ma-extension"
      EOF
      

   4. Erstellen Sie die Autorisierungsrichtlinie.

      gcloud network-security authz-policies import ma-authz-policy \
      --source=authz-policy-content-authz.yaml \
      --location=LOCATION
      

Wenn eine Autorisierungserweiterung mit einem CONTENT_AUTHZ-Profil verknüpft ist, empfängt sie alle ext_proc-Ereignisse, einschließlich Anfrage- und Antwortheadern, Text und Trailern. Wenn Ihre auf ext_proc basierende Autorisierungserweiterung sowohl die Autorisierung zur Anfragezeit als auch die inhaltsbasierte Autorisierung verarbeiten kann, empfehlen wir, eine einzelne CUSTOM-Autorisierungsrichtlinie mit dem Richtlinienprofil CONTENT_AUTHZ zu konfigurieren. Diese Richtlinie sollte auf Ihre vielseitige Autorisierungserweiterung verweisen. Dieser Ansatz ermöglicht beide Arten der Autorisierung über eine einzelne Erweiterung und ext_proc-Verbindung, was die Latenzprofile verbessern kann.

Autorisierung an Richtlinien für die semantische Governance delegieren

Sie können eine Autorisierungserweiterung konfigurieren, um Entscheidungen zu Intent-Gating und Einschränkungen in natürlicher Sprache für Autorisierungsrichtlinien an die Richtlinien-Engine für semantische Governance (semanticGovernancePolicyEngine) zu delegieren.

Informationen zum Bereitstellen der Richtlinien-Engine und zum Erstellen der erforderlichen CONTENT_AUTHZ-Autorisierungsrichtlinie und der Bindung der Autorisierungserweiterung auf Ihrem Gateway finden Sie unter Richtlinien-Engine mit Agent Gateway verbinden.

Autorisierung basierend auf MCP-Protokollattributen

Agent Gateway parst die MCP-Protokollnutzlast in einer Anfrage und stellt die extrahierten Attribute für Autorisierungsrichtlinien zur Verfügung.

Sie können den Zugriff anhand von MCP-Methodenparametern wie den Namen bestimmter Tools einschränken. In diesem Abschnitt finden Sie zwei Beispiele, eines für eine ALLOW-Richtlinie und eines für DENY.

1. Autorisierungsrichtlinie konfigurieren

   ALLOW-Richtlinienbeispiel

   In diesem Beispiel wird der Zugriff auf eine bestimmte Gruppe von Tools auf dem MCP-Server und auf die Funktionen des Basisprotokolls erlaubt, der Zugriff auf Prompts und Ressourcen jedoch nicht.

   Achten Sie beim Schreiben einer ALLOW-Richtlinie darauf, dass Sie baseProtocolMethodsOption: MATCH_BASE_PROTOCOL_METHODS angeben, damit nicht zugriffsspezifische MCP-RPCs wie „initialize“, „logging“, „completion“, „notifications“ und „ping“ weiterhin funktionieren. Andernfalls kann keine MCP-Sitzung hergestellt werden.

   cat >authz-policy-restrict-tools.yaml <<EOF
   name: my-authz-policy-restrict-tools
   target:
     resources:
     - "projects/PROJECT_ID/locations/LOCATION/agentGateways/AGENT_GATEWAY_NAME"
   policyProfile: REQUEST_AUTHZ
   httpRules:
   - to:
       operations:
       - mcp:
           baseProtocolMethodsOption: MATCH_BASE_PROTOCOL_METHODS
           methods:
           - name: "tools/list"
           - name: "tools/call"
             params:
             - exact: "get_weather"
             - exact: "get_location"
   action: ALLOW
   EOF
   

   DENY-Richtlinienbeispiel

   In diesem Beispiel wird der Zugriff auf alle Prompts/ Methoden für einen MCP-Server hinter einem Agent Gateway verboten.

   cat >authz-policy-disallow-prompts.yaml <<EOF
   name: my-authz-policy-disallow-prompts
   target:
     resources:
     - "projects/PROJECT_ID/locations/LOCATION/agentGateways/AGENT_GATEWAY_NAME"
   policyProfile: REQUEST_AUTHZ
   httpRules:
   - to:
       operations:
       - mcp:
           methods:
           - name: "prompts"
   action: DENY
   EOF
   

2. Erstellen Sie die Autorisierungsrichtlinie.

   gcloud network-security authz-policies import AUTHZ_POLICY_NAME \
   --source=AUTH_POLICY_YAML_FILE_PATH \
   --location=LOCATION
   

   Ersetzen Sie Folgendes:

   • AUTHZ_POLICY_NAME: Der Name der Autorisierungsrichtlinie.
   • AUTH_POLICY_YAML_FILE_PATH: Der Pfad zur YAML-Datei der Autorisierungsrichtlinie.
   • LOCATION: Der Speicherort der Ressourcen.

Beschränkungen

Bei der Verwendung von Autorisierungsrichtlinien gelten die folgenden Einschränkungen:

• Die maximale Anzahl von Autorisierungsrichtlinien pro Gateway hängt vom Gateway-Modus ab:

  • Für Agent-to-Anywhere-Gateways (Ausgang) können Sie unabhängig vom Richtlinienprofil (REQUEST_AUTHZ oder CONTENT_AUTHZ) maximal vier Autorisierungsrichtlinien pro Gateway konfigurieren.
  • Für Client-to-Agent-Gateways (Ingress) können Sie maximal eine CONTENT_AUTHZ-Richtlinie konfigurieren.

  Weitere Informationen finden Sie unter Empfohlene Konfiguration für eingehenden und ausgehenden Traffic.

• Wenn Sie benutzerdefinierte Autorisierungserweiterungen mit dem Profil CONTENT_AUTHZ verwenden, müssen diese das ext_proc-Protokoll und den FULL_DUPLEX_STREAMED-Modus für Körperereignisse unterstützen.

• Wenn Sie mehrere benutzerdefinierte Autorisierungsrichtlinien konfigurieren, die dasselbe Profil verwenden, ist die Ausführungsreihenfolge nicht garantiert.

Weitere Informationen zu den Einschränkungen von Autorisierungserweiterungen finden Sie in den folgenden Abschnitten:

• Einschränkungen, die für alle Erweiterungen gelten, finden Sie unter Einschränkungen von Erweiterungen.

• Informationen zu Einschränkungen, die für Callouts gelten, finden Sie unter Einschränkungen von Callouts.

Nächste Schritte