Infrastruttura GCP sicura
Checklist per il rafforzamento della sicurezza di GCP per team piccoli e medi
Una base di riferimento pratica per i team che eseguono carichi di lavoro di produzione su Google Cloud senza un reparto di sicurezza dedicato. Inizia da dove è più facile ridurre i percorsi più probabili verso un incidente grave.
Percorsi di minaccia comuni in GCP
La maggior parte degli incidenti cloud nasce da una piccola lacuna di responsabilità o di configurazione. Individua questi percorsi prima che lo faccia un attaccante.
- Un utente, un account di servizio o un'identità del carico di lavoro con autorizzazioni eccessive può trasformare una singola credenziale rubata in un accesso esteso a più progetti.
- Un endpoint di gestione esposto, una porta di debug o una regola firewall permissiva possono aggirare ogni controllo pensato per il normale traffico applicativo.
- Un bucket di archiviazione pubblico o un URL firmato troppo permissivo possono esporre dati dei clienti senza alcuna compromissione visibile dell'applicazione.
- I carichi di lavoro obsoleti creano un rischio duraturo quando immagini vecchie, spazi dei nomi dimenticati, account di servizio inutilizzati e risorse senza responsabile restano distribuibili.
- Prove di audit mancanti o conservate per poco tempo rendono difficile stabilire chi ha modificato un criterio, quando è iniziato l'accesso e a quali dati si è arrivati.
- Un backup non testato è solo una speranza. Ripristini non riusciti, conservazione incompleta e chiavi di crittografia inaccessibili possono trasformare un evento di sicurezza in una perdita permanente.
Identità e accesso
Considera l'identità come il piano di controllo principale. Ogni persona, processo di automazione e carico di lavoro deve avere un'identità distinta con uno scopo circoscritto.
Rendi espliciti i confini delle risorse
Usa l'organizzazione e le cartelle per i guardrail e separa sviluppo, staging e produzione in progetti distinti o dietro confini di attendibilità più rigidi. Applica i criteri dell'organizzazione al livello più alto possibile, limita l'uso dei servizi ed evita di condividere progetti di produzione tra prodotti non correlati.
Concedi il ruolo minimo nell'ambito più ristretto
Preferisci ruoli predefiniti o personalizzati ai ruoli primitivi troppo ampi, concedili a gruppi e identità dei carichi di lavoro e usa le condizioni IAM quando un nome di risorsa o un tag può restringere l'accesso. Esamina le autorizzazioni inutilizzate e rimuovi l'accesso permanente alla produzione che dovrebbe esistere solo tramite una procedura di accesso di emergenza (break-glass).
Elimina le credenziali di lunga durata
Usa Workload Identity Federation for GKE in modo che i pod ricevano credenziali di breve durata senza chiavi di account di servizio esportate. Ove possibile, blocca la creazione e il caricamento delle chiavi con i criteri dell'organizzazione, fai l'inventario delle chiavi rimanenti e configura avvisi sulle modifiche IAM ad alto rischio in Cloud Audit Logs.
Rete e perimetro
Presumi che prima o poi qualche difetto dell'applicazione sarà raggiungibile dalla rete. Limita ciò a cui quel difetto può accedere.
Parti dal rifiuto predefinito e aggiungi percorsi denominati
Usa regole firewall VPC a privilegio minimo e NetworkPolicies Kubernetes per il traffico dei pod. Separa gli ambienti in reti distinte, documenta ogni percorso in ingresso e rimuovi le regole di debug troppo ampie che consentono porte di gestione o tutti i protocolli da ampi intervalli di indirizzi.
Mantieni privati i nodi e i piani di controllo
Disabilita gli indirizzi IP esterni sui nodi GKE. Preferisci l'endpoint privato del piano di controllo basato su DNS e, quando un endpoint IP è inevitabile, limitalo con le reti autorizzate. Fornisci ai carichi di lavoro un percorso di uscita deliberato invece di un accesso esteso a internet.
Pubblica solo i servizi pubblici voluti
Esponi le applicazioni tramite un gateway o un bilanciatore del carico revisionato, non tramite indirizzi di pod o nodi esposti per caso. Esegui la terminazione TLS con certificati gestiti, limita host e percorsi in ingresso, applica limiti alle richieste e alla frequenza e mantieni le interfacce di amministrazione dietro un accesso basato sull'identità.
Dati e segreti
Proteggi i dati inattivi, in transito e in uso, poi dimostra di saperli recuperare. Il rilevamento dei dati fa parte del controllo.
Impedisci l'accesso pubblico accidentale
Applica la prevenzione dell'accesso pubblico e l'accesso uniforme a livello di bucket su Cloud Storage. Classifica i bucket in base alla sensibilità, limita l'accesso a oggetti e chiavi, abilita il logging per i dati di alto valore e usa chiavi di crittografia gestite dal cliente dove il tuo modello di rischio o di conformità lo richiede.
Tieni i segreti fuori da immagini e codice sorgente
Archivia le credenziali in Secret Manager e concedi l'accesso a una specifica identità del carico di lavoro e a una specifica versione del segreto. Ruota i segreti in modo consapevole, evita di copiarli in Git o nelle immagini container e non considerare i normali Kubernetes Secrets un confine di protezione completo.
Testa il ripristino, non solo la creazione dei backup
Definisci obiettivi per il punto di ripristino (RPO) e il tempo di ripristino (RTO), conserva copie al di fuori del dominio di errore della produzione e proteggi l'accesso ai backup e alle chiavi di crittografia dall'identità del carico di lavoro. Esegui ripristini periodici in un ambiente isolato, verifica i dati e registra il tempo impiegato ed eventuali passaggi manuali.
Rafforzamento della sicurezza di GKE
GKE protegge il piano di controllo gestito, ma la configurazione del cluster, gli spazi dei nomi, i criteri di ammissione e i carichi di lavoro restano sotto la tua responsabilità.
Fai degli spazi dei nomi il contratto di isolamento
Separa team e ambienti in spazi dei nomi o cluster, associa in quegli ambiti ruoli Kubernetes RBAC ristretti e applica quote di risorse e NetworkPolicies. Evita l'accesso in scrittura a livello di intero cluster per la delivery delle applicazioni e assegna a ogni carico di lavoro un proprio account di servizio quando necessita di un'identità distinta.
Ammetti solo immagini e configurazioni attendibili
Applica lo standard Pod Security restrittivo o regole Policy Controller equivalenti. Esegui il deployment delle immagini tramite digest immutabile, analizzale per individuare vulnerabilità, usa Binary Authorization quando la provenienza è importante e rifiuta accessi imprevisti all'host, escalation dei privilegi e binding cluster-admin.
Elimina i privilegi non necessari dei container
Esegui i container come utente non root, rimuovi le capability Linux, usa un file system root di sola lettura quando possibile e applica il profilo seccomp RuntimeDefault. Non montare il token dell'account di servizio se non serve, evita container privilegiati e spazi dei nomi dell'host, riduci al minimo i permessi dell'account di servizio dei nodi e usa Shielded Nodes insieme a Container-Optimized OS.
Rilevamento e ripristino
I controlli falliscono. Affidati a prove concrete e a procedure collaudate con esercitazioni, non alla convinzione che nessuno abbia sbagliato.
Raccogli le prove che ti serviranno
Centralizza Cloud Audit Logs e i log di sistema e dei carichi di lavoro GKE in un'unica destinazione, con tempi di conservazione adeguati alle tue esigenze di indagine. Abilita in modo selettivo gli audit log di accesso ai dati per i dati sensibili, limita l'accesso ai log e registra le modifiche amministrative a IAM, firewall, archiviazione e configurazione del cluster.
Configura avvisi per le modifiche rilevanti per la sicurezza
Configura avvisi per esposizione pubblica dell'archiviazione, modifiche estese al firewall o a IAM, chiavi di account di servizio impreviste, rifiuti di ammissione, esposizione del piano di controllo, errori di autenticazione ripetuti, logging disabilitato, backup non riusciti e certificati in scadenza. Indirizza ogni avviso a un responsabile, con i passaggi per confermarlo o scartarlo.
Esercitati nella risposta
Scrivi brevi runbook per credenziali trapelate, dati esposti pubblicamente, carichi di lavoro compromessi e perdita di regioni o progetti. Indica chi può autorizzare il contenimento, come revocare l'accesso, come preservare le prove e come ripristinare il servizio. Testa i runbook con le persone che li useranno.
Una checklist con priorità a 30, 60 e 90 giorni
Se parti da una base di riferimento incompleta, ordina il lavoro in modo da ridurre prima l'esposizione e rendere ripetibili le revisioni successive.
Giorni da 1 a 30: chiudi i percorsi più evidenti
Fai l'inventario di progetti e responsabili, rimuovi le credenziali inutilizzate e di lunga durata, verifica gli audit log, blocca i bucket pubblici, esamina le regole firewall e le concessioni IAM più ampie, individua le lacune nei backup di produzione e correggi ogni endpoint pubblico senza responsabile. Assegna un responsabile e una scadenza a ogni rilievo.
Giorni da 31 a 60: rendi ripetibile la base di riferimento
Porta la configurazione di rete, identità e carichi di lavoro in un'infrastruttura come codice revisionata e in una delivery GitOps. Adotta Workload Identity, nodi privati, Pod Security restrittivo, controlli sulle immagini attendibili, log centralizzati e avvisi per le modifiche più importanti.
Giorni da 61 a 90: dimostralo e mantienilo
Esegui test di ripristino e un'esercitazione tabletop sugli incidenti, rivedi gli accessi privilegiati e la scadenza delle eccezioni, analizza di nuovo immagini e dipendenze, verifica che i responsabili ricevano gli avvisi e misura le lacune rimaste. Inserisci i controlli in un ciclo di revisione periodico prima che le prove diventino obsolete.
Usa questa checklist come punto di partenza. Snow Tree può applicare la base di riferimento nell'ambito della piattaforma gestita o di un intervento di consulenza mirato.
Riferimenti ufficiali
Considera le indicazioni attuali di Google come fonte tecnica di riferimento quando cambiano le impostazioni predefinite della piattaforma o le funzionalità dei prodotti.
Piattaforma gestita