Questo documento descrive come Google gestisce le vulnerabilità di sicurezza e le patch per Apigee hybrid. Salvo dove diversamente indicato, Apigee include sia il piano di gestione sia il piano dati.
Responsabilità condivisa per l'applicazione di patch
L'applicazione di patch è una responsabilità condivisa tra Google e il cliente. Apigee X e Apigee hybrid hanno responsabilità condivise diverse, dato che il piano dati per Apigee hybrid è gestito interamente dal cliente. Per informazioni sulle responsabilità condivise di Apigee hybrid, consulta Modello di responsabilità condivisa di Apigee hybrid.
Come vengono rilevate le vulnerabilità
Google adotta un approccio proattivo alla sicurezza dei sistemi software, utilizzando i principi di progettazione Secure by Default e implementando varie pratiche di hardening della sicurezza.
Ad esempio, le applicazioni containerizzate alimentano le varie funzionalità della piattaforma di gestione delle API Apigee. Le applicazioni containerizzate vengono sottoposte a deployment su Kubernetes. Le immagini container sono basate su immagini di base minimali (ad esempio, immagini di base distroless) per la massima sicurezza e prestazioni migliorate.
Tuttavia, anche i sistemi software progettati al meglio possono presentare vulnerabilità. Per trovare queste vulnerabilità e applicare le patch prima che possano essere sfruttate, Google ha effettuato investimenti significativi su più fronti.
Security scanner
Google identifica e corregge in modo proattivo le vulnerabilità su diversi tipi di immagini container:
- Container proprietari: immagini container create e distribuite da Google nell' ambito della piattaforma Apigee. Si tratta di applicazioni proprietarie di Google che alimentano la piattaforma di gestione delle API Apigee incluse le funzionalità di base come il routing del traffico, la gestione delle quote e la gestione delle chiavi.
- Container di terze parti: immagini container create dalla community open source, ma distribuite da Google nell'ambito della piattaforma Apigee. Si tratta principalmente di componenti open source utilizzati dalla piattaforma per attività operative comuni come la registrazione, il monitoraggio e la gestione dei certificati.
Google esegue la scansione dei container utilizzando Container Analysis di Container Registry per rilevare vulnerabilità e patch mancanti nei container proprietari e di terze parti. Se sono disponibili correzioni, Google avvia il processo di applicazione di patch e rilascio. Queste scansioni vengono eseguite regolarmente (quando vengono pubblicate nuove immagini) e on demand (prima di un rilascio) per massimizzare le possibilità di rilevare nuove vulnerabilità e pianificare la correzione o la mitigazione anticipata.
Ricerca sulla sicurezza
Oltre alla scansione automatica, Google rileva e applica patch alle vulnerabilità sconosciute agli scanner nei seguenti modi:
- Google esegue audit di sicurezza e conformità, test di penetrazione di applicazioni e reti
, test di segmentazione e rilevamento di vulnerabilità di sicurezza su tutti i componenti Apigee.
Team specializzati di Google e fornitori di sicurezza di terze parti di fiducia conducono le proprie ricerche sugli attacchi. - 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 è applicare patch a grandi parti dell'infrastruttura internet prima che la vulnerabilità venga annunciata pubblicamente. In alcuni casi, Google contribuisce a questa community con le vulnerabilità rilevate. Ad esempio, Project Zero di Google ha rilevato e pubblicizzato le vulnerabilità Spectre e Meltdown. Il team di sicurezza di Google Cloud trova e corregge regolarmente anche le vulnerabilità nella macchina virtuale basata su kernel (KVM).
Vulnerability Reward Program
Google collabora attivamente con la community di esperti sulla sicurezza attraverso diversi Vulnerability Reward Program. Un Vulnerability Reward Program di Google Cloud dedicato offre premi significativi, tra cui 133.337 $per la migliore vulnerabilità cloud rilevata ogni anno. Il programma copre tutte le dipendenze software di Apigee.
OSS
La collaborazione di Google in materia di sicurezza avviene a molti livelli. A volte avviene formalmente tramite programmi in cui le organizzazioni si registrano per ricevere notifiche pre-release sulle vulnerabilità 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.
Sebbene le vulnerabilità meno gravi vengano rilevate 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 anticipata consente a Google di avere tempo prima che la vulnerabilità diventi pubblica per studiare in che modo influisce su Apigee, sviluppare patch o mitigazioni e preparare consigli e comunicazioni per i clienti. Quando possibile, Google applica patch a tutti i cluster (per Apigee X) prima del rilascio pubblico di la vulnerabilità. Per Apigee hybrid, le release di patch vengono rese disponibili regolarmente per risolvere le vulnerabilità di sicurezza nelle immagini container e i clienti sono invitati a rimanere aggiornati con le versioni di patch più recenti.
Come vengono classificate le vulnerabilità
Apigee effettua ingenti investimenti nell'hardening della sicurezza dell'intero stack, inclusi l'immagine di base, le librerie di terze parti e il software applicativo proprietario, oltre a impostare valori predefiniti validi, configurazioni con hardening della sicurezza e componenti gestiti. Insieme, questi sforzi contribuiscono a ridurre l'impatto e la probabilità di vulnerabilità.
Il team di sicurezza di Apigee classifica le vulnerabilità in base al Common Vulnerability Scoring System (CVSS).
La tabella seguente descrive le categorie di gravità delle vulnerabilità:
| Gravità | Descrizione |
| Critico | Una vulnerabilità facilmente sfruttabile in tutti i cluster da un utente malintenzionato remoto attaccante che porta alla compromissione completa del sistema. |
| Alta | Una vulnerabilità facilmente sfruttabile per molti cluster che porta alla perdita di riservatezza, integrità o disponibilità. |
| Media | Una vulnerabilità sfruttabile per alcuni cluster in cui la perdita di riservatezza, integrità o disponibilità è limitata da configurazioni comuni, dalla difficoltà dello sfruttamento stesso, dall'accesso richiesto o dall'interazione dell'utente. |
| Bassa | Tutte le altre vulnerabilità. Lo sfruttamento è improbabile o le conseguenze dello sfruttamento sono limitate. |
Come vengono comunicate le vulnerabilità e le patch
L'obiettivo di Google è mitigare le vulnerabilità rilevate entro un periodo di tempo appropriato per i rischi che rappresentano. Apigee è incluso nell' ATO provvisorio FedRAMP di Google Cloud che richiede la correzione delle vulnerabilità note entro intervalli di tempo specifici in base al livello di gravità, come mostrato nella Guida alla gestione delle prestazioni del monitoraggio continuo FedRAMP. L'ATO provvisorio FedRAMP di Google Cloud non include i componenti del piano dati di Apigee hybrid (gestiti dal cliente), ma puntiamo agli stessi intervalli di tempo di correzione per questi prodotti.
Vulnerabilità rilevate dalla scansione proattiva
Google rileva le vulnerabilità di sicurezza tramite la scansione proattiva dei file binari e dell' infrastruttura sottostante che ospita la piattaforma Apigee. Apigee rilascia regolarmente aggiornamenti delle patch per risolvere queste vulnerabilità in modo tempestivo, a seconda della gravità dei CVE sottostanti. L'applicazione di patch a una vulnerabilità comporta l'upgrade a una nuova versione di Apigee hybrid, ovvero un upgrade della versione secondaria o un upgrade della versione di patch, a seconda della natura della vulnerabilità. Queste vulnerabilità vengono risolte principalmente nell'ambito delle release di patch mensili per Apigee hybrid e incluse negli aggiornamenti software regolari della nostra flotta gestita nel caso di Apigee X. Le patch di sicurezza vengono comunicate tramite le note di rilascio sia per Apigee X sia per Apigee hybrid.
La correzione di alcune vulnerabilità richiede solo un upgrade del piano di controllo, eseguito automaticamente da Google su Apigee, mentre altre richiedono il deployment di nuovi file binari nel piano dati. Nel caso di Apigee X, Google si occupa del deployment dei nuovi file binari nell'intera flotta. I clienti che eseguono Apigee Apigee hybrid devono applicare la release di patch ai propri cluster Apigee hybrid per eseguire il deployment dei file binari aggiornati.
Per mantenere i cluster con patch e hardening contro le vulnerabilità di tutte le gravità, ti consigliamo di applicare la release di patch più recente per qualsiasi versione secondaria di Apigee hybrid. Per chi utilizza Apigee hybrid su Anthos, Google consiglia di eseguire l'upgrade dei componenti Anthos almeno una volta al mese.
Vulnerabilità segnalate dai clienti
Con Apigee hybrid, i clienti ricevono i file binari di Apigee da eseguire nei propri data center o nelle piattaforme cloud preferite. Nell'ambito degli standard di sicurezza di un cliente per il lancio di software in produzione nei propri data center, potrebbe eseguire una serie di test di sicurezza. Questi test potrebbero includere test di penetrazione, scansione dei container, scansione statica del codice e così via. Questi test potrebbero segnalare possibili vulnerabilità nel software Apigee. Prima di attivare questi pacchetti nei propri data center, i clienti devono determinare se gli elementi segnalati sono sfruttabili e quindi rappresentano un rischio per la sicurezza.
Vulnerabilità con una proof of concept di exploit
Se il cliente identifica una vulnerabilità sfruttabile e dispone di una proof of concept (POC) su come sfruttare la vulnerabilità, deve segnalare il problema tramite il Vulnerability Reward Program di Google disponibile all'indirizzo goo.gle/vulnz. In questo modo, il problema viene segnalato al team di sicurezza di Google, che convaliderà la proof of concept e ne determinerà la gravità e il potenziale impatto. Il problema verrà quindi inoltrato ad Apigee. Il cliente potrebbe avere diritto a un premio tramite il programma VRP.
Vulnerabilità identificata da uno strumento automatico
Se il cliente ha generato un report di possibili vulnerabilità nel prodotto Apigee basato sulla scansione statica o su un altro strumento o tecnica, ma non dispone di proof of concept su come sfruttare i problemi, questi elementi possono essere segnalati all'assistenza tramite il portale di assistenza di Google Cloud. Segnalando il problema all'assistenza, il cliente riceve un numero di ticket per il monitoraggio e può visualizzare aggiornamenti e risposte al report. Il team di assistenza inoltrerà internamente i problemi segnalati, se necessario.
Identificatori CVE
I clienti devono includere il maggior numero possibile di informazioni sulla vulnerabilità e, in particolare includere l'identificatore CVE, il nome della libreria/del pacchetto, il nome dell'immagine container e così via per ogni elemento. I CVE ci consentono di sapere che stiamo esaminando la stessa vulnerabilità. Se fornisci solo una descrizione del problema o un altro numero di monitoraggio proprietario, non è possibile correlare il problema tra gli strumenti di rilevamento o i processi di reporting. Senza un CVE, Google potrebbe non essere in grado di rispondere all'elemento specifico.
Risposta
Per gli elementi segnalati all'assistenza con un punteggio di gravità critico o alto, i clienti possono aspettarsi una risposta tramite il sistema di ticketing dell'assistenza. Per gli elementi segnalati al VRP, consulta le regole e la documentazione fornite dal programma.