Configure políticas de segurança

A RFC 7230 define o campo User-Agent como um campo de cabeçalho que contém informações sobre o agente do utilizador que está a fazer o pedido. Pode permitir ou recusar pedidos 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 Google Cloud Armor Enterprise)
  • Números de sistemas autónomos (ASNs)

Estas capacidades permitem-lhe restringir as transferências de conteúdo a utilizadores em localizações específicas onde tem restrições de licenciamento de conteúdo, permitir apenas que endereços IP corporativos acedam a pontos finais de teste ou preparação e negar uma lista de endereços IP de clientes inválidos conhecidos.

O Cloud Armor integra-se com o ASN para lhe permitir autorizar ou bloquear o tráfego de rede originário de ASNs específicos. As políticas de segurança de limite 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 IP, para controlar o fluxo de tráfego.

Pode decorar pedidos que o Cloud Armor permite inserindo cabeçalhos personalizados com nomes e valores configuráveis.

A integração do Cloud Armor com as informações sobre ameaças da Google permite-lhe 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 aplicam-se a todo o conteúdo publicado a partir da RFC de multimédia, incluindo conteúdo em cache e falhas de cache.

As políticas de segurança do Cloud Armor são configuradas por serviço de RFC de multimédia. Todas as solicitações destinadas ao endereço IP (ou nomes de anfitrião) desse serviço têm a política de segurança aplicada de forma consistente. Podem ser aplicadas políticas de segurança diferentes a diferentes serviços, e pode criar vários serviços para diferentes geografias, conforme necessário.

Para uma proteção mais detalhada do conteúdo ao nível do utilizador, recomendamos a utilização de URLs assinados e cookies assinados em conjunto com uma política do Cloud Armor.

A RFC 7230 não considera o cabeçalho referer durante a avaliação de regras das políticas de segurança de extremidade de filtragem de cabeçalhos da camada 7 quando está definido para qualquer um dos seguintes valores:

  • Vários URLs
  • Um URL relativo
  • URLs absolutos válidos que contenham informações do utilizador ou um componente de fragmento

Configure políticas de segurança

Siga as instruções abaixo 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 do Media CDN, certifique-se de que cumpre os seguintes requisitos:

Também precisa das seguintes autorizações de gestão de identidade e acesso para autorizar, criar e anexar políticas de segurança a um serviço de RFC de multimédia:

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

Os utilizadores que precisam de anexar um certificado existente a um serviço do Media CDN só precisam destas autorizações de IAM:

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

A função roles/networkservices.edgeCacheUser inclui todas estas autorizações.

Crie 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 a definir um conjunto de critérios de correspondência (uma expressão) para um pedido e uma ação. Por exemplo, uma expressão pode conter lógica de correspondência para clientes localizados na Índia, sendo a ação associada allow. Se um pedido não corresponder à regra, o Cloud Armor continua a avaliar a regra seguinte até que todas as regras tenham sido tentadas.

As políticas de segurança têm uma regra predefinida com uma ação allow. A regra predefinida permite pedidos que não correspondem às regras anteriores. Pode alterar esta opção para uma regra deny quando quiser allow apenas pedidos que correspondam às regras anteriores e rejeitar todos os outros.

O exemplo seguinte mostra como criar uma regra que bloqueia todos os clientes geolocalizados na Austrália com um HTTP 403 e permite todos os outros pedidos.

gcloud

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

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

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

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

Em seguida, pode adicionar uma regra com uma prioridade mais elevada:

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

O resultado é o seguinte:

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 inspecionar a política, vê as duas regras: a primeira regra bloqueia os pedidos originários da Austrália (origin.region_code == 'AU') e a segunda regra, com a prioridade mais baixa, permite todo o tráfego que não corresponda à regra (ou regras) com prioridade mais alta.

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

Adicione 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 aplicações ou serviços acessíveis externamente. Cada regra é avaliada relativamente ao tráfego recebido.

