Panoramica sulla progettazione della sicurezza dell'infrastruttura Google

Questi contenuti sono stati aggiornati l'ultima volta a giugno 2024 e rappresentano lo status quo come del tempo in cui è stato scritto. Le norme e i sistemi di sicurezza di Google potrebbero cambiare in futuro, grazie al costante miglioramento della protezione per i nostri clienti.

Introduzione

Questo documento fornisce una panoramica di come la sicurezza è integrata in Google dell'infrastruttura tecnica. È destinato ai responsabili della sicurezza, architetti e revisori.

In questo documento vengono descritte le seguenti informazioni:

  • 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 dell'utente finale
    • Comunicazione sicura tra i servizi
    • Comunicazione sicura e privata con i clienti su internet
    • Operatività sicura da parte dei tecnici di Google
  • Il modo in cui utilizziamo questa infrastruttura per creare servizi internet, tra cui ai consumatori quali Ricerca Google, Gmail e Google Foto e servizi aziendali come Google Workspace e in Google Cloud.
  • I prodotti e i servizi per la 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 modello di sicurezza Zero Trust.

  • Come è progettata la sicurezza dell’infrastruttura diversi strati. Questi livelli includono:

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

Infrastruttura sicura di basso livello

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

Sicurezza dei locali fisici

Progettiamo e costruiamo i nostri data center, che includono più livelli di sicurezza fisica. L'accesso a questi data center è controllato severamente. Usiamo più livelli di sicurezza fisica per proteggere i pavimenti dei nostri data center. Usiamo identificazione biometrica, rilevamento dei metalli, videocamere, barriere per veicoli e sistemi di rilevamento delle intrusioni basati su laser. Per ulteriori informazioni, vedi Sicurezza dei data center.

All'interno del data center, implementiamo ulteriori controlli per garantire l'accesso ai server è protetto e monitorato. Per ulteriori informazioni, vedi Come Google protegge lo spazio fisico-logico nei dati .

Ospitiamo anche alcuni server in data center di terze parti. In questi data center, sono conformi agli stessi standard normativi dei nostri data center. Me garantire l'implementazione di misure di sicurezza fisica controllate da Google Connettività controllata da Google in aggiunta ai livelli di sicurezza forniti dall'operatore del data center. Ad esempio, eseguiamo l'identificazione biometrica sistemi, videocamere e metal detector indipendenti dal livello forniti dall'operatore del data center.

Se non diversamente indicato, i controlli di sicurezza in questo documento si applicano sia a Data center di proprietà di Google e data center di terze parti.

Origine e progettazione hardware

I data center di Google sono costituiti da migliaia di server collegati a un in ogni rete. Noi progettiamo le schede server e le apparecchiature di rete. Esaminiamo le i fornitori di componenti con cui collaboriamo e scelgono i componenti con attenzione. Lavoriamo con i fornitori per controllare e convalidare le proprietà di sicurezza fornite tra i componenti. Progettiamo chip personalizzati, incluso 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 fungere da le radici di attendibilità hardware.

Stack di avvio protetto e identità delle macchine

I server di Google utilizzano varie tecnologie per garantire l'avvio e lo stack software. In ogni passaggio del processo di avvio, Google implementa controlli leader del settore che aiutano ad applicare lo stato di avvio previsto per contribuire a proteggere i dati dei clienti.

Ci impegniamo a migliorare continuamente i nostri server con ogni hardware e per renderli disponibili al resto del settore tramite il coinvolgimento nei processi relativi agli standard con Trusted Computing Group e DMTF.

Ogni server nel data center ha una propria identità univoca. Questa identità può essere legato alle radici di attendibilità hardware e al software stivali. Questa identità viene utilizzata per autenticare le chiamate API da e verso di basso livello e di gestione dei servizi sulla macchina. Questa identità viene utilizzata anche per server reciproci l'autenticazione e la crittografia del trasporto. Abbiamo sviluppato Application Layer Transport Security (ALTS) sistema per la protezione delle comunicazioni RPC (chiamata di procedura remota, RPC) all'interno del nostro dell'infrastruttura. Queste identità macchina possono essere revocate centralmente a causa di un incidente di sicurezza. Inoltre, i relativi certificati e chiavi vengono regolarmente ruotate e quelle precedenti revocate.

