Configura policy di sicurezza

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

• Indirizzi e intervalli IPv4 e IPv6 (CIDR)
• Codice paese (area geografica)
• Filtro di livello 7
• Google Threat Intelligence (richiede il livello Google Cloud Armor Enterprise)

Queste funzionalità ti consentono di limitare i download di contenuti agli utenti in località specifiche in cui hai limitazioni di licenza dei contenuti, consentire l'accesso agli endpoint di test o di staging solo agli indirizzi IP aziendali e negare l'accesso a un elenco di indirizzi IP client dannosi noti.

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

L'integrazione di Google Cloud Armor con Google Threat Intelligence ti consente di controllare il traffico da indirizzi IP e domini dannosi noti, fornendo una protezione avanzata dalle minacce.

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 servizio Media CDN. Tutte le richieste destinate all'indirizzo IP (o ai nomi host) del servizio hanno il criterio di sicurezza applicato in modo coerente. 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 di utilizzare URL firmati 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 filtraggio delle intestazioni di livello 7 quando è impostata su uno dei seguenti valori:

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

Configura policy di sicurezza

Per configurare una policy di sicurezza, segui queste istruzioni.

Prima di iniziare

Per collegare un criterio di sicurezza di Google Cloud Armor a un servizio Media CDN, assicurati che:

• Acquisire familiarità con Google Cloud Armor.
• Avere un servizio Media CDN esistente a cui vuoi applicare il criterio.
• Facoltativo, ma consigliato: attiva la registrazione nel servizio Media CDN per poter identificare le richieste bloccate.

Per autorizzare, creare e collegare le norme 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 collegare un certificato esistente a un servizio Media CDN richiedono solo 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 ogni 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 che si trovano 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 state provate tutte le regole.

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

Il seguente esempio mostra come creare una regola che blocca tutti i client geolocalizzati in Australia con un errore HTTP 403 e consente 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 la priorità più bassa, consente tutto il traffico che non corrisponde alla regola (o alle regole) con priorità più 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

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 applicazioni o servizi esposti esternamente. Ogni regola viene valutata in relazione al traffico in entrata.

Questi attributi possono essere utilizzati per le richieste HTTP nelle norme 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 di un criterio di sicurezza di Google Cloud Armor è costituita da una condizione di corrispondenza e da un'azione da intraprendere 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 una policy a un servizio

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 criterio di sicurezza di Google Cloud Armor. In alternativa, puoi aggiornare in modo atomico più regole in una policy 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 di policy

Per esaminare le norme associate 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 una policy esistente, aggiorna il servizio associato e trasmetti una stringa vuota come policy.

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

Esempi

Prendi in considerazione i seguenti casi d'uso dettagliati.

Esempio: identifica le richieste bloccate

Per registrare le richieste bloccate, devi aver abilitato il logging per un determinato servizio Edge Cache.

Le richieste consentite o rifiutate da una norma di filtraggio vengono registrate in Logging. Per filtrare le richieste rifiutate, la seguente query di logging per la configurazione prod-video-service avrebbe il seguente aspetto:

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

Esempio: personalizzare i codici di risposta

Puoi configurare una regola Google Cloud Armor per restituire un codice di stato specifico come azione associata a una determinata regola. Nella maggior parte dei casi, è meglio restituire un codice di stato HTTP 403 DENY per indicare chiaramente che il client è stato bloccato dalla regola.

I codici di stato supportati sono:

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

Il seguente esempio mostra come configurare il codice di stato restituito:

Per specificare uno dei valori di [allow | deny-403 | deny-404 | deny-502] come azione associata alla regola, esegui questo comando. Questo esempio configura la regola per restituire un codice di stato 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 di una norma di sicurezza può definire una risposta con un codice di stato diverso.

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

Un caso comune nella pubblicazione di contenuti multimediali è il rifiuto di connessioni da client che si trovano al di fuori della regione per la quale disponi di licenze per i contenuti o meccanismi di pagamento.

Ad esempio, potresti voler consentire solo ai client che si trovano in India, nonché a tutti gli indirizzi IP inclusi nella lista consentita, compresi quelli dei partner dei 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 ottiene 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 in modo che corrisponda a tutti gli altri client. I criteri di sicurezza hanno sempre una regola predefinita. In genere, questa impostazione viene configurata per default deny il traffico che non consenti esplicitamente. In altri casi, potresti scegliere di bloccare parte del traffico e default allow tutto il resto.

Nell'output del criterio di sicurezza, prendi nota di quanto segue:

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

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

Quando visualizzi i dettagli della norma, 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 delle risposte personalizzata con la variabile di intestazione {region_code}. Questa intestazione può essere esaminata utilizzando JavaScript e riflessa al client.

Esempio: bloccare il traffico proveniente da IP dannosi noti

I seguenti blocchi di espressioni del linguaggio delle regole personalizzate di Google Cloud Armor bloccano il traffico proveniente da indirizzi IP identificati come dannosi:

evaluateThreatIntelligence('iplist-known-malicious-ips')

L'espressione indica a Google Cloud Armor di controllare le richieste in entrata rispetto all'elenco costantemente aggiornato di indirizzi IP dannosi noti di Google e fornisce una protezione solida e automatizzata.

Per bloccare automaticamente gli indirizzi IP dannosi, puoi configurare le tue policy di sicurezza perimetrale con le regole di Google Threat Intelligence.

I seguenti comandi Google Cloud CLI mostrano come aggiungere una nuova regola Google Threat Intelligence a un criterio esistente, ad esempio 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"

Esempio: bloccare i client dannosi per indirizzo IP e intervalli IP

Utilizzando il linguaggio delle regole personalizzate di Google Cloud Armor, la seguente espressione ottiene 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. 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 l'elusione 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: consentire 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"

Queste espressioni possono essere combinate anche con origin.ip o inIpRange(origin.ip, '...') per consentire a tester, partner e intervalli IP aziendali, anche se non provengono da una delle aree geografiche specificate.

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

Esempio: bloccare i clienti di un insieme specifico di paesi

Un esempio meno comune potrebbe essere quello di bloccare i client di un determinato insieme di paesi, ma consentire altrimenti le richieste di 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, per poi passare a una regola di autorizzazione predefinita per tutte le altre richieste.

Il seguente esempio descrive un criterio che blocca i client provenienti dal Canada, nonché tutti i client la cui posizione è sconosciuta, 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 è collegato il criterio. L'applicazione di questo criterio avviene prima di qualsiasi ricerca nella cache. Le richieste non consentite dalla policy di sicurezza perimetrale vengono rifiutate con il codice di stato configurato.

La seguente espressione corrisponde alle richieste provenienti 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 edge 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"
    

Registrazione dei provvedimenti

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

Per attivare la registrazione, assicurati che logConfig.enable sia impostato su true nel tuo servizio. I servizi senza log abilitati 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 dall'esterno 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 è associata alcuna policy 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 allegato ha i seguenti valori:

enforcedSecurityPolicy:
  name: no_policy
  outcome: ALLOW

Informazioni sulle classificazioni GeoIP

Media CDN si basa sulle origini dati interne di classificazione IP di Google per derivare una località (regione, stato, provincia o città) da un indirizzo IP. Se esegui la migrazione da più provider o dividi il traffico tra più provider, 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 maggiori informazioni, consulta unicode_region_subtag nello standard tecnico Unicode.
• Per i client per i quali non è possibile derivare la posizione, origin.region_code è impostato su ZZ.

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

Inoltre, i log delle richieste di Media CDN includono clientRegion e altri dati specifici del client che puoi convalidare rispetto alle origini dati esistenti.

Passaggi successivi

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