Panoramica sulla progettazione della sicurezza dell'infrastruttura Google

Questi contenuti sono stati aggiornati per l'ultima volta a giugno 2024 e rappresentano lo status quo al momento della redazione. I criteri e i sistemi di sicurezza di Google potranno variare in futuro, in virtù del costante miglioramento della protezione per i nostri clienti.

Scarica la versione PDF

Introduzione

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

Questo documento descrive quanto segue:

  • L'infrastruttura tecnica globale di Google, progettata per fornire sicurezza durante l'intero ciclo di vita di trattamento delle informazioni in Google. Questa infrastruttura contribuisce a 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 sicura e privata con i clienti su internet
    • Funzionamento sicuro da parte degli ingegneri di Google
  • Come utilizziamo questa infrastruttura per creare servizi internet, inclusi servizi per i consumatori come la Ricerca Google, Gmail e Google Foto, e servizi aziendali come Google Workspace e Google Cloud.
  • I prodotti e 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 la sicurezza dell'infrastruttura è progettata in livelli progressivi. Questi livelli includono:

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

Infrastruttura di basso livello sicura

Questa sezione descrive in che modo proteggiamo i locali fisici dei nostri data center, l'hardware dei nostri data center e lo stack software in esecuzione sull'hardware.

Sicurezza dei locali fisici

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

All'interno del data center, implementiamo controlli aggiuntivi per garantire che l'accesso fisico ai server sia protetto e monitorato. Per saperne di più, vedi In che modo Google protegge lo spazio fisico-logico in un data center.

Ospitiamo inoltre alcuni server in data center di terze parti. In questi data center, ci allineiamo agli stessi standard normativi dei nostri data center. Garantiamo misure di sicurezza fisica controllate da Google e connettività controllata da Google in aggiunta ai livelli di sicurezza forniti dall'operatore del data center. Ad esempio, utilizziamo sistemi di identificazione biometrica, telecamere e metal detector indipendenti dai livelli di sicurezza forniti dall'operatore del data center.

Se non diversamente specificato, i controlli di sicurezza descritti in questo documento si applicano sia ai data center di proprietà di Google sia a quelli di terze parti.

Origine e progettazione hardware

I data center di Google sono costituiti da migliaia di server connessi a una rete locale. Progettiamo le schede server e le apparecchiature di networking. Controlliamo i fornitori di componenti con cui collaboriamo e scegliamo i componenti con attenzione. 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), che implementiamo su server, dispositivi e periferiche. Questi chip ci consentono di identificare e autenticare i dispositivi Google legittimi a livello hardware e fungono da radici di attendibilità hardware.

Stack di avvio protetto e identità della macchina

I server Google utilizzano varie tecnologie per garantire l'avvio dello stack software previsto. In ogni fase della procedura di avvio, Google implementa controlli leader del settore per contribuire a imporre lo stato di avvio che ci aspettiamo e per contribuire a proteggere i dati dei clienti.

Ci impegniamo a migliorare continuamente i nostri server con ogni generazione di hardware successiva e a portare questi miglioramenti nel resto del settore partecipando ai processi di standardizzazione con Trusted Computing Group e DMTF.

