Configurar políticas de seguridad

Media CDN usa las políticas de seguridad de Google Cloud Armor para evitar que el tráfico no deseado llegue a sus servicios. Puedes permitir o denegar solicitudes en función de lo siguiente:

  • Direcciones y rangos IPv4 e IPv6 (CIDRs)
  • Código de país (geografía)
  • Filtrado de capa 7
  • Inteligencia de amenazas de Google (requiere el nivel Enterprise de Google Cloud Armor)
  • Números de sistemas autónomos (ASNs)

Estas funciones te permiten restringir las descargas de contenido a los usuarios de ubicaciones específicas en las que tengas restricciones de licencia de contenido, permitir que solo las direcciones IP corporativas accedan a los endpoints de prueba o de preproducción y denegar el acceso a una lista de direcciones IP de clientes maliciosos conocidos.

Cloud Armor se integra con ASN para permitirte o bloquear el tráfico de red procedente de ASNs específicos. Las políticas de seguridad perimetral de Cloud Armor pueden usar el ASN asociado a la dirección IP de origen, determinado por el operador de red responsable de esos prefijos de IP, para controlar el flujo de tráfico.

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

La integración de Cloud Armor con la inteligencia sobre amenazas de Google te permite controlar el tráfico de direcciones IP y dominios maliciosos conocidos, lo que proporciona una protección avanzada frente a las amenazas.

Las políticas de seguridad de Cloud Armor se aplican a todo el contenido que se sirve desde Media CDN, incluido el contenido almacenado en caché y los datos que no están en caché.

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

Para proteger el contenido de forma más granular a nivel de usuario, te recomendamos que uses URLs y cookies firmadas junto con una política de 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 la capa 7 cuando se le asigna alguno de los siguientes valores:

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

Configurar políticas de seguridad

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

Antes de empezar

Para adjuntar una política de seguridad de Cloud Armor a un servicio de Media CDN, asegúrate de que se cumplan los siguientes requisitos:

  • Familiarízate con Cloud Armor.
  • Tener un servicio de Media CDN al que quieras aplicar la política.
  • Opcional, pero recomendado: habilita el registro en tu servicio Media CDN para poder identificar las solicitudes bloqueadas.

También necesitas los siguientes permisos de gestión de identidades y accesos para autorizar, crear y adjuntar políticas de seguridad a un servicio de Media CDN:

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

Los usuarios que necesiten adjuntar un certificado a un servicio de Media CDN solo requieren estos permisos de gestión de identidades y accesos:

  • 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 Cloud Armor se componen de varias reglas, y cada regla define un conjunto de criterios de coincidencia (una expresión) para una solicitud y una acción. Por ejemplo, una expresión puede contener lógica de coincidencia para clientes que se encuentren en la India, y la acción asociada puede ser allow. Si una solicitud no coincide con la regla, Cloud Armor sigue evaluando la siguiente regla hasta que se hayan probado todas.

Las políticas de seguridad tienen una regla predeterminada con una acción allow. La regla predeterminada permite las solicitudes que no coinciden con las reglas anteriores. Puede cambiarla a una regla deny cuando quiera allow solo 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 geolocalizados en Australia con un error HTTP 403 y permita todas las demás solicitudes.

gcloud

Para crear una política de tipo CLOUD_ARMOR_EDGE, usa el comando gcloud compute security-policies create:

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

De esta forma, se 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].

A continuación, puedes añadir 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"

El resultado es el siguiente:

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

Terraform 

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 inspecciona la política, verá las dos reglas: la primera bloquea las solicitudes procedentes de Australia (origin.region_code == 'AU') y la segunda, que tiene la prioridad más baja, permite todo el tráfico que no coincida con la regla (o las reglas) de mayor prioridad.

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

Añadir reglas a una política de seguridad

Las políticas de seguridad de Cloud Armor son conjuntos de reglas que se basan en atributos de capa 7 para proteger aplicaciones o servicios orientados al exterior. Cada regla se evalúa en relación con el tráfico entrante.

Estos atributos se pueden usar en 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 las reglas de políticas de seguridad, consulta la referencia del lenguaje de reglas personalizadas de Cloud Armor.

Una regla de política de seguridad de Cloud Armor consta de una condición de coincidencia y una acción que se debe llevar a cabo cuando se cumpla esa condición.

gcloud

Para crear una regla para una política de seguridad, usa el comando gcloud compute security-policies rules create PRIORITY. Sustituye PRIORITY por la prioridad de la regla en la política:

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

Adjuntar una política a un servicio

gcloud

Para adjuntar una política de Cloud Armor a un servicio de Media CDN, usa el comando gcloud edge-cache services update:

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

Actualizar una regla de una política de seguridad

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

gcloud

Usa el comando gcloud compute security-policies rules update:

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
  ]

Por ejemplo, el siguiente comando actualiza una regla con prioridad 1111 para permitir el tráfico del intervalo de direcciones IP 192.0.2.0/24:

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"

Para actualizar la prioridad de una regla, debes usar la API REST. Para obtener más información, consulta el método securityPolicies.patchRule.

Ver un archivo adjunto de una política

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

gcloud

Para ver la política de Cloud Armor asociada a un servicio de Media CDN, usa el comando gcloud edge-cache services describe:

gcloud edge-cache services describe MY_SERVICE

El campo edgeSecurityPolicy del servicio describe la política adjunta:

name: "MY_SERVICE"
edgeSecurityPolicy: "SECURITY_POLICY

Eliminar una política

