Configurar políticas de segurança

A CDN de mídia usa políticas de segurança do Google Cloud Armor para impedir que tráfego indesejado atinja os serviços dela. É possível permitir ou negar solicitações com base no seguinte:

  • Endereços e intervalos IPv4 e IPv6 (CIDRs)
  • Código do país (geografia)
  • Filtragem da camada 7
  • Google Threat Intelligence (requer o nível do Google Cloud Armor Enterprise)
  • Números de sistemas autônomos (ASNs)

Esses recursos permitem restringir downloads de conteúdo a usuários em locais específicos em que você tem restrições de licenciamento de conteúdo, permitir apenas que endereços IP corporativos acessem endpoints de teste ou de preparo e negar uma lista de endereços IP de clientes ruins conhecidos.

O Cloud Armor se integra ao ASN para permitir ou bloquear o tráfego de rede originário de ASNs específicos. As políticas de segurança de borda do Cloud Armor podem usar o ASN associado ao endereço IP de origem, conforme determinado pelo operador de rede responsável por esses prefixos de IP, para controlar o fluxo de tráfego.

É possível decorar as solicitações permitidas pelo Cloud Armor inserindo cabeçalhos personalizados com nomes e valores configuráveis.

A integração do Cloud Armor com o Google Threat Intelligence permite controlar o tráfego de endereços IP e domínios maliciosos conhecidos, oferecendo proteção avançada contra ameaças.

As políticas de segurança do Cloud Armor se aplicam a todo o conteúdo veiculado pela CDN de mídia, incluindo conteúdo armazenado em cache e ausências no cache.

As políticas de segurança do Cloud Armor são configuradas por serviço da CDN de mídia. Todas as solicitações destinadas ao endereço IP (ou nomes de host) desse serviço têm a política de segurança aplicada de forma consistente. Serviços diferentes podem ter políticas de segurança diferentes aplicadas a eles, e você pode criar vários serviços para diferentes regiões geográficas, conforme necessário.

Para uma proteção mais refinada do conteúdo no nível do usuário, recomendamos o uso de URLs e cookies assinados em conjunto com uma política do Cloud Armor.

A CDN de mídia não considera o cabeçalho referer durante a avaliação de regras de políticas de segurança de borda de filtragem de cabeçalho da camada 7 quando ele está definido como um dos seguintes valores:

  • Vários URLs
  • Um URL relativo
  • URLs absolutos válidos que contêm informações do usuário ou um componente de fragmento

Configurar políticas de segurança

Use as instruções a seguir para configurar uma política de segurança.

Antes de começar

Para anexar uma política de segurança do Cloud Armor a um serviço da CDN de mídia, verifique o seguinte:

  • Conheça o Cloud Armor.
  • Tenha um serviço da CDN de mídia ao qual você quer aplicar a política.
  • Opcional, mas recomendado: ative a geração de registros no serviço da CDN de mídia para identificar solicitações bloqueadas.

Você também precisa das seguintes permissões do Identity and Access Management para autorizar, criar e anexar políticas de segurança a um serviço da CDN de mídia:

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

Os usuários que precisam anexar um certificado a um serviço da CDN de mídia só precisam destas permissões do IAM:

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

O papel roles/networkservices.edgeCacheUser inclui todas essas permissões.

Criar uma política de segurança

As políticas de segurança do Cloud Armor são compostas por várias regras, com cada regra definindo um conjunto de critérios de correspondência (uma expressão) para uma solicitação, e uma ação. Por exemplo, uma expressão pode conter lógica de correspondência para clientes localizados na Índia, com a ação associada sendo allow. Se uma solicitação não corresponder à regra, o Cloud Armor continuará avaliando a próxima regra até que todas as regras tenham sido tentadas.

As políticas de segurança têm uma regra padrão com uma ação allow. A regra padrão permite solicitações que não correspondem às regras anteriores. Isso pode ser alterado para uma regra deny quando você quiser allow apenas solicitações que correspondam às regras anteriores e rejeitar todas as outras.

O exemplo a seguir mostra como criar uma regra que bloqueia todos os clientes geolocalizados na Austrália com um HTTP 403 e permite todas as outras solicitações.

gcloud

Para criar uma nova política do tipo CLOUD_ARMOR_EDGE, use o gcloud compute security-policies create comando:

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

Isso cria uma política com uma regra de permissão padrão na prioridade mais baixa (priority: 2147483647):

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

Em seguida, você pode adicionar uma regra com uma prioridade mais alta:

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

A saída é esta:

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"
  }
}

Se você inspecionar a política, verá as duas regras: a primeira bloqueia solicitações originárias da Austrália (origin.region_code == 'AU') e a segunda, regra de prioridade mais baixa, permite todo o tráfego que não corresponde à regra (ou regras) de maior prioridade.

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

Adicionar regras a uma política de segurança

As políticas de segurança do Cloud Armor são conjuntos de regras que correspondem aos atributos da camada 7 para proteger aplicativos ou serviços externos. Cada regra é avaliada em relação ao tráfego recebido.

