Applicazione delle patch di sicurezza

Questo documento descrive come Google gestisce le vulnerabilità di sicurezza e le patch per Google Kubernetes Engine (GKE). Queste informazioni potrebbero essere utili per gli esperti di sicurezza che supportano la risoluzione di problemi o vulnerabilità di sicurezza che richiedono assistenza strategica, come incidenti e problemi riassegnati dall'assistenza.

Responsabilità condivisa per l'applicazione di patch

L'applicazione di patch è una responsabilità condivisa tra Google e il cliente. Piattaforme diverse hanno responsabilità condivise diverse. Per saperne di più, consulta i seguenti argomenti su ciascuna piattaforma:

Come scopriamo le vulnerabilità

Google ha investito molto nella progettazione e nel rafforzamento della sicurezza proattiva, ma anche i sistemi software meglio progettati possono presentare vulnerabilità. Per trovare queste vulnerabilità e correggerle prima che possano essere sfruttate, Google ha effettuato investimenti significativi su più fronti.

Ai fini dell'applicazione di patch, GKE è un livello del sistema operativo con container in esecuzione sopra. I sistemi operativi, Container-Optimized OS o Ubuntu, sono protetti e contengono la quantità minima di software necessaria per eseguire i container. Le funzionalità di GKE vengono eseguite come container sopra le immagini di base. GKE si impegna costantemente a ridurre il numero di dipendenze dei componenti di sistema, il che contribuisce a ridurre la superficie di attacco e a migliorare l'efficienza della gestione delle vulnerabilità. Ad esempio, i componenti di sistema GKE potrebbero utilizzare immagini di base minimali quando possibile.

Google identifica e corregge le vulnerabilità e le patch mancanti nei seguenti modi:

  • Container-Optimized OS: Google analizza le immagini per identificare potenziali vulnerabilità e patch mancanti. Il team di Container-Optimized OS esamina e risolve i problemi.

  • Ubuntu: Canonical fornisce a Google build del sistema operativo a cui sono state applicate tutte le patch di sicurezza disponibili.

Google esegue la scansione dei container utilizzando Container Registry Artifact Analysis per rilevare vulnerabilità e patch mancanti nei container Kubernetes e gestiti da Google. Se sono disponibili correzioni, lo scanner avvia automaticamente il processo di applicazione delle patch e di rilascio.

Oltre alla scansione automatica, Google rileva e corregge le vulnerabilità sconosciute agli scanner nei seguenti modi.

Google esegue audit, penetration test e rilevamento di vulnerabilità su tutte le piattaforme. Per un elenco delle piattaforme, consulta la sezione precedente Patching shared responsibility.

Team specializzati all'interno di Google e fornitori di sicurezza di terze parti affidabili conducono le proprie ricerche sugli attacchi. Google ha collaborato anche con la CNCF per fornire gran parte delle competenze di consulenza organizzativa e tecnica per il controllo della sicurezza di Kubernetes.

Google collabora attivamente con la comunità di ricerca sulla sicurezza tramite diversi programmi di premi per le vulnerabilità. Un programma di premi per le vulnerabilità dedicato Google Cloud offre ricompense significative, inclusi 133.337 $per la migliore vulnerabilità del cloud trovata ogni anno. Per GKE, esiste un programma che premia i ricercatori di sicurezza se riescono a violare i nostri controlli di sicurezza. Il programma copre tutte le dipendenze software di GKE.

Google collabora con altri partner del settore e di software open source che condividono vulnerabilità, ricerche sulla sicurezza e patch prima del rilascio pubblico della vulnerabilità. L'obiettivo di questa collaborazione è quello di correggere grandi parti dell'infrastruttura internet prima che la vulnerabilità venga annunciata al pubblico. In alcuni casi, Google contribuisce a questa community con le vulnerabilità rilevate. Ad esempio, il progetto Zero di Google ha scoperto e reso pubbliche le vulnerabilità Spectre e Meltdown. Il Google Cloud team di sicurezza trova e corregge regolarmente le vulnerabilità nella macchina virtuale basata su kernel (KVM).

La collaborazione di Google in materia di sicurezza avviene a molti livelli. A volte si verifica formalmente tramite programmi in cui le organizzazioni si registrano per ricevere notifiche in anteprima sulle vulnerabilità del software per prodotti come Kubernetes e Envoy. La collaborazione avviene anche in modo informale grazie al nostro coinvolgimento in molti progetti open source come il kernel Linux, i runtime dei container, la tecnologia di virtualizzazione e altri.

Per Kubernetes, Google è un membro attivo e fondatore del Security Response Committee (SRC) e ha scritto gran parte della procedura di rilascio della sicurezza. Google fa parte dell'elenco dei distributori di Kubernetes che ricevono una notifica preventiva delle vulnerabilità ed è coinvolta nel triage, nell'applicazione di patch, nello sviluppo di misure di mitigazione e nella comunicazione di quasi tutte le vulnerabilità di sicurezza gravi di Kubernetes. Google ha anche scoperto diverse vulnerabilità di Kubernetes, come CVE-2019-11254, CVE-2019-11255 e CVE-2021-25741.

