Configurar políticas de seguridad

La CDN de Media usa políticas de seguridad de Google Cloud Armor para evitar que el tráfico no deseado llegue a sus servicios. Puedes permitir o rechazar solicitudes según lo siguiente:

• Direcciones y rangos (CIDR) de IPv4 e IPv6
• Código de país (ubicación geográfica)
• Filtrado de capa 7
• Google Threat Intelligence (requiere el nivel Google Cloud Armor Enterprise)

Estas capacidades te permiten restringir las descargas de contenido a los usuarios en ubicaciones específicas en las que tienes restricciones de licencias de contenido, solo permiten que las direcciones IP corporativas accedan a los extremos de pruebas o de etapa de pruebas, y rechazan una lista de direcciones IP maliciosas conocidas de cliente.

Puedes decorar las solicitudes que permite Google Cloud Armor insertando encabezados personalizados con nombres y valores configurables.

La integración de Google Cloud Armor con Google Threat Intelligence te permite controlar el tráfico de direcciones IP y dominios maliciosos conocidos, lo que proporciona protección avanzada contra amenazas.

Las políticas de seguridad de Google Cloud Armor se aplican a todo el contenido que se entrega desde Media CDN, incluido el contenido almacenado en caché y los errores de caché.

Las políticas de seguridad de Google Cloud Armor se configuran por servicio de Media CDN. Todas las solicitudes destinadas a la dirección IP (o nombres de host) de ese servicio tienen la política de seguridad aplicada de manera coherente. Se pueden aplicar diferentes políticas de seguridad a los distintos servicios, y puedes crear varios servicios para diferentes ubicaciones geográficas según sea necesario.

Para obtener una protección más detallada del contenido a nivel de usuario, te recomendamos usar las URL y cookies firmadas junto con una política de Google Cloud Armor.

Media CDN no tiene en cuenta el encabezado referer durante la evaluación de reglas de las políticas de seguridad perimetral de filtrado de encabezados de capa 7 cuando se establece en cualquiera de los siguientes valores:

• Varias URLs
• Una URL relativa
• URLs absolutas válidas que contienen información del usuario o un componente de fragmento

Configurar políticas de seguridad

Sigue estas instrucciones para configurar una política de seguridad.

Antes de comenzar

Para adjuntar una política de seguridad de Google Cloud Armor a un servicio de CDN de Media, asegúrate de cumplir con los siguientes requisitos:

• Familiarízate con Google Cloud Armor.
• Tienes un servicio de Media CDN existente al que deseas aplicar la política.
• Opcional, pero recomendado: Habilita el registro en tu servicio de Media CDN para que puedas identificar las solicitudes bloqueadas.

También necesitas los siguientes permisos de Identity and Access Management para autorizar, crear y adjuntar políticas de seguridad a un servicio de CDN de Media:

• compute.securityPolicies.addAssociation
• compute.securityPolicies.create
• compute.securityPolicies.delete
• compute.securityPolicies.get
• compute.securityPolicies.list
• compute.securityPolicies.update
• compute.securityPolicies.use

Los usuarios que necesitan adjuntar un certificado existente a un servicio de Media CDN solo requieren estos permisos de IAM:

• compute.securityPolicies.get
• compute.securityPolicies.list
• compute.securityPolicies.use

El rol roles/networkservices.edgeCacheUser incluye todos estos permisos.

Crear una política de seguridad

Las políticas de seguridad de Google Cloud Armor están compuestas por varias reglas, en las que cada regla define un conjunto de criterios coincidentes (una expresión) para una solicitud y una. Por ejemplo, una expresión puede contener lógica de coincidencia para los clientes que se encuentran en la India, y la acción asociada es allow. Si una solicitud no coincide con la regla, Google Cloud Armor continúa evaluando la siguiente regla hasta que se intentan todas las reglas.

Las políticas de seguridad tienen una regla predeterminada con una acción de allow. La regla predeterminada permite las solicitudes que no coinciden con las reglas anteriores. Esto se puede cambiar a una regla deny cuando solo quieras allow las solicitudes que coincidan con las reglas anteriores y rechazar todas las demás.

