Panoramica sulla progettazione della sicurezza dell'infrastruttura Google

Questi contenuti sono stati aggiornati l'ultima volta a giugno 2023 e rappresentano lo status quo al momento della loro redazione. Le norme e i sistemi di sicurezza di Google potrebbero cambiare in futuro, in virtù del costante miglioramento della protezione per i nostri clienti.

Introduzione

Questo documento offre una panoramica di come la sicurezza è progettata nell'infrastruttura tecnica di Google. È rivolto a responsabili della sicurezza, architetti della sicurezza e revisori dei conti.

Questo documento descrive quanto segue:

  • L'infrastruttura tecnica globale di Google, progettata per fornire sicurezza durante l'intero ciclo di vita di elaborazione delle informazioni in Google. Questa infrastruttura consente di fornire quanto segue:
    • Deployment sicuro dei servizi
    • Archiviazione sicura dei dati con misure di salvaguardia della privacy degli utenti finali
    • Comunicazione sicura tra i servizi
    • Comunicazione privata e sicura con i clienti su Internet
    • Utilizzo sicuro da parte dei tecnici di Google
  • Come utilizziamo questa infrastruttura per creare servizi Internet, compresi i servizi per i consumatori come la Ricerca Google, Gmail e Google Foto, e i servizi aziendali come Google Workspace e Google Cloud.
  • Il nostro investimento nella protezione della nostra infrastruttura e delle nostre operazioni. Abbiamo molti ingegneri impegnati nella sicurezza e nella privacy su Google, inclusi molti di enti del settore riconosciuti.
  • I prodotti e i servizi di sicurezza che sono il risultato delle innovazioni che abbiamo implementato internamente per soddisfare le nostre esigenze di sicurezza. Ad esempio, BeyondCorp è il risultato diretto dell'implementazione interna del modello di sicurezza Zero Trust.

  • Il modo in cui la sicurezza dell'infrastruttura è progettata in livelli progressivi. Questi livelli includono:

Le sezioni rimanenti di questo documento descrivono i livelli di sicurezza.

Infrastruttura sicura a basso livello

Questa sezione descrive il modo in cui proteggiamo le sedi fisiche dei nostri data center, l'hardware nei nostri data center e lo stack software in esecuzione sull'hardware.

Sicurezza delle sedi fisiche

Progettiamo e costruiamo i nostri data center, che includono diversi livelli di sicurezza fisica. L'accesso a questi data center è strettamente controllato. Utilizziamo diversi livelli di sicurezza fisica per proteggere i nostri data center. Utilizziamo l'identificazione biometrica, il rilevamento dei metalli, le videocamere, le barriere per i veicoli e i sistemi di rilevamento delle intrusioni basati su laser. Per ulteriori informazioni, consulta Sicurezza dei data center.

Alcuni server sono ospitati anche in data center di terze parti. In questi data center, assicuriamo che ci siano misure di sicurezza fisica controllate da Google oltre ai livelli di sicurezza forniti dall'operatore del data center. Ad esempio, gestiamo sistemi di identificazione biometrica, videocamere e rilevatori di metallo indipendenti dai livelli di sicurezza forniti dall'operatore del data center.

Origine e progettazione hardware

Un data center di Google è costituito da migliaia di server collegati a una rete locale. Progettiamo le schede server e le apparecchiature di networking. Controlliamo i fornitori di componenti e collaboriamo con cura. Collaboriamo con i fornitori per controllare e convalidare le proprietà di sicurezza fornite dai componenti. Progettiamo anche chip personalizzati, incluso un chip di sicurezza hardware (chiamato Titan), di cui eseguiamo il deployment su server, dispositivi e periferiche. Questi chip ci permettono di identificare e autenticare i dispositivi Google legittimi a livello di hardware e servono come radice di attendibilità hardware.

Stack di avvio protetto e identità macchina

