Configurar políticas de autorização para o Secure Web Proxy

Nesta página, descrevemos como configurar políticas de autorização para o Secure Web Proxy.

Antes de começar

Criar uma política de autorização

É possível configurar políticas de autorização para dois casos de uso distintos:

  • Controlar o tráfego agêntico: para proteger o tráfego de saída de agentes de IA para servidores, ferramentas e modelos do Protocolo de Contexto de Modelo (MCP), consulte Configurar políticas de autorização para destinos agênticos. É possível configurar políticas e vinculações de extensão no recurso agentGateway para aplicar restrições de ferramentas do MCP, identidades de agentes mTLS e limpeza de payload.

  • Proteger o tráfego da Web não agêntico: para proteger o tráfego de saída da Web de cargas de trabalho corporativas não agênticas, consulte os exemplos nas seções a seguir. É possível configurar políticas diretamente no recurso Gateway do Secure Web Proxy para aplicar identidades de certificado do cliente mTLS, contas de serviço, tags seguras ou extensões de autorização personalizadas.

Para criar uma política de autorização para o Secure Web Proxy, faça o seguinte:

Configurar políticas de autorização para destinos de agentes

Ao implantar o Secure Web Proxy como um Gateway de Agente, é possível definir políticas de autorização para inspecionar e restringir o tráfego direcionado aos servidores de ferramentas do MCP e aos destinos de agentes de IA.

É possível configurar regras que aplicam o controle de acesso nas seguintes camadas de solicitação:

  • Regras de rede: pule a inspeção de TLS ou a análise profunda de payload para endpoints de modelos ou Agent Endpoints externos confiáveis específicos.

  • Vinculações de extensão: use recursos ExtensionBinding nas Service Extensions para anexar processadores externos de governança e segurança, como o Identity-Aware Proxy (IAP) para confirmação de identidade do agente e o Model Armor para limpeza de comandos e respostas.

  • Filtragem de métodos e ferramentas HTTP do MCP: aplique controles detalhados sobre ações específicas do MCP, como tools/list ou tools/call, e valide argumentos para restringir as ferramentas que um agente pode invocar.

Ordem de avaliação das regras de autorização

Ao processar o tráfego de saída do agente de IA por um Gateway de Agente, as regras são avaliadas na seguinte sequência:

  1. Regras de autorização de rede (L4): avaliadas primeiro. Se uma regra de correspondência de SNI for aplicada, como permitir a comunicação direta com um endpoint de modelo externo, o tráfego vai ignorar a interceptação de TLS.

  2. Intercepção de TLS: o tráfego que não é ignorado é interceptado e descriptografado usando a política de inspeção de TLS do gateway.

  3. Regras de vinculação de extensão: as solicitações são avaliadas por serviços de extensão configurados, como o IAP, para verificar a identidade do autor da chamada nos cabeçalhos da solicitação, e o Model Armor, para inspecionar payloads descriptografados em busca de segurança de comandos e evitar vazamentos de dados sensíveis nas respostas.

  4. Regras de autorização HTTP (L7): as políticas de autorização no nível HTTP, como restrições de ferramentas MCP e filtragem de métodos, são avaliadas.

Exemplo 1: restringir a execução de ferramentas do MCP

O exemplo a seguir mostra uma política de autorização anexada a um recurso agentGateway que permite que os agentes descubram ferramentas (tools/list) e executem apenas ferramentas aprovadas (tools/call para get_weather e get_location):

  1. Crie um arquivo chamado 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

    Substitua:

    • PROJECT_ID: ID do projeto do Google Cloud .
    • LOCATION: região em que as instâncias do Gateway de Agente e do Secure Web Proxy são implantadas
    • AGENT_GATEWAY_NAME: nome do recurso agentGateway associado ao gateway do Secure Web Proxy.

  2. Para importar a política de autorização, execute o comando gcloud network-security authz-policies import.

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

Exemplo 2: ignorar a interceptação de TLS usando a correspondência de SNI

Se determinados provedores de modelos externos ou APIs de agentes usarem fixação de certificado ou não exigirem inspeção de payload, use regras de rede para corresponder à Indicação de Nome do Servidor (SNI) e permitir a conexão sem descriptografar a sessão.

  1. Crie um arquivo chamado 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

    Substitua:

    • PROJECT_ID: ID do projeto do Google Cloud .
    • LOCATION: região em que as instâncias do Gateway de Agente e do Secure Web Proxy são implantadas
    • AGENT_GATEWAY_NAME: nome do recurso agentGateway associado ao gateway do Secure Web Proxy.

  2. Para importar a política de autorização, execute o comando gcloud network-security authz-policies import.

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