En el siguiente ejemplo, se muestra cómo crear una regla que bloquee a todos los clientes ubicados en Australia con un HTTP 403 y permita todas las demás solicitudes.

gcloud compute security-policies create block-australia \
    --type="CLOUD_ARMOR_EDGE" --project="PROJECT_ID"

Created [https://www.googleapis.com/compute/v1/projects/PROJECT_ID/global/securityPolicies/block-australia].

gcloud compute security-policies rules create 1000 \
    --security-policy=block-australia --description "block AU" \
    --expression="origin.region_code == 'AU'" --action="deny-403"

Updated [https://www.googleapis.com/compute/v1/projects/PROJECT_ID/global/securityPolicies/block-australia].

resource "google_compute_security_policy" "default" {
  name        = "block-australia"
  type        = "CLOUD_ARMOR_EDGE"
  description = "block AU"

  rule {
    action      = "deny(403)"
    description = "block AU"
    priority    = "1000"
    match {
      expr {
        expression = "origin.region_code == 'AU'"
      }
    }
  }
  rule {
    action   = "allow"
    priority = "2147483647"
    match {
      versioned_expr = "SRC_IPS_V1"
      config {
        src_ip_ranges = ["*"]
      }
    }
    description = "default rule"
  }
}

Si inspeccionas la política, verás las dos reglas: la primera bloquea las solicitudes que se originan en Australia (origin.region_code == 'AU') y la segunda, la de menor prioridad, que permite que todo el tráfico no coincida con la regla de prioridad más alta (o reglas).

kind: compute#securityPolicy
name: block-australia
rules:
- action: deny(403)
  description: block AU
  kind: compute#securityPolicyRule
  match:
    expr:
      expression: origin.region_code == 'AU'
  preview: false
  priority: 1000
- action: allow
  description: default rule
  kind: compute#securityPolicyRule
  match:
    config:
      srcIpRanges:
      - '*'
    versionedExpr: SRC_IPS_V1
  preview: false
  priority: 2147483647
  ruleNumber: '1'
type: CLOUD_ARMOR_EDGE

Agrega reglas a una política de seguridad

Las políticas de seguridad de Google Cloud Armor son conjuntos de reglas que coinciden con los atributos de la capa 7 para proteger aplicaciones o servicios externos. Cada regla se evalúa con respecto al tráfico entrante.

Estos atributos se pueden usar para solicitudes HTTP en políticas de seguridad: request.headers, request.method, request.path, request.scheme y request.query. Para obtener más información sobre cómo escribir expresiones para reglas de políticas de seguridad, consulta la referencia del lenguaje de reglas personalizadas de Google Cloud Armor.

Una regla de política de seguridad de Google Cloud Armor consiste en una condición de coincidencia y una acción que se realiza cuando se cumple esa condición.

gcloud compute security-policies rules create PRIORITY \
    --security-policy POLICY_NAME \
    --description DESCRIPTION \
    --src-ip-ranges IP_RANGES | --expression EXPRESSION \
    --action=[ allow | deny-403 | deny-404 | deny-502 ] \
    --preview

Adjunta una política a un servicio

gcloud edge-cache services update MY_SERVICE \
    --edge-security-policy=SECURITY_POLICY

Actualiza una regla en una política de seguridad

Sigue estas instrucciones para actualizar una sola regla en una política de seguridad de Google Cloud Armor. También puedes actualizar varias reglas de forma atómica en una política de seguridad.

gcloud compute security-policies rules update PRIORITY [ \
    --security-policy POLICY_NAME  \
    --description DESCRIPTION  \
    --src-ip-ranges IP_RANGES  | --expression EXPRESSION \
    --action=[ allow | deny-403 | deny-404 | deny-502 ]  \
    --preview
  ]
  

gcloud compute security-policies rules update 1111 \
    --security-policy my-policy \
    --description "allow traffic from 192.0.2.0/24" \
    --src-ip-ranges "192.0.2.0/24" \
    --action "allow"

Visualiza un adjunto de política

Para revisar qué política está adjunta a un servicio existente, inspecciona (describe) ese servicio.

gcloud edge-cache services describe MY_SERVICE

name: "MY_SERVICE"
edgeSecurityPolicy: "SECURITY_POLICY

Cómo quitar una política

Para quitar una política existente, actualiza el servicio asociado y pasa una cadena vacía como la política.

  gcloud edge-cache services update MY_SERVICE \
      --edge-security-policy=""

Ejemplos

Considera los siguientes caso de uso de ejemplo detallado.

Ejemplo: Identifica solicitudes bloqueadas

Debes tener el registro habilitado para que el servicio de almacenamiento en caché perimetral determinado para que las solicitudes bloqueadas se registren.

Las solicitudes permitidas o denegadas por una política de filtro se registran en Logging. A fin de filtrar las solicitudes rechazadas, la siguiente consulta de Logging para la configuración prod-video-service vería de la siguiente manera:

resource.type="edge_cache_service"
jsonPayload.statusDetails="denied_by_security_policy"

Ejemplo: Personaliza los códigos de respuesta

Puedes configurar una regla de Google Cloud Armor para que muestre un código de estado específico como la acción asociada con una regla determinada. En la mayoría de los casos, lo mejor es devolver un código de estado HTTP 403 DENY para indicar claramente que la regla bloqueó al cliente.

Los códigos de estado admitidos son los siguientes:

• HTTP 403 Forbidden
• HTTP 404 Not Found
• HTTP 502 Bad Gateway

En el siguiente ejemplo, se muestra cómo configurar el código de estado que se muestra:

Para especificar uno de [allow | deny-403 | deny-404 | deny-502] como la acción asociada con la regla, ejecuta el siguiente comando. En este ejemplo, se configura la regla para que devuelva un código de estado HTTP 502.

gcloud compute security-policies rules create 1000 \
    --security-policy=block-australia --description "block AU" \
    --expression="origin.region_code == 'AU'" --action="deny-502"

Cada regla de una política de seguridad puede definir una respuesta de código de estado diferente.

Ejemplo: Rechaza clientes fuera de un país, excepto las direcciones IP permitidas

Un caso común en la entrega de contenido multimedia es denegar las conexiones de los clientes que están fuera de la región para la que tienes licencias de contenido o mecanismos de pago.

Por ejemplo, es posible que solo quieras permitir los clientes ubicados en India, así como cualquier dirección IP que se encuentre en la lista de entidades permitidas, incluidas las de los socios de contenido y tus propios empleados, dentro del rango 192.0.2.0/24, y rechazar a todos los demás.

Mediante el lenguaje de reglas personalizadas de Google Cloud Armor, la siguiente expresión lo logra:

origin.region_code == "IN" || inIpRange(origin.ip, '192.0.2.0/24')

Esta expresión se configura como una regla allow, con una regla deny predeterminada configurada para que coincida con todos los demás clientes. Las políticas de seguridad siempre tienen una regla predeterminada. Por lo general, configuras esto para el tráfico de default deny que no permites de forma explícita. En otros casos, puedes optar por bloquear parte del tráfico y default allow todo el resto.

En el resultado de la política de seguridad, ten en cuenta lo siguiente:

• La regla de prioridad más alta (priority: 0) permite el tráfico de India OR de la lista definida de direcciones IP.
• La regla de prioridad más baja representa un default deny. El motor de reglas rechaza a todos los clientes que las reglas de mayor prioridad no evalúan como verdaderas.
• Puedes combinar varias reglas con operadores booleanos.

La política permite el tráfico de clientes en la India y de clientes de un rango de IP definido, y rechaza todo el resto del tráfico.

Cuando veas los detalles de la política, el resultado será similar al siguiente:

kind: compute#securityPolicy
name: allow-india-only
type: "CLOUD_ARMOR_EDGE"
rules:
- action: allow
  description: ''
  kind: compute#securityPolicyRule
  match:
    expr:
      expression: origin.region_code == "IN" || inIpRange(origin.ip, '192.0.2.0/24')
  preview: false
  priority: 0
- action: deny(403)
  description: Default rule, higher priority overrides it
  kind: compute#securityPolicyRule
  match:
    config:
      srcIpRanges:
      - '*'
    versionedExpr: SRC_IPS_V1
  preview: false
  priority: 2147483647

También puedes establecer un encabezado de respuesta personalizado con la variable de encabezado {region_code}. Este encabezado se puede inspeccionar con JavaScript y se refleja en el cliente.

Ejemplo: Bloquea el tráfico de IPs maliciosas conocidas

La siguiente expresión del lenguaje de reglas personalizadas de Google Cloud Armor bloquea el tráfico de las direcciones IP que se identifican como maliciosas:

evaluateThreatIntelligence('iplist-known-malicious-ips')

La expresión dirige Google Cloud Armor para que verifique las solicitudes entrantes en la lista de direcciones IP maliciosas conocidas de Google, que se actualiza constantemente, y proporciona protección sólida y automatizada.

Para bloquear automáticamente las direcciones IP maliciosas, puedes configurar tus políticas de seguridad perimetral con las reglas de Google Threat Intelligence.

Los siguientes comandos de Google Cloud CLI muestran cómo agregar una regla nueva de Inteligencia sobre amenazas de Google a una política existente, como my-edge-policy:

  gcloud compute security-policies create my-edge-policy \
      --type=CLOUD_ARMOR_EDGE

  gcloud edge-cache services update my-edge-cache-service \
      --edge-security-policy "my-edge-policy"

  gcloud compute security-policies rules create 1000 \
      --security-policy "my-edge-policy" \
      --expression "evaluateThreatIntelligence('iplist-known-malicious-ips')" \
      --action "deny-403"

Ejemplo: Bloquea clientes maliciosos por dirección y rangos de IP

Mediante el lenguaje de reglas personalizadas de Google Cloud Armor, la siguiente expresión lo logra:

inIpRange(origin.ip, '192.0.2.2/32') || inIpRange(origin.ip, '192.0.2.170/32')

Puedes bloquear rangos de IP hasta una máscara /8 en IPv4 y una /32 en IPv6. Un caso común para las plataformas de transmisión es bloquear los rangos de IP de salida de los proxies o proveedores de VPN a fin de minimizar la elusión de las licencias de contenido:

inIpRange(origin.ip, '192.0.2.0/24') || inIpRange(origin.ip, '198.51.100.0/24') || inIpRange(origin.ip, '203.0.113.0/24') || inIpRange(origin.ip, '2001:DB8::B33F:2002/64')

Se admiten rangos de direcciones IPv4 e IPv6.

Ejemplo: Solo permitir una lista fija de ubicaciones geográficas

Si tienes una lista de códigos de país, puedes usar el operador booleano OR || para combinar condiciones de coincidencia.

Con el lenguaje de reglas personalizadas de Google Cloud Armor, la siguiente expresión permite a los usuarios identificados que provienen de Australia o Nueva Zelanda:

origin.region_code == "AU" || origin.region_code == "NZ"

Además, se puede combinar con expresiones origin.ip o inIpRange(origin.ip, '...') para permitir rangos de IP corporativos, socios y verificadores, incluso si no son de una de las ubicaciones geográficas especificadas.

Existe la cantidad documentada de subexpresiones para cada regla con una expresión personalizada. Si necesitas combinar más subexpresiones, define varias reglas dentro de una sola política.

Ejemplo: Bloquea clientes de un conjunto específico de países

Un ejemplo menos común podría ser bloquear clientes de un conjunto determinado de países, pero permitir solicitudes de todos los demás países.

Para ello, crea una política que bloquee tanto el país como los clientes cuya región no se pueda determinar y, luego, recurre a una regla de permiso predeterminada para todas las demás solicitudes.

En el siguiente ejemplo, se describe una política que bloquea a los clientes de Canadá y a los clientes cuya ubicación es desconocida, pero permite todo el resto del tráfico:

  kind: compute#securityPolicy
  name: block-canada
  type: "CLOUD_ARMOR_EDGE"
  rules:
  - action: deny(403)
    description: ''
    kind: compute#securityPolicyRule
    match:
      expr:
        expression: origin.region_code == "CA" || origin.region_code == "ZZ"
    preview: false
    priority: 0
  - action: allow
    description: Default rule, higher priority overrides it
    kind: compute#securityPolicyRule
    match:
      config:
        srcIpRanges:
        - '*'
      versionedExpr: SRC_IPS_V1
    preview: false
    priority: 2147483647

Ejemplo: Rechaza solicitudes de contenido almacenado en caché con encabezados específicos

Una política de seguridad perimetral se aplica a todas las solicitudes dirigidas a cualquier servicio de Media CDN al que se vincule la política. Esta aplicación de la política se realiza antes de cualquier búsqueda en la caché. Las solicitudes que no permite la política de seguridad perimetral se rechazan con el código de estado configurado.

La siguiente expresión coincide con las solicitudes de la dirección IP 1.2.3.4 que contienen la cadena user1 en el encabezado user-agent:

inIpRange(origin.ip, '1.2.3.4/32') && request.headers['user-agent'].contains('user1')

El siguiente comando agrega la regla de filtrado 105 a la política de seguridad perimetral my-edge-policy, que está vinculada a un servicio de Media CDN:

gcloud compute security-policies rules create 105 \
    --security-policy "my-edge-policy" \
    --expression = "inIpRange(origin.ip, '1.2.3.4/32') && request.headers['user-agent'].contains('charlie')" \
    --action= deny-403 \
    --description="block requests from IP addresses in which the user-agent header contains the string charlie"
    

Registra acciones de aplicación

Cada registro de solicitud proporciona detalles sobre qué política de seguridad se aplicó y si se permitió (ALLOW) o rechazó (DENY) la solicitud.

Para habilitar el registro, asegúrate de que logConfig.enable esté configurado como true en tu servicio. Los servicios sin registros habilitados no registran eventos de políticas de seguridad.

Cuando un cliente se encuentra fuera de Estados Unidos y se aplica una política de seguridad llamada deny-non-us-clients, que rechaza las solicitudes que se originan fuera de EE.UU., esta es la entrada de registro de una solicitud rechazada:

enforcedSecurityPolicy:
  name: deny-non-us-clients
  outcome: DENY

Los servicios sin una política de Google Cloud Armor adjunta contienen no_policy como el valor de enforcedSecurityPolicy.name y un outcome de ALLOW. Por ejemplo, una entrada del registro de solicitudes para un servicio sin una política adjunta tiene los siguientes valores:

enforcedSecurityPolicy:
  name: no_policy
  outcome: ALLOW

Comprende las clasificaciones de GeoIP

Media CDN se basa en las fuentes de datos internas de clasificación de IP de Google para derivar una ubicación (región, estado, provincia o ciudad) a partir de una dirección IP. Si migras desde varios proveedores o divides el tráfico entre ellos, es posible que, en ocasiones, una pequeña cantidad de direcciones IP se asocien con diferentes ubicaciones.

• Google Cloud Armor usa códigos de región ISO 3166-1 alfa 2 para asociar un cliente a una ubicación geográfica.
• Por ejemplo, US para los Estados Unidos o AU para Australia.
• En algunos casos, una región corresponde a un país, pero no siempre es así. Por ejemplo, el código US incluye todos los estados de Estados Unidos, un distrito y seis áreas periféricas.
• Para obtener más información, consulta unicode_region_subtag en el estándar técnico de Unicode.
• Para los clientes en los que no se puede derivar la ubicación, origin.region_code se establece en ZZ.

Puedes agregar datos geográficos a los encabezados de respuesta a un extremo de Media CDN (con routing.routeRules[].headerActions[].responseHeadersToAdd[]) o reflejar los datos geográficos proporcionados a un . Cloud Function para validar las diferencias entre las fuentes de datos geoIP durante la integración y pruebas iniciales.

Además, los registros de solicitudes de Media CDN incluyen el campo clientRegion y otros datos específicos del cliente que puedes validar con tus fuentes de datos existentes.

¿Qué sigue?

• Aprende a usar las solicitudes firmadas para autorizar contenido por usuario.
• Revisa la referencia de las reglas de Google Cloud Armor para comprender cómo se pueden expresar y combinar las reglas de coincidencia geográficas y de IP.
• Visita la documentación del registro para comprender cómo consultar los registros de solicitudes y verificar qué solicitudes se bloquearon.