O Media CDN usa as políticas de segurança do Google Cloud Armor para evitar que o tráfego não chegue aos serviços. É possível permitir ou negar solicitações com base no seguintes:
- Endereços e intervalos IPv4 e IPv6 (CIDRs)
- Código do país (região geográfica)
- Filtragem da camada 7
Com esses recursos, você pode restringir o download de conteúdo a usuários locais onde você tem restrições de licenciamento de conteúdo, permite apenas empresas endereços IP para acessar endpoints de teste ou preparo e negar uma lista de endereços IP endereços IP ruins do cliente.
É possível decorar solicitações permitidas pelo Google Cloud Armor inserindo cabeçalhos com nomes e valores configuráveis.
As políticas de segurança do Google Cloud Armor se aplicam a todo o conteúdo disponibilizado por Media CDN, incluindo conteúdo e ausências no cache.
As políticas de segurança do Google Cloud Armor são configuradas serviço Media CDN: todas as solicitações destinadas ao serviço Os endereços IP (ou nomes de host) têm a política de segurança aplicada de maneira consistente. Diferentes serviços podem ter diferentes políticas de segurança 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 detalhada do conteúdo por usuário, recomendamos usando URLs e cookies assinados nos junto com uma política do Google Cloud Armor.
O Media CDN não considera o cabeçalho referer
durante
das políticas de segurança de borda para filtragem do cabeçalho da camada 7
definido como qualquer um destes valores:
- Vários URLs
- Um URL relativo
- URLs absolutos válidos contendo 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 Media CDN serviço, verifique o seguinte:
- Conhecer Google Cloud Armor:
- Ter um serviço do Media CDN em que você quer aplicar a política.
- Opcional, mas recomendado: ative a geração de registros no Media CDN para identificar solicitações bloqueadas.
Você também precisa das seguintes permissões do Identity and Access Management para autorizar, criar e ou anexar políticas de segurança a um serviço do Media CDN:
compute.securityPolicies.addAssociation
compute.securityPolicies.create
compute.securityPolicies.delete
compute.securityPolicies.get
compute.securityPolicies.list
compute.securityPolicies.update
compute.securityPolicies.use
Usuários que precisam anexar um certificado existente a um Media CDN exigem apenas estas permissões do IAM:
compute.securityPolicies.get
compute.securityPolicies.list
compute.securityPolicies.use
O papel roles/networkservices.edgeCacheUser
inclui todos os itens a seguir.
permissões.
Criar uma política de segurança
As políticas de segurança do Google Cloud Armor são compostas de várias regras, com
cada regra que 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 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 continua a avaliar
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 um
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 geolocalizada para a 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 menor
prioridade (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
Ao inspecionar a política, você vê as duas regras: a primeira bloqueia
solicitações originadas da Austrália (origin.region_code == 'AU'
) e as
A segunda é a regra de menor prioridade, que permite todo o tráfego que não corresponda
regra (ou regras) de 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 Google Cloud Armor são conjuntos de regras que correspondem atributos da camada 7 para proteger aplicativos externos ou serviços. 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 de segurança
regras de política, 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
gcloud compute security-policies rules create PRIORITY
comando.
Substitua PRIORITY
pela prioridade da regra no
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 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. Como alternativa, é possível atualizar atomicamente várias regras em uma política de segurança da nuvem.
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
.
Ver um anexo de política
Para revisar qual política está anexada a um serviço atual, inspecione (describe) esse serviço.
gcloud
Para conferir a política do Google Cloud Armor conectada a um
serviço 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 passe um valor 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
gcloud edge-cache services describe MY_SERVICE
kubectl.
Exemplos
Considere os exemplos de casos de uso detalhados a seguir.
Exemplo: identificar solicitações bloqueadas
É preciso ter a geração de registros ativada para um determinado Edge Serviço de cache para solicitações bloqueadas a serem registradas.
As solicitações permitidas ou negadas por uma política de filtragem são registradas para
a geração de registros. Para filtrar as solicitações rejeitadas, faça o seguinte:
Consulta do Logging
Para a configuração prod-video-service
será semelhante a:
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
bloqueados 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 um dos [allow | deny-403 | deny-404 | deny-502]
como a ação
associada à regra, execute o comando a seguir. Este exemplo configura
a regra retornar um erro 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 na veiculação de mídia é negar conexões de clientes que não fora da região em que você tem licenças de conteúdo ou mecanismos de pagamento.
Por exemplo, talvez você queira permitir somente clientes localizados na Índia e
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, dentro do intervalo 192.0.2.0/24
, e rejeitar todos os outros.
Usando o Regras personalizadas do Google Cloud Armor idioma, a expressão a seguir faz isso:
origin.region_code == "IN" || inIpRange(origin.ip, '192.0.2.0/24')
Essa expressão é configurada como uma regra allow
, com um deny
padrão
configurada para corresponder a todos os outros clientes. Políticas de segurança
sempre têm uma regra padrão.
Normalmente, essa configuração é definida para tráfego default deny
que você não
permitir explicitamente. Em outros casos, você pode optar por bloquear parte do tráfego e
default allow
todos os outros tráfegos.
Na saída da política de segurança, observe o seguinte:
- A regra de prioridade mais alta (
priority: 0
) permite tráfego da Índia OR da lista definida de endereços IP. - A regra de prioridade mais baixa representa um
default deny
. Mecanismo de regras nega a todos os clientes que as regras de maior prioridade não são avaliadas como verdadeiras. - É possível combinar várias regras usando operadores booleanos.
A política permite tráfego de clientes na Índia, permite que clientes de um intervalo de IP definido e nega todo o restante do tráfego.
Quando você consultar os detalhes da política, A saída será assim:
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.
pela variável de cabeçalho {region_code}
. Para inspecionar esse cabeçalho, use
JavaScript e refletidas no cliente.
Exemplo: bloquear clientes maliciosos por endereço IP e intervalos de IP
Usando o Regras personalizadas do Google Cloud Armor idioma, a expressão a seguir faz isso:
inIpRange(origin.ip, '192.0.2.2/32') || inIpRange(origin.ip, '192.0.2.170/32')
É possível bloquear intervalos de IP com até uma máscara /8
no IPv4 e uma /32
no IPv6. Um
um caso comum de plataformas de streaming é bloquear os intervalos de IP de saída de proxies
ou provedores de VPN para minimizar a evasão do 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')
Intervalos de endereços IPv4 e IPv6 são compatíveis.
Exemplo: permitir apenas uma lista fixa de regiões geográficas
Se você tiver uma lista de códigos de países, use o operador booleano OR ||
para
combinar condições de correspondência.
Usando o Regras personalizadas do Google Cloud Armor idioma, a expressão a seguir permite que usuários identificados como provenientes da Austrália ou Nova Zelândia:
origin.region_code == "AU" || origin.region_code == "NZ"
Ele também pode ser combinado com expressões origin.ip
ou inIpRange(origin.ip,
'...')
para permitir testadores, parceiros e seus intervalos de IP corporativos.
mesmo que eles não sejam
de uma das regiões geográficas 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 é bloquear clientes de um determinado conjunto de países, mas permitir solicitações de todos os outros países.
Para isso, crie uma política que bloqueia o país e qualquer clientes em que sua região não pode ser determinada e, em seguida, recaem de permissão padrão para todas as outras solicitações.
O exemplo a seguir descreve uma política que também bloqueia clientes do Canadá como qualquer cliente em que o local é desconhecido, mas permite todos os outros tipos de 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 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 do Media CDN que o está anexada. Essa aplicação da política ocorre antes de qualquer cache pesquisa. As solicitações não permitidas pela política de segurança de borda são negadas pelo código de status configurado.
A expressão a seguir corresponde às 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á anexado 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"
Registrando ações de fiscalizaçã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
nos seus
serviço. Serviços sem registros ativados não registram eventos de políticas 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 e nega solicitações originadas fora
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
O Media CDN depende da classificação de IP interno do Google fontes de dados para obter uma localização (região, estado, província ou cidade) de um endereço IP endereço IP. Se você estiver migrando ou dividindo o tráfego de vários de rede, um pequeno número de endereços IP às vezes pode ser associado a em locais diferentes.
- O Google Cloud Armor usa a norma 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 ouAU
para Austrália. - Em alguns casos, uma região corresponde a um país, mas esta nem sempre é o
caso. Por exemplo, o código
US
inclui todos os estados dos Estados Unidos. Estados, um distrito e seis áreas periféricas. - Para mais informações, consulte unicode_region_subtag do padrão técnico do Unicode.
- Para clientes em que o local não pode ser obtido, o
origin.region_code
é definido comoZZ
.
Você pode adicionar
de dados geográficos para cabeçalhos de resposta
a um endpoint do Media CDN (com
routing.routeRules[].headerActions[].responseHeadersToAdd[]
) ou refletem a
dados geográficos fornecidos a um Cloud
função 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 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.
- Revise a referência de regras do Google Cloud Armor entender como as regras de correspondência geográfica e de IP podem ser expressadas e combinados.
- Acesse a documentação de geração de registros para entender como consultar registros de solicitações e verificar quais foram bloqueadas.