Exemplo 3: ativar a inspeção profunda de payload com o Model Armor usando vinculações de extensão

Para se proteger contra injeção de comandos, saída tóxica ou vazamento de dados sensíveis, é possível transferir o processamento de tráfego para o Model Armor ou um processador ext_proc personalizado usando vinculações de extensão em extensões de serviço.

Esse modelo separa o provedor de extensões do consumidor da seguinte maneira:

  • Serviços do Google (1P): para serviços integrados do Google, como o Model Armor e o IAP, o Google gerencia a infraestrutura subjacente. É possível vincular diretamente o serviço usando URIs de endpoint predefinidos (modelarmor.googleapis.com ou iap.googleapis.com).
  • Extensões personalizadas e de parceiros (2P/3P): para processadores internos personalizados ou fornecedores de segurança terceirizados, o produtor publica um recurso ProducerExtension que aponta para o anexo de serviço do Private Service Connect, e o consumidor vincula esse URI de recurso.

Para mais informações sobre como as políticas e extensões de autorização são avaliadas em um recurso agentGateway, consulte Delegar autorização com extensões de serviço e Políticas extensíveis no Gateway de Agente.

Para configurar uma vinculação de extensão para o Model Armor, faça o seguinte:

  1. Ative a API Service Extensions.

    gcloud services enable serviceextensions.googleapis.com

  2. Crie um arquivo de configuração chamado extension-binding-model-armor.yaml que direcione o recurso agentGateway, defina os modelos de inspeção e intercepte o tráfego destinado aos servidores 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"

    Substitua:

    • PROJECT_ID: ID do projeto do Google Cloud .
    • LOCATION: região em que as instâncias do Gateway de Agente e do Secure Web Proxy estão implantadas
    • AGENT_GATEWAY_NAME: nome do recurso agentGateway
    • TEMPLATE_PROJECT_ID: ID do projeto em que os modelos do Model Armor são criados
    • REQUEST_TEMPLATE_ID: ID do modelo usado para inspecionar as solicitações recebidas.
    • RESPONSE_TEMPLATE_ID: ID do modelo usado para inspecionar as respostas enviadas

    Observação:

    • O failOpen: false bloqueia o tráfego se o serviço de extensão não estiver acessível. Para permitir que o tráfego passe sem inspeção durante interrupções de serviço, defina failOpen: true.
    • Para vincular uma extensão interna ou de terceiros personalizada em vez do Model Armor, defina producerExtension como o caminho do recurso do produtor no seguinte formato: projects/PRODUCER_PROJECT_ID/locations/LOCATION/producerExtensions/PRODUCER_EXTENSION_NAME.

  3. Para importar a vinculação de extensão, execute o comando 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

Para mais informações sobre como vincular o IAP para confirmação de identidade, consulte Anexar vinculações de extensão ao Gateway de Agente.

Política de autorização com base na identidade mTLS

O Secure Web Proxy permite aplicar regras de segurança com base em identidades derivadas de certificados de TLS mútuo (mTLS). Aplicar regras com base nessas identidades é especialmente útil em ambientes de confiança zero, em que o tráfego entre os clientes e o proxy é protegido por mTLS. Para mais informações, consulte Política de autorização com base em principais.

O exemplo a seguir mostra uma política de autorização para uma instância do Secure Web Proxy chamada swp1. Neste exemplo, presumimos que o tráfego para o proxy use o protocolo HTTPS.

A política com o perfil REQUEST_AUTHZ exige que todo o tráfego para example.com/mcp exija autenticação mTLS de um principal específico antes que o tráfego seja permitido. A política também nega todo o tráfego de saída que não seja destinado a example.com/mcp.

  1. Crie o arquivo YAML da política de autorização.

    O exemplo a seguir cria um arquivo authz-policy.yaml. A política permite o tráfego para o host e o caminho especificados somente se o cliente apresentar um certificado que corresponda ao principal SPIFFE ID definido.

    $ 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

    Substitua:

    • PROJECT_ID: ID do projeto do Google Cloud .
    • LOCATION: região da instância do Secure Web Proxy

  2. Crie uma política de autorização e importe o arquivo YAML usando o comando gcloud network-security authz-policies import.

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

    Substitua LOCATION pela região da instância do Secure Web Proxy.

