Configurer des règles d'autorisation pour Secure Web Proxy

Cette page explique comment configurer des règles d'autorisation pour Secure Web Proxy.

Avant de commencer

Créer une règle d'autorisation

Vous pouvez configurer des règles d'autorisation pour deux cas d'utilisation distincts :

  • Gérer le trafic agentif : pour sécuriser le trafic sortant des agents IA vers les serveurs, outils et modèles Model Context Protocol (MCP), consultez Configurer des règles d'autorisation pour les destinations agentives. Vous pouvez configurer des règles et des liaisons d'extension sur la ressource agentGateway pour appliquer des restrictions d'outils MCP, des identités d'agent mTLS et le nettoyage de la charge utile.

  • Sécuriser le trafic Web non agentique : pour sécuriser le trafic Web sortant des charges de travail d'entreprise non agentiques, consultez les exemples des sections suivantes. Vous pouvez configurer des règles directement sur la ressource Secure Web Proxy Gateway pour appliquer des identités de certificat client mTLS, des comptes de service, des tags sécurisés ou des extensions d'autorisation personnalisées.

Pour créer une stratégie d'autorisation pour Secure Web Proxy, procédez comme suit :

Configurer des règles d'autorisation pour les destinations d'agent

Lorsque vous déployez Secure Web Proxy en tant qu'Agent Gateway, vous pouvez définir des stratégies d'autorisation pour inspecter et limiter le trafic dirigé vers les serveurs d'outils MCP et les destinations des agents IA.

Vous pouvez configurer des règles qui appliquent le contrôle des accès aux couches de requête suivantes :

  • Règles de réseau : ignorez l'inspection TLS ou l'analyse approfondie de la charge utile pour des points de terminaison de modèles ou d'agents externes de confiance spécifiques.

  • Liaisons d'extension : utilisez les ressources ExtensionBinding dans Service Extensions pour associer des processeurs de gouvernance et de sécurité externes, tels qu'Identity-Aware Proxy (IAP) pour la validation de l'identité des agents et Model Armor pour l'assainissement des prompts et des réponses.

  • Filtrage des méthodes et des outils MCP HTTP : appliquez des contrôles précis sur des actions MCP spécifiques, telles que tools/list ou tools/call, et validez les arguments pour limiter les outils qu'un agent peut appeler.

Ordre d'évaluation des règles d'autorisation

Lors du traitement du trafic sortant de l'agent IA via une Agent Gateway, les règles sont évaluées dans l'ordre suivant :

  1. Règles d'autorisation réseau (L4) : évaluées en premier. Si une règle de correspondance SNI s'applique, par exemple pour autoriser la communication directe avec un point de terminaison de modèle externe, le trafic contourne l'interception TLS.

  2. Interception TLS : le trafic qui n'est pas contourné est ensuite intercepté et déchiffré à l'aide de la règle d'inspection TLS de la passerelle.

  3. Règles de liaison d'extension : les requêtes sont évaluées par des services d'extension configurés, tels qu'IAP, pour vérifier l'identité de l'appelant dans les en-têtes de requête, et Model Armor, pour inspecter les charges utiles déchiffrées afin de garantir la sécurité des requêtes et d'éviter les fuites de données sensibles dans les réponses.

  4. Règles d'autorisation HTTP (L7) : les règles d'autorisation au niveau HTTP, telles que les restrictions d'outils MCP et le filtrage des méthodes, sont évaluées.

Exemple 1 : Restreindre l'exécution des outils MCP

L'exemple suivant montre une règle d'autorisation associée à une ressource agentGateway qui permet aux agents de découvrir des outils (tools/list) et d'exécuter uniquement les outils approuvés (tools/call pour get_weather et get_location) :

  1. Créez un fichier nommé authz-policy-mcp.yaml.

    name: 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

    Remplacez les éléments suivants :

    • PROJECT_ID : ID de votre projet Google Cloud
    • LOCATION : région où vos instances Agent Gateway et Secure Web Proxy sont déployées
    • AGENT_GATEWAY_NAME : nom de la ressource agentGateway associée à votre passerelle Secure Web Proxy.

  2. Pour importer la stratégie d'autorisation, exécutez la commande gcloud network-security authz-policies import.

    gcloud network-security authz-policies import authz-policy-restrict-tools \
    --source=authz-policy-mcp.yaml \
    --location=LOCATION

Exemple 2 : Contourner l'interception TLS à l'aide de la correspondance SNI

