Google utiliza tecnología de IA para traducir contenido a tu idioma preferido. Las traducciones realizadas con IA pueden contener errores.

Configura políticas de autorización para el Proxy web seguro

En esta página, se describe cómo configurar políticas de autorización para Secure Web Proxy.

Antes de comenzar

Revisa las páginas Descripción general del Secure Web Proxy y Descripción general de la política de autorización.
Habilita las siguientes APIs:
- API de seguridad de red
- API de Network Services
- API de Certificate Manager
Asegúrate de tener los roles y permisos adecuados.
Debes tener una instancia activa de Secure Web Proxy implementada y asociada con un GatewaySecurityPolicy. Para obtener más información, consulta Implementa una instancia de Secure Web Proxy.
Para configurar las políticas de autorización de Secure Web Proxy, debes habilitar una política de inspección de TLS.

Crea una política de autorización

Puedes configurar políticas de autorización para dos casos de uso distintos:

Controla el tráfico de agentes: Para proteger el tráfico saliente de los agentes de IA a los servidores, las herramientas y los modelos del Protocolo de contexto del modelo (MCP), consulta Configura políticas de autorización para destinos de agentes. Puedes configurar políticas y vinculaciones de extensiones en el recurso agentGateway para aplicar restricciones de herramientas de MCP, identidades de agentes de mTLS y limpieza de cargas útiles.
Protege el tráfico web no agéntico: Para proteger el tráfico web saliente de las cargas de trabajo empresariales no agénticas, consulta los ejemplos de las siguientes secciones. Puedes configurar políticas directamente en el recurso Gateway de Secure Web Proxy para aplicar de manera forzosa identidades de certificados de cliente de mTLS, cuentas de servicio, etiquetas seguras o extensiones de autorización personalizadas.

Para crear una política de autorización para Secure Web Proxy, haz lo siguiente:

Configura un archivo YAML que defina el destino y las reglas.
Para importar el archivo YAML, ejecuta el comando gcloud network-security authz-policies import.

Configura políticas de autorización para destinos de agentes

Cuando implementas Secure Web Proxy como un Agent Gateway, puedes definir políticas de autorización para inspeccionar y restringir el tráfico que se dirige a los servidores de herramientas de MCP y a los destinos de los agentes de IA.

Puedes configurar reglas que apliquen el control de acceso en las siguientes capas de solicitud:

Reglas de red: Omite la inspección de TLS o el análisis profundo de cargas útiles para extremos de agentes o modelos externos de confianza específicos.
Vinculaciones de extensiones: Usa recursos ExtensionBinding en Service Extensions para adjuntar procesadores de seguridad y administración externos, como Identity-Aware Proxy (IAP) para la verificación de identidad de agentes y Model Armor para la limpieza de instrucciones y respuestas.
Filtrado de métodos y herramientas de MCP HTTP: Aplica controles detallados sobre acciones específicas de MCP, como tools/list o tools/call, y valida argumentos para restringir las herramientas que puede invocar un agente.

Orden de evaluación de las reglas de autorización

Cuando se procesa el tráfico saliente del agente de IA a través de una Agent Gateway, las reglas se evalúan en la siguiente secuencia:

Reglas de autorización de red (L4): Se evalúan primero. Si se aplica una regla de coincidencia de SNI, como permitir la comunicación directa con un extremo de modelo externo, el tráfico omite la intercepción de TLS.
Intercepción de TLS: El tráfico que no se omite se intercepta y desencripta con la política de inspección de TLS de la puerta de enlace.
Reglas de vinculación de extensiones: Los servicios de extensión configurados, como IAP, evalúan las solicitudes para verificar la identidad del emisor en los encabezados de las solicitudes y Model Armor para inspeccionar las cargas útiles desencriptadas en busca de seguridad de las instrucciones y evitar filtraciones de datos sensibles en las respuestas.
Reglas de autorización HTTP (L7): Se evalúan las políticas de autorización a nivel de HTTP, como las restricciones de herramientas de MCP y el filtrado de métodos.

Ejemplo 1: Restringe la ejecución de herramientas de MCP

En el siguiente ejemplo, se muestra una política de autorización adjunta a un recurso agentGateway que permite que los agentes descubran herramientas (tools/list) y ejecuten solo las herramientas aprobadas (tools/call para get_weather y get_location):

Crea un archivo llamado 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

Reemplaza lo siguiente:

PROJECT_IDEs el ID del proyecto de Google Cloud .
LOCATION: Es la región en la que se implementan tus instancias de Agent Gateway y Secure Web Proxy.
AGENT_GATEWAY_NAME: Es el nombre del recurso agentGateway que está asociado con tu puerta de enlace de Secure Web Proxy.

Para importar la política de autorización, ejecuta el comando gcloud network-security authz-policies import.

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

Ejemplo 2: Omite la interceptación de TLS con la coincidencia de SNI

Si ciertos proveedores de modelos externos o APIs de agentes usan la fijación de certificados o no requieren la inspección de la carga útil, puedes usar reglas de red para que coincidan con la indicación del nombre del servidor (SNI) y permitir la conexión sin desencriptar la sesión.