Abbiamo sviluppato sistemi automatici per:

  • Assicurati che i server eseguano versioni aggiornate degli stack software (incluse le patch di sicurezza).
  • Rilevare e diagnosticare problemi relativi all'hardware e al software.
  • Garantisci l'integrità delle macchine e delle periferiche con avvio verificato e attestazione.
  • Assicurati che solo le macchine che eseguono il software e il firmware previsti possano e credenziali di accesso che le permettono di comunicare sulla rete di produzione.
  • Rimuovere o riparare le macchine se non superano il controllo di integrità o quando non sono più necessari.

Per ulteriori informazioni su come proteggiamo lo stack di avvio e l'integrità delle macchine, consulta In che modo Google applica l'integrità in fase di avvio in produzione di Compute Engine e Attestazione remota disaggregate.

Deployment sicuro dei servizi

I servizi Google sono i file binari delle applicazioni che i nostri sviluppatori scrivono ed eseguono sulla nostra infrastruttura. Esempi di servizi Google sono Gmail server, database Spanner, server Cloud Storage, YouTube transcodificatori video e VM di Compute Engine che eseguono applicazioni del cliente. A la scalabilità richiesta del carico di lavoro, migliaia di macchine potrebbero che eseguono file binari dello stesso servizio. Un servizio di orchestrazione di cluster, chiamato Borg controlla i servizi in esecuzione direttamente sull'infrastruttura.

L'infrastruttura non presuppone alcuna attendibilità tra i servizi in esecuzione sull'infrastruttura. Questo modello di attendibilità è definito zero-trust di sicurezza del prodotto. Un modello di sicurezza Zero Trust prevede che nessun dispositivo o utente attendibili per impostazione predefinita, all'interno o all'esterno della rete.

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

Google Cloud e Google Workspace supportano i requisiti normativi sulla residenza dei dati. Per ulteriori informazioni sulla residenza dei dati per 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: scegli una posizione geografica per i tuoi dati.

Identità, integrità e isolamento dei servizi

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

I servizi non si basano sulla segmentazione della rete interna o sul firewall in quanto meccanismo di sicurezza principale. Filtro in entrata e in uscita in vari punti di la nostra rete aiuta a prevenire lo spoofing degli indirizzi 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 è associato un account di servizio. e identità di base. Un servizio viene fornito con credenziali crittografiche che può utilizzare per dimostrare la sua identità ad altri servizi durante l'elaborazione o la ricezione di RPC. Questi vengono utilizzate nei criteri di sicurezza. I criteri di sicurezza assicurano che comunicano con il server previsto e i server limitando i metodi e i dati a cui determinati clienti possono accedere.

Utilizziamo varie tecniche di isolamento e sandboxing per proteggere un servizio da altri servizi in esecuzione sulla stessa macchina. Queste tecniche includono Linux separazione degli utenti, in base alla lingua (ad esempio, API) e le sandbox basate su kernel, kernel dell'applicazione per i container (come gVisor) e virtualizzazione basata su hardware. In generale, utilizziamo più livelli per i carichi di lavoro più rischiosi. I carichi di lavoro più rischiosi includono carichi di lavoro per elaborare input non sottoposti a sanitizzazione da internet. Ad esempio, carichi di lavoro più rischiosi includono l'esecuzione di convertitori di file complessi su input non attendibili o l'esecuzione per prodotti come Compute Engine.

Per una maggiore sicurezza, servizi sensibili come l'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ù solido per i tuoi carichi di lavoro e per proteggere i dati in uso, supportiamo Servizi di Confidential Computing per le istanze di macchine virtuali (VM) Compute Engine dei nodi di Google Kubernetes Engine (GKE).

Gestione degli accessi tra i servizi

