Configurazione dei criteri di sicurezza

Media CDN utilizza i criteri di sicurezza di Google Cloud Armor per prevenire attacchi indesiderati dal traffico verso i suoi servizi. Puoi consentire o rifiutare le richieste in base seguenti:

  • Indirizzi e intervalli IPv4 e IPv6 (CIDR)
  • Codice paese (area geografica)
  • Filtro di livello 7

Queste funzionalità ti consentono di limitare il download di contenuti a utenti di gruppi specifici località in cui sono previste limitazioni relative alle licenze dei contenuti, consenti solo l'accesso indirizzi IP per accedere a endpoint di test o di gestione temporanea e di negare un elenco di indirizzi IP client non validi.

Puoi decorare le richieste consentite da Google Cloud Armor inserendole intestazioni con nomi e valori configurabili.

I criteri di sicurezza di Google Cloud Armor si applicano a tutti i contenuti pubblicati da Media CDN, inclusi i contenuti e gli errori della cache.

I criteri di sicurezza di Google Cloud Armor sono configurati Servizio Media CDN: tutte le richieste destinate al servizio Il criterio di sicurezza viene applicato in modo coerente per gli indirizzi IP (o nomi host). A servizi diversi possono essere applicati criteri di sicurezza diversi e puoi creare più servizi per aree geografiche diverse in base alle esigenze.

Per una protezione più granulare dei contenuti a livello di singolo utente, ti consigliamo utilizzando URL e cookie firmati in combinazione con un criterio Google Cloud Armor.

Media CDN non prende in considerazione l'intestazione referer durante la valutazione delle regole dei criteri di sicurezza perimetrale del filtro dell'intestazione di livello 7 quando impostato su uno dei seguenti valori:

  • Più URL
  • Un URL relativo
  • Un URL assoluto valido contenente informazioni sugli utenti o un componente di frammenti

Configurazione dei criteri di sicurezza

Segui le istruzioni riportate di seguito per configurare un criterio di sicurezza.

Prima di iniziare

Per collegare un criterio di sicurezza di Google Cloud Armor a Media CDN verifica quanto segue:

Devi disporre anche delle seguenti autorizzazioni di Identity and Access Management per autorizzare, creare e collega i criteri di sicurezza a un servizio Media CDN:

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

Utenti che devono collegare un certificato esistente a Media CDN richiedono solo le seguenti autorizzazioni IAM:

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

Il ruolo roles/networkservices.edgeCacheUser include tutte queste opzioni autorizzazioni aggiuntive.

Crea un criterio di sicurezza

I criteri di sicurezza di Google Cloud Armor sono composti da diverse regole, che includono ogni regola che definisce un insieme di criteri di corrispondenza (un'espressione) per una richiesta, e un'azione. Ad esempio, un'espressione può contenere logica di corrispondenza per clienti con sede in India, con l'azione associata allow. Se una richiesta non corrisponde alla regola, Google Cloud Armor continua a valutare alla regola successiva, fino a quando non avrai eseguito tutte le regole.

I criteri di sicurezza hanno una regola predefinita con un'azione allow. Il valore predefinito consente le richieste che non corrispondono alle regole precedenti. Questo può essere modificato deny regola quando vuoi allow solo le richieste che corrispondono alle regole precedenti e rifiutare tutti gli altri.

L'esempio seguente mostra come creare una regola che blocchi tutti i client geolocalizzato in Australia con HTTP 403 e consente tutte le altre richieste.

gcloud

Per creare un nuovo criterio di tipo CLOUD_ARMOR_EDGE, utilizza la proprietà Comando gcloud compute security-policies create:

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

Viene creato un criterio con una regola di autorizzazione predefinita impostata sul livello più basso priorità (priority: 2147483647):

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

Dopodiché puoi aggiungere una regola con una priorità più alta:

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

L'output è il seguente:

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 esamini il criterio, vedi le due regole: la prima regola blocca delle richieste provenienti dall'Australia (origin.region_code == 'AU') e seconda, la regola con priorità più bassa, consente a tutto il traffico che non corrisponde alla una o più regole di priorità.

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

Aggiungi regole a un criterio di sicurezza

I criteri di sicurezza di Google Cloud Armor sono insiemi di regole che corrispondono Attributi di livello 7 per proteggere le applicazioni rivolte all'esterno i servizi di machine learning. Ogni regola viene valutata in base al traffico in entrata.

Questi attributi possono essere utilizzati per le richieste HTTP nei criteri di sicurezza: request.headers, request.method, request.path, request.scheme e request.query. Per ulteriori informazioni sulla scrittura di espressioni per la sicurezza sulle regole dei criteri, consulta Riferimento al linguaggio delle regole personalizzate di Google Cloud Armor.

Una regola del criterio di sicurezza di Google Cloud Armor è composta da una condizione di corrispondenza e un'azione da eseguire quando questa condizione è soddisfatta.

gcloud

Per creare una regola per un criterio di sicurezza, utilizza la gcloud compute security-policies rules create PRIORITY un comando kubectl. Sostituisci PRIORITY con la priorità della regola nel norme:

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

Collega un criterio a un servizio

gcloud

Per collegare un criterio Google Cloud Armor esistente a un servizio Media CDN, utilizza Comando gcloud edge-cache services update:

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

Aggiorna una regola in un criterio di sicurezza

Utilizza queste istruzioni per aggiornare una singola regola in un ambiente Google Cloud Armor criteri di sicurezza. In alternativa, puoi aggiornare atomicamente più regole in un criteri di sicurezza.

gcloud

Utilizza la 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
  ]