Esses atributos podem ser usados para solicitações HTTP em políticas de segurança: request.headers, request.method, request.path, request.scheme e request.query. Para mais informações sobre como escrever expressões para regras de política de segurança, consulte a referência de linguagem de regras personalizadas do Cloud Armor.

Uma regra de política de segurança do Cloud Armor consiste em uma condição de correspondência e uma ação a ser tomada quando essa condição é atendida.

gcloud

Para criar uma regra para uma política de segurança, use o gcloud compute security-policies rules create PRIORITY comando. Substitua PRIORITY pela prioridade da regra na 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

Anexar uma política a um serviço

gcloud

Para anexar uma política do Cloud Armor a um serviço da CDN de mídia, use o gcloud edge-cache services update comando:

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

Atualizar uma regra em uma política de segurança

Use estas instruções para atualizar apenas uma regra em uma política de segurança do Cloud Armor. Como alternativa, você pode atualizar atomicamente várias regras em uma política de segurança.

gcloud

Use o gcloud compute security-policies rules update comando:

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 exemplo, o comando a seguir atualiza uma regra com prioridade 1.111 para permitir o tráfego do intervalo de endereços 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 atualizar a prioridade de uma regra, use a API REST. Para mais informações, consulte o securityPolicies.patchRule método.

Conferir um anexo de política

Para revisar qual política está anexada a um serviço, inspecione (descreva) esse serviço.

gcloud

Para conferir a política do Cloud Armor anexada a um serviço da CDN de mídia, use o gcloud edge-cache services describe comando:

gcloud edge-cache services describe SERVICE_NAME

O campo edgeSecurityPolicy do serviço descreve a política anexada:

name: "SERVICE_NAME"
edgeSecurityPolicy: "SECURITY_POLICY

Remover uma política

Para remover uma política, atualize o serviço associado e transmita uma string vazia como a política.

gcloud

Use o gcloud edge-cache services update comando:

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

O campo edgeSecurityPolicy agora é omitido da saída do gcloud edge-cache services describe SERVICE_NAME comando.

Exemplos

Considere os seguintes exemplos de casos de uso detalhados.

Exemplo: identificar solicitações bloqueadas

É necessário ter a geração de registros ativada para um determinado serviço do Edge Cache para que as solicitações bloqueadas sejam registradas.

As solicitações permitidas ou negadas por uma política de filtragem são registradas no Cloud Logging. Para filtrar solicitações rejeitadas, a seguinte consulta do Cloud Logging para a configuração prod-video-service seria semelhante a esta:

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

Exemplo: personalizar códigos de resposta

É possível configurar uma regra do Cloud Armor para retornar um código de status específico como a ação associada a uma determinada regra. Na maioria dos casos, é melhor retornar um código de status HTTP 403 DENY para sinalizar claramente que o cliente foi bloqueado pela regra.

Os códigos de status aceitos são:

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

O exemplo a seguir mostra como configurar o código de status retornado:

Para especificar um de [allow | deny-403 | deny-404 | deny-502] como a ação associada à regra, execute o seguinte comando. Este exemplo configura a regra para retornar um código de status 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 regra em uma política de segurança pode definir uma resposta de código de status diferente.

Exemplo: negar clientes fora de um país, exceto para endereços IP permitidos

Um caso comum na veiculação de mídia é negar conexões de clientes que estão fora da região para a qual você tem licenças de conteúdo ou mecanismos de pagamento.

Por exemplo, talvez você queira permitir apenas clientes localizados na Índia, bem como todos os endereços IP que estão na lista de permissões, incluindo os de parceiros de conteúdo e seus próprios funcionários, no intervalo 192.0.2.0/24, e rejeitar todos os outros.

Usando a linguagem de regras personalizadas do Cloud Armor, a expressão a seguir realiza isso:

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

Essa expressão é configurada como uma regra allow, com uma regra deny padrão configurada para corresponder a todos os outros clientes. As políticas de segurança sempre têm uma regra padrão. Normalmente, você configura isso para default deny tráfego que não permite explicitamente. Em outros casos, você pode bloquear pouco trânsito e default allow todo o outro tráfego.

Na saída da política de segurança, observe o seguinte:

  • A regra de maior prioridade (priority: 0) permite o tráfego da Índia OU da lista definida de endereços IP.
  • A regra de prioridade mais baixa representa um default deny. O mecanismo de regras nega todos os clientes que as regras de maior prioridade não avaliam como verdadeiras.
  • É possível combinar várias regras usando operadores booleanos.

A política permite o tráfego de clientes na Índia, permite clientes de um intervalo de IP definido e nega todo o outro tráfego.

Ao conferir os detalhes da política, a saída é semelhante a esta:

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

Também é possível definir um cabeçalho de resposta personalizado com a variável de cabeçalho {region_code}. Esse cabeçalho pode ser inspecionado usando JavaScript e refletido no cliente.

Exemplo: bloquear o tráfego de IPs maliciosos conhecidos

A expressão de linguagem de regras personalizadas do Cloud Armor a seguir bloqueia o tráfego de endereços IP identificados como maliciosos:

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

A expressão direciona o Cloud Armor para verificar as solicitações recebidas na lista de endereços IP maliciosos conhecidos do Google, que é atualizada constantemente, e oferece proteção robusta e automatizada.