Il proprietario di un servizio può gestire l'accesso creando un elenco di altri servizi in grado di comunicare con il servizio. Questa funzionalità di gestione degli accessi forniti dall'infrastruttura di Google. Ad esempio, un servizio può limitare la gestione RPC esclusivamente a un elenco consentito di altri servizi. Il proprietario può anche configurare al servizio con un elenco di identità di servizio consentite, che l'infrastruttura viene applicata automaticamente. L'applicazione include audit logging, giustificazioni e limitazione dell'accesso unilaterale (ad esempio per richieste dei tecnici).

Anche gli ingegneri di Google che hanno bisogno di accedere ai servizi vengono rilasciati identities. I servizi possono essere configurati in modo da consentire o negare l'accesso in base a le loro identità. Tutte queste identità (macchina, servizio e dipendente) in uno spazio dei nomi globale gestito dall'infrastruttura.

Per gestire queste identità, l'infrastruttura fornisce un sistema di flussi di lavoro include catene di approvazione, logging e notifiche. Ad esempio, il livello può applicare l'autorizzazione di più parti. Questo sistema utilizza la funzionalità regola 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 a processi di gestione degli accessi sicuri di scalare fino a migliaia di servizi in esecuzione sull'infrastruttura.

L'infrastruttura fornisce anche servizi con il servizio canonico per gli utenti, dei gruppi e delle iscrizioni in modo da poter implementare e un controllo granulare degli accessi, ove necessario.

Le identità degli utenti finali vengono gestite separatamente, come descritto in Accedi alla gestione dei dati degli utenti finali in Google Workspace.

Crittografia delle comunicazioni tra carichi di lavoro

L'infrastruttura fornisce riservatezza e integrità per i dati RPC sul in ogni rete. Tutto il traffico delle reti virtuali di Google Cloud è criptato. Comunicazione tra i carichi di lavoro dell'infrastruttura Google Cloud criptato, con esenzioni concesse solo per i carichi di lavoro ad alte prestazioni in cui il traffico non supera i vari livelli di sicurezza fisica a livello perimetrale di un data center Google. Comunicazione tra i servizi dell'infrastruttura Google Cloud ha integrità crittografica protezione dei dati.

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

Gestione degli accessi ai dati degli utenti finali in Google Workspace

Un tipico servizio Google Workspace ha lo scopo di fare qualcosa per per l'utente finale. Ad esempio, un utente finale può archiviare le proprie email Gmail. L'interazione dell'utente finale con un'applicazione, ad esempio Gmail potrebbe abbracciare altri servizi all'interno dell'infrastruttura. Per esempio, Gmail potrebbe chiamare un'API People per accedere rubrica di un utente.

La Crittografia delle comunicazioni tra i servizi in che modo un servizio (ad esempio Contatti Google) è progettato per proteggere Richieste RPC da un altro servizio (ad esempio Gmail). Tuttavia, questo livello di controllo dell'accesso rappresenta ancora un ampio insieme di autorizzazioni. perché Gmail può richiedere i contatti di qualsiasi utente in qualunque nel tempo.

Quando Gmail effettua una richiesta RPC a Contatti Google per conto di utente finale, l'infrastruttura consente a Gmail di presentare ticket di autorizzazione nella richiesta RPC. Questo ticket dimostra che Gmail sta effettuando la richiesta RPC per conto di quel particolare scopo. utente. Il ticket consente a Contatti Google di implementare una protezione per restituisce solo i dati per l'utente finale indicato nel ticket.

L'infrastruttura fornisce un servizio di identità utente centrale che rilascia questi dati ticket di contesto per l'utente finale. Il servizio di identità verifica l'accesso dell'utente finale. e quindi invia una credenziale utente, come un cookie o un token OAuth, alla dal dispositivo dell'utente. Ogni richiesta successiva dal dispositivo alla nostra infrastruttura Deve presentare la credenziale dell'utente finale.

Quando un servizio riceve la credenziale di un utente finale, passa la credenziale al servizio di identità per la verifica. Se la credenziale dell'utente finale viene verificato, il servizio di identità restituisce un contesto di breve durata dell'utente ticket che può essere utilizzato per le RPC relative alla richiesta dell'utente. Nel nostro esempio, il servizio che riceve il ticket contestuale dell'utente finale è Gmail, che passa il ticket ai Contatti Google. Da quel momento in poi, per qualsiasi a cascata, il servizio di chiamata può inviare il ticket contestuale dell'utente finale del chiamante come parte della RPC.