Ogni server nel data center ha una propria identità univoca. Questa identità può essere collegata alle radici di attendibilità hardware e al software di avvio della 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 (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 vecchi vengono revocati.

Abbiamo sviluppato sistemi automatizzati per:

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

Per ulteriori informazioni su come proteggiamo il nostro boot stack e l'integrità delle macchine, consulta Come Google applica l'integrità di avvio sulle macchine di produzione e Attestazione remota di macchine disaggregate.

Deployment sicuro dei servizi

I servizi Google sono i 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 transcodificatori video di YouTube e le VM di Compute Engine che eseguono applicazioni dei clienti. Per gestire la scala richiesta del carico di lavoro, migliaia di macchine potrebbero eseguire i binari dello stesso servizio. Un servizio di orchestrazione dei cluster, chiamato Borg, controlla i servizi in esecuzione direttamente sull'infrastruttura.

L'infrastruttura non presuppone alcuna relazione di attendibilità tra i servizi in esecuzione. Questo modello di trust è denominato modello di sicurezza Zero Trust. Un modello di sicurezza Zero Trust significa che nessun dispositivo o utente è considerato attendibile per impostazione predefinita, che si trovi 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 un insieme di macchine, tranne in circostanze specifiche, ad esempio quando utilizzi Google Cloud per eseguire il provisioning delle VM suinodi sole-tenant per Compute Engine.

Google Cloud e Google Workspace supportano i requisiti normativi relativi alla residenza dei dati. Per saperne di più sulla residenza dei dati e su Google Cloud, consulta Limitazione delle località delle risorse. Per saperne di più sulla residenza dei dati e su Google Workspace, vedi Regioni di dati: scegliere una posizione geografica per i propri dati.

Identità, integrità e isolamento dei servizi

Per attivare la comunicazione tra servizi, le applicazioni utilizzano l'autenticazione e l'autorizzazione crittografiche. L'autenticazione e l'autorizzazione forniscono un controllo dell'accesso efficace a un livello di astrazione e una granularità che amministratori e servizi possono comprendere.

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

Ogni servizio eseguito sull'infrastruttura ha un'identità dell'account di servizio associata. A un servizio vengono fornite credenziali crittografiche che può utilizzare per dimostrare la propria identità ad altri servizi quando effettua o riceve RPC. Queste identità vengono utilizzate nei criteri di sicurezza. I criteri di sicurezza garantiscono 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 sandboxing per proteggere un servizio da altri servizi in esecuzione sulla stessa macchina. Queste tecniche includono la separazione degli utenti Linux, le sandbox basate sul linguaggio (come l'API Sandboxed) e sul kernel, il kernel dell'applicazione per i container (come gVisor) e la virtualizzazione basata su hardware. In generale, utilizziamo più livelli di isolamento per i carichi di lavoro più rischiosi. I carichi di lavoro più rischiosi includono quelli che elaborano input non sanificati da internet. Ad esempio, i workload più rischiosi includono l'esecuzione di convertitori di file complessi su input non attendibili o l'esecuzione di codice arbitrario come servizio per prodotti come 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 per i tuoi workload e per proteggere i dati in uso, supportiamo i servizi di Confidential Computing per le istanze di macchine virtuali (VM) Compute Engine e i nodi Google Kubernetes Engine (GKE).

Gestione dell'accesso tra servizi

Il proprietario di un servizio può gestire l'accesso creando un elenco di altri servizi che possono comunicare con il servizio. Questa funzionalità di gestione dell'accesso è fornita dall'infrastruttura Google. Ad esempio, un servizio può limitare le RPC in entrata solo a un elenco consentito di altri servizi. Il proprietario può anche configurare il servizio con un elenco consentito di identità di servizio, che l'infrastruttura applica automaticamente. L'applicazione include la registrazione degli audit, le giustificazioni e la limitazione unilaterale dell'accesso (ad esempio per le richieste degli ingegneri).

Anche agli ingegneri di Google che hanno bisogno di accedere ai servizi vengono 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 workflow che include catene di approvazione, logging e notifiche. Ad esempio, le norme di sicurezza possono imporre l'autorizzazione da più parti. Questo sistema utilizza la regola delle due persone per garantire che un tecnico che agisce da solo non possa eseguire operazioni sensibili senza prima ottenere l'approvazione di un altro tecnico autorizzato. Questo sistema consente di scalare a migliaia di servizi in esecuzione sull'infrastruttura processi di gestione dell'accesso sicuri.

L'infrastruttura fornisce inoltre servizi con il servizio canonico per la gestione di utenti, gruppi e appartenenze, in modo che possano implementare un controllo dell'accesso personalizzato e granulare, se 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 workload

L'infrastruttura garantisce riservatezza e integrità per i dati RPC sulla rete. Tutto il traffico di Google Cloud rete virtuale è criptato. La comunicazione tra i carichi di lavoro dell'infrastruttura è crittografata, con esenzioni concesse solo per i carichi di lavoro ad alte prestazioni in cui il traffico non attraversa i più livelli di sicurezza fisica all'edge di un data center Google. Google Cloud La comunicazione tra i servizi di infrastruttura Google Cloud è protetta dall'integrità crittografica.

L'infrastruttura fornisce automaticamente ed efficientemente (con l'aiuto dell'offload hardware) la crittografia end-to-end per il traffico RPC dell'infrastruttura che passa attraverso la rete tra i data center.

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