Si certains fournisseurs de modèles externes ou API d'agents utilisent l'épinglage de certificat ou ne nécessitent pas d'inspection de la charge utile, vous pouvez utiliser des règles réseau pour faire correspondre l'indication du nom du serveur (SNI) et autoriser la connexion sans déchiffrer la session.

  1. Créez un fichier nommé authz-policy-sni.yaml.

    name: authz-policy-skip-interception
target:
  resources:
  - "projects/PROJECT_ID/locations/LOCATION/agentGateways/AGENT_GATEWAY_NAME"
policyProfile: REQUEST_AUTHZ
networkRules:
- to:
    operations:
    - snis:
      - exact: "api.example-model-provider.com"
action: ALLOW

    Remplacez les éléments suivants :

    • PROJECT_ID : ID de votre projet Google Cloud
    • LOCATION : région où vos instances Agent Gateway et Secure Web Proxy sont déployées
    • AGENT_GATEWAY_NAME : nom de la ressource agentGateway associée à votre passerelle Secure Web Proxy.

  2. Pour importer la stratégie d'autorisation, exécutez la commande gcloud network-security authz-policies import.

    gcloud network-security authz-policies import authz-policy-skip-interception \
    --source=authz-policy-sni.yaml \
    --location=LOCATION

Exemple 3 : Activer l'inspection approfondie de la charge utile avec Model Armor à l'aide de liaisons d'extension

Pour vous protéger contre l'injection de prompt, les sorties toxiques ou les fuites de données sensibles, vous pouvez décharger le traitement du trafic vers Model Armor ou un processeur ext_proc personnalisé à l'aide de liaisons d'extension dans les extensions de service.

Ce modèle sépare le fournisseur d'extension du consommateur de la manière suivante :

  • Services Google (1P) : pour les services Google intégrés, tels que Model Armor et IAP, Google gère l'infrastructure sous-jacente. Vous pouvez lier directement le service à l'aide d'URI de point de terminaison prédéfinis (modelarmor.googleapis.com ou iap.googleapis.com).
  • Extensions personnalisées et partenaires (2P/3P) : pour les processeurs internes personnalisés ou les fournisseurs de sécurité tiers, le producteur publie une ressource ProducerExtension qui pointe vers son rattachement de service Private Service Connect, et le consommateur lie cet URI de ressource.

Pour en savoir plus sur l'évaluation des règles d'autorisation et des extensions sur une ressource agentGateway, consultez Déléguer l'autorisation avec les extensions de service et Règles extensibles sur Agent Gateway.

Pour configurer une liaison d'extension pour Model Armor, procédez comme suit :

  1. Activez l'API Service Extensions.

    gcloud services enable serviceextensions.googleapis.com

  2. Créez un fichier de configuration nommé extension-binding-model-armor.yaml qui cible votre ressource agentGateway, définit vos modèles d'inspection et intercepte le trafic destiné aux serveurs MCP.

    name: ext-binding-model-armor
target:
  resources:
  - "//networkservices.googleapis.com/projects/PROJECT_ID/locations/LOCATION/agentGateways/AGENT_GATEWAY_NAME"
failOpen: false
producerExtension: modelarmor.googleapis.com
producerMetadata:
  model_armor_settings: '[
    {
      "request_template_id": "projects/TEMPLATE_PROJECT_ID/locations/LOCATION/templates/REQUEST_TEMPLATE_ID",
      "response_template_id": "projects/TEMPLATE_PROJECT_ID/locations/LOCATION/templates/RESPONSE_TEMPLATE_ID"
    }
  ]'
matchConditions:
- to:
    destination:
      resources:
      - prefix: "urn:mcp"

    Remplacez les éléments suivants :

    • PROJECT_ID : ID de votre projet Google Cloud
    • LOCATION : région où vos instances Agent Gateway et Secure Web Proxy sont déployées
    • AGENT_GATEWAY_NAME : nom de votre ressource agentGateway
    • TEMPLATE_PROJECT_ID : ID du projet dans lequel vos modèles Model Armor sont créés
    • REQUEST_TEMPLATE_ID : ID du modèle utilisé pour inspecter les requêtes entrantes
    • RESPONSE_TEMPLATE_ID : ID du modèle utilisé pour inspecter les réponses sortantes

    Remarque :

    • failOpen: false bloque le trafic si le service d'extension n'est pas accessible. Pour autoriser le trafic à passer sans inspection lors d'interruptions de service, définissez failOpen: true.
    • Pour lier une extension interne ou tierce personnalisée au lieu de Model Armor, définissez producerExtension sur le chemin d'accès à la ressource du producteur au format suivant : projects/PRODUCER_PROJECT_ID/locations/LOCATION/producerExtensions/PRODUCER_EXTENSION_NAME.

  3. Pour importer la liaison d'extension, exécutez la commande gcloud beta service-extensions extension-bindings import.

    gcloud beta service-extensions extension-bindings import ext-binding-model-armor \
    --source=extension-binding-model-armor.yaml \
    --location=LOCATION

