Panoramica sulla progettazione della sicurezza dell'infrastruttura Google

Questi contenuti sono stati aggiornati l'ultima volta a giugno 2023 e rappresentano lo status quo del momento in cui sono stati redatti. Criteri e sistemi di sicurezza di Google possono variare in futuro, in virtù del costante miglioramento della protezione per i nostri clienti.

Introduzione

Questo documento offre una panoramica di come la sicurezza è integrata nella progettazione dell'infrastruttura tecnica di Google. È rivolta a dirigenti, architetti e revisori della sicurezza.

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
    • Comunicazioni sicure e private con i clienti su internet
    • Funzionamento sicuro da parte dei tecnici di Google
  • Come utilizziamo questa infrastruttura per creare servizi internet, inclusi servizi consumer come Ricerca Google, Gmail e Google Foto e servizi aziendali come Google Workspace e Google Cloud.
  • Il nostro investimento nella protezione della nostra infrastruttura e delle nostre operazioni. Abbiamo molti ingegneri che si dedicano alla sicurezza e alla privacy su Google, inclusi molti che sono autorità di settore riconosciute.
  • I prodotti e i servizi di sicurezza che sono il risultato di innovazioni che abbiamo implementato internamente per soddisfare le nostre esigenze di sicurezza. Ad esempio, BeyondCorp è il risultato diretto della nostra implementazione interna del modello di sicurezza Zero Trust.

  • Come è progettata la sicurezza dell'infrastruttura a livelli progressivi. Questi livelli includono:

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

Infrastruttura di basso livello sicura

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

Sicurezza dei locali fisici

Progettiamo e costruiamo i nostri data center, che incorporano più livelli di sicurezza fisica. L'accesso a questi data center è controllato severamente. Utilizziamo diversi livelli di sicurezza fisica per proteggere i piani dei nostri data center. Usiamo sistemi di rilevamento biometrico, rilevamento dei metalli, telecamere, barriere per i veicoli e sistemi di rilevamento delle intrusioni basati su laser. Per ulteriori informazioni, consulta Sicurezza dei data center.

Alcuni server vengono ospitati anche in data center di terze parti. In questi data center, ci 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, telecamere e metal detector 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 connessi a una rete locale. Progettiamo le schede server e le apparecchiature di rete. Esaminiamo i fornitori dei componenti con cui collaboriamo e scegliamo i componenti con cura. Collaboriamo con i fornitori per verificare e convalidare le proprietà di sicurezza fornite dai componenti. Progettiamo anche chip personalizzati, tra cui un chip di sicurezza hardware (chiamato Titan), di cui eseguiamo il deployment su server, dispositivi e periferiche. Questi chip ci consentono di identificare e autenticare i dispositivi Google legittimi a livello di hardware e di fungere da radice di attendibilità hardware.

Stack di avvio protetto e identità macchina

I server di Google utilizzano varie tecnologie per garantire l'avvio dello stack software corretto. Utilizziamo le firme crittografiche per i componenti di basso livello come il Baseboard Management Controller (BMC), il BIOS, il bootloader, il kernel e l'immagine del sistema operativo di base. Queste firme possono essere convalidate durante ogni ciclo di avvio o di aggiornamento. Il primo controllo dell'integrità per i server Google utilizza una radice di attendibilità hardware. I componenti sono controllati, creati e protetti da Google con l'attestazione di integrità. Con ogni nuova generazione di hardware, ci impegniamo a migliorare continuamente la sicurezza. Ad esempio, a seconda della generazione del design del server, la radice di attendibilità della catena di avvio è in una delle seguenti opzioni:

  • Il chip hardware Titan
  • Un chip firmware bloccabile
  • Un microcontroller che esegue il nostro codice di sicurezza

Ogni server nel data center ha una propria identità unica. Questa identità può essere legata alla radice di attendibilità hardware e al software con cui viene avviata la macchina. 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 dei server e la crittografia del trasporto. Abbiamo sviluppato il sistema Application Layer Transport Security (ALTS) per proteggere le comunicazioni RPC (Remote Procedure Call, chiamata di procedura remota) all'interno della nostra infrastruttura. Queste identità macchina possono essere revocate centralmente per rispondere a un incidente di sicurezza. Inoltre, i certificati e le chiavi vengono ruotati regolarmente e quelli precedenti vengono revocati.