Crea un archivo llamado 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
```
Reemplaza lo siguiente:
- PROJECT_IDEs el ID del proyecto de Google Cloud .
- LOCATION: Es la región en la que se implementan tus instancias de Agent Gateway y Secure Web Proxy.
- AGENT_GATEWAY_NAME: Es el nombre del recurso agentGateway que está asociado con tu puerta de enlace de Secure Web Proxy.

Para importar la política de autorización, ejecuta el comando gcloud network-security authz-policies import.

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

Ejemplo 3: Habilita la inspección profunda de cargas útiles con Model Armor usando vinculaciones de extensiones

Para protegerte contra la inyección de instrucciones, el resultado tóxico o la filtración de datos sensibles, puedes descargar el procesamiento del tráfico a Model Armor o a un procesador ext_proc personalizado con vinculaciones de extensiones en Service Extensions.

Este modelo separa al proveedor de extensiones del consumidor de la siguiente manera:

Servicios de Google (1P): Para los servicios integrados de Google, como Model Armor y la IAP, Google administra la infraestructura subyacente. Puedes vincular directamente el servicio con los URIs de extremos predefinidos (modelarmor.googleapis.com o iap.googleapis.com).
Extensiones personalizadas y de socios (2P/3P): Para los procesadores internos personalizados o los proveedores de seguridad de terceros, el productor publica un recurso ProducerExtension que apunta a su adjunto de servicio de Private Service Connect, y el consumidor vincula ese URI de recurso.

Para obtener más información sobre cómo se evalúan las políticas y extensiones de autorización en un recurso agentGateway, consulta Delega la autorización con Service Extensions y Políticas extensibles en Agent Gateway.

Para configurar una vinculación de extensión para Model Armor, haz lo siguiente:

Habilita la API de Service Extensions.

gcloud services enable serviceextensions.googleapis.com

Crea un archivo de configuración llamado extension-binding-model-armor.yaml que oriente tu recurso agentGateway, establezca tus plantillas de inspección y bloquee el tráfico destinado a los servidores de 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"
```
Reemplaza lo siguiente:
- PROJECT_IDEs el ID del proyecto de Google Cloud .
- LOCATION: Es la región en la que se implementan tus instancias de Agent Gateway y Secure Web Proxy.
- AGENT_GATEWAY_NAME: Es el nombre de tu recurso agentGateway.
- TEMPLATE_PROJECT_ID: Es el ID del proyecto en el que se crean tus plantillas de Model Armor.
- REQUEST_TEMPLATE_ID: Es el ID de la plantilla que se usa para inspeccionar las solicitudes entrantes.
- RESPONSE_TEMPLATE_ID: Es el ID de la plantilla que se usa para inspeccionar las respuestas salientes.
Nota:
- failOpen: false bloquea el tráfico si no se puede acceder al servicio de extensión. Para permitir que el tráfico pase sin inspección durante las interrupciones del servicio, establece failOpen: true.
- Para vincular una extensión interna o de terceros personalizada en lugar de Model Armor, establece producerExtension en la ruta de acceso del recurso del productor con el siguiente formato: projects/PRODUCER_PROJECT_ID/locations/LOCATION/producerExtensions/PRODUCER_EXTENSION_NAME.

Para importar la vinculación de la extensión, ejecuta el 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 obtener más información sobre la vinculación de IAP para la verificación de identidad, consulta Adjunta vinculaciones de extensiones a Agent Gateway.

Política de autorización basada en la identidad de mTLS

Secure Web Proxy admite la aplicación de reglas de seguridad basadas en identidades derivadas de certificados de TLS mutua (mTLS). Aplicar reglas basadas en estas identidades es especialmente útil en entornos de confianza cero, en los que el tráfico entre los clientes y el proxy está protegido por mTLS. Para obtener más información, consulta Política de autorización basada en principales.

En el siguiente ejemplo, se muestra una política de autorización para una instancia de Secure Web Proxy llamada swp1. En este ejemplo, se supone que el tráfico al proxy usa el protocolo HTTPS.

La política con el perfil REQUEST_AUTHZ aplica que todo el tráfico a example.com/mcp requiera autenticación de mTLS de una principal específica antes de que se permita el paso del tráfico. La política también rechaza todo el tráfico saliente que no esté destinado a example.com/mcp.

Crea el archivo YAML de la política de autorización.

En el siguiente ejemplo, se crea un archivo authz-policy.yaml. La política permite el tráfico al host y la ruta de acceso especificados solo si el cliente presenta un certificado que coincide con la principal SPIFFE ID definida.

$ 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

Reemplaza lo siguiente:

PROJECT_IDEs el ID del proyecto de Google Cloud .
LOCATION: Es la región de tu instancia de Secure Web Proxy.

Crea una política de autorización y, luego, importa el archivo YAML con el comando gcloud network-security authz-policies import.
```
gcloud beta network-security authz-policies import my-authz-policy-allow
    --source=authz-policy.yaml
    --location= LOCATION 
```
Reemplaza LOCATION por la región de tu instancia de Secure Web Proxy.