Estes atributos podem ser usados para pedidos 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íticas de segurança, consulte a referência da linguagem de regras personalizadas do Cloud Armor.

Uma regra de uma política de segurança do Cloud Armor consiste numa condição de correspondência e numa ação a realizar quando essa condição é cumprida.

gcloud

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

Anexe uma política a um serviço

gcloud

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

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

Atualize uma regra numa política de segurança

Use estas instruções para atualizar uma única regra numa política de segurança do Cloud Armor. Em alternativa, pode atualizar atomicamente várias regras numa política de segurança.

gcloud

Use o 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 exemplo, o comando seguinte atualiza uma regra com a prioridade 1111 para permitir 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, tem de usar a API REST. Para mais informações, consulte o método securityPolicies.patchRule.

Veja um anexo de política

Para rever a política associada a um serviço existente, inspecione (descreva) esse serviço.

gcloud

Para ver a política do Cloud Armor anexada a um serviço do Media CDN, use o comando gcloud edge-cache services describe:

gcloud edge-cache services describe MY_SERVICE

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

name: "MY_SERVICE"
edgeSecurityPolicy: "SECURITY_POLICY

Remova uma política

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

gcloud

Use o comando gcloud edge-cache services update:

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

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

Exemplos

Considere os seguintes exemplos de utilização detalhados.

Exemplo: identificar pedidos bloqueados

Tem de ter o registo ativado para um determinado serviço Edge Cache para que os pedidos bloqueados sejam registados.

Os pedidos permitidos ou recusados por uma política de filtragem são registados no Registo. Para filtrar pedidos rejeitados, a seguinte consulta de registo para a configuração prod-video-service teria o seguinte aspeto:

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

Exemplo: personalizar códigos de resposta

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

Os códigos de estado suportados são:

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

O exemplo seguinte mostra como configurar o código de estado devolvido:

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

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

Um caso comum na publicação de conteúdo multimédia é a recusa de ligações de clientes que estão fora da região para a qual tem licenças de conteúdo ou mecanismos de pagamento.

Por exemplo, pode querer permitir apenas clientes localizados na Índia, bem como todos os endereços IP que estejam na lista de autorizações, incluindo os de parceiros de conteúdo e os 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 seguinte expressão consegue este resultado:

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

Esta expressão está configurada como uma regra allow, com uma regra deny predefinida configurada para corresponder a todos os outros clientes. As políticas de segurança têm sempre uma regra predefinida. Normalmente, configura isto para o tráfego default deny que não permite explicitamente. Noutros casos, pode optar por bloquear algum tráfego e default allow todo o outro tráfego.

No resultado da política de segurança, tenha em atenção o seguinte:

  • A regra de prioridade mais elevada (priority: 0) permite tráfego da Índia OU da lista definida de endereços IP.
  • A regra de prioridade mais baixa representa um default deny. O motor de regras recusa todos os clientes para os quais as regras de prioridade mais alta não são avaliadas como verdadeiras.
  • Pode combinar várias regras através de operadores booleanos.

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

Quando vê os detalhes da política, o resultado é semelhante ao seguinte:

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 pode definir um cabeçalho de resposta personalizado com a variável de cabeçalho {region_code}. Este cabeçalho pode ser inspecionado através de JavaScript e refletido no cliente.

Exemplo: bloqueie tráfego de IPs maliciosos conhecidos

A expressão da linguagem de regras personalizadas do Cloud Armor seguinte 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 os pedidos recebidos com base na lista constantemente atualizada da Google de endereços IP maliciosos conhecidos e oferece uma proteção robusta e automática.

Para bloquear automaticamente endereços IP maliciosos, pode configurar as suas políticas de segurança de limite com regras de informações sobre ameaças da Google.

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

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

Usando a linguagem de regras personalizadas do Cloud Armor, a seguinte expressão consegue este resultado:

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