Abbiamo sviluppato sistemi automatici per:

  • Assicurati che i server eseguano versioni aggiornate degli stack software (incluse le patch di sicurezza).
  • Rileva e diagnostica problemi hardware e software.
  • Garantisci l'integrità delle macchine e delle periferiche con avvio verificato e 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 riassegna le macchine dal servizio quando non sono più necessarie.

Deployment sicuro dei servizi

I servizi Google sono i programmi binari delle applicazioni 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 transcodifiche video di YouTube e le VM di Compute Engine che eseguono 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 cluster, denominato Borg, controlla i servizi in esecuzione direttamente nell'infrastruttura.

L'infrastruttura non presuppone alcun trust tra i servizi in esecuzione sull'infrastruttura. Questo modello di attendibilità è definito modello di sicurezza Zero Trust. Un modello di sicurezza Zero Trust implica che nessun dispositivo o utente sia considerato attendibile per impostazione predefinita, sia all'interno che 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 su un unico insieme di macchine, tranne in circostanze specifiche, ad esempio quando utilizzi Google Cloud per eseguire il provisioning di VM su 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 residenza e sovranità dei dati. Per ulteriori informazioni sulla residenza dei dati e su Google Workspace, vedi Regioni di dati: scegliere una posizione geografica per i tuoi dati.

Identità, integrità e isolamento dei servizi

Per abilitare la comunicazione tra i servizi, le applicazioni utilizzano l'autenticazione e l'autorizzazione crittografiche. L'autenticazione e l'autorizzazione forniscono un efficace controllo dell'accesso a un livello di astrazione e di granularità comprensibili per amministratori e servizi.

I servizi non si basano sulla segmentazione della rete interna o sul firewall come meccanismo di sicurezza principale. I filtri in entrata e in uscita in vari punti della rete aiutano a prevenire lo spoofing degli IP. Questo approccio ci aiuta anche a massimizzare le prestazioni e la disponibilità della 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 durante la creazione o la ricezione di RPC. Queste identità vengono utilizzate nei criteri di sicurezza. I criteri di sicurezza assicurano che i client comunichino con il server previsto e che i server limitino i metodi e i dati a cui possono accedere determinati client.