Ad esempio, il comando seguente aggiorna una regola con priorità 1111 in consenti il traffico dall'intervallo di indirizzi 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"

Per aggiornare la priorità di una regola, devi utilizzare l'API REST. Per maggiori informazioni informazioni, consulta Metodo securityPolicies.patchRule.

Visualizza un allegato ai criteri

Per esaminare quali criteri sono associati a un servizio esistente, controlla (descrivi) quel servizio.

gcloud

Per visualizzare il criterio Google Cloud Armor collegato a un servizio Media CDN, utilizza Comando gcloud edge-cache services describe:

gcloud edge-cache services describe MY_SERVICE

Il campo edgeSecurityPolicy del servizio descrive criterio allegato:

name: "MY_SERVICE"
edgeSecurityPolicy: "SECURITY_POLICY

Rimuovere un criterio

Per rimuovere un criterio esistente, aggiorna il servizio associato e trasmetti un campo vuoto come criterio.

gcloud

Utilizza la Comando gcloud edge-cache services update: 

gcloud edge-cache services update MY_SERVICE 

  --edge-security-policy=""

Il campo edgeSecurityPolicy è ora omesso dall'output dell'attributo gcloud edge-cache services describe MY_SERVICE .

Esempi

Considera i seguenti casi d'uso di esempio dettagliati.

Esempio: identificare le richieste bloccate

Devi avere attivato il logging per un determinato perimetro Servizio cache per la registrazione delle richieste bloccate.

Le richieste consentite o rifiutate da un criterio di filtro vengono registrate su Logging. Per filtrare le richieste rifiutate, procedi nel seguente modo Query di logging per la configurazione prod-video-service sarebbe:

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

Esempio: personalizzare i codici di risposta

Le regole di Google Cloud Armor possono essere configurate in modo che restituiscano un codice di stato specifico come azione associata a una determinata regola. Nella maggior parte dei casi, è meglio restituire un codice HTTP 403 (deny-403) per indicare chiaramente che il client bloccati dalla regola.

I codici di stato supportati sono:

  • HTTP 403 (non consentito)
  • HTTP 404 (non trovato)
  • HTTP 502 (Gateway non valido)

L'esempio seguente mostra come configurare il codice di stato restituito:

Per specificare un'azione tra [allow | deny-403 | deny-404 | deny-502] associati alla regola, esegui questo comando. Questo esempio configura della regola per restituire un errore HTTP 502.

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

Ogni regola in un criterio di sicurezza può definire una risposta al codice di stato diversa.

Esempio: rifiutare i client all'esterno di un paese, ad eccezione degli indirizzi IP consentiti

Un caso comune nella pubblicazione di contenuti multimediali è quello di negare le connessioni dai client che sono al di fuori della regione per la quale disponi di licenze per i contenuti o meccanismi di pagamento.

Ad esempio, potresti voler consentire solo i clienti ubicati in India e Qualsiasi indirizzo IP presente nella lista consentita, inclusi quelli dei partner della rete di contenuti. e i tuoi dipendenti, nell'intervallo 192.0.2.0/24 e rifiuta tutti gli altri.

L'utilizzo del Regole personalizzate di Google Cloud Armor lingua, per ottenere questo risultato:

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

Questa espressione è configurata come regola allow, con un valore predefinito deny una regola configurata per corrispondere a tutti gli altri client. Criteri di sicurezza hanno sempre una regola predefinita. In genere lo configuri per default deny il traffico che non gestisci consentito in modo esplicito. In altri casi, puoi scegliere di bloccare del traffico default allow tutto il resto del traffico.

Nell'output del criterio di sicurezza, tieni presente quanto segue:

  • La regola con priorità più alta (priority: 0) consente il traffico dall'India OR dall'elenco di indirizzi IP definito.
  • La regola con priorità più bassa rappresenta un default deny. Il motore delle regole nega a tutti i client che le regole con priorità più elevata non restituiscono true.
  • Puoi combinare più regole utilizzando operatori booleani.

Queste norme consentono il traffico proveniente dai clienti in India, da un intervallo IP definito e nega tutto il traffico.

Quando visualizzi i dettagli delle norme, l'output è simile al seguente:

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

Puoi anche impostare un'intestazione della risposta personalizzata con la variabile di intestazione {region_code}. Questa intestazione può essere ispezionata utilizzando JavaScript e vengono riflesse al client.

Esempio: bloccare i client dannosi in base all'indirizzo e agli intervalli IP