Un tipico servizio Google Workspace è scritto per fare qualcosa 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 Google Contatti) è 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 può richiedere i contatti di qualsiasi utente in qualsiasi momento.

Quando Gmail effettua una richiesta RPC a Google Contatti 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 questo particolare utente finale. Il ticket consente a Google Contatti di implementare una protezione 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 contesto utente finale. Il servizio di identità verifica l'accesso dell'utente finale e poi invia una credenziale utente, come un cookie o un token OAuth, al dispositivo dell'utente. Ogni successiva richiesta dal dispositivo alla nostra infrastruttura deve presentare quella credenziale utente finale.

Quando un servizio riceve una credenziale utente finale, la passa al servizio di identità per la verifica. Se la credenziale utente finale viene verificata, il servizio di identità restituisce un ticket di contesto 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 utente finale è Gmail, che lo trasmette a Google Contatti. A questo punto, in caso di chiamate a cascata, il servizio chiamante può inviare il ticket di contesto utente finale al servizio chiamato nell'ambito della RPC.

Il seguente diagramma mostra come comunicano il servizio A e il servizio B. L'infrastruttura fornisce l'identità del servizio, l'autenticazione reciproca automatica, la comunicazione interservizio criptata e l'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 interservizio criptata, l'autenticazione reciproca automatica utilizza le identità del chiamante e del destinatario. La comunicazione è possibile solo quando una configurazione delle regole di accesso lo consente.

Diagramma che mostra come comunicano il servizio A e il servizio B.

Per informazioni sulla gestione dell'accesso in Google Cloud, consulta 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 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 in genere eseguita con agenti di servizio anziché con ticket di contesto 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 Google Cloud organizzazione. Le richieste ai servizi Google Cloud passano tramite IAM per verificare le autorizzazioni.

La procedura di gestione degli accessi è la seguente:

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

Per informazioni sulla gestione dell'accesso in Google Cloud, consulta Panoramica di IAM.

Archiviazione sicura dei dati

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

Crittografia dei dati inattivi

L'infrastruttura di Google fornisce vari servizi di archiviazione e file system distribuiti (ad esempio Spanner e Colossus), nonché un Key Management Service centralizzato. Le applicazioni di Google accedono all'archiviazione fisica utilizzando l'infrastruttura di archiviazione. Utilizziamo diversi livelli di crittografia per proteggere i dati inattivi. Per impostazione predefinita, l'infrastruttura di archiviazione cripta i dati utente prima che vengano scritti nell'archiviazione fisica.

L'infrastruttura esegue la crittografia a livello di applicazione o di infrastruttura di archiviazione. Le chiavi per questa crittografia sono gestite e di proprietà di Google. La crittografia consente all'infrastruttura di isolarsi da potenziali minacce ai livelli inferiori dello spazio di archiviazione, ad esempio firmware del disco dannoso. Ove applicabile, abilitiamo 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 ritirato possa lasciare fisicamente la nostra custodia, il dispositivo viene pulito utilizzando una procedura in più passaggi che include due verifiche indipendenti. I dispositivi che non superano questa procedura di pulizia vengono distrutti fisicamente (ovvero tritati) in loco.

Oltre alla crittografia eseguita dall'infrastruttura con chiavi di crittografia di proprietà di Google e gestite da Google, Google Cloud e Google Workspace fornisce servizi di gestione delle chiavi per le chiavi di cui puoi essere proprietario e che puoi gestire. Per Google Cloud, Cloud KMS è un servizio cloud che ti consente di creare le tue chiavi di crittografia, incluse quelle basate su hardware con certificazione FIPS 140-3 L3. Queste chiavi sono specifiche per te, non per il servizio Google Cloud , e puoi gestirle in base alle tue norme e procedure. Per Google Workspace, puoi utilizzare la crittografia lato client. Per saperne di più, vedi Crittografia lato client e collaborazione rafforzata in Google Workspace.

Eliminazione dei dati

L'eliminazione di dati o materiale crittografico in genere inizia con la marcatura di chiavi o dati specifici come pianificati per l'eliminazione. La procedura di contrassegno dei dati per l'eliminazione tiene conto dei criteri specifici del servizio e di quelli specifici del cliente.