Pode bloquear intervalos de IP até uma máscara /8 no IPv4 e /32 no IPv6. Um caso comum para plataformas de streaming é o bloqueio dos intervalos de IP de saída de proxies ou fornecedores de VPNs para minimizar a evasão da 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')

São suportados intervalos de endereços IPv4 e IPv6.

Exemplo: permitir apenas uma lista fixa de geografias

Se tiver uma lista de códigos de países, pode usar o operador booleano OU || para combinar condições de correspondência.

Usando a linguagem de regras personalizadas do Cloud Armor, a seguinte expressão permite utilizadores identificados como provenientes da Austrália ou da Nova Zelândia:

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

Além disso, pode combinar esta opção com expressões origin.ip ou inIpRange(origin.ip, '...') para permitir que testadores, parceiros e os seus intervalos de IP corporativos acedam ao conteúdo, mesmo que não sejam de uma das geografias especificadas.

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

Exemplo: bloqueie 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, caso contrário, permitir pedidos de todos os outros países.

Para tal, crie uma política que bloqueie o país e todos os clientes cuja região não possa ser determinada e, em seguida, recorra a uma regra de autorização predefinida para todos os outros pedidos.

O exemplo seguinte descreve uma política que bloqueia clientes do Canadá, bem como clientes cuja localização é desconhecida, 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: recusar pedidos de conteúdo em cache com cabeçalhos específicos

Uma política de segurança de limite aplica-se a todos os pedidos que segmentam qualquer serviço de CDN de multimédia ao qual a política está anexada. Esta aplicação de políticas ocorre antes de qualquer pesquisa na cache. Os pedidos que não são permitidos pela política de segurança de limite são recusados com o código de estado configurado.

A seguinte expressão corresponde a pedidos 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 seguinte adiciona a regra de filtragem 105 à política de segurança de limite my-edge-policy, que está anexada a um serviço de CDN de multimé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"

Registo de ações de aplicação

Cada registo de pedidos fornece detalhes sobre a política de segurança que foi aplicada e se o pedido foi permitido (ALLOW) ou rejeitado (DENY).

Para ativar o registo, certifique-se de que logConfig.enable está definido como true no seu serviço. Os serviços sem registos ativados não registam eventos de política de segurança.

Quando um cliente está localizado fora dos Estados Unidos e está em vigor uma política de segurança denominada deny-non-us-clients que recusa pedidos originados fora dos EUA, esta é a entrada de registo para um pedido recusado:

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 do registo de pedidos para um serviço sem uma política anexada tem os seguintes valores:

enforcedSecurityPolicy:
  name: no_policy
  outcome: ALLOW

Compreenda as classificações de GeoIP

A RFC depende de origens de dados de classificação de IP internas da Google para derivar uma localização (região, estado, província ou cidade) a partir de um endereço IP. Se estiver a migrar ou a dividir o tráfego entre vários fornecedores, por vezes, um pequeno número de endereços IP pode estar associado a localizações diferentes.

  • O Cloud Armor usa códigos de regiões ISO 3166-1 alfa 2 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 é assim. Por exemplo, o código US inclui todos os estados dos Estados Unidos, um distrito e seis áreas periféricas.
  • Para mais informações, consulte unicode_region_subtag na norma técnica Unicode.
  • Para clientes em que não é possível obter a localização, o valor de origin.region_code é definido como ZZ.

Pode adicionar dados geográficos aos cabeçalhos de resposta a um ponto final da RFC (com routing.routeRules[].headerActions[].responseHeadersToAdd[]) ou refletir os dados geográficos fornecidos a uma função da nuvem para validar quaisquer diferenças entre origens de dados geoIP durante a integração e os testes iniciais.

Além disso, os registos de pedidos da RFC de multimédia na nuvem incluem o clientRegion e outros dados específicos do cliente que pode validar em relação às suas origens de dados existentes.

O que se segue?