Pour en savoir plus sur la liaison d'IAP pour la validation de l'identité, consultez Associer des liaisons d'extension à Agent Gateway.

Règle d'autorisation basée sur l'identité mTLS

Secure Web Proxy permet d'appliquer des règles de sécurité basées sur des identités dérivées de certificats TLS mutuels (mTLS). L'application de règles basées sur ces identités est particulièrement utile dans les environnements de confiance zéro, où le trafic entre les clients et le proxy est sécurisé par mTLS. Pour en savoir plus, consultez Stratégie d'autorisation basée sur les comptes principaux.

L'exemple suivant montre une stratégie d'autorisation pour une instance Secure Web Proxy nommée swp1. Cet exemple suppose que le trafic vers le proxy utilise le protocole HTTPS.

La règle avec le profil REQUEST_AUTHZ applique l'authentification mTLS à partir d'un compte principal spécifique pour tout le trafic vers example.com/mcp avant que le trafic ne soit autorisé à passer. La règle refuse également tout le trafic sortant qui n'est pas destiné à example.com/mcp.

  1. Créez le fichier YAML de la règle d'autorisation.

    L'exemple suivant crée un fichier authz-policy.yaml. La règle n'autorise le trafic vers l'hôte et le chemin d'accès spécifiés que si le client présente un certificat correspondant au compte principal SPIFFE ID défini.

    $ cat >authz-policy.yaml <<EOF
name: test-authz-policy-mtls
target:
  resources:
  - "projects/ PROJECT_ID /locations/ LOCATION /gateways/swp1"
policyProfile: REQUEST_AUTHZ
httpRules:
- to:
  operations:
  - hosts:
      - exact: "example.com"
    paths:
      - exact: "/mcp"
  from:
    sources:
    - principals:
      - principalSelector: CLIENT_CERT_URI_SAN
        principal:
          exact: "spiffe:// PROJECT_ID .global.123.workload.id.goog/ns/ns1/sa/hellomcp"
action: ALLOW
EOF

    Remplacez les éléments suivants :

    • PROJECT_ID : ID de votre projet Google Cloud
    • LOCATION : région de votre instance Secure Web Proxy

  2. Créez une règle d'autorisation et importez le fichier YAML à l'aide de la commande gcloud network-security authz-policies import.

    gcloud beta network-security authz-policies import my-authz-policy-allow
    --source=authz-policy.yaml
    --location= LOCATION

    Remplacez LOCATION par la région de votre instance Secure Web Proxy.

Règle d'autorisation basée sur des comptes de service ou des tags

Vous pouvez appliquer une stratégie d'autorisation basée sur des comptes de service ou des tags associés à différentes ressources Google Cloud .

Cet exemple suppose que vous avez effectué les opérations suivantes :

Compte de service

  1. Créez un fichier YAML de règle d'autorisation pour autoriser certaines requêtes.

    L'exemple suivant crée un fichier authz-policy.yaml pour l'instance Secure Web Proxy nommée swp1. La stratégie est configurée pour autoriser les requêtes provenant d'une instance de machine virtuelle (VM) Compute Engine avec le compte de service my-sa-123@56788. à atteindre le chemin d'accès example1.com/url1.

    $ cat >authz-policy.yaml <<EOF
name: my-authz-policy-allow
target:
    resources:
    - "projects/PROJECT_ID/locations/ LOCATION /gateways/swp1"
policyProfile: REQUEST_AUTHZ
httpRules:
- from:
    sources:
        - resources:
            - iamServiceAccount:
                exact: "my-sa-123@56788."
  to:
    operations:
    - hosts:
        - exact: "example1.com"
    paths:
    - prefix: "/url1"
action: ALLOW
EOF

    Remplacez les éléments suivants :

    • PROJECT_ID : ID de votre projet Google Cloud
    • LOCATION : région de votre instance Secure Web Proxy

  2. Créez une règle d'autorisation et importez le fichier YAML à l'aide de la commande gcloud network-security authz-policies import.

    L'exemple de commande suivant montre comment importer le fichier de stratégie créé précédemment et créer une stratégie d'autorisation :

    gcloud network-security authz-policies import my-authz-policy-allow

    --source=authz-policy.yaml
    --location= LOCATION

    Remplacez LOCATION par la région de votre instance Secure Web Proxy.

