Security Command Center: posture e threat detection

Security Command Center (SCC) è il piano di controllo della sicurezza a livello di organization: va abilitato in cima alla gerarchia per avere visibilità completa su asset e finding. Devi distinguere i built-in service, perché l’esame chiede spesso “quale servizio rileva cosa”:

  • Security Health Analytics (SHA): rileva le misconfiguration in modo continuo (bucket con allUsers, binding IAM troppo permissivi, firewall aperti, dischi senza CMEK). È posture management preventivo, non runtime.
  • Event Threat Detection (ETD): analizza in near-real-time i Cloud Logging alla ricerca di minacce attive (brute-force SSH, crypto mining, grant IAM anomali, malware).
  • Container Threat Detection e Web Security Scanner coprono i layer specifici.

I finding si gestiscono con severità e mute rule e si esportano via Pub/Sub o BigQuery. Il tier Premium/Enterprise abilita ETD, attack path simulation e la maggior parte dei detector; lo Standard offre un SHA ridotto.

Cloud Audit Logs e Cloud Logging

Esistono quattro tipi di audit log e per l’esame conta soprattutto il loro comportamento di default:

  • Admin Activity: sempre attivo, non disabilitabile, senza costo. Traccia le operazioni che modificano config o metadata (le scritture).
  • Data Access: da abilitare esplicitamente (eccetto BigQuery, già attivo). Traccia le letture dei dati e genera volumi elevati.
  • System Event: sempre attivo, generato dalla piattaforma.
  • Policy Denied: registra gli accessi negati da una policy, ad esempio da VPC Service Controls.

Per una detection scalabile usa un aggregated sink a livello di organization che routa i log verso BigQuery, Pub/Sub o Cloud Storage senza dipendere dai singoli progetti. La lettura dei Data Access log richiede il ruolo Private Logs Viewer. Cloud Logging alimenta le log-based metric e Cloud Monitoring gestisce alerting e dashboard.

Incident response e remediation automatica

Il pattern canonico di automazione è: finding SCC → notifica Pub/Sub → Cloud Function che applica la remediation (rimuove allUsers da un bucket, revoca un binding IAM, disabilita una risorsa). Automatizza le risposte ripetitive, ma logga ogni azione per l’audit. Per il contenimento manuale di un incidente pensa a difesa in profondità: disabilita e ruota le credenziali compromesse (service account key, chiavi in Cloud KMS), isola la risorsa con firewall rule restrittive e conserva le evidenze nei log.

Container security e Binary Authorization

Su GKE la difesa in profondità combina più controlli: private cluster, Shielded GKE nodes, Workload Identity per accedere alle API Google senza service account key statiche sul nodo (non montare mai file JSON di chiave nei pod), Container Threat Detection per il runtime e la vulnerability scanning delle immagini in Artifact Registry.

Binary Authorization è un controllo deploy-time: consente il deploy solo di immagini firmate da attestor fidati secondo una policy, su GKE e Cloud Run. Non è uno scanner né un controllo runtime. Le modalità sono enforced-blocking (blocca il deploy non conforme) e dry-run (audita in Cloud Audit Logs senza bloccare). Continuous Validation ricontrolla nel tempo i pod già in esecuzione; il breakglass permette un override d’emergenza, che resta però registrato nei log.

Trappole tipiche d’esame

  • Rilevare bucket pubblici o IAM troppo permissivo → Security Health Analytics: è posture statica, non ETD (che copre le minacce attive dai log) né Cloud Armor (WAF/DDoS perimetrale).
  • Rilevare brute-force SSH o crypto mining → Event Threat Detection: minacce runtime dai log; SHA non le vede perché guarda solo la configurazione.
  • Sapere chi ha LETTO i dati di un bucket → abilita i Data Access logs: Admin Activity registra solo le scritture/config, quindi di default le letture non compaiono da nessuna parte.
  • Consentire il deploy delle sole immagini approvate → Binary Authorization: verifica un’attestazione al momento del deploy; Container Analysis/Artifact Registry scanning cerca vulnerabilità ma non blocca il deploy.
  • Accedere alle API Google dai pod GKE senza chiavi → Workload Identity: scaricare una service account key JSON nel container è l’anti-pattern che l’esame propone come distrattore.
  • Remediation automatica di un finding SCC → export Pub/Sub + Cloud Function: SCC rileva e notifica ma non “ripara” da solo; la logica di fix vive nella function innescata dalla notifica.