Política de autorización basada en cuentas de servicio o etiquetas

Puedes aplicar una política de autorización basada en cuentas de servicio o etiquetas adjuntas a varios recursos de Google Cloud .

En este ejemplo, se supone que completaste lo siguiente:

Creaste una cuenta de servicio y la conectaste a un recurso de Google Cloud.
Creaste una etiqueta y la adjuntaste a un recurso de Google Cloud como un par clave-valor. Cuando crees una etiqueta, establece su marca --purpose como GCE_FIREWALL. Las políticas de autorización requieren el propósito GCE_FIREWALL para aplicar la etiqueta.

Cuenta de servicio

Crea un archivo YAML de política de autorización para permitir ciertas solicitudes.

En el siguiente ejemplo, se crea un archivo authz-policy.yaml para la instancia de Secure Web Proxy llamada swp1. La política está configurada para permitir que las solicitudes de una instancia de máquina virtual (VM) de Compute Engine con la cuenta de servicio my-sa-123@56788. lleguen a la ruta de acceso 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
```
Reemplaza lo siguiente:
- PROJECT_IDEs el ID del proyecto de Google Cloud .
- LOCATION: Es la región de tu instancia de Secure Web Proxy.
Crea una política de autorización y, luego, importa el archivo YAML con el comando gcloud network-security authz-policies import.

En el siguiente comando de ejemplo, se muestra cómo importar el archivo de política creado anteriormente y crear una política de autorización:
```
gcloud network-security authz-policies import my-authz-policy-allow

    --source=authz-policy.yaml
    --location= LOCATION 
```
Reemplaza LOCATION por la región de tu instancia de Secure Web Proxy.

Etiqueta

Crea un archivo YAML de política de autorización para permitir ciertas solicitudes.

En el siguiente ejemplo, se crea un archivo authz-policy-tag.yaml para la instancia de Secure Web Proxy llamada swp1. La política solo permite que las solicitudes que se originan en un recurso de Google Cloud con un valor de etiqueta de TAG_VALUE_PERMANENT_ID accedan a la ruta de 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
```
Reemplaza lo siguiente:
- PROJECT_IDEs el ID del proyecto de Google Cloud .
- LOCATION: Es la región de tu instancia de Secure Web Proxy.
- GATEWAY_NAME: Es el nombre de tu puerta de enlace de Secure Web Proxy.
- TAG_VALUE_PERMANENT_ID: Es el ID permanente de un valor de etiqueta, como tagValues/123456789012.
Crea una política de autorización y, luego, importa el archivo YAML con el comando gcloud network-security authz-policies import.

En el siguiente comando de ejemplo, se importa el archivo de política creado antes y se crea una política de autorización en la región de Google Cloud especificada:
```
gcloud network-security authz-policies import my-authz-policy-tag-allow
    --source=authz-policy-tag.yaml
    --location= LOCATION 
```
Reemplaza LOCATION por la región de tu instancia de Secure Web Proxy.

Política de autorización para delegar decisiones de autorización

Para las decisiones de autorización complejas que no se pueden expresar con reglas ALLOW o DENY estándar, puedes crear una política de autorización con una acción CUSTOM. Luego, puedes delegar tus decisiones de autorización a las extensiones de autorización (extensiones de servicio).

Cuando configuras una política con una acción CUSTOM, Secure Web Proxy descarga los metadatos o la carga útil de la solicitud en Service Extensions. Según la respuesta de las extensiones de servicio, el proxy permite o rechaza el tráfico.

Secure Web Proxy admite los siguientes tipos de delegaciones:

Delega las decisiones de autorización de solicitudes a las extensiones de servicio: puedes usar una política de autorización configurada con una acción CUSTOM y un perfil REQUEST_AUTHZ para delegar decisiones según los metadatos y encabezados de la solicitud. En este modo, la decisión de acceso se delega a una extensión de autorización. Puedes usar este modo para verificar identidades y permisos.
Delega las decisiones de autorización de contenido a las extensiones de servicio: puedes usar una política de autorización con una acción CUSTOM y un perfil CONTENT_AUTHZ para delegar decisiones a una extensión de autorización según la carga útil de datos real de la solicitud. Este modo te permite habilitar la inspección profunda de contenido y la aplicación de medidas de seguridad, lo que te permite buscar información sensible o patrones maliciosos a través de la integración en servicios como Model Armor.

Limitaciones

Cuando implementas políticas de autorización para Secure Web Proxy, se aplican las siguientes limitaciones:

Restricciones de destino y conectividad: Las extensiones de autorización para Secure Web Proxy no admiten IAP como destino directo.
Conflicto y compatibilidad de políticas: Si tienes una política de seguridad de puerta de enlace con reglas de seguridad existentes, no es necesario que las quites. Secure Web Proxy ignora estas reglas cuando aplicas una política de autorización a tu instancia.
Requisitos de protocolo y de inspección: Para configurar las políticas de autorización de Secure Web Proxy, debes habilitar la inspección de TLS.

¿Qué sigue?

Usa mTLS de frontend con Secure Web Proxy