Se pianifichi l'eliminazione dei dati o disattivi prima le chiavi, possiamo recuperare i dati eliminati involontariamente, indipendentemente dal fatto che l'eliminazione sia stata avviata dal cliente, sia dovuta a un bug o sia il risultato di un errore di processo interno.

Quando un utente finale elimina il proprio account, l'infrastruttura notifica ai 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 a un utente finale di controllare i propri dati.

Per saperne di più, consulta la sezione Eliminazione dei dati su Google Cloud. Per informazioni su come utilizzare Cloud Key Management Service per disattivare le tue chiavi, consulta Eliminare e ripristinare le versioni delle chiavi.

Comunicazione internet sicura

Questa sezione descrive come proteggiamo la comunicazione tra internet e i servizi eseguiti sull'infrastruttura di Google.

Come descritto in Progettazione e provenienza dell'hardware, l'infrastruttura è costituita da molte macchine fisiche interconnesse tramite LAN e WAN. La sicurezza della comunicazione tra i servizi non dipende dalla sicurezza della rete. Tuttavia, isoliamo la nostra infrastruttura da internet in uno spazio di indirizzi IP privati. Esporremo solo un sottoinsieme delle macchine direttamente al traffico internet esterno, in modo da poter implementare protezioni aggiuntive, come difese contro gli attacchi denial of service (DoS).

Servizio Google Front End (GFE)

Quando un servizio deve rendersi disponibile su internet, può registrarsi con un servizio di infrastruttura chiamato Google Front End (GFE). GFE garantisce che tutte le connessioni TLS vengano terminate con i certificati corretti e seguendo le best practice, ad esempio il supporto della segretezza perfetta. GFE applica anche protezioni contro gli attacchi DoS. Il 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 di reverse proxy intelligente. GFE fornisce l'hosting dell'indirizzo IP pubblico del suo nome DNS pubblico, la protezione DoS e la terminazione TLS. I GFE vengono eseguiti sull'infrastruttura come qualsiasi altro servizio e possono essere scalati in base ai volumi delle richieste in entrata.

Quando le VM dei clienti nelle reti VPC accedono alle API e ai servizi Google ospitati direttamente su Borg, le VM dei clienti comunicano con GFE specifiche chiamate Cloud Front Ends. Google Cloud Per ridurre al minimo la latenza, i front-end cloud si trovano nella stessa regione cloud della VM del cliente. Il routing di rete tra le VM del cliente e i front-end cloud non richiede che le VM del cliente abbiano indirizzi IP esterni. Quando l'accesso privato Google è abilitato, le VM dei clienti con solo indirizzi IP interni possono comunicare con gli indirizzi IP esterni per i servizi e le API di Google utilizzando Cloud Front Ends. Tutto il routing di rete tra le VM dei clienti, le API e i servizi Google dipende dagli hop successivi all'interno della rete di produzione di Google, anche per le VM dei clienti che hanno indirizzi IP esterni.

Protezione DoS

La scalabilità 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 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 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 bloccare o limitare il traffico associato all'attacco.

Le istanze GFE segnalano anche informazioni sulle richieste che ricevono al servizio DoS centrale, incluse 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 bloccare 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 Google. Il servizio richiede un nome utente e una password e può anche richiedere agli utenti informazioni aggiuntive in base ai fattori di rischio. Esempi di fattori di rischio includono l'accesso degli utenti dallo stesso dispositivo o da una località simile in passato. Dopo aver autenticato l'utente, il servizio di identità emette credenziali come cookie e token OAuth che possono essere utilizzati per chiamate successive.

Quando gli utenti accedono, possono utilizzare fattori secondari 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 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 ha adottato questo standard di autenticazione aperto.

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 del controllo del codice sorgente e alla procedura di revisione da parte di due persone 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 contribuiscono a eliminare le vulnerabilità XSS nelle app web. Utilizziamo anche strumenti automatizzati come fuzzing, strumenti di analisi statica e scanner di sicurezza web per rilevare automaticamente i bug di sicurezza.

Come controllo finale, utilizziamo revisioni di sicurezza manuali che vanno da rapide valutazioni per le funzionalità meno rischiose a revisioni approfondite della progettazione e dell'implementazione per le funzionalità più rischiose. Il team che esegue 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 fuzzers che possiamo utilizzare per i prodotti futuri.

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