Il seguente diagramma mostra come comunicano il servizio A e il servizio B. La che fornisce l'identità dei servizi, l'autenticazione reciproca automatica comunicazione criptata tra i servizi e applicazione dei criteri di accesso definite dal proprietario del servizio. Ogni servizio ha una configurazione del servizio, creato dal proprietario del servizio. Per le comunicazioni crittografate tra i servizi, l'autenticazione reciproca automatica utilizza identità di chiamante e destinatario. Comunicazione è possibile solo se 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 Panoramica IAM.

Gestione degli accessi ai dati degli utenti finali in Google Cloud

Simile a Accedi alla gestione dei dati degli utenti finali in Google Workspace, l'infrastruttura fornisce un servizio di identità utente centrale che autentica account di servizio e problemi di ticket contestuali per l'utente finale dopo che un account di servizio autenticati. La gestione degli accessi tra i servizi Google Cloud che di solito viene fatto agenti di servizio anziché usare 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 dell'organizzazione Google Cloud. Le richieste ai servizi Google Cloud vengono inviate tramite IAM per verificare le autorizzazioni.

Il processo di gestione degli accessi è il seguente:

  1. Una richiesta arriva tramite Servizio Google Front End o il servizio Cloud Front End per le VM dei clienti.
  2. La richiesta viene instradata al servizio di identità dell'utente centrale completa il controllo dell'autenticazione e invia i ticket di contesto dell'utente finale.
  3. La richiesta viene anche indirizzata alla verifica di elementi come i seguenti:
  4. Una volta superati tutti questi controlli, i servizi di backend di Google Cloud vengono chiamato.

Per informazioni sulla gestione degli accessi in Google Cloud, consulta Panoramica IAM.

Archiviazione sicura dei dati

Questa sezione descrive come implementiamo la sicurezza dei dati memorizzati sul dell'infrastruttura.

Crittografia dei dati inattivi

L'infrastruttura di Google offre vari servizi di archiviazione (ad esempio, Spanner e Colossus) e un Key Management Service centralizzato. Applicazioni di Google accedono allo spazio di archiviazione fisico tramite l'infrastruttura di archiviazione. Usiamo diversi livelli di crittografia per proteggere i dati inattivi. Per impostazione predefinita, crittografa i dati utente prima che vengano scritti su carta archiviazione.

L'infrastruttura esegue la crittografia a livello di applicazione a livello di infrastruttura. Le chiavi per questa crittografia sono gestite e di proprietà di in tutti i canali Google. La crittografia consente all’infrastruttura di isolarsi da potenziali minacce ai livelli inferiori di archiviazione, ad esempio un firmware del disco dannoso. Dove applicabile, abilitiamo inoltre il supporto della crittografia hardware nei nostri dischi rigidi e SSD e monitoriamo meticolosamente ciascuna unità durante il suo ciclo di vita. Prima di un dispositivo di archiviazione criptato dismesso può lasciare fisicamente in custodia, dispositivo viene ripulito utilizzando un processo in più fasi che include due verifiche. I dispositivi che non superano questo processo di pulizia vengono fisicamente distrutti (ovvero distrutti) on-premise.

Oltre alla crittografia eseguita dall'infrastruttura con Chiavi gestite da Google, Google Cloud Google Workspace offre servizi di gestione delle chiavi che puoi proprietario e gestore. Per Google Cloud, Cloud KMS è un servizio cloud che consente di creare chiavi di crittografia, incluse chiavi certificate FIPS 140-3 L3 basate su hardware. Queste chiavi sono specifiche a te, non al servizio Google Cloud, e potrai gestire in base ai tuoi criteri e alle tue procedure. Per Google Workspace, puoi usare la crittografia lato client. Per ulteriori informazioni le informazioni, vedi Crittografia lato client e collaborazione rafforzata in Google Workspace.

Eliminazione dei dati