Sebbene le vulnerabilità meno gravi vengano scoperte e corrette al di fuori di questi processi, la maggior parte delle vulnerabilità di sicurezza critiche viene segnalata privatamente tramite uno dei canali elencati in precedenza. La segnalazione tempestiva consente a Google di avere tempo prima che la vulnerabilità diventi pubblica per studiare in che modo influisce su GKE, sviluppare patch o mitigazioni e preparare consigli e comunicazioni per i clienti. Se possibile, Google applica patch a tutti i cluster prima del rilascio pubblico della vulnerabilità.

Classificazione delle vulnerabilità

GKE investe molto nella protezione dell'intero stack, inclusi i livelli di sistema operativo, container, Kubernetes e rete, oltre a impostare valori predefiniti validi, configurazioni protette e componenti gestiti. Nel complesso, questi sforzi contribuiscono a ridurre l'impatto e la probabilità di vulnerabilità.

Il team di sicurezza di GKE classifica le vulnerabilità in base al sistema di punteggio delle vulnerabilità di Kubernetes. Le classificazioni prendono in considerazione molti fattori, tra cui la configurazione GKE e l'hardening della sicurezza. A causa di questi fattori e degli investimenti che GKE effettua in sicurezza, le classificazioni delle vulnerabilità di GKE potrebbero differire da altre fonti di classificazione.

La tabella seguente descrive le categorie di gravità delle vulnerabilità:

Gravità Descrizione
Critico Una vulnerabilità facilmente sfruttabile in tutti i cluster da un aggressore remoto non autenticato che porta alla compromissione completa del sistema.
Alta Una vulnerabilità facilmente sfruttabile per molti cluster che comporta la perdita di riservatezza, integrità o disponibilità.
Media Una vulnerabilità sfruttabile per alcuni cluster in cui la perdita di confidenzialità, integrità o disponibilità è limitata da configurazioni comuni, difficoltà dello sfruttamento stesso, accesso richiesto o interazione dell'utente.
Bassa Tutte le altre vulnerabilità. Lo sfruttamento è improbabile o le conseguenze dello sfruttamento sono limitate.

Consulta i bollettini sulla sicurezza per esempi di vulnerabilità, correzioni e mitigazioni e le relative valutazioni.

Come vengono applicate le patch alle vulnerabilità per i cluster GKE

L'applicazione di una patch a una vulnerabilità comporta l'upgrade a un nuovo numero di versione di GKE. Le versioni di GKE includono componenti con controllo delle versioni per il sistema operativo, i componenti Kubernetes e altri container che costituiscono la piattaforma GKE. La correzione di alcune vulnerabilità richiede solo un upgrade del control plane, eseguito automaticamente da Google su GKE, mentre altre richiedono upgrade sia del control plane che dei nodi.

Per mantenere i cluster protetti dalle vulnerabilità di qualsiasi gravità, ti consigliamo di seguire le best practice per gli upgrade dei cluster GKE per assicurarti che il cluster riceva le patch di sicurezza in modo tempestivo.

Google consiglia di eseguire l'upgrade dei cluster Kubernetes almeno una volta al mese. Per un elenco delle piattaforme, consulta la sezione precedente Patching shared responsibility.

Alcuni scanner di sicurezza o controlli manuali della versione potrebbero presupporre erroneamente che un componente come runc o containerd non disponga di una patch di sicurezza specifica upstream. GKE applica regolarmente patch ai componenti ed esegue l'upgrade della versione del pacchetto solo quando necessario, il che significa che i componenti GKE sono funzionalmente simili alle loro controparti upstream anche se il numero di versione del componente GKE non corrisponde al numero di versione upstream. Per informazioni dettagliate su una CVE specifica, consulta i bollettini sulla sicurezza di GKE.

Tempistiche delle patch

L'obiettivo di Google è mitigare le vulnerabilità rilevate entro un periodo di tempo appropriato per i rischi che rappresentano. GKE è incluso nell'ATO provvisoria FedRAMP diGoogle Cloud, che richiede la correzione delle vulnerabilità note entro tempistiche specifiche in base al livello di gravità, come specificato nel controllo RA-5(d) del record di valutazione del rischio (RA) RA-5, "Vulnerability Scanning", nel foglio di lavoro FedRAMP Security Controls Baseline.

Per ogni vulnerabilità nota, l'obiettivo di GKE è rilasciare versioni patch che risolvano la vulnerabilità entro il periodo di tempo corrispondente. L'autorizzazione provvisoria a operare (ATO) FedRAMP non include Google Distributed Cloud, GKE su AWS, GKE su Azure o cluster collegati GKE, ma puntiamo agli stessi tempi di correzione per questi prodotti. Google Cloud Dopo che GKE rende disponibili le versioni patch per correggere una vulnerabilità nota, esegui l'upgrade dei cluster a queste versioni per rispettare le tempistiche di applicazione delle patch per la tua organizzazione.

Come vengono comunicate le vulnerabilità e le patch

La migliore fonte di informazioni aggiornate su vulnerabilità e patch di sicurezza è il feed dei bollettini di sicurezza per i seguenti prodotti:

  • Google Kubernetes Engine (GKE)
  • Google Distributed Cloud (solo software) su VMware
  • GKE su AWS
  • GKE su Azure
  • Google Distributed Cloud (solo software) su bare metal

