Stai visualizzando la documentazione relativa a Apigee e Apigee ibrido.
Visualizza la documentazione di
Apigee Edge.
Questo documento descrive come Google gestisce le vulnerabilità e le patch di sicurezza per Apigee hybrid. Salvo dove diversamente indicato, Apigee include sia il piano di gestione piano dati.
Responsabilità condivisa per gli aggiornamenti
L'applicazione di patch è una responsabilità condivisa tra Google e il cliente. Apigee X e Apigee hybrid hanno diverse responsabilità condivise, poiché il piano di dati di Apigee hybrid è gestito interamente dal cliente. Per informazioni sulle responsabilità condivise di Apigee hybrid, consulta Modello di responsabilità condivisa di Apigee hybrid.
Come vengono scoperte le vulnerabilità
Google adotta un approccio proattivo alla sicurezza dei sistemi software utilizzando la progettazione Secure by default e l'implementazione di varie pratiche di protezione della sicurezza.
Ad esempio, le applicazioni containerizzate sono alla base delle varie piattaforme di gestione delle API Apigee le funzionalità di machine learning. Le applicazioni containerizzate vengono distribuite su Kubernetes. Le immagini container sono basate su immagini di base minime (ad esempio, immagini di base senza distribuzione) per la massima sicurezza e un miglioramento delle prestazioni.
Tuttavia, anche i sistemi software più progettati possono presentare delle vulnerabilità. Per trovarli vulnerabilità e patch prima che possano essere sfruttate, Google ha su più fronti.
Scanner di sicurezza
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 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. Sono prevalentemente open source utilizzati dalla piattaforma per attività operative comuni come logging, 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 la procedura di applicazione dei patch e di rilascio. Queste scansioni vengono eseguite regolarmente (quando vengono pubblicate nuove immagini) e su richiesta (prima di una release) per massimizzare le probabilità di rilevare nuove vulnerabilità e pianificare tempestivamente la correzione o la mitigazione.
Ricerca sulla sicurezza
Oltre alla scansione automatica, Google scopre e corregge le vulnerabilità sconosciute agli scanner nei seguenti modi:
- Google esegue i propri controlli di sicurezza e conformità, test di penetrazione di applicazioni e reti, test di segmentazione e rilevamento di vulnerabilità di sicurezza su tutti i componenti di Apigee.
Team specializzati all'interno di Google e fornitori di servizi di sicurezza di terze parti attendibili conducono la propria ricerca sugli attacchi. - Google collabora con altri partner di software open source e del settore che condividono
vulnerabilità, ricerca sulla sicurezza e patch prima del rilascio pubblico della vulnerabilità.
L'obiettivo di questa collaborazione è patchare grandi porzioni dell'infrastruttura Internet prima che la vulnerabilità viene comunicata al pubblico. In alcuni casi, Google contribuisce con le vulnerabilità rilevate a questa community. Ad esempio, Project Zero di Google ha scoperto e pubblicizzato il Spectre e Meltdown le vulnerabilità. Il team di sicurezza di Google Cloud trova e corregge regolarmente anche le vulnerabilità nella VM basata su kernel (KVM).
Programmi di ricompensa per le vulnerabilità
Google interagisce attivamente con la comunità di ricerca sulla sicurezza tramite più programmi di riconoscimento vulnerabilità. Un programma a premi dedicato per le vulnerabilità di Google Cloud offre premi significativi, inclusi 133.337 $ per la migliore vulnerabilità cloud rilevata ogni anno. Il programma copre tutte le dipendenze software di Apigee.
OSS
La collaborazione per la sicurezza di Google avviene su molti livelli. A volte avviene formalmente programmi a cui le organizzazioni si registrano per ricevere notifiche di pre-release relative a software le vulnerabilità per prodotti come Kubernetes ed Envoy. La collaborazione avviene anche in modo informale grazie al nostro impegno con molti progetti open source come il kernel Linux, i runtime dei container, la tecnologia di virtualizzazione e altro.
Sebbene vengano scoperte e applicate patch al di fuori di questi processi per le vulnerabilità meno gravi, le vulnerabilità critiche di sicurezza vengono segnalate privatamente attraverso uno dei canali in precedenza in elenco. I primi report lasciano a Google il tempo, prima che la vulnerabilità diventi pubblica, per cercare come riguarda Apigee, sviluppa patch o mitigazioni e prepara consigli e comunicazioni per clienti. Quando possibile, Google applica le patch a tutti i cluster (per Apigee X) prima della release pubblica la vulnerabilità. Per Apigee hybrid, le release delle patch vengono rese disponibili su base regolare per risolvere le vulnerabilità di sicurezza nelle immagini container e i clienti sono invitati a aggiornati con le ultime versioni delle patch.
Classificazione delle vulnerabilità
Apigee fa grandi investimenti nell'applicazione di misure di sicurezza nell'intero stack, inclusa l'immagine di base, le librerie di terze parti e il software per le applicazioni proprietarie, oltre a impostare valori predefiniti, configurazioni con misure di sicurezza e componenti gestiti. Insieme, queste misure contribuiscono a ridurre l'impatto e la probabilità di vulnerabilità.
Il team di sicurezza di Apigee classifica le vulnerabilità in base Common Vulnerability Scoring System (CVSS).
La tabella seguente descrive le categorie di gravità della vulnerabilità:
Gravità | Descrizione |
Critico | Una vulnerabilità facilmente sfruttabile in tutti i cluster da un remoto non autenticato 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 si verifica la perdita di riservatezza, l'integrità o la disponibilità è limitata da configurazioni comuni, difficoltà dell'exploit stesso, di accesso richiesto o di interazione dell'utente. |
Bassa | Tutte le altre vulnerabilità. È improbabile che lo sfruttamento o le conseguenze di uno sfruttamento siano limitate. |
Come vengono comunicate vulnerabilità e patch
L'obiettivo di Google è ridurre le vulnerabilità rilevate in un periodo di tempo appropriato per i rischi che rappresentano. Apigee è incluso in ATO provvisorio FedRAMP di Google Cloud che richiede che le vulnerabilità note vengano risolte entro specifici periodi di tempo in base il loro livello di gravità Specificato in FedRAMP RA-5d. L'ATO provvisorio FedRAMP di Google Cloud non include i componenti del piano dati ibrido Apigee (gestite dal cliente), ma puntiamo a rispettare gli stessi tempi di correzione per questi prodotti.
Vulnerabilità rilevate dalla scansione proattiva
Google rileva le vulnerabilità della sicurezza attraverso la scansione proattiva dei file binari e all'infrastruttura sottostante che ospita la piattaforma Apigee. Apigee rilascia aggiornamenti delle patch regolari per risolvere queste vulnerabilità in modo tempestivo, a seconda della gravità delle CVE sottostanti. La correzione di una vulnerabilità comporta l'upgrade a una nuova versione di Apigee hybrid, ovvero un upgrade di una versione minore o un upgrade di una versione della patch, a seconda della natura della vulnerabilità. Queste vulnerabilità vengono in genere risolte nell'ambito delle release mensili delle patch per Apigee hybrid e incluse nei regolari aggiornamenti software del nostro parco gestito nel caso di Apigee X. Le patch di sicurezza vengono comunicate tramite le note di rilascio sia per Apigee X che per Apigee hybrid.
La correzione di alcune vulnerabilità richiede solo un upgrade del piano di controllo, eseguito automaticamente Google su Apigee, mentre altri richiedono l'implementazione di nuovi file binari nel piano dati. Nel caso di Apigee X, Google si occupa di implementare i nuovi binari nell'intero parco risorse. Clienti che utilizzano Apigee Apigee hybrid deve applicare la release della patch ai propri cluster ibridi Apigee per implementare file binari.
Per mantenere i cluster con patch e protezione avanzata contro vulnerabilità di ogni gravità, ti consigliamo applicando la release più recente della patch per una determinata versione secondaria di Apigee hybrid. Per chi esegue 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 programmi binari Apigee da eseguire nei loro dati o le piattaforme cloud preferite. Nell'ambito di gli standard di sicurezza di un cliente per il lancio del software in produzione nei propri data center, è possibile eseguire una serie di test di sicurezza. Questi test potrebbero includere penetration testing, scansione dei container, scansione del codice statico e così via. Questi test potrebbero segnalare possibili vulnerabilità nel software Apigee. Prima di abilitare questi pacchetti nei loro data center, i clienti occorre stabilire se questi elementi segnalati sono sfruttabili e pertanto 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 (PDC) su come sfruttano la vulnerabilità, il cliente dovrebbe segnalare il problema tramite il premio Vulnerabilità di Google Programma disponibile all'indirizzo goo.gle/vulnz. Il problema viene segnalato all'amministratore Il team di sicurezza di Google, che convaliderà il proof of concept, ne determinerà la gravità e il potenziale impatto. Il problema verrà quindi riassegnato ad Apigee. Il cliente potrebbe avere diritto a un premio tramite il programma VRP.
Vulnerabilità identificata da uno strumento automatizzato
Se il cliente ha generato un report su possibili vulnerabilità nel prodotto Apigee in base a un'analisi statica o a 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 Google Cloud. Segnalando i problema da fornire all'assistenza, il cliente dispone di un numero di ticket da monitorare e può vedere aggiornamenti e risposte al report. Il team di assistenza riassegna quindi i problemi segnalati internamente, se opportuno.
Identificatori CVE
I clienti dovrebbero includere quante più informazioni possibili sulla vulnerabilità, in particolare includono l'identificatore CVE, nome della libreria o del pacchetto, nome dell'immagine container e così via per ogni articolo. Le CVE ci consentono di sapere che stiamo esaminando la stessa vulnerabilità. Fornendo solo un la descrizione del problema o un altro numero di tracciamento proprietario non consente la correlazione dei problema nei vari strumenti di rilevamento o nei processi di segnalazione. Senza una CVE, Google potrebbe non essere in grado all'elemento specifico.
Risposta
Per gli elementi segnalati all'assistenza con un punteggio di gravità critico o elevato, i clienti possono aspettarsi una risposta tramite il sistema di ticketing dell'assistenza. Per gli elementi segnalati al VRP, consulta: le regole documentazione fornita dal programma.