Utilizziamo varie tecniche di isolamento e limitazione tramite sandbox per proteggere un servizio da altri servizi in esecuzione sulla stessa macchina. Queste tecniche includono la separazione degli utenti Linux, le sandbox basate su linguaggio (come l'API con sandbox) e le 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 carichi di lavoro più rischiosi. I carichi di lavoro più rischiosi includono elementi forniti dall'utente che richiedono un'elaborazione aggiuntiva. Ad esempio, i carichi di lavoro più rischiosi includono l'esecuzione di convertitori di file complessi su dati forniti dall'utente o l'esecuzione di codice fornito dall'utente per prodotti come App Engine o Compute Engine.

Per una maggiore sicurezza, i servizi sensibili come il servizio di orchestrazione 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 Confidential Computing per le VM di Compute Engine e i nodi Google Kubernetes Engine (GKE).

Gestione degli accessi tra i servizi

Il proprietario di un servizio può utilizzare le funzionalità di gestione degli accessi offerte 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. Il servizio può essere configurato con l'elenco consentito delle identità di servizio e l'infrastruttura applica automaticamente questa limitazione di accesso. L'applicazione include audit logging, giustificazioni e limitazioni di accesso unilaterali (ad esempio per le richieste dei tecnici).

Ai tecnici di Google che hanno bisogno di accedere ai servizi vengono inoltre rilasciate identità individuali. I servizi possono essere configurati per consentire o negare l'accesso in base alle loro identità. 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 multi-parti. Questo sistema utilizza la regola delle due persone per garantire che un ingegnere che agisce da solo non possa eseguire operazioni sensibili senza prima ottenere l'approvazione di un altro ingegnere autorizzato. Questo sistema consente a processi sicuri di gestione degli accessi di scalare fino a migliaia di servizi in esecuzione sull'infrastruttura.

L'infrastruttura fornisce inoltre servizi con il servizio canonico per la gestione di utenti, gruppi e iscrizioni, in modo che sia possibile implementare controllo dell'accesso personalizzato e granulare ove necessario.

Le identità degli utenti finali vengono gestite separatamente, come descritto in Gestione dell'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 networking virtuale di Google Cloud è criptato. Tutte le comunicazioni tra i servizi di infrastruttura sono autenticate e la maggior parte delle comunicazioni tra i servizi è crittografata, il che aggiunge un ulteriore livello di sicurezza per proteggere le comunicazioni anche in caso di tocchi di rete o di compromissione di un dispositivo di rete. Le eccezioni al requisito di crittografia per le comunicazioni tra i servizi sono concesse solo per il traffico con requisiti di bassa latenza e che non lascia un'unica struttura di rete all'interno dei vari livelli di sicurezza fisica del nostro data center.

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

Gestione dell'accesso ai dati degli utenti finali in Google Workspace

Un tipico servizio di Google Workspace è scritto per fare qualcosa per un utente finale. Ad esempio, un utente finale può archiviare le proprie email in Gmail. L'interazione dell'utente finale con un'applicazione come Gmail può estendersi su 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 la progettazione di un servizio (ad esempio Contatti Google) per proteggere le richieste RPC da un altro servizio, ad esempio 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 per l'utente finale nella richiesta RPC. Questo ticket dimostra che Gmail effettua la richiesta RPC per conto dell'utente finale in questione. Il ticket consente a Contatti Google di implementare una salvaguardia in modo che restituisca solo i dati per l'utente finale indicato nel ticket.

L'infrastruttura fornisce un servizio centrale di identità dell'utente che emette questi ticket di contesto per l'utente finale. Il servizio di identità verifica l'accesso dell'utente finale, quindi emette una credenziale utente, ad esempio un cookie o un token OAuth, sul dispositivo dell'utente. Ogni successiva richiesta del dispositivo alla nostra infrastruttura deve presentare la credenziale dell'utente finale.

Quando un servizio riceve una credenziale di utente finale, passa 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 di breve durata per l'utente finale che può essere utilizzato per le RPC relative alla richiesta dell'utente. Nel nostro esempio, il servizio che riceve il ticket di contesto per l'utente finale è Gmail, che lo passa a Contatti Google. Da quel momento in poi, per qualsiasi chiamata a cascata, il servizio di chiamata può inviare il ticket di contesto dell'utente finale alla chiamata come parte dell'RPC.

Il seguente diagramma mostra la modalità di comunicazione tra il Servizio A e il Servizio B. L'infrastruttura offre identità del servizio, autenticazione reciproca automatica, comunicazioni criptate tra i servizi e applicazione dei criteri di accesso definiti dal proprietario del servizio. Ogni servizio ha una configurazione del servizio, creata dal proprietario del servizio. Per le comunicazioni criptate tra i servizi, l'autenticazione reciproca automatica utilizza le identità di chiamante e destinatario. La comunicazione è possibile solo quando la configurazione di una regola di accesso lo consente.

Diagramma che mostra il modo in cui comunicano il Servizio A e il Servizio B.

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

Gestione dell'accesso ai dati degli utenti finali in Google Cloud

Analogamente alla gestione degli accessi ai dati degli utenti finali in Google Workspace, l'infrastruttura fornisce un servizio di identità dell'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 degli accessi tra i servizi Google Cloud in genere viene eseguita 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 nella tua organizzazione Google Cloud. Tutte le richieste ai servizi Google Cloud passano tramite IAM per verificare le autorizzazioni.

Il processo di gestione degli accessi è il seguente:

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

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

Archiviazione sicura dei dati

Questa sezione descrive come implementiamo la sicurezza per i dati archiviati nell'infrastruttura.

Crittografia at-rest

L'infrastruttura di Google offre vari servizi di archiviazione e file system distribuiti (ad esempio Spanner e Colossus) e un servizio di gestione centrale delle chiavi. Le applicazioni di Google accedono allo spazio di archiviazione fisico tramite 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 vengano scritti nello spazio di archiviazione fisico.

L'infrastruttura esegue la crittografia a livello di applicazione o di infrastruttura di archiviazione. La crittografia consente all'infrastruttura di isolare se stessa da potenziali minacce ai livelli di archiviazione inferiori, come 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à per tutta la durata del suo ciclo di vita. Prima che un dispositivo di archiviazione criptato dismesso possa lasciare fisicamente la nostra custodia, il dispositivo viene ripulito mediante una procedura in più passaggi che include due verifiche indipendenti. I dispositivi che non superano questo processo di pulizia vengono distrutti fisicamente (ovvero triturati) on-premise.

Oltre alla crittografia eseguita dall'infrastruttura, Google Cloud e Google Workspace forniscono anche 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 saperne di più, consulta Crittografia lato client e collaborazione rafforzata in Google Workspace.

Eliminazione dei dati

In genere, l'eliminazione dei dati inizia contrassegnando dati specifici come pianificati per l'eliminazione anziché eliminarli effettivamente. Questo approccio ci consente di ripristinare le eliminazioni non intenzionali, indipendentemente dal fatto che siano avviate dal cliente, dovute a un bug o dovute a un errore di processo interno. Dopo essere stati contrassegnati come pianificati per l'eliminazione, i dati vengono eliminati in base ai 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 l'account è stato eliminato. I servizi possono quindi pianificare l'eliminazione dei dati associati all'account utente finale eliminato. Questa funzionalità consente all'utente finale di controllare i propri dati.

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

Comunicazione internet sicura

Questa sezione descrive come proteggiamo le comunicazioni tra internet e i servizi in esecuzione sull'infrastruttura Google.

Come discusso in Design e provenienza dell'hardware, l'infrastruttura è composta da molte macchine fisiche interconnesse tramite LAN e WAN. La sicurezza delle comunicazioni tra i servizi non dipende dalla sicurezza della rete. Tuttavia, analizziamo la nostra infrastruttura da internet a uno spazio di indirizzi IP privati. Mostriamo solo un sottoinsieme delle macchine direttamente al traffico internet esterno in modo da poter implementare protezioni aggiuntive, come le difese dagli attacchi DoS (Denial of Service).

Servizio Google Front End (GFE)

Quando un servizio deve rendersi disponibile su internet, può registrarsi in un servizio di infrastruttura chiamato Google Front End (GFE). Il GFE garantisce che tutte le connessioni TLS vengano terminate con certificati corretti e seguendo best practice come il supporto della Perfetta Forward Secrecy. Il GFE applica anche protezioni contro gli attacchi DoS. Quindi, il GFE 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 GFE come frontend proxy smart reverse. Il GFE fornisce l'hosting dell'indirizzo IP pubblico per il nome DNS pubblico, la protezione DoS e la terminazione TLS. I GFE vengono eseguiti nell'infrastruttura come qualsiasi altro servizio e possono scalare per adeguarsi ai volumi di richieste in entrata.

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

Protezione DoS

La portata della nostra infrastruttura le consente di assorbire molti attacchi DoS. Per ridurre ulteriormente il rischio di impatto DoS sui servizi, disponiamo di protezioni DoS multilivello.

Quando la nostra backbone 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 informazioni sul traffico in entrata a un servizio DoS centrale in esecuzione sull'infrastruttura. Quando il servizio DoS centrale rileva un attacco DoS, può configurare i bilanciatori del carico in modo da limitare o limitare il traffico associato all'attacco.

Le istanze GFE segnalano anche informazioni sulle richieste che ricevono al servizio DoS centrale, comprese informazioni a livello di applicazione a cui i bilanciatori del carico non hanno accesso. Il servizio DoS centrale può quindi configurare le istanze GFE per ridurre o limitare il traffico degli attacchi.

Autenticazione degli utenti

Dopo la protezione DoS, il nuovo livello 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 l'inserimento di nome utente e password e può anche richiedere ulteriori informazioni agli utenti in base ai fattori di rischio. Esempi di fattori di rischio includono se gli utenti hanno eseguito l'accesso dallo stesso dispositivo o da una posizione simile in passato. Dopo l'autenticazione dell'utente, il servizio di identità rilascia le credenziali, ad esempio cookie e token OAuth che possono essere utilizzati per le chiamate successive.

Quando gli utenti accedono, possono usare due fattori, ad esempio 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 FIDO Universal 2nd Factor (U2F). Abbiamo contribuito allo sviluppo dello standard aperto U2F con la FIDO Alliance. La maggior parte delle piattaforme web e dei browser hanno adottato questo standard di autenticazione aperta.

Sicurezza operativa

Questa sezione descrive come sviluppiamo il software dell'infrastruttura, proteggiamo le macchine e le credenziali dei nostri dipendenti e ci difendiamo dalle minacce all'infrastruttura da parte di utenti malintenzionati interni ed esterni.

Sviluppo di software sicuro

Oltre alle protezioni per il controllo del codice sorgente e al processo di revisione a 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 automatizzati come fuzzer, strumenti di analisi statica e scanner di sicurezza web per rilevare automaticamente i bug di sicurezza.

Come controllo finale, utilizziamo revisioni manuali della sicurezza che vanno dalla classificazione rapida per le funzionalità meno rischiose a revisioni approfondite di progettazione e implementazione per le funzionalità più rischiose. Il team che si occupa di queste revisioni include esperti di sicurezza web, crittografia e sicurezza dei sistemi operativi. Le revisioni possono portare allo sviluppo di nuove funzionalità della libreria di sicurezza e di nuovi fuzzer che possiamo utilizzare per i prodotti futuri.

Inoltre, eseguiamo un Vulnerability Rewards Program, che premia chiunque scopra bug nella nostra infrastruttura o nelle nostre applicazioni e ci informi. Per ulteriori informazioni su questo programma, inclusi i premi che abbiamo offerto, consulta le statistiche chiave dei cacciatori di bug.

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

Protezioni del codice sorgente

Il nostro codice sorgente è archiviato in repository con integrità e governance del codice sorgente integrate, dove è possibile controllare sia le versioni attuali che quelle precedenti del servizio. L'infrastruttura richiede che i programmi binari di un servizio vengano creati da un codice sorgente specifico, dopo l'esame, il check-in e il test. Autorizzazione binaria per Borg (BAB) è un controllo di applicazione interno che viene eseguito quando viene eseguito il deployment di un servizio. BAB esegue quanto segue:

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

Protezione dei dispositivi e delle credenziali dei dipendenti

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

Monitoriamo i dispositivi client che i nostri dipendenti utilizzano per gestire la nostra infrastruttura. Ci assicuriamo che le immagini del sistema operativo per questi dispositivi siano aggiornate con le patch di sicurezza e controlliamo le applicazioni che i dipendenti possono installare sui loro dispositivi. Disponiamo inoltre di 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.

La connessione 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 gestione degli accessi a livello di applicazione espongono le applicazioni interne ai dipendenti solo quando questi ultimi utilizzano un dispositivo gestito e si connettono dalle reti e dalle posizioni geografiche previste. L'attendibilità di un dispositivo client avviene in base a un certificato emesso alla singola macchina e in base alle dichiarazioni sulla sua configurazione (come il software aggiornato). Per ulteriori informazioni, consulta BeyondCorp.

Riduzione dei rischi provenienti da personale interno

I rischi interni rappresentano il potenziale di un dipendente, di un appaltatore o di un altro partner commerciale attuale o precedente che ha o era autorizzato ad accedere alla nostra rete, al nostro sistema o ai nostri dati a un uso improprio di tale accesso che compromette la riservatezza, l'integrità o la disponibilità dei nostri sistemi informativi o informativi.

Per 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 un accesso privilegiato per attività particolari utilizzando un'automazione che può svolgere le stesse attività in modo sicuro e controllato. Esponiamo API limitate che consentono il debug senza esporre i 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 ulteriori informazioni, consulta La gestione degli accessi con privilegi in Google Cloud (PDF).

Utilizziamo l'autorizzazione binaria per Borg per proteggere la nostra catena di fornitura dai rischi provenienti da personale interno. Inoltre, il nostro investimento in BeyondProd contribuisce a proteggere i dati utente nell'infrastruttura di Google e a instaurare 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 Google acceda ai tuoi contenuti solo per validi motivi aziendali, ad esempio per risolvere un'interruzione del servizio o per partecipare alle richieste di assistenza. Access Approval garantisce che l'assistenza clienti Google Cloud e il team di ingegneri richiedano la tua approvazione esplicita ogni volta che devono accedere ai tuoi dati. L'approvazione viene verificata crittograficamente per garantire l'integrità dell'approvazione dell'accesso.

Monitoraggio delle minacce

Il Threat Analysis Group di Google monitora gli utenti malintenzionati e l'evoluzione delle loro tattiche e tecniche. L'obiettivo di questo gruppo è contribuire a migliorare la sicurezza 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 sulle 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 comprendere meglio il funzionamento del malware all'interno della tua azienda.

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

Rilevamento delle intrusioni

Utilizziamo sofisticate pipeline di elaborazione dati per integrare indicatori basati su host su singoli dispositivi, indicatori basati sulla rete provenienti da vari punti di monitoraggio nell'infrastruttura e indicatori dei servizi di infrastruttura. Le regole e l'intelligenza artificiale basate su queste pipeline forniscono avvisi agli ingegneri della sicurezza operativa in caso di possibili incidenti. I nostri team di indagine e risposta agli incidenti classificano, esaminano e rispondono a questi potenziali incidenti 24 ore su 24, 365 giorni l'anno. Conduciamo esercizi di Red Team per misurare e migliorare l'efficacia dei nostri meccanismi di rilevamento e risposta.

Passaggi successivi