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, grazie al costante miglioramento della protezione per i nostri clienti.

Introduzione

Questo documento fornisce una panoramica su 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 tutela della privacy dell'utente finale
    • Comunicazione sicura tra i servizi
    • Comunicazioni sicure e private con i clienti su internet
    • Funzionamento sicuro dei tecnici di Google
  • Come utilizziamo questa infrastruttura per creare servizi internet, inclusi servizi consumer come Ricerca Google, Gmail e Google Foto, nonché servizi aziendali come Google Workspace e Google Cloud.
  • I nostri investimenti nella sicurezza della nostra infrastruttura e delle nostre operazioni. Abbiamo molti ingegneri dedicati alla sicurezza e alla privacy su Google, tra cui 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.

  • Modalità di progettazione della sicurezza dell'infrastruttura a livelli progressivi. Questi livelli includono:

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

Proteggere l'infrastruttura di basso livello

Questa sezione descrive le modalità di protezione delle strutture fisiche dei nostri data center, dell'hardware dei data center e dello stack software in esecuzione sull'hardware.

Sicurezza dei locali fisici

Progettiamo e costruiamo i nostri data center, che includono vari livelli di sicurezza fisica. L'accesso a questi data center è strettamente controllato. Usiamo vari livelli di sicurezza fisica per proteggere i piani dei nostri data center. Utilizziamo identificazione biometrica, 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.

Inoltre, ospitiamo alcuni server in data center di terze parti. In questi data center, garantiamo la presenza di misure di sicurezza fisica controllate da Google in aggiunta 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 Google è costituito da migliaia di server connessi a una rete locale. Progettiamo le schede server e le apparecchiature di networking. Controlliamo i fornitori dei componenti con cui collaboriamo e scegliamo i componenti con attenzione. Collaboriamo con i fornitori per verificare e convalidare le proprietà di sicurezza fornite dai componenti. Progettiamo inoltre chip personalizzati, tra cui 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 di fungere da radice di attendibilità hardware.