L'eliminazione del materiale o dei dati crittografici inizia in genere con il contrassegno chiavi o dati specifici pianificati per l'eliminazione. La procedura per contrassegnare i dati per l'eliminazione prende in considerazione le norme specifiche del servizio e norme specifiche.

Pianificando l'eliminazione dei dati o disattivando prima le chiavi, possiamo ripristinare da eliminazioni non intenzionali, indipendentemente dal fatto che siano avviate dal cliente, a causa di un bug o essere il risultato di un errore interno del processo.

Quando un utente finale elimina il proprio account, l'infrastruttura invia una notifica ai servizi che gestiscono i dati dell'utente finale che l'account è stato eliminato. La possono quindi pianificare i dati associati all'utente finale eliminato per l'eliminazione. Questa funzione consente all'utente finale di controllare e i dati di Google Cloud.

Per ulteriori informazioni, consulta la sezione Eliminazione dei dati Google Cloud. Per informazioni su come utilizzare Cloud Key Management Service per disabilitare le tue chiavi, consulta Eliminare e ripristinare le tue chiavi le versioni della chiave.

Comunicazione sicura su internet

Questa sezione descrive il modo in cui proteggiamo le comunicazioni tra internet e il in esecuzione sull'infrastruttura di Google.

Come discusso in Origine e progettazione hardware, L'infrastruttura è costituita da molte macchine fisiche interconnesse tramite LAN e WAN. La sicurezza delle comunicazioni tra i servizi dipende dalla sicurezza della rete. Tuttavia, isoliamo la nostra infrastruttura da internet a uno spazio di indirizzi IP privato. Esponiamo solo un sottoinsieme le macchine direttamente al traffico internet esterno, in modo che possiamo protezioni aggiuntive quali difese contro gli attacchi DoS (Denial of Service) attacchi informatici.

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 assicura che tutte le connessioni TLS vengano terminate con i certificati corretti e seguendo best practice come il supporto della Perfect Forward Secrecy. GFE e applica protezioni contro gli attacchi DoS. Il GFE inoltra quindi le richieste il servizio mediante il protocollo di sicurezza RPC discusso in Accedi alla gestione dei dati degli utenti finali in Google Workspace.

In effetti, qualsiasi servizio interno che deve essere pubblicato esternamente utilizza il GFE. come frontend proxy inversa intelligente. GFE fornisce l'hosting di indirizzi IP pubblici nome DNS pubblico, protezione DoS e terminazione TLS. I GFE vengono eseguiti dell'infrastruttura come qualsiasi altro servizio e può scalare per adeguarsi alle richieste in entrata come i bilanciatori del carico e i volumi di archiviazione.

Quando le VM dei clienti nelle reti VPC di Google Cloud accedono alle API e ai servizi Google ospitate direttamente su Borg, le VM dei clienti comunicano GFE denominati Cloud Front End. Per ridurre al minimo la latenza, Cloud Front End si trovano all'interno della stessa regione cloud della VM del cliente. Routing di rete tra le VM del cliente e Cloud Front End non richiede che le VM del cliente che hanno un indirizzo IP esterno. Quando L'accesso privato Google è abilitato, Le VM con solo indirizzi IP interni possono comunicare con l'IP esterno indirizzi IP per le API e i servizi Google utilizzando Cloud Front End. Tutta la rete il routing tra le VM del cliente, le API di Google e i servizi dipende dagli hop successivi nella rete di produzione di Google, anche per le VM dei clienti che dispongono di e gli indirizzi IP esterni.

Protezione DoS

La portata della nostra infrastruttura le consente di assorbire molti attacchi DoS. A ridurre ulteriormente il rischio di impatto DoS sui servizi, abbiamo sistemi multilivello, delle protezioni DoS a più livelli.

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

Le istanze GFE segnalano anche informazioni sulle richieste ricezione 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 bloccare o limitare il traffico degli attacchi.

Autenticazione degli utenti

Dopo la protezione DoS, il livello successivo di difesa per la comunicazione sicura arriva 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ò richiede inoltre agli utenti informazioni aggiuntive in base ai fattori di rischio. Esempio i fattori di rischio includono se gli utenti hanno eseguito l'accesso dallo stesso dispositivo o da una località simile in passato. Dopo l'autenticazione dell'utente, l'identità emette credenziali come cookie e token OAuth che possono essere utilizzati per chiamate successive.

