Google Cloud Armor: Proteggere le API con Policy WAF Avanzate e Whitelist Dinamiche

Esporre endpoint di backend o microservizi critici direttamente su Internet senza uno strato di protezione perimetrale avanzato è uno dei rischi architetturali più elevati nel Cloud.

Anche in presenza di autenticazione robusta basata su token o chiavi segrete, gli endpoint pubblici sono costantemente bersagliati da scansioni automatiche, attacchi di brute-force, tentativi di injection e richieste DDoS Layer 7.

In questo articolo tecnico analizziamo come abbiamo implementato per i nostri clienti un perimetro di sicurezza di livello enterprise utilizzando Google Cloud Armor, il Web Application Firewall (WAF) e DDoS mitigation service nativo di Google Cloud Platform.

1. L’Architettura Perimetrale con Cloud Armor

Cloud Armor opera a monte dell’infrastruttura, direttamente sui Google Cloud Global External Application Load Balancer, ispezionando il traffico prima che raggiunga le istanze di backend (Cloud Run, GKE o Compute Engine):

+-------------------+      1. Richiesta HTTP/S       +------------------------------------+
|   Client / Bot    | -----------------------------> |  Global External Load Balancer     |
+-------------------+                                +------------------------------------+
                                                                    |
                                                                    v
                                                     +------------------------------------+
                                                     |  Google Cloud Armor Security Policy |
                                                     |  - Regole OWASP ModSecurity Core   |
                                                     |  - Path Isolation (/callback/*)    |
                                                     |  - IP Whitelist & Geo-Blocking     |
                                                     |  - Rate Limiting & Bot Defense     |
                                                     +------------------------------------+
                                                                    |
                                           +------------------------+------------------------+
                                           | [Traffico Consentito]                           | [Traffico Negato]
                                           v                                                 v
                        +------------------------------------+                         +------------+
                        | Backend Microservices (Cloud Run)  |                         | HTTP 403   |
                        +------------------------------------+                         +------------+

2. Blindare gli Endpoint Sensibili: Il Caso /callback/*

Un’esigenza frequente nelle architetture multi-cloud (es. server primari su Hetzner o on-premises che dialogano con microservizi su GCP) è consentire l’accesso a determinate API interne o webhook solo a specifici IP autorizzati, bloccando qualsiasi altro tentativo proveniente dal web pubblico.

Con Cloud Armor abbiamo strutturato una policy differenziata:

• Default Action: ALLOW per le rotte pubbliche generali dell’applicazione.
• Regola ad Alta Priorità per Path Sensibili: DENY (403) su pattern come /callback o /callback/*.
• Regola di Whitelist Prioritaria (Bypass Rule): ALLOW per gli specifici indirizzi IPv4/IPv6 dei server remoti di fiducia e per l’IP di uscita Cloud NAT dell’infrastruttura.

Snippet di Definizione Terraform:

resource "google_compute_security_policy" "api_backend_policy" {
  name        = "api-backend-protection-policy"
  description = "Protezione WAF per backend con isolamento rotte sensibili"

  # 1. Regola di bypass per IP noti verso rotte callback
  rule {
    action   = "allow"
    priority = "1000"
    match {
      expr {
        expression = "inIpRange(origin.ip, '49.13.121.22/32') && request.path.matches('/callback.*')"
      }
    }
    description = "Allow trusted remote IP to callback endpoints"
  }

  # 2. Blocco di tutte le altre richieste verso /callback
  rule {
    action   = "deny(403)"
    priority = "2000"
    match {
      expr {
        expression = "request.path.matches('/callback.*')"
      }
    }
    description = "Block public access to callback endpoints"
  }

  # 3. Regola di default per il traffico pubblico ordinario
  rule {
    action   = "allow"
    priority = "2147483647"
    match {
      versioned_expr = "SRC_IPS_V1"
      config {
        src_ip_ranges = ["*"]
      }
    }
    description = "Default allow rule for public routes"
  }
}

3. Rate Limiting e Prevenzione Brute-Force

Oltre al filtraggio basato su percorsi e IP, Cloud Armor consente di applicare il Rate Limiting nativo a livello di indirizzo IP client o chiave utente:

• Soglia: Max 100 richieste ogni 60 secondi per singolo IP.
• Azione in caso di superamento: Blocco temporaneo (deny(429)) per 5 minuti (Ban Duration).
• Vantaggio: I microservizi di backend non vengono sovraccaricati e non subiscono spike di consumo CPU o costi imprevisti di autoscaling.

4. Monitoraggio e Log di Sicurezza su Cloud Logging

Tutte le decisioni di Cloud Armor vengono loggate in streaming su Cloud Logging. Configurando metriche personalizzate e notifiche push via webhook, il team SecOps riceve alert immediati in caso di anomalie:

• Picchi improvvisi di risposte 403 Forbidden generate da Cloud Armor.
• Tentativi di scansione coordinati da botnet o crawler non autorizzati.

Conclusioni

Implementare Google Cloud Armor consente di bloccare le minacce direttamente al perimetro globale di Google, riducendo drasticamente la superficie di attacco e garantendo che solo il traffico legittimo raggiunga i microservizi applicativi.