Stack di avvio protetto e identità della 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 controller di gestione del baseboard (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 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 tramite l'attestazione dell'integrità. Con ogni nuova generazione di hardware, ci impegniamo per migliorare costantemente la sicurezza. Ad esempio, a seconda della generazione della progettazione del server, la radice di attendibilità della catena di avvio è una delle seguenti:

  • Chip hardware Titan
  • Un chip del firmware bloccabile
  • Un microcontrollore 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 si avvia 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 del server e la crittografia del trasporto. Abbiamo sviluppato il sistema Application Layer Transport Security (ALTS) per proteggere le comunicazioni RPC (chiamata di procedura remota) all'interno della nostra infrastruttura. Queste identità delle macchine 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 rialloca 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 transcodifiche video di YouTube e le VM 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 dei cluster, chiamato Borg, controlla i servizi in esecuzione direttamente sull'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 per impostazione predefinita nessun dispositivo o utente è considerato attendibile, né all'interno né all'esterno della rete.

Poiché l'infrastruttura è progettata per essere multi-tenant, i dati dei nostri clienti (clienti, aziende e persino i nostri stessi) vengono 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 singolo set di macchine, tranne in circostanze specifiche, ad esempio quando utilizzi Google Cloud per eseguire il provisioning delle 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 saperne di più sulla residenza dei dati e su Google Workspace, consulta 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 crittografica. L'autenticazione e l'autorizzazione forniscono un solido controllo dell'accesso a un livello di astrazione e con una granularità comprensibile 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 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. A un servizio vengono fornite 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 separazione degli utenti Linux, sandbox basate sul linguaggio (come l'API con sandbox) e sandbox basate su kernel, kernel dell'applicazione per container (ad esempio gVisor) e virtualizzazione hardware. In generale, usiamo più livelli di isolamento per carichi di lavoro più rischiosi. I carichi di lavoro più pericolosi includono elementi forniti dall'utente che richiedono un'ulteriore elaborazione. 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 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 dei 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 i 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. Quel servizio può essere configurato con l'elenco delle identità di servizio consentite e l'infrastruttura applica automaticamente questa limitazione di accesso. L'applicazione include audit logging, giustificazioni e limitazione di accesso unilaterale (ad esempio per le richieste dei tecnici).

I tecnici 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 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 flussi di lavoro che include catene di approvazione, logging e notifiche. Ad esempio, il criterio di sicurezza può applicare l'autorizzazione multiparti. 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 tecnico autorizzato. Questo sistema consente processi sicuri di gestione degli accessi per scalare fino a migliaia di servizi in esecuzione nell'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 dove necessario.

Le identità degli utenti finali sono gestite separatamente, come descritto in Gestione degli accessi ai dati degli utenti finali in Google Workspace.

Crittografia delle comunicazioni tra i servizi

L'infrastruttura fornisce riservatezza e integrità per i dati RPC sulla rete. Tutto il traffico del 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 attacco alla rete o in caso di compromissione di un dispositivo di rete. Le eccezioni al requisito di crittografia per le comunicazioni tra servizi sono concesse solo per il traffico che presenta requisiti di bassa latenza e che non lascia un'unica struttura di networking 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 su Gmail. L'interazione dell'utente finale con un'applicazione come Gmail può abbracciare 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, ad esempio Contatti Google, è progettato per proteggere le richieste RPC da un altro servizio, ad esempio Gmail. Tuttavia, questo livello di controllo dell'accesso è comunque un ampio set di autorizzazioni perché Gmail può 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 dell'utente finale specifico. Il ticket consente a Contatti Google di implementare una salvaguardia in modo che restituisca solo i dati dell'utente finale indicato nel ticket.

L'infrastruttura fornisce un servizio di identità utente centrale che emette questi ticket di contesto dell'utente finale. 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 richiesta successiva dal dispositivo alla nostra infrastruttura deve presentare la credenziale dell'utente finale.

Quando un servizio riceve una credenziale di utente finale, passa la credenziali 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 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 come comunicano il servizio A e il servizio B. L'infrastruttura fornisce identità di 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. Per le comunicazioni criptate tra i servizi, l'autenticazione reciproca automatica utilizza identità di chiamante e di chiamante. La comunicazione è possibile solo quando la configurazione di una regola di accesso lo consente.

Diagramma che mostra come 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 dell'accesso ai dati degli utenti finali in Google Workspace, l'infrastruttura offre un servizio di identità degli utenti centrale che autentica gli account di servizio ed emette ticket di contesto dell'utente finale dopo l'autenticazione di un account di servizio. La gestione degli accessi tra i servizi Google Cloud in genere viene eseguita tramite agenti di servizio anziché utilizzare i ticket di contesto degli utenti finali.

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.

La procedura di gestione degli accessi è la seguente:

  1. Una richiesta arriva 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 dell'autenticazione ed emette i ticket di contesto per l'utente finale.
  3. La richiesta viene inoltrata anche per controllare elementi come:
  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 le modalità con cui implementiamo la sicurezza per i 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), oltre a un Key Management Service centralizzato. Le applicazioni Google accedono all'archiviazione fisica tramite l'infrastruttura. Usiamo 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 al livello dell'infrastruttura di applicazione o di archiviazione. La crittografia consente all'infrastruttura di isolarsi dalle potenziali minacce ai livelli di archiviazione inferiori, come il firmware dannoso del disco. Ove applicabile, attiviamo anche il supporto della crittografia hardware nei nostri dischi rigidi e nelle unità SSD e monitoriamo meticolosamente ogni unità durante il suo ciclo di vita. Prima che un dispositivo di archiviazione criptato dismesso possa lasciare fisicamente la nostra custodia, il dispositivo viene ripulito utilizzando una procedura in più passaggi che include due verifiche indipendenti. I dispositivi che non superano questa procedura di pulizia vengono fisicamente distrutti (ovvero sminuiti) 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 rafforzamento della collaborazione in Google Workspace.

Eliminazione dei dati

L'eliminazione dei dati in genere inizia con la marcatura di dati specifici come pianificati per l'eliminazione anziché l'eliminazione effettiva dei dati. Questo approccio ci consente di eseguire il ripristino in caso di eliminazioni non intenzionali, a prescindere dal fatto che siano avviate dal cliente, dovute a un bug o sia il risultato di un errore di processo interno. Dopo essere stati 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 invia una notifica ai servizi che gestiscono i dati dell'utente finale dell'eliminazione dell'account. 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 maggiori informazioni, consulta Eliminazione dei dati su Google Cloud.

Comunicazione internet sicura

Questa sezione descrive le modalità in cui proteggiamo le comunicazioni tra internet e i servizi in esecuzione sull'infrastruttura di 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, isoliamo la nostra infrastruttura da internet in uno spazio di indirizzi IP privato. Esponiamo un sottoinsieme delle macchine direttamente al traffico internet esterno. In questo modo possiamo 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 a un servizio di infrastruttura chiamato Google Front End (GFE). GFE garantisce che tutte le connessioni TLS vengano terminate con certificati corretti e seguendo le best practice, come il supporto della Perfect Forward Secrecy (PFS). GFE applica anche protezioni contro gli attacchi DoS. GFE inoltra quindi 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 inverso intelligente. GFE offre l'hosting dell'indirizzo IP pubblico per l'hosting del nome DNS pubblico, della protezione DoS e della 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 del cliente di accedere a un servizio Google direttamente utilizzando il loro indirizzo IP pubblico o privato. Gli indirizzi IP privati sono disponibili solo quando è abilitato l'accesso privato Google.

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 a più livelli.

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 per ridurre o limitare il traffico associato all'attacco.

Le istanze GFE segnalano anche informazioni sulle richieste che ricevono al servizio DoS centrale, comprese 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 eliminare o limitare il traffico degli attacchi.

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 ulteriori informazioni agli utenti in base ai fattori di rischio. Alcuni esempi di fattori di rischio includono il fatto che gli utenti abbiano eseguito l'accesso dallo stesso dispositivo o da una località 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 secondi 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 a sviluppare lo 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 proteggiamo l'infrastruttura dalle minacce all'infrastruttura da parte di utenti malintenzionati interni ed esterni.

Sviluppo sicuro di software

Oltre alle protezioni per il controllo delle fonti e alla procedura 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 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 da una rapida valutazione per le funzionalità meno rischiose a revisioni approfondite di progettazione e implementazione per le funzionalità più rischiose. Il team che effettua le revisioni include esperti di sicurezza web, crittografia e sicurezza del sistema operativo. Le revisioni possono portare allo sviluppo di nuove funzionalità delle librerie di sicurezza e di nuovi fuzzer che possiamo utilizzare per prodotti futuri.

Inoltre, eseguiamo un Vulnerability Rewards Program che premia chiunque scopra e ci segnali bug nella nostra infrastruttura o nelle nostre applicazioni. Per ulteriori informazioni su questo programma, inclusi i premi che abbiamo accordato, consulta le statistiche chiave per i 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 il più grande mittente di CVE e correzioni di bug di sicurezza per l'hypervisor KVM Linux.

Protezioni per il codice sorgente

Il nostro codice sorgente è archiviato in repository con integrità e governance integrate, dove è possibile controllare sia la versione attuale che quella precedente 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 si verifica quando viene eseguito il deployment di un servizio. BAB fa quanto segue:

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

Mantenere al sicuro i dispositivi e le credenziali dei dipendenti

Implementiamo misure di salvaguardia per contribuire a proteggere le credenziali e i dispositivi dei nostri dipendenti dalla compromissione. 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. Un dispositivo client è considerato attendibile in base a un certificato emesso sulla singola macchina e in base alle asserzioni relative alla sua configurazione (come il software aggiornato). Per ulteriori informazioni, consulta BeyondCorp.

Riduzione dei rischi provenienti da personale interno

Il rischio interno è il potenziale di un dipendente, un appaltatore o un altro partner commerciale attuale o precedente che ha o ha autorizzato l'accesso alla nostra rete, al nostro sistema o ai nostri dati per un uso improprio di tale accesso al fine di minare la riservatezza, l'integrità o la disponibilità dei nostri sistemi informativi o di informazione.

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. Lavoriamo costantemente per eliminare la necessità di accesso privilegiato per determinate attività utilizzando un'automazione che possa svolgere le stesse attività in modo sicuro e controllato. Esponiamo API limitate che consentono il debug senza esporre dati sensibili e abbiamo bisogno di approvazioni 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 per la sicurezza monitora i pattern di accesso e analizza eventi insoliti. Per maggiori informazioni, consulta Privileged Access Management 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 creare 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 progettazione richiedano la tua approvazione esplicita ogni volta che hanno bisogno di accedere ai tuoi dati. L'approvazione viene verificata tramite crittografia per garantire l'integrità dell'approvazione dell'accesso.

Monitoraggio delle minacce

Il Threat Analysis Group di Google monitora gli autori delle minacce 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 Google Security Operations e VirusTotal per monitorare e rispondere a molti tipi di malware. Google Cloud Threat Intelligence for Google Security Operations è un team di ricercatori sulle minacce che sviluppano le informazioni sulle minacce da utilizzare con Google Security Operations. 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 Minacce Horizons.

Rilevamento delle intrusioni

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

Passaggi successivi