Protezione al bordo con Cloud Armor

Google Cloud Armor si colloca davanti all’external Application Load Balancer e ispeziona il traffico Layer 7 prima che raggiunga i backend. Una security policy è un insieme ordinato di rule (match + action allow/deny/throttle) valutate per priorità. Esistono due tipi: le backend security policy proteggono i backend service, mentre le edge security policy filtrano al confine della rete Google, utili per contenuto servito da Cloud CDN.

Le preconfigured WAF rules derivano dall’OWASP ModSecurity Core Rule Set e coprono SQLi, XSS, LFI/RFI, RCE; si attivano con sensitivity level crescenti, bilanciando copertura e falsi positivi. Il rate limiting (throttle e rate-based ban) mitiga abusi applicativi e credential stuffing. Adaptive Protection usa ML per rilevare attacchi DDoS Layer 7 anomali e propone rule già pronte, ma richiede Cloud Armor Enterprise. Fondamentale la preview mode: applica una rule in sola logging per validarla contro il traffico reale prima di renderla bloccante.

Attenzione allo scope: le WAF rule e il rate limiting valgono solo per il traffico HTTP(S) dietro l’Application Load Balancer. Per attacchi volumetrici su protocolli non-HTTP serve Advanced Network DDoS Protection (anch’essa parte di Cloud Armor Enterprise) sui network load balancer / IP esterni. Cloud Armor protegge dalla minaccia esterna: non è un controllo contro l’esfiltrazione dei dati, che è compito di VPC Service Controls.

Accesso zero-trust con Identity-Aware Proxy

Identity-Aware Proxy applica l’autorizzazione a livello applicativo: ogni richiesta HTTP(S) verso App Engine, Cloud Run, GKE o VM dietro un load balancer passa per IAP, che verifica l’identità e valuta una IAM policy (ruolo IAP-secured Web App User). Il risultato è il modello BeyondCorp: nessuna VPN, nessun perimetro di rete implicito, l’accesso dipende dall’identità autenticata e non dall’essere “dentro la rete”. Il backend può fidarsi dell’header JWT firmato da IAP per conoscere l’utente. IAP TCP forwarding estende lo stesso principio a SSH/RDP verso VM prive di IP pubblico, sostituendo i bastion host esposti.

Context-aware access e device trust

Lo zero-trust maturo non guarda solo “chi” accede, ma anche “in quali condizioni”. Con Access Context Manager si definiscono access level basati su attributi di contesto: indirizzo IP/subnet, region geografica, stato del dispositivo (device policy via Endpoint Verification, come storage cifrato o OS aggiornato). Questi access level si applicano alle risorse protette da IAP (BeyondCorp Enterprise) e possono far parte di un perimetro VPC Service Controls. Così si concede l’app, per esempio, solo da dispositivi aziendali gestiti e da region approvate, negando il resto.

Terminazione TLS gestita

Il load balancer termina TLS. I Google-managed SSL certificate automatizzano emissione e rinnovo; Certificate Manager scala su molti domini e su certificati wildcard. La postura crittografica si controlla con le SSL policy, che impongono la minimum TLS version (es. TLS 1.2) e il set di cipher (profili come MODERN o RESTRICTED). Il managed certificate risolve il ciclo di vita del certificato, ma è la SSL policy — non il certificato — a irrigidire versione e cifrari.

Trappole tipiche d’esame

  • App web da proteggere da SQLi/XSS → soluzione: Cloud Armor preconfigured WAF rules (OWASP CRS) su una security policy, non le VPC firewall rule, che operano a Layer 3/4 e non ispezionano il payload HTTP.
  • Accesso a un’app interna senza VPN → soluzione: Identity-Aware Proxy con IAM, non un bastion o un firewall per IP; per SSH/RDP verso VM senza IP pubblico usa IAP TCP forwarding.
  • Accesso solo da dispositivi gestiti o da certe region → soluzione: access level di Access Context Manager (context-aware access) applicati a IAP, non ruoli IAM statici che ignorano il contesto.
  • DDoS volumetrico su protocolli non-HTTP → soluzione: Advanced Network DDoS Protection di Cloud Armor Enterprise, non le WAF rule, valide solo dietro l’Application Load Balancer.
  • Forzare TLS 1.2 minimo e cifrari forti → soluzione: SSL policy sul load balancer, non il managed certificate, che gestisce solo emissione e rinnovo.
  • Testare una nuova rule Cloud Armor senza bloccare utenti legittimi → soluzione: preview mode (solo logging), poi promozione a enforcing dopo l’analisi dei match.