A Media CDN usa políticas de segurança do Google Cloud Armor para evitar que o tráfego indesejado acesse os serviços. Você pode 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
Com esses recursos, você pode restringir os downloads de conteúdo para usuários em locais específicos em que você tem restrições de licenciamento de conteúdo, permitir apenas endereços IP corporativos para acessar endpoints de teste ou de preparação e negar uma lista de endereços IP de clientes inválidos conhecidos.
É possível decorar solicitações que o Google Cloud Armor permite inserindo cabeçalhos personalizados com nomes e valores configuráveis.
As políticas de segurança do Google Cloud Armor se aplicam a todo o conteúdo veiculado pelo Media CDN, incluindo conteúdo em cache e ausências no cache.
As políticas de segurança do Google Cloud Armor são configuradas por serviço do Media CDN. 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. É possível aplicar políticas de segurança diferentes a serviços distintos, e você pode criar vários serviços para diferentes localidades, conforme necessário.
Para uma proteção mais detalhada do conteúdo por usuário, recomendamos usar URLs e cookies assinados em conjunto com uma política do Google Cloud Armor.
A CDN de mídia não considera o cabeçalho referer
durante a avaliação de regras das políticas de segurança de filtro de cabeçalho da camada 7 quando ele é definido para qualquer 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 Google Cloud Armor a um serviço de CDN de mídia, siga estas etapas:
- Conheça o Google Cloud Armor.
- Ter um serviço de CDN de mídia em que você quer aplicar a política.
- Opcional, mas recomendado: ative o registro no seu serviço da Media CDN 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 de 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 do Media CDN precisam apenas 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 Google Cloud Armor são compostas por várias regras, e
cada regra define 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 uma 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 Google Cloud Armor vai continuar avaliando
a próxima regra até que todas sejam 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
comando gcloud compute security-policies create
:
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, adicione uma regra com 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
Se você inspecionar a política, verá as duas regras: a primeira bloqueia solicitações originadas da Austrália (origin.region_code == 'AU'
), e a segunda, de prioridade mais baixa, permite todo o tráfego que não corresponde à regra de 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
Adicionar regras a uma política de segurança
As políticas de segurança do Google 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.
Estes 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 da linguagem de regras personalizadas do Google Cloud Armor.
Uma regra de política de segurança do Google 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
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
Anexar uma política a um serviço
gcloud
Para anexar uma política do Google Cloud Armor 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
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 Google Cloud Armor. Você também pode atualizar atomicamente várias regras em uma política de segurança.
gcloud
Use o comando gcloud compute security-policies rules update
(em inglês).
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
método securityPolicies.patchRule
.
Conferir um anexo de política
Para conferir qual política está anexada a um serviço, inspecione (descreva) esse serviço.
gcloud
Para conferir a política do Google 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
Remover uma política
Para remover uma política atual, atualize o serviço associado e transmita uma string vazia como a política.
gcloud
Use o comando gcloud edge-cache services update
(em inglês).
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 detalhados de casos de uso.
Exemplo: identificar solicitações bloqueadas
É necessário ter a geração de registros ativada para um determinado serviço de cache do Edge para que as solicitações bloqueadas sejam registradas.
As solicitações permitidas ou negadas por uma política de filtragem são registradas no
Registro. Para filtrar solicitações rejeitadas, a seguinte
consulta de geração de registros
para a configuração prod-video-service
seria:
resource.type="edge_cache_service" jsonPayload.statusDetails="denied_by_security_policy"
Exemplo: personalizar códigos de resposta
As regras do Google Cloud Armor podem ser configuradas 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 HTTP 403 (deny-403
) para indicar claramente que o cliente foi
bloqueado pela regra.
Os códigos de status compatíveis são:
- HTTP 403 (Proibido)
- HTTP 404 (não encontrado)
- HTTP 502 (gateway inválido)
O exemplo a seguir demonstra como configurar o código de status retornado:
Para especificar uma das [allow | deny-403 | deny-404 | deny-502]
como a ação
associada à regra, execute o comando a seguir. Este exemplo configura
a regra para retornar um 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 endereços IP permitidos
Um caso comum no fornecimento 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, você pode permitir apenas clientes localizados na Índia, bem como
qualquer endereço IP que esteja na lista de permissões, incluindo os de parceiros de conteúdo
e seus próprios funcionários, dentro do intervalo 192.0.2.0/24
, e rejeitar todos os outros.
Usando a linguagem das regras personalizadas do Google Cloud Armor, a expressão a seguir consegue 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 o tráfego default deny
que não é permitido explicitamente. Em outros casos, você pode bloquear parte do tráfego e
default allow
todo o tráfego.
Na saída da política de segurança, observe o seguinte:
- A regra de prioridade mais alta (
priority: 0
) permite o tráfego da Índia OU da lista de endereços IP definida. - A regra de prioridade mais baixa representa um
default deny
. O mecanismo de regras nega a todos os clientes que as regras de prioridade mais alta não são avaliadas 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 tráfego restante.
Quando você confere 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 para o cliente.
Exemplo: bloquear clientes maliciosos por endereço e intervalo de IP
Usando a linguagem das regras personalizadas do Google Cloud Armor, a expressão a seguir consegue 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 provedores
de VPN ou proxies para minimizar a evasão 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 compatíveis.
Exemplo: permitir apenas uma lista fixa de localidades
Se você tiver uma lista de códigos de país, use o operador booleano OR ||
para
combinar as condições de correspondência.
Usando a linguagem das regras personalizadas do Google Cloud Armor, a expressão a seguir permite que usuários identificados como vindos da Austrália ou da Nova Zelândia:
origin.region_code == "AU" || origin.region_code == "NZ"
Além disso, é possível combinar isso com expressões origin.ip
ou inIpRange(origin.ip,
'...')
para permitir que testadores, parceiros e seus intervalos de IP corporativos acessem,
mesmo que não sejam de uma das localidades especificadas.
Há o número documentado de subexpressões de 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 pode ser determinada e, em seguida, acesse 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 qualquer cliente em que o local seja desconhecido, mas permite todo o 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 é aplicada a todas as solicitações que segmentam qualquer serviço do Media CDN ao qual a política está anexada. Essa aplicação de política ocorre antes de qualquer pesquisa de cache. As solicitações que não são permitidas pela política de segurança perimetral 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 do 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"
Como 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
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, negando solicitações originadas 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 Google 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 usa as fontes de dados de classificação de IP internas do Google para extrair um local (região, estado, província ou cidade) de um endereço IP. Se você estiver migrando de ou dividindo o tráfego entre vários provedores, um pequeno número de endereços IP poderá ser associado a locais diferentes.
- O Google Cloud Armor usa códigos de região ISO 3166-1 Alfa 2 para associar um cliente a um local geográfico.
- Por exemplo,
US
para os Estados Unidos ouAU
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. - Para mais informações, consulte unicode_region_subtag no Unicode Technical Standard.
- Para clientes em que o local não pode ser derivado, o
origin.region_code
é definido comoZZ
.
É possível adicionar
dados geográficos aos cabeçalhos de resposta
a um endpoint do Media CDN (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 origens de dados de geoIP durante a integração e o teste iniciais.
Além disso, os registros de solicitação do Media CDN incluem clientRegion
e outros dados específicos do cliente que podem ser validados com suas fontes de dados
existentes.
A seguir
- Saiba como usar solicitações assinadas para autorizar conteúdo por usuário.
- Consulte a referência de regras do Google Cloud Armor para entender como as regras de correspondência geográfica e de IP podem ser expressas e combinadas.
- Acesse a documentação de geração de registros para entender como consultar os registros de solicitações e verificar quais solicitações foram bloqueadas.