L'utilizzo del Regole personalizzate di Google Cloud Armor lingua, per ottenere questo risultato:

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

Puoi bloccare intervalli IP fino a una maschera /8 in IPv4 e /32 in IPv6. R il caso comune delle piattaforme di flussi di dati è il blocco degli intervalli IP in uscita dei proxy o VPN per ridurre al minimo la circonvenzione delle licenze sui contenuti:

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

Sono supportati entrambi gli intervalli di indirizzi IPv4 e IPv6.

Esempio: consentire solo un elenco fisso di aree geografiche

Se hai un elenco di codici paese, puoi utilizzare l'operatore booleano O || per combinare le condizioni di corrispondenza.

L'utilizzo del Regole personalizzate di Google Cloud Armor lingua, la seguente espressione consente agli utenti identificati come provenienti dall'Australia o Nuova Zelanda:

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

Inoltre, è possibile combinare questa opzione con le espressioni origin.ip o inIpRange(origin.ip, '...') per consentire a tester, partner e agli intervalli IP aziendali. anche se non provengono da una delle aree geografiche specificate.

Per ogni regola esiste il numero documentato di sottoespressioni con un'espressione personalizzata. Se devi combinare più sottoespressioni, definisci più regole all'interno di un singolo criterio.

Esempio: bloccare i clienti di un insieme specifico di paesi

Un esempio meno comune potrebbe essere il blocco dei clienti provenienti da un determinato insieme di paesi, ma consentire comunque le richieste da tutti gli altri paesi.

Per farlo, crei una norma che blocca sia il paese sia qualsiasi la cui regione non può essere determinata, per poi passare una regola di autorizzazione predefinita per tutte le altre richieste.

L'esempio seguente descrive una norma che blocca i clienti in Canada. dei client la cui località è sconosciuta, ma consente tutto il traffico:

  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

Esempio: rifiutare le richieste di contenuti memorizzati nella cache con intestazioni specifiche

Un criterio di sicurezza perimetrale si applica a tutte le richieste che hanno come target qualsiasi servizio Media CDN che a cui è associato un criterio. L'applicazione di questo criterio viene eseguita prima di qualsiasi cache . Le richieste non consentite dal criterio di sicurezza perimetrale vengono rifiutate con il codice di stato configurato.

La seguente espressione trova corrispondenze con le richieste dall'indirizzo IP 1.2.3.4 che contengono la stringa user1 nell'intestazione user-agent:

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

Il seguente comando aggiunge la regola di filtro 105 al criterio di sicurezza perimetrale my-edge-policy, collegato a un servizio 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"

Misure di applicazione di Logging

Ogni log delle richieste fornisce i dettagli sul criterio di sicurezza è stata applicata e se la richiesta è stata consentita (ALLOW) o rifiutata (DENY).

Per attivare il logging, assicurati che logConfig.enable sia impostato su true nel tuo completamente gestito di Google Cloud. I servizi senza log abilitati non registrano gli eventi dei criteri di sicurezza.

Quando un cliente si trova al di fuori degli Stati Uniti e viene applicata una norma di sicurezza chiamata L'deny-non-us-clients è in vigore che nega le richieste che hanno origine al di fuori Negli Stati Uniti, questa è la voce di log per una richiesta rifiutata:

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

I servizi a cui non è collegato alcun criterio Google Cloud Armor contengono no_policy come il valore di enforcedSecurityPolicy.name e un outcome di ALLOW. Per Ad esempio, una voce di log delle richieste per un servizio senza un Il criterio collegato ha i seguenti valori:

enforcedSecurityPolicy:
  name: no_policy
  outcome: ALLOW

Informazioni sulle classificazioni GeoIP

Media CDN si basa sulla classificazione IP interna di Google origini dati per ricavare una località (regione, stato, provincia o città) da un . Se esegui la migrazione o la suddivisione del traffico tra più istanze provider, a volte un piccolo numero di indirizzi IP potrebbe essere associato località diverse.

  • Google Cloud Armor utilizza la certificazione ISO 3166-1 alpha 2 i codici regione per associare un client a una posizione geografica.
  • Ad esempio, US per gli Stati Uniti o AU per Australia.
  • In alcuni casi, una regione corrisponde a un paese, ma non è sempre il caso per verificare se è così. Ad esempio, il codice US include tutti gli stati degli Stati Uniti stati, un distretto e sei aree periferiche.
  • Per saperne di più, consulta unicode_region_subtag nello standard tecnico Unicode.
  • Per i clienti in cui non è possibile ricavare la località, origin.region_code impostata su ZZ.

Puoi aggiungere dati geografici e intestazioni delle risposte a un endpoint Media CDN (con routing.routeRules[].headerActions[].responseHeadersToAdd[]) o rispecchiare le i dati geografici forniti a un account Cloud Funzione per convalidare eventuali differenze tra le origini dati geoIP durante le fasi di integrazione e test iniziali.

Inoltre, i log delle richieste di Media CDN includono il campo clientRegion e altri dati specifici del cliente che puoi convalidare in base ai dati esistenti fonti.

Passaggi successivi