Quando gli utenti accedono, possono usare secondi fattori, come OTP o i token di sicurezza resistenti al phishing, come Token di sicurezza Titan. Il token di sicurezza Titan è un token fisico che supporta FIDO U2F (Universal 2nd Factor). Abbiamo contribuito a sviluppare lo standard aperto U2F con la FIDO Alliance. La maggior parte del web piattaforme e browser hanno adottato questo standard di autenticazione aperto.

Sicurezza operativa

Questa sezione descrive il modo in cui sviluppiamo il software dell'infrastruttura, proteggiamo le nostre dei dipendenti macchine e credenziali e difenderti dalle minacce al dell'infrastruttura da parte di utenti malintenzionati interni ed esterni.

Sviluppo sicuro di software

Inoltre Le protezioni del controllo del codice sorgente e la procedura di revisione tra due parti. descritte in precedenza, utilizziamo librerie che impediscono agli sviluppatori di introdurre alcune classi di bug di sicurezza. Ad esempio, abbiamo librerie e framework che aiutano a eliminare le vulnerabilità XSS nelle app web. Usiamo anche strumenti automatizzati come fuzzer, strumenti di analisi statici e scanner di sicurezza web per rilevare automaticamente i bug di sicurezza.

Come controllo finale, utilizziamo controlli di sicurezza manuali che variano da una valutazione rapida per le funzionalità meno rischiose, alle revisioni approfondite della progettazione e dell'implementazione per le funzionalità più rischiose. Il team che si occupa delle revisioni include esperti su sicurezza web, crittografia e sicurezza del sistema operativo. Le recensioni può portare allo sviluppo di nuove funzionalità della libreria di sicurezza e di nuovi utilizzabili per i prodotti futuri.

Inoltre, viene eseguito un Vulnerability Rewards Program che premia chiunque scopra e ci informi di bug nella nostra infrastruttura. o applicazioni. Per ulteriori informazioni su questo programma, inclusi i premi che abbiamo dato, vedi Statistiche chiave per cacciare di bug.

Investiamo anche nella ricerca di exploit zero-day e altri problemi di sicurezza nel software open source che utilizziamo. Eseguiamo Project Zero, un team di ricercatori Google dedicato alla ricerca zero-day le vulnerabilità, tra cui Spectre e Meltdown. Inoltre, siamo il principale autore di CVE e correzioni di bug di sicurezza per Hypervisor KVM Linux.

Protezioni del codice sorgente

Il nostro codice sorgente è archiviato in repository con integrità del codice sorgente integrata e la governance, in cui è possibile controllare sia la versione attuale che quella precedente del servizio. L'infrastruttura richiede che i file binari di un servizio vengano creati da codice sorgente, dopo essere stato esaminato, archiviato e testato. Autorizzazione binaria per Borg (BAB) è un controllo interno di applicazione delle norme che si verifica quando viene eseguito il deployment di un servizio. BAB svolge le seguenti operazioni:

  • Assicura che il software di produzione e la configurazione di cui viene eseguito il deployment di Google viene esaminato e autorizzato, in particolare quando il codice può accedere ai dati utente.
  • Garantisce che i deployment di codice e configurazione soddisfino determinati requisiti minimi standard.
  • Limita la capacità di un addetto ai lavori o di un avversario di commettere modifiche al codice sorgente e fornisce anche una traccia forense da all'origine.

Proteggere le credenziali e i dispositivi dei dipendenti

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

Monitoriamo i dispositivi client che i nostri dipendenti utilizzano per gestire le nostre dell'infrastruttura. Ci assicuriamo che le immagini del sistema operativo per questi dispositivi siano aggiornato con le patch di sicurezza e noi controlliamo le applicazioni installabili sui propri dispositivi. Abbiamo anche sistemi che analizzano applicazioni, download, estensioni del browser e contenuti del browser web per per determinare se sono adatti ai dispositivi aziendali.