Para quitar una política, actualice el servicio asociado y envíe una cadena vacía como política.

gcloud

Usa el comando gcloud edge-cache services update:

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

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

Ejemplos

Consulta los siguientes ejemplos detallados de casos prácticos.

Ejemplo: identificar solicitudes bloqueadas

Debes tener el registro habilitado en un servicio EdgeCache determinado para que se registren las solicitudes bloqueadas.

Las solicitudes permitidas o denegadas por una política de filtrado se registran en Logging. Para filtrar las solicitudes rechazadas, la siguiente consulta de registro de la configuración prod-video-service sería similar a esta:

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

Ejemplo: personalizar códigos de respuesta

Puede configurar una regla de Cloud Armor para que devuelva un código de estado específico como acción asociada a 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 ha bloqueado 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 devuelto:

Para especificar uno de los [allow | deny-403 | deny-404 | deny-502] como acción asociada a 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: Denegar el acceso a clientes que no se encuentren en un país, excepto a las direcciones IP permitidas

Un caso habitual en la publicación de contenido multimedia es denegar las conexiones de los clientes que se encuentran fuera de la región para la que tienes licencias de contenido o mecanismos de pago.

Por ejemplo, puede que solo quiera permitir el acceso a los clientes ubicados en la India, así como a cualquier dirección IP que esté en la lista de permitidas, incluidas las de los partners de contenido y sus propios empleados, dentro del intervalo 192.0.2.0/24, y rechazar todas las demás.

Con el lenguaje de reglas personalizadas de Cloud Armor, se puede conseguir con la siguiente expresión:

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. Normalmente, se configura para default deny que no permites explícitamente. En otros casos, puede que prefieras bloquear parte del tráfico ydefault allow el resto.

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

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

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

Cuando vea 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 puede definir un encabezado de respuesta personalizado con la variable de encabezado {region_code}. Este encabezado se puede inspeccionar mediante JavaScript y se refleja en el cliente.

Ejemplo: Bloquear el tráfico de IPs maliciosas conocidas

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

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

La expresión indica a Cloud Armor que compruebe las solicitudes entrantes con la lista de direcciones IP maliciosas conocidas que Google actualiza constantemente y proporciona una protección sólida y automatizada.

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

Los siguientes comandos de la CLI de Google Cloud muestran cómo añadir una nueva regla de inteligencia de amenazas de Google a una política ya creada, 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: bloquear clientes maliciosos por dirección IP e intervalos de IPs

Con el lenguaje de reglas personalizadas de Cloud Armor, se puede conseguir con la siguiente expresión:

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

Puedes bloquear intervalos de IP con una máscara de /8 en IPv4 y de /32 en IPv6. Un caso habitual de las plataformas de streaming es bloquear los intervalos de IPs de salida de proxies o proveedores de VPN para minimizar la elusión de 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 intervalos de direcciones IPv4 e IPv6.

Ejemplo: Permitir solo una lista fija de zonas 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 las reglas personalizadas de Cloud Armor, la siguiente expresión permite a los usuarios identificados como procedentes 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 que los testers, los partners y tus intervalos de IP corporativos accedan, aunque no sean de una de las zonas geográficas especificadas.

Existe un número documentado de subexpresiones por cada regla con una expresión personalizada. Si necesitas combinar más subexpresiones, define varias reglas en una sola política.

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

Un ejemplo menos habitual sería bloquear a los clientes de un conjunto de países, pero permitir las 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, a continuación, aplica 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á, así como a los clientes cuya ubicación se desconoce, pero permite todo el tráfico restante:

  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: Denegar 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 esté adjunta la política. Esta aplicación de la política se lleva a cabo antes de cualquier búsqueda en caché. Las solicitudes que no se permiten según la política de seguridad perimetral se deniegan 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 añade la regla de filtrado 105 a la política de seguridad de Edge my-edge-policy, que está adjunta 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"

Registro de las medidas por incumplimiento de políticas

Cada registro de solicitudes proporciona detalles sobre qué política de seguridad se ha aplicado y si se ha permitido (ALLOW) o rechazado (DENY) la solicitud.

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

Cuando un cliente se encuentra fuera de Estados Unidos y está en vigor una política de seguridad llamada deny-non-us-clients que deniega las solicitudes que se originan fuera de Estados Unidos, esta es la entrada de registro de una solicitud denegada:

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

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

enforcedSecurityPolicy:
  name: no_policy
  outcome: ALLOW

Acerca de las clasificaciones de GeoIP

Media CDN se basa en las fuentes de datos de clasificación de IPs internas de Google para obtener una ubicación (región, estado, provincia o ciudad) a partir de una dirección IP. Si va a migrar de varios proveedores o va a dividir el tráfico entre ellos, es posible que un pequeño número de direcciones IP se asocie a veces a ubicaciones diferentes.

  • 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 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 zonas periféricas.
  • Para obtener más información, consulta unicode_region_subtag en el estándar técnico de Unicode.
  • En el caso de los clientes cuya ubicación no se pueda determinar, el valor de origin.region_code será ZZ.

Puede añadir datos geográficos a los encabezados de respuesta a un endpoint de Media CDN (con routing.routeRules[].headerActions[].responseHeadersToAdd[]) o reflejar los datos geográficos proporcionados a una función de Cloud para validar las diferencias entre las fuentes de datos de geolocalización por IP durante la integración y las pruebas iniciales.

Además, los registros de solicitudes de Media CDN incluyen clientRegion y otros datos específicos del cliente que puede validar con sus fuentes de datos.

Siguientes pasos