Questi bollettini seguono uno schema di numerazione delle vulnerabilità comune Google Cloud e sono collegati dalla pagina principale dei bollettini Google Cloud e dalle note di rilascio di GKE. Ogni pagina dei bollettini di sicurezza ha un feed RSS a cui gli utenti possono iscriversi per ricevere aggiornamenti.

A volte le vulnerabilità vengono mantenute private sotto embargo per un periodo di tempo limitato. Gli embarghi contribuiscono a impedire la pubblicazione anticipata di vulnerabilità che potrebbero portare a tentativi di sfruttamento diffusi prima che possano essere adottate misure per risolverle. In situazioni di embargo, le note di rilascio fanno riferimento agli "aggiornamenti della sicurezza" fino a quando l'embargo non sarà stato revocato. Una volta terminato l'embargo, Google aggiorna le note di rilascio per includere le vulnerabilità specifiche.

Il team di sicurezza GKE pubblica bollettini sulla sicurezza per le vulnerabilità con gravità elevata e critica. Quando è necessaria l'azione del cliente per risolvere queste vulnerabilità di gravità alta e critica, Google contatta i clienti via email. Inoltre, Google potrebbe contattare i clienti con contratti di assistenza tramite i canali di assistenza.

Qual è il modo più rapido per installare una patch di sicurezza?

Tutti i cluster rimarranno automaticamente patchati con gli upgrade automatici di GKE. Questa sezione descrive come applicare patch più velocemente degli upgrade automatici per correzioni di sicurezza specifiche o su base continuativa. Combinando ambienti di test, aggiornamenti manuali cross-channel, impostazioni di patch accelerate e notifiche basate sugli eventi, puoi ridurre i tempi di lead per l'applicazione di patch.

GKE gestisce i rollout delle versioni nei vari canali di rilascio per garantire che le nuove versioni siano qualificate e testate. Per ridurre i tempi di implementazione delle patch, devi capire come funzionano questi rollout e poi adattare il comportamento predefinito per soddisfare le tue esigenze specifiche.

Il soaking di una versione patchata prevede l'esecuzione sui cluster nel tempo per osservarne la stabilità. Questo processo consente di rilevare bug che vengono visualizzati solo dopo un uso prolungato in ambienti diversi. Per garantire un tempo di rodaggio sufficiente, le release delle patch GKE vengono introdotte prima nel canale rapido, seguito da quello regolare e da quello stabile. Le release vengono inoltre testate in ogni canale prima di diventare il target di upgrade per il canale.

Qualifica le patch in anticipo e gestisci l'implementazione con la sequenza di implementazione

Per qualificare una patch di sicurezza che vuoi accelerare, utilizza la sequenza di implementazione per eseguire l'implementazione negli ambienti, testando una patch in altri cluster GKE prima di eseguire l'upgrade dell'ambiente di produzione. Questo approccio ti consente di verificare la compatibilità del workload e di rilevare eventuali problemi non appena Google rilascia una correzione di sicurezza. Dopodiché, puoi applicare la versione patchata al resto del parco risorse e controllare il tempo di soak rimanente.

Riduci i ritardi di assorbimento con gli upgrade automatici delle patch accelerati

In alternativa, puoi scegliere di utilizzare le patch più rapidamente attivando gli aggiornamenti automatici delle patch accelerati per i tuoi cluster. Questa funzionalità indica a GKE di ignorare il tempo di rodaggio nel canale per gli aggiornamenti delle patch, in particolare le patch di sicurezza. Se utilizzi questo approccio, Google consiglia di eseguire un cluster di test sul canale rapido (anche con upgrade automatici delle patch accelerati) per qualificare le patch.

Upgrade manuali alle versioni patch più recenti nei canali Regolare e Stabile

Se i tuoi workload di produzione si trovano su cluster registrati nei canali Regular o Stable, non devi abbandonare questi canali o attendere l'implementazione automatica e graduale di una patch per riceverla se è presente un aggiornamento della sicurezza specifico a cui devi dare la priorità.

Se hai qualificato la versione patch, puoi avviare manualmente gli upgrade dei tuoi cluster nelle versioni Regular o Stable a quella patch esatta per controllare il tempo di rodaggio rimanente.

Automatizza la gestione delle patch con le notifiche del cluster

Non è necessario monitorare la pagina web dei bollettini di sicurezza per informazioni sulle patch. Per ricevere notifiche programmatiche rapide delle patch disponibili e attivare le azioni di qualificazione e upgrade delle patch, puoi utilizzare le notifiche del cluster.

Per ricevere notifiche relative a bollettini di sicurezza o upgrade pianificati, configura le notifiche in modo da filtrare specificamente i seguenti tipi di eventi:

Le notifiche dei cluster ti consentono di ricevere messaggi in tempo reale quando si verificano questi eventi. Puoi integrare queste notifiche nei sistemi di gestione degli eventi e delle informazioni di sicurezza (SIEM), nelle operazioni di chat o attivare pipeline di test automatizzati.