Investiamo anche 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 che si dedica alla ricerca di vulnerabilità zero-day, tra cui Spectre e Meltdown. Inoltre, siamo il principale autore di CVE e correzioni di bug di sicurezza per l'hypervisor Linux KVM.

Protezioni del codice sorgente

Il nostro codice sorgente è archiviato in repository con integrità e governance del codice sorgente integrate, in cui è possibile controllare le versioni attuali e precedenti del servizio. L'infrastruttura richiede che i programmi binari di un servizio vengano creati da un codice sorgente specifico, dopo che è stato esaminato, archiviato e testato. L'autorizzazione binaria per Borg (BAB) è un controllo interno dell'applicazione forzata che viene eseguito durante il deployment di un servizio. BAB fa quanto segue:

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

Proteggere i dispositivi e le credenziali dei dipendenti

Implementiamo misure di salvaguardia per proteggere i dispositivi e le credenziali dei nostri dipendenti da compromissioni. 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 utilizzati dai nostri dipendenti per gestire la nostra infrastruttura. Ci assicuriamo che le immagini del sistema operativo di questi dispositivi siano aggiornate con le patch di sicurezza e controlliamo le applicazioni che i dipendenti possono installare sui loro dispositivi. Abbiamo anche sistemi che analizzano le applicazioni, i download, le estensioni del browser e i contenuti del browser web installati dagli utenti per determinare se sono adatti ai dispositivi aziendali.

La connessione alla LAN aziendale non è il nostro meccanismo principale per la concessione dei 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 utilizzano un dispositivo gestito e si connettono da reti e posizioni geografiche previste. Un dispositivo client è considerato attendibile in base a un certificato rilasciato alla singola macchina e in base ad asserzioni sulla sua configurazione (ad esempio software aggiornato). Per saperne di più, vedi BeyondCorp.

Riduzione dei rischi provenienti da personale interno

Il rischio interno è la possibilità che un dipendente, un collaboratore o un altro partner commerciale attuale o precedente che ha o aveva accesso autorizzato alla nostra rete, al nostro sistema o ai nostri dati abusi di questo accesso per minare la riservatezza, l'integrità o la disponibilità delle nostre informazioni o dei nostri sistemi informativi.

Per contribuire a ridurre il rischio 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 con privilegi per determinate attività utilizzando l'automazione, che può svolgere le stesse attività in modo sicuro e controllato. Esporiamo API limitate che consentono il debug senza esporre dati sensibili e richiediamo 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 di sicurezza monitora i modelli di accesso e indaga sugli eventi insoliti. Per ulteriori informazioni, vedi Accesso con privilegi in Google Cloud.

Utilizziamo l'autorizzazione binaria per Borg per proteggere la nostra supply chain dai rischi provenienti da personale interno. Inoltre, il nostro investimento in BeyondProd contribuisce a proteggere i dati utente nell'infrastruttura Google e a stabilire 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 o rispondere alle tue richieste di assistenza. Access Approval garantisce che assistenza clienti Google Cloud e il team di ingegneri richiedano la tua approvazione esplicita quando devono accedere ai tuoi dati. L'approvazione viene verificata crittograficamente per garantire l'integrità dell'approvazione dell'accesso.

Per ulteriori informazioni sulle protezioni dei servizi di produzione, consulta In che modo Google protegge i propri servizi di produzione.

Monitoraggio delle minacce

Il Threat Analysis Group di Google monitora i soggetti malintenzionati e l'evoluzione delle loro tattiche e tecniche. Gli obiettivi di questo gruppo sono contribuire a migliorare la sicurezza dei prodotti Google e condividere queste informazioni a vantaggio della community online.

Ad esempio 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 per Google Security Operations è un team di ricercatori di minacce che sviluppano Threat Intelligence da utilizzare con Google Security Operations. VirusTotal è una soluzione di visualizzazione e database di malware che puoi utilizzare per comprendere meglio il funzionamento del malware all'interno della tua azienda.

Per saperne di più sulle nostre attività di monitoraggio delle minacce, consulta il report Threat Horizons.

Rilevamento delle intrusioni

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

Passaggi successivi