Tag

  1. Créez un fichier YAML de règle d'autorisation pour autoriser certaines requêtes.

    L'exemple suivant crée un fichier authz-policy-tag.yaml pour l'instance Secure Web Proxy nommée swp1. La règle n'autorise que les requêtes provenant d'une ressource Google Cloudavec une valeur de tag TAG_VALUE_PERMANENT_ID à accéder au chemin d'URL example1.com/url1.

    $ cat >authz-policy-tag.yaml <<EOF
name: my-authz-policy-tag-allow
target:
    resources:
    - "projects/PROJECT_ID/locations/ LOCATION /gateways/ GATEWAY_NAME "
policyProfile: REQUEST_AUTHZ
httpRules:
- from:
    sources:
    - resources:
        - tagValueIdSet:
            ids: ["TAG_VALUE_PERMANENT_ID"]
  to:
    operations:
    - hosts:
        - exact: "example1.com"
        paths:
        - exact: "/url1"
action: ALLOW
EOF

    Remplacez les éléments suivants :

    • PROJECT_ID : ID de votre projet Google Cloud
    • LOCATION : région de votre instance Secure Web Proxy
    • GATEWAY_NAME : nom de votre passerelle Secure Web Proxy
    • TAG_VALUE_PERMANENT_ID : ID permanent d'une valeur de tag, par exemple tagValues/123456789012

  2. Créez une règle d'autorisation et importez le fichier YAML à l'aide de la commande gcloud network-security authz-policies import.

    L'exemple de commande suivant importe le fichier de stratégie créé précédemment et crée une stratégie d'autorisation dans la région Google Cloud spécifiée :

    gcloud network-security authz-policies import my-authz-policy-tag-allow
    --source=authz-policy-tag.yaml
    --location= LOCATION

    Remplacez LOCATION par la région de votre instance Secure Web Proxy.

Règle d'autorisation pour déléguer les décisions d'autorisation

Pour les décisions d'autorisation complexes qui ne peuvent pas être exprimées à l'aide de règles ALLOW ou DENY standards, vous pouvez créer une règle d'autorisation avec une action CUSTOM. Vous pouvez ensuite déléguer vos décisions d'autorisation à des extensions d'autorisation (Service Extensions).

Lorsque vous configurez une stratégie avec une action CUSTOM, Secure Web Proxy transfère les métadonnées ou la charge utile de la requête vers Service Extensions. En fonction de la réponse de Service Extensions, le proxy autorise ou refuse le trafic.

Secure Web Proxy est compatible avec les types de délégations suivants :

  • Déléguer les décisions d'autorisation de requête aux extensions de service : vous pouvez utiliser une stratégie d'autorisation configurée avec une action CUSTOM et un profil REQUEST_AUTHZ pour déléguer les décisions en fonction des métadonnées et des en-têtes de requête. Dans ce mode, la décision d'accès est déléguée à une extension d'autorisation. Vous pouvez utiliser ce mode pour vérifier les identités et les autorisations.

  • Déléguer les décisions d'autorisation de contenu aux extensions de service : vous pouvez utiliser une règle d'autorisation avec une action CUSTOM et un profil CONTENT_AUTHZ pour déléguer les décisions à une extension d'autorisation en fonction de la charge utile de données réelle de la requête. Ce mode vous permet d'activer l'inspection approfondie du contenu et l'application de la sécurité, ce qui vous permet de rechercher des informations sensibles ou des schémas malveillants en l'intégrant à des services tels que Model Armor.

Limites

Lorsque vous implémentez des règles d'autorisation pour Secure Web Proxy, les limites suivantes s'appliquent :

  • Contraintes de cible et de connectivité : les extensions d'autorisation pour Secure Web Proxy ne sont pas compatibles avec IAP en tant que cible directe.

  • Conflit et compatibilité des stratégies : si vous disposez d'une stratégie de sécurité de passerelle avec des règles de sécurité existantes, vous n'avez pas besoin de les supprimer. Secure Web Proxy ignore ces règles lorsque vous appliquez une stratégie d'autorisation à votre instance.

  • Exigences concernant le protocole et l'inspection : pour configurer des règles d'autorisation Secure Web Proxy, vous devez activer l'inspection TLS.

Étapes suivantes