Configura policy di sicurezza

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

  • 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)
  • Numeri di sistema autonomo (ASN)

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

Cloud Armor si integra con ASN per consentirti di consentire o bloccare il traffico di rete proveniente da ASN specifici. Le policy di sicurezza perimetrale di Cloud Armor possono utilizzare l'ASN associato all'indirizzo IP di origine, come determinato dall'operatore di rete responsabile di questi prefissi IP, per controllare il flusso di traffico.

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

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

Le policy di sicurezza di Cloud Armor si applicano a tutti i contenuti gestiti da Media CDN, inclusi i contenuti memorizzati nella cache e i fallimenti della cache.

Le policy di sicurezza di Cloud Armor sono configurate per ogni servizio Media CDN: tutte le richieste destinate all'indirizzo IP (o ai nomi host) del servizio hanno la policy di sicurezza applicata in modo coerente. A servizi diversi possono essere applicate policy di sicurezza diverse 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 firmati e cookie firmati insieme a una policy di Cloud Armor.

Media CDN non considera l'intestazione referer durante la valutazione delle regole delle policy di sicurezza perimetrale per il filtro delle intestazioni di livello 7 quando è impostata su uno dei seguenti valori:

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

Configura policy di sicurezza

Utilizza le seguenti istruzioni per configurare una policy di sicurezza.

Prima di iniziare

Per collegare una policy di sicurezza di Cloud Armor a un servizio Media CDN, assicurati di:

  • Avere familiarità con Cloud Armor.
  • Avere un servizio Media CDN esistente a cui vuoi applicare la policy.
  • (Facoltativo, ma consigliato) Attivare il logging sul servizio Media CDN in modo da poter identificare le richieste bloccate.

Per autorizzare, creare e collegare policy di sicurezza a un servizio Media CDN, devi disporre anche delle seguenti autorizzazioni 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

Le policy di sicurezza di Cloud Armor sono composte 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 client che si trovano in India, con l'azione associata allow. Se una richiesta non corrisponde alla regola, Cloud Armor continua a valutare la regola successiva, finché non vengono tentate tutte le regole.

Le policy di sicurezza hanno una regola predefinita con un'azione allow. La regola predefinita consente le richieste che non corrispondono alle regole precedenti. Questa 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 blocca tutti i client geolocalizzati in Australia con un codice HTTP 403 e consente tutte le altre richieste.

gcloud

Per creare una nuova policy di tipo CLOUD_ARMOR_EDGE, utilizza il gcloud compute security-policies create comando:

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

Viene creata una policy con una regola di autorizzazione predefinita con la priorità più bassa (priority: 2147483647):

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

Poi 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 la policy, 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

Aggiungi regole a una policy di sicurezza

Le policy di sicurezza di 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 policy di sicurezza: request.headers, request.method, request.path, request.scheme e request.query. Per saperne di più sulla scrittura di espressioni per le regole delle policy di sicurezza, consulta il riferimento per il linguaggio delle regole personalizzate di Cloud Armor.

Una regola di una policy di sicurezza di Cloud Armor è costituita da una condizione di corrispondenza e da un'azione da intraprendere quando la condizione è soddisfatta.

gcloud

Per creare una regola per una policy di sicurezza, utilizza il gcloud compute security-policies rules create PRIORITY comando. Sostituisci PRIORITY con la priorità della regola nella policy:

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 una policy a un servizio

gcloud

Per collegare una policy di Cloud Armor esistente a un servizio Media CDN, utilizza il gcloud edge-cache services update comando:

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

Aggiorna una regola in una policy di sicurezza

Utilizza queste istruzioni per aggiornare una singola regola in una policy di sicurezza di Cloud Armor. In alternativa, puoi aggiornare in modo atomico più regole in una policy di sicurezza.

gcloud

Utilizza il gcloud compute security-policies rules update comando:

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 per consentire 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 saperne di più, consulta il metodo securityPolicies.patchRule.

Visualizza un collegamento a una policy

Per esaminare la policy collegata a un servizio esistente, ispeziona (descrivi) il servizio.

gcloud

Per visualizzare la policy di Cloud Armor collegata a un servizio Media CDN, utilizza il gcloud edge-cache services describe comando:

gcloud edge-cache services describe MY_SERVICE

Il campo edgeSecurityPolicy del servizio descrive la policy collegata:

name: "MY_SERVICE"
edgeSecurityPolicy: "SECURITY_POLICY

Rimuovi una policy

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

gcloud

Utilizza il gcloud edge-cache services update comando:

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

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

Esempi

Considera i seguenti esempi di casi d'uso dettagliati.

Esempio: identifica le richieste bloccate

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

Le richieste consentite o negate da una policy di filtro vengono registrate in Cloud Logging. Per filtrare le richieste rifiutate, la seguente query di Cloud Logging per la configurazione prod-video-service avrà il seguente aspetto:

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