Política de autorização com base em contas de serviço ou tags

É possível aplicar uma política de autorização com base em contas de serviço ou tags anexadas a vários recursos do Google Cloud .

Este exemplo pressupõe que você tenha concluído o seguinte:

Conta de serviço

  1. Crie um arquivo YAML de política de autorização para permitir determinadas solicitações.

    O exemplo a seguir cria um arquivo authz-policy.yaml para a instância do Secure Web Proxy chamada swp1. A política é configurada para permitir que as solicitações de uma instância de máquina virtual (VM) do Compute Engine com a conta de serviço my-sa-123@56788. alcancem o caminho 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

    Substitua:

    • PROJECT_ID: ID do projeto do Google Cloud .
    • LOCATION: região da instância do Secure Web Proxy

  2. Crie uma política de autorização e importe o arquivo YAML usando o comando gcloud network-security authz-policies import.

    O comando de exemplo a seguir mostra como importar o arquivo de política criado anteriormente e criar uma política de autorização:

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

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

    Substitua LOCATION pela região da instância do Secure Web Proxy.

Tag

  1. Crie um arquivo YAML de política de autorização para permitir determinadas solicitações.

    O exemplo a seguir cria um arquivo authz-policy-tag.yaml para a instância do Secure Web Proxy chamada swp1. A política permite que apenas as solicitações originadas de um recurso do Google Cloudcom um valor de tag TAG_VALUE_PERMANENT_ID acessem o caminho do 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

    Substitua:

    • PROJECT_ID: ID do projeto do Google Cloud .
    • LOCATION: região da instância do Secure Web Proxy
    • GATEWAY_NAME: nome do gateway do Secure Web Proxy
    • TAG_VALUE_PERMANENT_ID: ID permanente de um valor de tag, como tagValues/123456789012.

  2. Crie uma política de autorização e importe o arquivo YAML usando o comando gcloud network-security authz-policies import.

    O exemplo de comando a seguir importa o arquivo de política criado anteriormente e cria uma política de autorização na região Google Cloud especificada:

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

    Substitua LOCATION pela região da instância do Secure Web Proxy.

Política de autorização para delegar decisões de autorização

Para decisões de autorização complexas que não podem ser expressas usando regras padrão ALLOW ou DENY, é possível criar uma política de autorização com uma ação CUSTOM. Em seguida, é possível delegar as decisões de autorização para extensões de autorização (extensões de serviço).

Quando você configura uma política com uma ação CUSTOM, o Secure Web Proxy transfere os metadados ou o payload da solicitação para as extensões de serviço. Dependendo da resposta das Extensões de Serviço, o proxy permite ou rejeita o tráfego.

O Secure Web Proxy é compatível com os seguintes tipos de delegações:

  • Delegar decisões de autorização de solicitação para as extensões de serviço: é possível usar uma política de autorização configurada com uma ação CUSTOM e um perfil REQUEST_AUTHZ para delegar decisões com base em metadados e cabeçalhos de solicitação. Nesse modo, a decisão de acesso é delegada a uma extensão de autorização. Use esse modo para verificar identidades e permissões.

  • Delegar decisões de autorização de conteúdo para as extensões de serviço: é possível usar uma política de autorização com uma ação CUSTOM e um perfil CONTENT_AUTHZ para delegar decisões a uma extensão de autorização com base no payload de dados real da solicitação. Esse modo permite ativar a inspeção profunda de conteúdo e a aplicação de segurança, permitindo que você verifique informações sensíveis ou padrões maliciosos integrando-se a serviços como o Model Armor.

Limitações

Ao implementar políticas de autorização para o Secure Web Proxy, as seguintes limitações se aplicam:

  • Restrições de destino e conectividade: as extensões de autorização do Secure Web Proxy não são compatíveis com o IAP como destino direto.

  • Conflito e compatibilidade de políticas: se você tiver uma política de segurança de gateway com regras de segurança, não será necessário removê-las. O Secure Web Proxy ignora essas regras quando você aplica uma política de autorização à instância.

  • Requisitos de protocolo e inspeção: para configurar as políticas de autorização do Secure Web Proxy, é necessário ativar a inspeção de TLS.

A seguir