Configura policy di sicurezza

Media CDN utilizza i criteri di sicurezza di Google Cloud Armor per impedire che il traffico indesiderato colpisca i suoi servizi. Puoi consentire o negare le richieste in base a quanto segue:

• Indirizzi e intervalli IPv4 e IPv6 (CIDR)
• Codice paese (geografia)
• Filtri a livello 7

Queste funzionalità ti consentono di limitare i download dei contenuti agli utenti in località specifiche in cui hai limitazioni per le licenze dei contenuti, di consentire solo agli indirizzi IP aziendali di accedere agli endpoint di test o di staging e di negare un elenco di indirizzi IP client non validi noti.

Puoi decorare le richieste consentite da Google Cloud Armor inserendo intestazioni personalizzate 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 memorizzati nella cache e i fallimenti della cache.

I criteri di sicurezza di Google Cloud Armor sono configurati per singolo servizio Media CDN: a tutte le richieste destinate all'indirizzo IP (o agli host name) del servizio viene applicato il criterio di sicurezza in modo coerente. A servizi diversi possono essere applicati criteri di sicurezza diversi e, se necessario, puoi creare più servizi per aree geografiche diverse.

Per una protezione più granulare dei contenuti a livello di utente, ti consigliamo di utilizzare 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 di filtro degli intestazioni di livello 7 se è impostata su uno dei seguenti valori:

• Più URL
• Un URL relativo
• URL assoluti validi contenenti informazioni sull'utente o un componente del frammento

Configura policy 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 un servizio Media CDN, assicurati di quanto segue:

• Devi conoscere Google Cloud Armor.
• Avere un servizio Media CDN esistente a cui vuoi applicare il criterio.
• (Facoltativo, ma consigliato) Abilita il logging sul servizio Media CDN per poter identificare le richieste bloccate.

Per autorizzare, creare e collegare i criteri di sicurezza a un servizio Media CDN, sono necessarie anche le seguenti autorizzazioni di Identity and Access Management:

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

Gli utenti che devono allegare un certificato esistente a un servizio Media CDN necessitano solo di queste autorizzazioni IAM:

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

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

Crea una policy di sicurezza

I criteri di sicurezza di Google Cloud Armor sono composti da diverse regole, con ciascuna regola che definisce un insieme di criteri di corrispondenza (un'espressione) per una richiesta e un'azione. Ad esempio, un'espressione può contenere una logica di corrispondenza per i clienti in India, con l'azione associata allow. Se una richiesta non corrisponde alla regola, Google Cloud Armor continua a valutare la regola successiva finché non sono stati provati tutti i criteri.

I criteri di sicurezza hanno una regola predefinita con un'azione allow. La regola predefinita consente le richieste che non corrispondono alle regole precedenti. Questa operazione può essere modificata in una regola deny quando vuoi allow solo le richieste che corrispondono alle regole precedenti e rifiutare tutte le altre.

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

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

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

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

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

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

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

Aggiungere regole a un criterio di sicurezza

I criteri di sicurezza di Google Cloud Armor sono insiemi di regole che corrispondono agli attributi di livello 7 per proteggere le applicazioni o i servizi rivolti all'esterno. 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 le regole dei criteri di sicurezza, consulta il riferimento per il 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 da un'azione da eseguire quando la condizione è soddisfatta.

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

Collegare un criterio a un servizio

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

Aggiornare una regola in un criterio di sicurezza

Segui queste istruzioni per aggiornare una singola regola in un criterio di sicurezza di Google Cloud Armor. In alternativa, puoi aggiornare in modo atomico più regole in un criterio di sicurezza.

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
  ]
  

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"

Visualizzare un allegato del criterio

Per esaminare i criteri associati a un servizio esistente, ispeziona (descrivi) il servizio.

gcloud edge-cache services describe MY_SERVICE

name: "MY_SERVICE"
edgeSecurityPolicy: "SECURITY_POLICY

Rimuovere una norma

Per rimuovere un criterio esistente, aggiorna il servizio associato e passa una stringa vuota come criterio.

gcloud edge-cache services update MY_SERVICE 

  --edge-security-policy=""

Esempi

Considera i seguenti casi d'uso dettagliati.

Esempio: identificare le richieste bloccate

Affinché le richieste bloccate vengano registrate, devi abilitare il logging per un determinato servizio Edge Cache.

Le richieste consentite o rifiutate da un criterio di filtro vengono registrate nel logging. Per filtrare in base alle richieste rifiutate, la seguente query di logging per la configurazione prod-video-service avrà il seguente aspetto:

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 per restituire 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 è stato bloccato dalla regola.

I codici di stato supportati sono:

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

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

Per specificare uno dei valori [allow | deny-403 | deny-404 | deny-502] come azione associata alla regola, esegui il seguente comando. Questo esempio configura la regola per restituire un codice 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 del codice di stato diversa.

Esempio: nega l'accesso ai client al di fuori di un paese, ad eccezione degli indirizzi IP consentiti