Para bloquear automaticamente endereços IP maliciosos, configure suas políticas de segurança de borda com regras do Google Threat Intelligence.

Os comandos da Google Cloud CLI a seguir mostram como adicionar uma nova regra do Google Threat Intelligence a uma política, 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"

Exemplo: bloquear clientes maliciosos por endereço IP e intervalos de IP

Usando a linguagem de regras personalizadas do Cloud Armor, a expressão a seguir realiza isso:

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

É possível bloquear intervalos de IP até uma máscara /8 no IPv4 e uma /32 no IPv6. Um caso comum para plataformas de streaming é bloquear os intervalos de IP de saída de proxies ou provedores de VPN para minimizar a burla de licenciamento de conteúdo:

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')

Os intervalos de endereços IPv4 e IPv6 são aceitos.

Exemplo: permitir apenas uma lista fixa de regiões geográficas

Se você tiver uma lista de códigos de país, poderá usar o operador booleano OR || para combinar condições de correspondência.

Usando a linguagem de regras personalizadas do Cloud Armor, a expressão a seguir permite usuários identificados como originários da Austrália ou da Nova Zelândia:

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

Isso também pode ser combinado com origin.ip ou inIpRange(origin.ip, '...') expressões para permitir testadores, parceiros e seus intervalos de IP corporativos, mesmo que não sejam de uma das regiões geográficas especificadas.

Há o número documentado de subexpressões para cada regra com uma expressão personalizada. Se você precisar combinar mais subexpressões, defina várias regras em uma única política.

Exemplo: bloquear clientes de um conjunto específico de países

Um exemplo menos comum pode ser bloquear clientes de um determinado conjunto de países, mas permitir solicitações de todos os outros países.

Para fazer isso, crie uma política que bloqueie o país e todos os clientes em que a região não possa ser determinada e, em seguida, passe para uma regra de permissão padrão para todas as outras solicitações.

O exemplo a seguir descreve uma política que bloqueia clientes do Canadá, bem como todos os clientes em que o local é desconhecido, mas permite todo o outro tráfego:

  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

Exemplo: negar solicitações de conteúdo armazenado em cache com cabeçalhos específicos

Uma política de segurança de borda se aplica a todas as solicitações direcionadas a qualquer serviço da CDN de mídia ao qual a política está anexada. Essa aplicação da política ocorre antes de qualquer pesquisa de cache. As solicitações que não são permitidas pela política de segurança de borda são negadas com o código de status configurado.

A expressão a seguir corresponde a solicitações do endereço IP 1.2.3.4 que contêm a string user1 no cabeçalho user-agent:

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

O comando a seguir adiciona a regra de filtragem 105 à política de segurança de borda my-edge-policy, que está anexada a um serviço da CDN de mídia:

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"

Registrar ações de aplicação

Cada registro de solicitação fornece detalhes sobre qual política de segurança foi aplicada e se a solicitação foi permitida (ALLOW) ou rejeitada (DENY).

Para ativar a geração de registros, verifique se logConfig.enable está definido como true no seu serviço. Os serviços sem registros ativados não registram eventos de política de segurança.

Quando um cliente está localizado fora dos Estados Unidos e uma política de segurança chamada deny-non-us-clients está em vigor, que nega solicitações originárias de fora dos EUA, esta é a entrada de registro de uma solicitação negada:

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

Os serviços sem uma política do Cloud Armor anexada contêm no_policy como o valor de enforcedSecurityPolicy.name e um outcome de ALLOW. Por exemplo, uma entrada de registro de solicitação para um serviço sem uma política anexada tem os seguintes valores:

enforcedSecurityPolicy:
  name: no_policy
  outcome: ALLOW

Entender as classificações de GeoIP

A CDN de mídia depende das fontes de dados de classificação de IP internas do Google para derivar um local (região, estado, província ou cidade) de um endereço IP. Se você estiver migrando ou dividindo o tráfego entre vários provedores, um pequeno número de endereços IP poderá ser associado a locais diferentes.

  • O Cloud Armor usa ISO 3166-1 alfa 2 códigos de região para associar um cliente a uma localização geográfica.
  • Por exemplo, US para os Estados Unidos ou AU para a Austrália.
  • Em alguns casos, uma região corresponde a um país, mas nem sempre é o caso. Por exemplo, o código US inclui todos os estados dos Estados Unidos, um distrito e seis áreas remotas.
  • Saiba mais em unicode_region_subtag no Unicode Technical Standard.
  • Para clientes em que o local não pode ser derivado, o origin.region_code é definido como ZZ.

É possível adicionar dados geográficos aos cabeçalhos de resposta a um endpoint da CDN de mídia (com routing.routeRules[].headerActions[].responseHeadersToAdd[]) ou refletir os dados geográficos fornecidos a uma função do Cloud para validar as diferenças entre as fontes de dados geoIP durante a integração e os testes iniciais.

Além disso, os registros de solicitação da CDN de mídia incluem o clientRegion e outros dados específicos do cliente que podem ser validados em relação às fontes de dados atuais.

A seguir