Google Cloud Armor: Dirección IP y filtro geográfico

Media CDN usa Google Cloud Armor para proporcionar compatibilidad con las lista de entidades permitidas y de bloqueo de direcciones IP, así como los controles de filtrado basados en códigos de país y región (ubicación geográfica). Puedes hacer lo siguiente:

  • Rechazar solicitudes basadas en direcciones y rangos (CIDR) IPv4 e IPv6.
  • Permitir o denegar solicitudes según el código de país (geografía).
  • Permitir solicitudes basadas en direcciones y rangos (CIDR) de IPv4 y de IPv6.

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.

Las políticas 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 direcciones IP y las políticas geográficas se configuran por servicio de almacenamiento en caché perimetral (EdgeCacheService). Todas las solicitudes dirigidas a la dirección IP (o nombres de host) de ese servicio tienen la política de seguridad aplicada de manera coherente. En los servicios diferentes, se pueden aplicar políticas de seguridad distintas, y puedes crear varios servicios para distintas geografías 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.

Configura políticas de seguridad

Usa las siguientes 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 almacenamiento en caché perimetral, debes hacer lo siguiente:

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

  • 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 almacenamiento en caché perimetral 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 ubicados en India, con la acción asociada que es permitida. Si una solicitud no coincide con la regla, la evaluación continúa con la siguiente hasta que se hayan probado todas las reglas.

Las políticas de seguridad tienen una regla predeterminada con una acción de permiso. La regla predeterminada permite solicitudes que no coinciden con las reglas anteriores. Esto se puede cambiar a una regla deny cuando quieras allow solo 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

Para crear una política nueva de tipo CLOUD_ARMOR_EDGE, ejecuta el siguiente comando:

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

Esto crea una política con una regla de permiso predeterminada con la prioridad más baja (priority: 2147483647):

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

Luego, puedes agregar una regla con una prioridad más alta:

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

Esta es la salida:

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

Terraform

media_cdn/security_policies/main.tf 
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

Para adjuntar esta política a tu Media CDN, consulta la siguiente sección.

Adjunta una política a un servicio

Para adjuntar una política existente de Google Cloud Armor llamada us-only-delivery-policy a un servicio de almacenamiento en caché perimetral llamado prod-media-service, haz lo siguiente:

gcloud 

gcloud edge-cache services update prod-media-service \
    --edge-security-policy=us-only-delivery-policy

Visualiza un adjunto de política

Para revisar qué política se vincula a un servicio existente, inspecciona (describe) ese servicio:

gcloud 

gcloud edge-cache services describe MY_SERVICE

En el campo edgeSecurityPolicy del servicio, se describe la política adjunta:

name: "MY_SERVICE"
edgeSecurityPolicy: "SECURITY_POLICY

Quita una política

Para quitar una política existente, actualiza el servicio asociado y pasa una string vacía como política:

gcloud 

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

El campo edgeSecurityPolicy ahora se omite del resultado del comando gcloud edge-cache services describe MY_SERVICE.

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"

Personaliza los códigos de respuesta

Las reglas de Google Cloud Armor se pueden configurar para que muestren un código de estado específico como la acción asociada con una regla determinada. En la mayoría de los casos, es mejor mostrar un código HTTP 403 (deny-403) para indicar con claridad que la regla bloqueó al cliente.

A continuación, se detallan los códigos de estado admitidos:

  • HTTP 403 (Prohibido)
  • HTTP 404 (No encontrado)
  • HTTP 502 (Puerta de enlace incorrecta)

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

gcloud

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 muestre un 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 en una política de seguridad puede definir una respuesta de código de estado diferente.

Ejemplos

Considera los siguientes caso de uso de ejemplo detallado.

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 clientes ubicados en India, así como cualquier dirección IP incluida en la lista de anunciantes permitidos (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, lo configuras como el tráfico default deny que no permites de forma explícita. En otros casos, puedes elegir bloquear parte del tráfico y default allow en el resto del tráfico.

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 encadenar varias reglas mediante el uso de operadores booleanos.

La siguiente política permite el tráfico de clientes en India, permite clientes de un rango de IP definido y niega todo el resto del tráfico:

gcloud

Ejecuta el siguiente comando security-policies describe:

gcloud compute security-policies describe allow-india-only

Esto da como resultado una política de Google Cloud Armor que se ve de la siguiente manera:

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 configurar un encabezado de respuesta personalizado con la variable de encabezado {region_code}. Este encabezado se puede inspeccionar con JavaScript y se refleja al cliente.

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 permite una lista fija de geografías

Si tienes una lista de códigos de país, puedes usar el operador booleano OR || para encadenar 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 encadenar con expresiones origin.ip o inIpRange(origin.ip, '...') para permitir verificadores, socios y rangos de IP corporativos, incluso si no provienen de una de las geografías especificadas.

Existe la cantidad documentada de subexpresiones por cada regla con una expresión personalizada. Si necesitas encadenar 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 puede ser bloquear a los clientes de un conjunto determinado de países, pero, de lo contrario, permitir las solicitudes de todos los demás países.

Para ello, crea una política que bloquee tanto el país como cualquier cliente en el que no se pueda determinar su región y, luego, establecer 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 cualquier cliente en el que la ubicación sea desconocida, pero permita 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

Registra acciones de aplicación

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

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 de registro de solicitud para un servicio sin una política adjunta tiene los siguientes valores:

enforcedSecurityPolicy:
  name: no_policy
  outcome: ALLOW

Información sobre las clasificaciones GeoIP

Media CDN se basa en las fuentes de datos de clasificación de IP internas de Google para derivar una ubicación (región, estado/provincia, ciudad) de una dirección IP. Si migras o divides el tráfico entre varios proveedores, a veces, una pequeña cantidad de direcciones IP puede estar asociada 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 clientRegion y otros datos específicos del cliente que puedes validar en tus fuentes de datos existentes.

¿Qué sigue?