Il collegamento alla LAN aziendale non è il nostro meccanismo principale per concedere privilegi di accesso. Utilizziamo invece la sicurezza Zero Trust per proteggere i dipendenti l'accesso alle nostre risorse. Controlli di gestione degli accessi a livello di applicazione di esporre le applicazioni interne ai dipendenti solo quando utilizzano una dispositivo e si connettono da reti e località geografiche previste. R dispositivo client viene considerato attendibile in base a un certificato emesso per il privato macchina e sulla base di asserzioni relative alla sua configurazione (come i dati software). Per ulteriori informazioni, vedi BeyondCorp.

Riduzione dei rischi provenienti da personale interno

Il rischio interno è il potenziale di un dipendente attuale o ex dipendente, di un lavoratore a contratto o altro partner commerciale che ha o aveva autorizzato l'accesso alla nostra rete, al nostro o dati di fare un uso improprio di tale accesso e comprometterne la riservatezza, l'integrità o disponibilità delle nostre informazioni o dei nostri sistemi informativi.

Per contribuire a ridurre i rischi provenienti da personale interno, limitiamo e monitoriamo attivamente le attività dipendenti a cui è stato concesso l'accesso amministrativo all'infrastruttura. Me lavorare costantemente per eliminare la necessità di accessi privilegiati per particolari le attività utilizzando l'automazione in grado di svolgere le stesse attività in un ambiente in modo controllato. Esponiamo API limitate che consentono il debug senza esporre 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 attraverso hook dell'infrastruttura. Il nostro team di sicurezza monitora i pattern di accesso indaga su eventi insoliti. Per ulteriori informazioni, vedi Gestione degli accessi con privilegi in Google Cloud (PDF).

Me Usare autorizzazione binaria per Borg per proteggere la nostra catena di fornitura dai rischi provenienti da personale interno. Inoltre, il nostro investimento nel BeyondProd contribuisce a proteggere i dati degli utenti nell'infrastruttura di Google e a instaurare un rapporto di fiducia nei nostri i servizi di machine learning.

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 motivi aziendali validi, ad esempio per risolvere un'interruzione o partecipare alle tue richieste di assistenza. Access Approval garantisce che l'assistenza clienti e i tecnici Google Cloud richiedano la tua approvazione esplicita quando devono accedere ai tuoi dati. L'approvazione è basata su crittografia verificati per garantire l'integrità dell'approvazione di accesso.

Per ulteriori informazioni sulle protezioni del servizio di produzione, consulta In che modo Google ne protegge la produzione Google Cloud.

Monitoraggio delle minacce

La Gruppo di analisi delle minacce 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 e la protezione dei prodotti Google e condividiamo questa intelligenza a vantaggio dei clienti online community.

Per Google Cloud, puoi utilizzare Google Cloud Threat Intelligence per le operazioni di sicurezza di Google e VirusTotal per monitorare e rispondere a molti tipi di malware. Minaccia Google Cloud Intelligence for Google Security Operations è un team di ricercatori che sviluppano minacce le informazioni sulle minacce da usare Google Security Operations. VirusTotal è una soluzione di database e visualizzazione del malware che puoi usare per a capire meglio come funziona il malware all'interno della tua azienda.

Per ulteriori informazioni sulle nostre attività di monitoraggio delle minacce, consulta Report Orizzonti di minaccia.

Rilevamento delle intrusioni

Utilizziamo pipeline di elaborazione dati sofisticate per integrare indicatori basati su host su singoli dispositivi, segnali basati sulla rete da vari punti di monitoraggio dell'infrastruttura e indicatori dai servizi di infrastruttura. Regole e macchina l'intelligence basata su queste pipeline offre agli ingegneri della sicurezza operativa e avvisi di possibili incidenti. I nostri team investigativi e di risposta agli incidenti valutare, analizzare e rispondere a questi potenziali incidenti 24 ore al giorno, 365 giorni l'anno. Conduciamo Squadra rossa esercizi per misurare e migliorare l'efficacia dei nostri sistemi di rilevamento e risposta i meccanismi della ricerca di informazioni.

Passaggi successivi