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 minimal 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 analizza i 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, test di penetrazione 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 offre premi significativi, incluso un premio di 133.337 $per la migliore vulnerabilità del cloud trovata ogni anno. Google Cloud 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 di 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 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 gravi vulnerabilità di sicurezza 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. Insieme, 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 patchati e protetti dalle vulnerabilità di qualsiasi gravità, consigliamo di utilizzare l'upgrade automatico dei nodi su GKE (attivato per impostazione predefinita). Per i cluster registrati nei canali di rilascio, le release delle patch vengono promosse quando soddisfano i requisiti di qualifica di ciascun canale. Se hai bisogno di una patch di GKE prima che raggiunga il canale del tuo cluster, puoi eseguire manualmente l'upgrade alla versione della patch se la patch è nella stessa versione secondaria di una disponibile nel canale di rilascio del cluster.

Su altre piattaforme in cui vengono eseguiti i cluster, Google consiglia di eseguire l'upgrade 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 provvisorio 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, "Scansione delle vulnerabilità", 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 GKE collegati, 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à di gravità alta 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 su eventi, puoi ridurre i tempi di lead time delle 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 la destinazione di upgrade predefinita per il canale.

Qualifica le patch in anticipo con un cluster dedicato nel canale rapido

Per qualificare una patch di sicurezza che vuoi accelerare, esegui un cluster dedicato registrato nel canale Rapido con gli upgrade automatici delle patch accelerati attivati. Utilizza questo cluster per verificare la compatibilità dei carichi di lavoro e rilevare eventuali problemi non appena Google rilascia una correzione di sicurezza. Questo cluster potrebbe essere utilizzato come qualifica una tantum per una patch specifica, ma eseguirlo in modo continuo offre ulteriori vantaggi in termini di affidabilità al tuo parco risorse.

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

Una volta che il cluster con registrazione rapida è in grado di rilevare i problemi, puoi scegliere di utilizzare le patch più rapidamente all'interno dei cluster di produzione su Regular e Stable. Attiva gli upgrade automatici delle patch accelerati per i cluster di produzione per iniziare gli upgrade all'ultima release di patch nel canale registrato non appena è disponibile. Questa funzionalità indica a GKE di ignorare il tempo di attesa nel canale per gli aggiornamenti delle patch, in particolare le patch di sicurezza.

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

Se i tuoi carichi di lavoro 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 il cluster registrato in Rapid ha superato la qualifica di una patch, puoi avviare manualmente un upgrade sui cluster di produzione in Regular o Stable a quella versione esatta della patch.

Automatizza la gestione delle patch con le notifiche Pub/Sub basate sugli eventi

Non è necessario monitorare la pagina web dei bollettini di sicurezza per informazioni sulle patch. Per ricevere notifiche programmatiche rapide delle patch disponibili utilizzando Pub/Sub per attivare le azioni di qualificazione e upgrade delle patch:

  • Avvisi basati sugli eventi:configura le notifiche del cluster utilizzando Pub/Sub.
  • Filtro di sicurezza:configura le notifiche del cluster in modo specifico per filtrare SecurityBulletinEvent e UpgradeEvent.
  • Azione programmatica:GKE invierà messaggi programmatici in tempo reale all'argomento Pub/Sub quando viene pubblicato un bollettino sulla sicurezza o quando una patch che mitiga un bollettino diventa disponibile per il tuo cluster nella tua zona o regione. Queste notifiche possono essere integrate nei tuoi sistemi SIEM (Security Information and Event Management), nelle operazioni di chat o attivare pipeline di test automatizzate.