Un caso comune nella pubblicazione di contenuti multimediali è la negazione delle connessioni da parte di client 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 in India, nonché tutti gli indirizzi IP presenti nella lista consentita, inclusi quelli dei partner per i contenuti e dei tuoi dipendenti, nell'intervallo 192.0.2.0/24 e rifiutare tutti gli altri.

Utilizzando il linguaggio delle regole personalizzate di Google Cloud Armor, la seguente espressione consente di ottenere questo risultato:

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

Questa espressione è configurata come regola allow, con una regola deny predefinita configurata per trovare corrispondenze con tutti gli altri client. I criteri di sicurezza hanno sempre una regola predefinita. In genere, viene configurato per il traffico default deny che non autorizzoli esplicitamente. In altri casi, puoi scegliere di bloccare parte del traffico e default allow tutto il resto.

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

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

Il criterio consente il traffico proveniente da client in India, da client di un intervallo IP definito e nega tutto il resto del traffico.

Quando visualizzi i dettagli del criterio, 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 di risposta personalizzata con la variabile di intestazione {region_code}. Questo header può essere esaminato utilizzando JavaScript e riflesso al client.

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

Utilizzando il linguaggio delle regole personalizzate di Google Cloud Armor, la seguente espressione consente di 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 una /32 in IPv6. Un caso comune per le piattaforme di streaming è il blocco degli intervalli IP in uscita dei proxy o dei fornitori di VPN per ridurre al minimo la circonvenzione delle licenze dei 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 sia gli intervalli di indirizzi IPv4 sia quelli IPv6.

Esempio: consenti solo un elenco fisso di aree geografiche

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

Utilizzando il linguaggio delle regole personalizzate di Google Cloud Armor, la seguente espressione consente agli utenti identificati come provenienti dall'Australia o dalla Nuova Zelanda:

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

Inoltre, può essere combinato con le espressioni origin.ip o inIpRange(origin.ip, '...') per consentire l'accesso a tester, partner e intervalli IP aziendali anche se non provengono da una delle aree geografiche specificate.

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

Esempio: bloccare i clienti di un insieme specifico di paesi

Un esempio meno comune potrebbe essere bloccare i clienti di un determinato insieme di paesi, ma consentire le richieste da tutti gli altri paesi.

Per farlo, crea una norma che blocchi sia il paese sia tutti i client per i quali non è possibile determinare la regione, quindi passa a una regola di autorizzazione predefinita per tutte le altre richieste.

L'esempio seguente descrive un criterio che blocca i client provenienti dal Canada, nonché tutti i client di cui non è nota la posizione, ma consente tutto il resto del 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 a cui è associato il criterio. L'applicazione di questo criterio avviene prima di qualsiasi ricerca nella cache. Le richieste non consentite dal criterio di sicurezza dell'edge vengono rifiutate con il codice di stato configurato.

La seguente espressione corrisponde alle 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 dell'edgemy-edge-policy, associato a un servizio CDN Media:

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"
    

Registrazione dei provvedimenti

Ogni log delle richieste fornisce dettagli su quale norma di sicurezza è stata applicata e se la richiesta è stata consentita (ALLOW) o rifiutata (DENY).

Per attivare la registrazione, assicurati che logConfig.enable sia impostato su true nel servizio. I servizi per i quali non sono stati attivati i log non registrano gli eventi dei criteri di sicurezza.

Quando un client si trova al di fuori degli Stati Uniti ed è in vigore un criterio di sicurezza chiamato deny-non-us-clients che nega le richieste provenienti al di fuori degli Stati Uniti, questa è la voce di log per una richiesta rifiutata:

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

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

enforcedSecurityPolicy:
  name: no_policy
  outcome: ALLOW

Informazioni sulle classificazioni GeoIP

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

• Google Cloud Armor utilizza i codici regione ISO 3166-1 alpha 2 per associare un client a una posizione geografica.
• Ad esempio, US per gli Stati Uniti o AU per l'Australia.
• In alcuni casi, una regione corrisponde a un paese, ma non sempre è così. Ad esempio, il codice US include tutti gli stati degli Stati Uniti, un distretto e sei aree periferiche.
• Per ulteriori informazioni, consulta unicode_region_subtag nello standard tecnico Unicode.
• Per i client di cui non è possibile dedurre la posizione, il valore origin.region_code è impostato su ZZ.

Puoi aggiungere dati geografici alle intestazioni di risposta a un endpoint Media CDN (con routing.routeRules[].headerActions[].responseHeadersToAdd[]) o riflettere i dati geografici forniti a una funzione Cloud per convalidare eventuali differenze tra le origini dati geoIP durante l'integrazione e i test iniziali.

Inoltre, i log delle richieste di Media CDN includono clientRegion e altri dati specifici del client che puoi convalidare in base alle tue fonti di dati esistenti.

Passaggi successivi

• Scopri come utilizzare le richieste firmate per autorizzare i contenuti in base all'utente.
• Consulta la documentazione di riferimento delle regole di Google Cloud Armor per capire come le regole di corrispondenza IP e geografica possono essere espresse e combinate.
• Consulta la documentazione sul logging per capire come eseguire query sui log delle richieste e controllare quali richieste sono state bloccate.