Esempio: personalizza i codici di risposta

Puoi configurare una regola di Cloud Armor in modo che restituisca un codice di stato specifico come azione associata a una determinata regola. Nella maggior parte dei casi, è preferibile restituire un codice di stato HTTP 403 DENY per segnalare 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

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 comando seguente. Questo esempio configura la regola in modo che restituisca 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 in una policy di sicurezza può definire una risposta con un codice di stato diverso.

Esempio: nega i client al di fuori di un paese, ad eccezione degli indirizzi IP consentiti

Un caso comune nella gestione dei contenuti multimediali è negare le connessioni dai client che si trovano al di fuori della regione per la quale disponi di licenze sui contenuti o meccanismi di pagamento.

Ad esempio, potresti voler consentire solo i client che si trovano in India, nonché tutti gli indirizzi IP inclusi nella lista consentita, inclusi quelli dei partner di contenuti e dei tuoi dipendenti, nell'intervallo 192.0.2.0/24 e rifiutare tutti gli altri.

Utilizzando il linguaggio delle regole personalizzate di Cloud Armor, la seguente espressione raggiunge questo obiettivo:

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. Le policy di sicurezza hanno sempre una regola predefinita. In genere, questa regola viene configurata in modo da default deny il traffico che non consenti esplicitamente. In altri casi, potresti scegliere di bloccare traffico moderato e default allow tutto il resto.

Nell'output della policy di sicurezza, tieni presente quanto segue:

  • La regola con la priorità più alta (priority: 0) consente il traffico dall'India OR 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ù alta non restituiscono il valore true.
  • Puoi combinare più regole utilizzando gli operatori booleani.

La policy consente il traffico proveniente da client in India, consente i client provenienti da un intervallo IP definito e nega tutto il resto del traffico.

Quando visualizzi i dettagli della policy, 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 esaminata utilizzando JavaScript e riflessa al client.

Esempio: blocca il traffico proveniente da IP dannosi noti

La seguente espressione del linguaggio delle regole personalizzate di Cloud Armor blocca il traffico proveniente da indirizzi IP identificati come dannosi:

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

L'espressione indica a Cloud Armor di confrontare le richieste in entrata con l'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 policy di sicurezza perimetrale con le regole di Google Threat Intelligence.

I seguenti comandi Google Cloud CLI mostrano come aggiungere una nuova regola di Google Threat Intelligence a una policy 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: blocca i client dannosi per indirizzo IP e intervalli IP

Utilizzando il linguaggio delle regole personalizzate di Cloud Armor, la seguente espressione raggiunge questo obiettivo:

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 è bloccare gli intervalli IP in uscita dei provider di proxy o VPN per ridurre al minimo l'elusione 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 sia gli intervalli di indirizzi IPv4 sia 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 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"

Questa espressione può essere combinata anche con le espressioni origin.ip o inIpRange(origin.ip, '...') per consentire i tester, i partner e gli 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 una singola policy.

Esempio: blocca i client provenienti da un insieme specifico di paesi

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

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

L'esempio seguente descrive una policy che blocca i client provenienti dal Canada, nonché tutti i client per cui la località è 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: nega le richieste di contenuti memorizzati nella cache con intestazioni specifiche

Una policy di sicurezza perimetrale si applica a tutte le richieste che hanno come target qualsiasi servizio Media CDN a cui è collegata la policy. L'applicazione di questa policy avviene prima di qualsiasi ricerca nella cache. Le richieste non consentite dalla policy di sicurezza perimetrale vengono negate 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 alla policy di sicurezza perimetrale my-edge-policy, collegata 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"

Registra i provvedimenti

Ogni log delle richieste fornisce dettagli sulla policy di sicurezza 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 servizio. I servizi per cui il logging non è attivato non registrano gli eventi delle policy di sicurezza.

Quando un client si trova al di fuori degli Stati Uniti ed è in vigore una policy di sicurezza denominata deny-non-us-clients che nega le richieste provenienti da paesi diversi dagli Stati Uniti, questa è la voce di log per una richiesta negata:

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

I servizi senza una policy di Cloud Armor collegata contengono no_policy come valore di enforcedSecurityPolicy.name e un outcome di ALLOW. Ad esempio, una voce di log delle richieste per un servizio senza una policy collegata 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 derivare una località (regione, stato, provincia o città) da un indirizzo IP. Se stai eseguendo la migrazione o la suddivisione del traffico tra più provider, un piccolo numero di indirizzi IP potrebbe a volte essere associato a località diverse.

  • 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 saperne di più, consulta unicode_region_subtag nello standard tecnico Unicode.
  • Per i client per cui non è possibile derivare la località, 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