I server di Google utilizzano varie tecnologie per assicurarsi che avviino lo stack software corretto. Utilizziamo firme crittografiche per componenti di basso livello come il controller di gestione del battiscopa (BMC), il BIOS, il bootloader, il kernel e l'immagine di sistema operativo di base. Queste firme possono essere convalidate durante ogni ciclo di avvio o aggiornamento. Il primo controllo di integrità per i server di Google utilizza una radice hardware affidabile. I componenti sono controllati, creati e protetti da Google con l'attestazione dell'integrità. Cerchiamo di migliorare costantemente la sicurezza a ogni nuova generazione di hardware. Ad esempio, a seconda della generazione del design del server, la radice di attendibilità della catena di avvio è una delle seguenti:

  • Il chip hardware Titan
  • Un chip del firmware con serratura
  • Un microcontroller che esegue il nostro codice di sicurezza

Ogni server nel data center ha una propria identità univoca. Questa identità può essere collegata alla radice di attendibilità dell'hardware e al software con cui la macchina si avvia. Questa identità viene utilizzata per autenticare le chiamate API da e verso i servizi di gestione di basso livello sulla macchina. Questa identità viene utilizzata anche per l'autenticazione reciproca del server e la crittografia dei trasferimenti. Abbiamo sviluppato il sistema Application Layer Transport Security (ALTS) per proteggere le comunicazioni di chiamata di procedura remota (RPC) all'interno della nostra infrastruttura. Le identità di queste macchine possono essere revocate centralmente per rispondere a un incidente di sicurezza. Inoltre, i certificati e le chiavi vengono ruotati di routine e i vecchi vengono revocati.

Abbiamo sviluppato sistemi automatici per:

  • Assicurati che i server eseguano versioni aggiornate dei loro stack software (incluse le patch di sicurezza).
  • Rilevamento e diagnosi di problemi hardware e software.
  • Assicura l'integrità delle macchine e delle periferiche con l'avvio verificato e l'attestazione implicita.
  • Assicurati che solo le macchine che eseguono il software e il firmware previsti possano accedere alle credenziali che consentono loro di comunicare sulla rete di produzione.
  • Rimuovi o alloca di nuovo le macchine dal servizio quando non sono più necessarie.

Deployment sicuro dei servizi

I servizi Google sono i programmi binari dell'applicazione che i nostri sviluppatori scrivono ed eseguono sulla nostra infrastruttura. Esempi di servizi Google sono i server Gmail, i database Spanner, i server Cloud Storage, i transcodifica video di YouTube e le VM di Compute Engine che eseguono le applicazioni dei clienti. Per gestire la scalabilità richiesta del carico di lavoro, migliaia di macchine potrebbero eseguire programmi binari dello stesso servizio. Un servizio di orchestrazione dei cluster, chiamato Borg, controlla i servizi in esecuzione direttamente sull'infrastruttura.

L'infrastruttura non assume alcun attendibilità tra i servizi in esecuzione nell'infrastruttura. Questo modello di attendibilità è noto come modello di sicurezza Zero Trust. Un modello di sicurezza Zero Trust significa che nessun dispositivo o utente è considerato attendibile per impostazione predefinita, che sia all'interno o all'esterno della rete.

Poiché l'infrastruttura è progettata per essere multi-tenant, i dati dei nostri clienti (consumatori, aziende e persino i nostri dati) sono distribuiti su un'infrastruttura condivisa. Questa infrastruttura è composta da decine di migliaia di macchine omogenee. L'infrastruttura non separa i dati dei clienti su una singola macchina o set di macchine, tranne che in circostanze specifiche, ad esempio quando utilizzi Google Cloud per il provisioning delle VM sui nodi single-tenant per Compute Engine.

Google Cloud e Google Workspace supportano i requisiti normativi relativi alla residenza dei dati. Per ulteriori informazioni sulla residenza dei dati e su Google Cloud, consulta Implementare i requisiti di localizzazione e sovranità dei dati. Per ulteriori informazioni sulla residenza dei dati e su Google Workspace, consulta Aree geografiche dati: scegli una posizione geografica per i tuoi dati.

Identità di servizio, integrità e isolamento

Per abilitare la comunicazione tra i servizi, le applicazioni utilizzano l'autenticazione crittografica e l'autorizzazione. Autenticazione e autorizzazione forniscono un forte controllo dell'accesso a livello di astrazione e granularità che gli amministratori e i servizi possono comprendere.

I servizi non si basano sulla segmentazione della rete interna o sul firewall come meccanismo di sicurezza principale. I filtri del traffico in entrata e in uscita in vari punti della nostra rete consentono di prevenire lo spoofing IP. Questo approccio ci aiuta anche a massimizzare le prestazioni e la disponibilità della nostra rete. Per Google Cloud, puoi aggiungere ulteriori meccanismi di sicurezza come Controlli di servizio VPC e Cloud Interconnect.

A ogni servizio eseguito sull'infrastruttura è associata un'identità dell'account di servizio. Un servizio viene fornito con credenziali crittografiche che può utilizzare per dimostrare la propria identità ad altri servizi quando crea o riceve RPC. Queste identità vengono utilizzate nei criteri di sicurezza. I criteri di sicurezza garantiscono che i client comunichino con il server di destinazione e che i server limitino i metodi e i dati a cui determinati client possono accedere.

Utilizziamo varie tecniche di isolamento e sandbox per proteggere un servizio da altri servizi in esecuzione sulla stessa macchina. Queste tecniche includono la separazione degli utenti Linux, basata su linguaggio (come l'API Sandbox) e sandbox basate su kernel, il kernel dell'applicazione per i container (come gVisor) e la virtualizzazione hardware. In generale, utilizziamo più livelli di isolamento per i carichi di lavoro più rischiosi. I carichi di lavoro più rischiosi includono elementi forniti dagli utenti che richiedono un'ulteriore elaborazione. Ad esempio, i carichi di lavoro più rischiosi includono l'esecuzione di convertitori di file complessi sui dati forniti dall'utente o l'esecuzione di codice fornito dall'utente per prodotti come App Engine o Compute Engine.

Per ulteriori servizi di sicurezza, come il servizio di orchestrazione dei cluster e alcuni servizi di gestione delle chiavi, vengono eseguiti esclusivamente su macchine dedicate.

In Google Cloud, per fornire un isolamento crittografico più efficace per i carichi di lavoro e proteggere i dati in uso, supportiamo i servizi di Confidential Computing per le VM di Compute Engine e i nodi di Google Kubernetes Engine (GKE).

Gestione degli accessi tra servizi

Il proprietario di un servizio può utilizzare le funzionalità di gestione degli accessi fornite dall'infrastruttura per specificare esattamente quali altri servizi possono comunicare con il servizio. Ad esempio, un servizio può limitare le RPC in entrata esclusivamente a un elenco consentito di altri servizi. Questo servizio può essere configurato con l'elenco consentito delle identità di servizio e l'infrastruttura applica automaticamente questa limitazione di accesso. L'applicazione include l'audit logging, le giustificazioni e la limitazione di accesso unilaterale (ad esempio per le richieste dei tecnici).

Gli ingegneri di Google che hanno bisogno di accedere ai servizi ricevono anche identità individuali. I servizi possono essere configurati in modo da consentire o negare l'accesso in base alle identità degli utenti. Tutte queste identità (macchina, servizio e dipendente) si trovano in uno spazio dei nomi globale gestito dall'infrastruttura.

Per gestire queste identità, l'infrastruttura fornisce un sistema di flusso di lavoro che include catene di approvazione, logging e notifica. Ad esempio, il criterio di sicurezza può applicare l'autorizzazione di più parti. Questo sistema utilizza la regola per due persone per garantire che un tecnico che agisca da solo non possa eseguire operazioni sensibili senza prima avere l'approvazione di un altro tecnico autorizzato. Questo sistema consente processi di gestione dell'accesso sicuri per scalare fino a migliaia di servizi in esecuzione sull'infrastruttura.

L'infrastruttura fornisce inoltre i servizi canonici per la gestione di utenti, gruppi e adesioni, in modo da poter implementare un controllo dell'accesso personalizzato e granulare, se necessario.

Le identità degli utenti finali sono gestite separatamente, come descritto nella sezione Gestire l'accesso ai dati degli utenti finali in Google Workspace.

Crittografia delle comunicazioni tra i servizi

L'infrastruttura offre riservatezza e integrità per i dati RPC sulla rete. Tutto il traffico di rete virtuale di Google Cloud è criptato. Tutte le comunicazioni tra i servizi di infrastruttura sono autenticate e la maggior parte delle comunicazioni tra i servizi è criptata, il che aggiunge un ulteriore livello di sicurezza per proteggere la comunicazione anche se la rete viene toccata o un dispositivo di rete è compromesso. Le eccezioni al requisito di crittografia per le comunicazioni tra i servizi vengono concesse solo per il traffico con requisiti di bassa latenza e che non lasciano un singolo tessuto di networking all'interno dei diversi livelli di sicurezza fisica nel nostro data center.

L'infrastruttura in modo automatico ed efficiente (con l'aiuto dell'offload hardware) fornisce la crittografia end-to-end per il traffico RPC dell'infrastruttura che passa sulla rete tra i data center.

Gestire l'accesso ai dati degli utenti finali in Google Workspace

Un servizio tipico di Google Workspace è stato scritto per eseguire un'azione per un utente finale. Ad esempio, un utente finale può archiviare la propria email su Gmail. L'interazione dell'utente finale con un'applicazione come Gmail potrebbe interessare altri servizi all'interno dell'infrastruttura. Ad esempio, Gmail potrebbe chiamare un'API People per accedere alla rubrica dell'utente finale.

La sezione Crittografia delle comunicazioni tra i servizi descrive in che modo un servizio (come Contatti Google) è progettato per proteggere le richieste RPC da un altro servizio (come Gmail). Tuttavia, questo livello di controllo dell'accesso è ancora un ampio insieme di autorizzazioni, perché Gmail è in grado di richiedere i contatti di qualsiasi utente in qualsiasi momento.

Quando Gmail effettua una richiesta RPC a Contatti Google per conto di un utente finale, l'infrastruttura consente a Gmail di presentare un ticket di autorizzazione dell'utente finale nella richiesta RPC. Questo ticket dimostra che Gmail sta effettuando la richiesta RPC per conto di un utente finale specifico. Il ticket consente a Contatti Google di implementare una protezione in modo che restituisca solo i dati per l'utente finale indicato nel ticket.

L'infrastruttura offre un servizio di identità utente centrale che emette questi ticket di contesto per gli utenti finali. Il servizio di identità verifica l'accesso dell'utente finale e quindi rilascia una credenziale utente, ad esempio un cookie o un token OAuth, al dispositivo dell'utente. Ogni successiva richiesta dal dispositivo alla nostra infrastruttura deve presentare la credenziale dell'utente finale.

Quando un servizio riceve una credenziale dell'utente finale, trasmette la credenziale al servizio di identità per la verifica. Se le credenziali dell'utente finale vengono verificate, il servizio di identità restituisce un ticket di contesto dell'utente finale di breve durata che può essere utilizzato per le RPC relative alla richiesta dell'utente. Nel nostro esempio, il servizio che riceve il ticket di contesto dell'utente finale è Gmail, che trasmette il ticket ai Contatti Google. Da quel momento, per qualsiasi chiamata a cascata, il servizio di chiamata può inviare il ticket di contesto dell'utente finale al destinatario come parte dell'RPC.

Il seguente diagramma mostra in che modo il servizio A e il servizio B comunicano. L'infrastruttura fornisce identità di servizio, autenticazione reciproca automatica, comunicazione criptata tra i servizi e applicazione dei criteri di accesso definiti dal proprietario del servizio. Ogni servizio ha una configurazione del servizio, che viene creata dal proprietario del servizio. Per la comunicazione criptata tra i servizi, l'autenticazione reciproca automatica utilizza le identità di chiamante e chiamante. La comunicazione è possibile solo quando una configurazione con una regola di accesso lo consente.

Diagramma che mostra come comunicano i servizi A e B.

Per informazioni sulla gestione degli accessi in Google Cloud, consulta la panoramica di IAM.

Gestire l'accesso ai dati degli utenti finali in Google Cloud

Analogamente a quanto accade per la Gestione degli accessi ai dati degli utenti finali in Google Workspace, l'infrastruttura fornisce un servizio di identità utente centrale che autentica gli account di servizio ed emette ticket di contesto per gli utenti finali dopo l'autenticazione di un account di servizio. La gestione dell'accesso tra i servizi Google Cloud viene eseguita generalmente con gli agenti di servizio anziché utilizzare i ticket di contesto dell'utente finale.

Google Cloud utilizza Identity and Access Management (IAM) e prodotti sensibili al contesto, come Identity-Aware Proxy, per consentirti di gestire l'accesso alle risorse della tua organizzazione Google Cloud. Tutte le richieste ai servizi Google Cloud passano attraverso IAM per verificare le autorizzazioni.

Il processo di gestione degli accessi è il seguente:

  1. Viene inviata una richiesta tramite il servizio Google Front End o il servizio Cloud Front End per le VM dei clienti.
  2. La richiesta viene instradata al servizio di identità utente centrale che completa il controllo di autenticazione ed emette i ticket di contesto dell'utente finale.
  3. La richiesta viene anche instradata per verificare elementi come i seguenti:
  4. Una volta superati tutti questi controlli, i servizi di backend Google Cloud vengono chiamati.

Per informazioni sulla gestione degli accessi in Google Cloud, consulta la panoramica di IAM.

Archiviazione sicura dei dati

Questa sezione descrive il modo in cui implementiamo la sicurezza dei dati archiviati nell'infrastruttura.

Crittografia at-rest

L'infrastruttura di Google fornisce vari servizi di archiviazione e file system distribuiti (ad esempio, Spanner e Colossus) e un servizio centrale di gestione delle chiavi. Le applicazioni di Google accedono all'archiviazione fisica utilizzando l'infrastruttura di archiviazione. Utilizziamo diversi livelli di crittografia per proteggere i dati at-rest. Per impostazione predefinita, l'infrastruttura di archiviazione cripta tutti i dati utente prima che questi siano scritti nello spazio di archiviazione fisico.

L'infrastruttura esegue la crittografia a livello di infrastruttura di archiviazione o applicazione. La crittografia consente all'infrastruttura di isolarsi dalle potenziali minacce ai livelli inferiori di archiviazione, ad esempio il firmware dannoso del disco. Ove applicabile, abilitiamo anche il supporto della crittografia hardware nei nostri dischi rigidi e SSD e monitoriamo meticolosamente ogni unità durante il suo ciclo di vita. Prima di essere ritirato, un dispositivo di archiviazione criptato può lasciare fisicamente la nostra custodia e viene pulito utilizzando una procedura in più passaggi che include due verifiche indipendenti. I dispositivi che non superano questo processo di pulizia vengono distrutti fisicamente (vale a dire, distrutti) on-premise.

Oltre alla crittografia eseguita dall'infrastruttura, Google Cloud e Google Workspace forniscono servizi di gestione delle chiavi. Per Google Cloud, Cloud KMS è un servizio cloud che consente ai clienti di gestire le chiavi di crittografia. Per Google Workspace, puoi utilizzare la crittografia lato client. Per scoprire di più, consulta Crittografia lato client e collaborazione rafforzata in Google Workspace.

Eliminazione dei dati

L'eliminazione dei dati in genere inizia con l'eliminazione dei dati specifici come pianificati per l'eliminazione invece che con l'eliminazione effettiva dei dati. Questo approccio ci permette di recuperare dalle eliminazioni non intenzionali, avviate dal cliente, a causa di un bug o a causa di un errore di processo interno. Una volta contrassegnati come pianificati per l'eliminazione, i dati vengono eliminati in conformità con i criteri specifici del servizio.

Quando un utente finale elimina il proprio account, l'infrastruttura informa i servizi che gestiscono i dati dell'utente finale che sono stati eliminati. I servizi possono quindi pianificare l'eliminazione dei dati associati all'account utente finale eliminato. Questa funzionalità consente a un utente finale di controllare i propri dati.

Per ulteriori informazioni, consulta Eliminazione dei dati su Google Cloud.

Comunicazione Internet sicura

Questa sezione descrive il modo in cui proteggiamo la comunicazione tra Internet e i servizi eseguiti sull'infrastruttura di Google.

Come discusso in Progettazione e provenienza dell'hardware, l'infrastruttura è composta da molte macchine fisiche interconnesse tramite LAN e WAN. La sicurezza della comunicazione tra i servizi non dipende dalla sicurezza della rete. Tuttavia, isolamo la nostra infrastruttura da Internet in uno spazio di indirizzi IP privati. Esponiamo un sottoinsieme di macchine direttamente al traffico Internet esterno per poter implementare protezioni aggiuntive come gli attacchi DoS (Denial of Service).

Servizio Google Front End (GFE)

Quando un servizio deve rendersi disponibile su Internet, può registrarsi autonomamente con un servizio di infrastruttura denominato GFE. Il GFE garantisce che tutte le connessioni TLS vengano terminate con certificati corretti e seguendo le best practice, come il supporto della perfetta Perfect Forward Secrecy. GFE applica anche protezioni contro gli attacchi DoS. Il GFE quindi inoltra le richieste per il servizio utilizzando il protocollo di sicurezza RPC descritto in Gestione dell'accesso ai dati degli utenti finali in Google Workspace.

In effetti, qualsiasi servizio interno che deve pubblicarsi esternamente utilizza il GFE come frontend smart del proxy inverso. GFE fornisce l'hosting di indirizzi IP pubblici per il nome DNS pubblico, la protezione DoS e la terminazione TLS. I GFE vengono eseguiti sull'infrastruttura come qualsiasi altro servizio e possono scalare in base ai volumi delle richieste in entrata.

Le VM dei clienti su Google Cloud non si registrano con GFE. Si registrano invece con Cloud Front End, una configurazione speciale di GFE che utilizza lo stack di networking Compute Engine. Cloud Front End consente alle VM dei clienti di accedere a un servizio Google direttamente utilizzando l'indirizzo IP pubblico o privato. Gli indirizzi IP privati sono disponibili solo se è abilitato l'accesso privato Google.

Protezione DoS

Le dimensioni della nostra infrastruttura consentono di assorbire molti attacchi DoS. Per ridurre ulteriormente il rischio di impatto DoS sui servizi, disponiamo di protezioni DoS a più livelli.

Quando la nostra dorsale in fibra ottica fornisce una connessione esterna a uno dei nostri data center, la connessione passa attraverso diversi livelli di bilanciatori del carico hardware e software. Questi bilanciatori del carico segnalano le informazioni sul traffico in entrata verso un servizio DoS centrale in esecuzione nell'infrastruttura. Quando il servizio DoS centrale rileva un attacco DoS, può configurare i bilanciatori del carico per bloccare o limitare il traffico associato all'attacco.

Le istanze GFE segnalano anche informazioni sulle richieste che ricevono dal servizio DoS centrale, incluse le informazioni a livello di applicazione a cui i bilanciatori del carico non hanno accesso. Il servizio DoS centrale può quindi configurare le istanze GFE in modo da ridurre o limitare il traffico di attacco.

Autenticazione degli utenti

Dopo la protezione DoS, il livello successivo di difesa per la comunicazione sicura proviene dal servizio di identità centrale. Gli utenti finali interagiscono con questo servizio tramite la pagina di accesso di Google. Il servizio richiede un nome utente e una password e può anche richiedere agli utenti ulteriori informazioni in base ai fattori di rischio. I fattori di rischio di esempio includono se gli utenti hanno eseguito l'accesso dallo stesso dispositivo o da una località simile in passato. Dopo l'autenticazione dell'utente, il servizio di identità rilascia credenziali come cookie e token OAuth che possono essere utilizzati per le chiamate successive.

Quando gli utenti accedono, possono utilizzare due fattori come OTP o token di sicurezza resistenti al phishing come il token di sicurezza Titan. Il token di sicurezza Titan è un token fisico che supporta il fattore universale 2° FIDO (U2F). Abbiamo contribuito allo sviluppo dello standard aperto U2F con la FIDO Alliance. La maggior parte delle piattaforme web e dei browser ha adottato questo standard di autenticazione aperto.

Sicurezza operativa

Questa sezione descrive il modo in cui sviluppiamo il software dell'infrastruttura, proteggiamo le credenziali e le macchine dei nostri dipendenti e difendiamo le minacce all'infrastruttura dall'interno e dall'esterno.

Sviluppo di software sicuri

Oltre alle protezioni del controllo del codice sorgente e al processo di revisione in due parti descritte in precedenza, utilizziamo librerie che impediscono agli sviluppatori di introdurre determinate classi di bug di sicurezza. Ad esempio, disponiamo di librerie e framework che aiutano a eliminare le vulnerabilità XSS nelle app web. Usiamo anche strumenti automatici come strumenti per il calcolo delle vulnerabilità, strumenti di analisi statici e scanner di sicurezza web per rilevare automaticamente i bug di sicurezza.

Come controllo finale, utilizziamo controlli di sicurezza manuali che vanno da controlli rapidi per le funzionalità meno rischiose a revisioni approfondite di progettazione e implementazione per le funzionalità più rischiose. Il team che conduce queste revisioni include esperti di sicurezza web, crittografia e sicurezza del sistema operativo. Le revisioni possono portare allo sviluppo di nuove funzionalità della libreria di sicurezza e di nuovi elementi utilizzati per i prodotti futuri.

Inoltre, eseguiamo un programma Vulnerability Rewards che premia chiunque rilevi e ci segnali i bug della nostra infrastruttura o delle nostre applicazioni. Per ulteriori informazioni su questo programma, inclusi i premi ricevuti, consulta le statistiche chiave sui cacciatori di bug.

Inoltre, investiamo nella ricerca di exploit zero-day e altri problemi di sicurezza nel software open source che utilizziamo. Gestiamo Project Zero, un team di ricercatori Google dedicati alla ricerca delle vulnerabilità zero-day, tra cui Spectre e Meltdown. Inoltre, siamo i maggiori autori di correzioni CVE e di sicurezza per l'hypervisor KVM Linux.

Protezioni del codice sorgente

Il nostro codice sorgente è archiviato in repository con integrità e governance integrate, in cui è possibile controllare sia la versione attuale che quella precedente del servizio. L'infrastruttura richiede che i programmi binari di un servizio vengano creati da codice sorgente specifico, dopo essere stati esaminati, controllati e verificati. L'autorizzazione binaria per Borg (BAB) è un controllo interno dell'applicazione che viene eseguito quando viene eseguito il deployment di un servizio. BAB esegue le seguenti operazioni:

  • Garantisce che il software di produzione e la configurazione di cui è stato eseguito il deployment in Google vengano esaminati e autorizzati, in particolare quando tale codice può accedere ai dati utente.
  • Garantisce che i deployment di codice e configurazione soddisfino determinati standard minimi.
  • Limita la capacità di un utente interno o avversario di apportare modifiche dannose al codice sorgente e fornisce anche una traccia forense da un servizio per tornare alla sua origine.

Proteggiamo i dispositivi e le credenziali dei dipendenti

Implementiamo misure di salvaguardia per proteggere i dispositivi e le credenziali dei dipendenti dai compromessi. Per proteggere i nostri dipendenti da tentativi di phishing sofisticati, abbiamo sostituito l'autenticazione a due fattori OTP con l'uso obbligatorio di token di sicurezza compatibili con U2F.

Monitoriamo i dispositivi client che i nostri dipendenti usano per gestire la nostra infrastruttura. Ci assicuriamo che le immagini del sistema operativo per questi dispositivi siano aggiornate con patch di sicurezza e controlliamo le applicazioni che i dipendenti possono installare sui loro dispositivi. Abbiamo anche sistemi che analizzano le applicazioni installate dagli utenti, i download, le estensioni del browser e i contenuti del browser web per determinare se sono adatti ai dispositivi aziendali.

Il collegamento alla LAN aziendale non è il nostro meccanismo principale per concedere i privilegi di accesso. Utilizziamo invece la sicurezza Zero Trust per proteggere l'accesso dei dipendenti alle nostre risorse. I controlli di Access Management a livello di applicazione espongono le applicazioni interne ai dipendenti solo quando questi utilizzano un dispositivo gestito e si connettono dalle reti e dalle posizioni geografiche previste. Un dispositivo client è attendibile in base a un certificato emesso per la singola macchina e in base alle dichiarazioni sulla sua configurazione (ad esempio il software aggiornato). Per maggiori informazioni, consulta BeyondCorp.

Riduzione dei rischi provenienti da personale interno

Per rischio interno si intende il potenziale di un dipendente, un appaltatore o un altro partner commerciale esistente o esistente che abbia o abbia avuto accesso autorizzato alla nostra rete, al nostro sistema o ai nostri dati per abusare di tale accesso e compromettere la riservatezza, l'integrità o la disponibilità dei nostri sistemi informativi o informativi.

Per contribuire a ridurre i rischi provenienti da personale interno, limitiamo e monitoriamo attivamente le attività dei dipendenti a cui è stato concesso l'accesso amministrativo all'infrastruttura. Ci impegniamo costantemente per eliminare la necessità di accesso privilegiato per determinate attività utilizzando l'automazione che può eseguire le stesse attività in modo sicuro e controllato. Esponiamo API limitate che consentono il debug senza esporre dati sensibili e richiediamo l'approvazione di due parti per determinate azioni sensibili eseguite da operatori umani.

L'accesso dei dipendenti Google alle informazioni degli utenti finali può essere registrato tramite hook dell'infrastruttura di basso livello. Il nostro team di sicurezza monitora i pattern di accesso ed esamina gli eventi insoliti. Per saperne di più, consulta Gestione degli accessi con privilegi in Google Cloud (PDF).

Utilizziamo l'autorizzazione binaria per Borg per proteggere la nostra catena di fornitura dal rischio interno. Inoltre, il nostro investimento in BeyondProd contribuisce a proteggere i dati utente nell'infrastruttura di Google e a conquistare la fiducia nei nostri servizi.

In Google Cloud, puoi monitorare l'accesso ai tuoi dati utilizzando Access Transparency. I log di Access Transparency ti consentono di verificare che il personale di Google acceda ai tuoi contenuti solo per motivi aziendali validi, ad esempio per risolvere un'interruzione del servizio o soddisfare le tue richieste di assistenza. L'approvazione dell'accesso assicura che l'assistenza clienti e i tecnici Cloud richiedano la tua approvazione esplicita ogni volta che devono accedere ai tuoi dati. L'approvazione è stata verificata tramite crittografia per garantire l'integrità dell'approvazione di accesso.

Monitoraggio delle minacce

Il gruppo di analisi delle minacce di Google monitora gli attori delle minacce e l'evoluzione delle loro tattiche e tecniche. L'obiettivo di questo gruppo è contribuire a migliorare la sicurezza e la protezione dei prodotti Google e condividere queste informazioni a vantaggio della community online.

Per Google Cloud, puoi utilizzare Google Cloud Threat Intelligence per Chronicle e VirusTotal per monitorare e rispondere a molti tipi di malware. Google Cloud Threat Intelligence per Chronicle è un team di ricercatori di minacce che sviluppano l'intelligence sulle minacce da utilizzare con Chronicle. VirusTotal è un database di malware e una soluzione di visualizzazione che puoi utilizzare per capire meglio come funziona il malware all'interno della tua azienda.

Per ulteriori informazioni sulle nostre attività di monitoraggio delle minacce, consulta il report Threat Horizons.

Rilevamento delle intrusioni

Utilizziamo pipeline di elaborazione dati sofisticate per integrare gli indicatori basati sull'host su singoli dispositivi, gli indicatori basati sulla rete provenienti da vari punti di monitoraggio nell'infrastruttura e gli indicatori dai servizi dell'infrastruttura. Le regole e l'intelligence artificiale basate su queste pipeline inviano avvisi sui possibili incidenti agli ingegneri della sicurezza operativa. I nostri team di indagine e risposta agli incidenti selezionano, esaminano e rispondono a questi potenziali incidenti 24 ore su 24, 365 giorni all'anno. Conduciamo l'attività del Red Team per misurare e migliorare l'efficacia dei nostri meccanismi di rilevamento e risposta.

Passaggi successivi