Panoramica sulla progettazione della sicurezza dell'infrastruttura Google

Mantieni tutto organizzato con le raccolte Salva e classifica i contenuti in base alle tue preferenze.

Questi contenuti sono stati aggiornati l'ultima volta a marzo 2022 e rappresentano lo status quo del momento in cui sono stati scritti. I criteri e i sistemi di sicurezza di Google possono cambiare in futuro, grazie al costante miglioramento della protezione per i nostri clienti.

Introduzione

Questo documento fornisce una panoramica sulla progettazione della sicurezza nell'infrastruttura tecnica di Google. È rivolto a dirigenti, architetti e controllori di sicurezza.

Questo documento descrive quanto segue:

  • l'infrastruttura tecnica globale di Google, progettata per garantire sicurezza durante l'intero ciclo di vita di elaborazione delle informazioni in Google. Questa infrastruttura consente di fornire quanto segue:
    • Deployment sicuro dei servizi
    • Archiviazione sicura dei dati con misure di salvaguardia della privacy degli utenti finali
    • Comunicazione sicura tra i servizi
    • Comunicazione sicura e privata con i clienti su Internet
    • Operazione sicura da parte degli ingegneri di Google
  • Come usiamo questa infrastruttura per creare servizi Internet, inclusi i servizi consumer come Ricerca Google, Gmail e Google Foto, nonché i servizi aziendali come Google Workspace e Google Cloud.
  • Il nostro investimento nella protezione della nostra infrastruttura e delle nostre operazioni. Abbiamo molti ingegneri che si dedicano alla sicurezza e alla privacy su Google, tra cui molti riconosciuti dalle autorità del settore.
  • I prodotti e servizi di sicurezza che sono il risultato delle innovazioni che abbiamo implementato internamente per soddisfare le nostre esigenze di sicurezza. Ad esempio, BeyondCorp è il risultato diretto dell'implementazione interna del modello di sicurezza Zero Trust.
  • La progettazione della sicurezza dell'infrastruttura su più livelli. Questi livelli includono:

Le sezioni rimanenti del documento descrivono i livelli di sicurezza.

Proteggere l'infrastruttura di basso livello

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

Sicurezza delle sedi fisiche

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

Inoltre, ospitiamo alcuni server in data center di terze parti. In questi data center, ci assicuriamo che ci siano misure di sicurezza fisica controllate da Google oltre ai livelli di sicurezza forniti dall'operatore del data center. Ad esempio, utilizziamo sistemi di identificazione biometrica, videocamere e rilevatori di metalli indipendenti dai livelli di sicurezza forniti dall'operatore del data center.

Origine e progettazione hardware

Un data center di Google è composto da migliaia di server connessi a una rete locale. Progettiamo le bacheche dei server e le apparecchiature di networking. Controlliamo i fornitori di componenti e scegliiamo con cura i componenti. 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 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 servono come radice di attendibilità hardware.

Stack di avvio protetto e identità della macchina

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

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

Ogni server nel data center ha la propria identità univoca. Questa identità può essere associata alla radice di attendibilità hardware e al software con cui viene avviata la macchina. Questa identità viene utilizzata per autenticare le chiamate API da e verso i servizi di gestione di basso livello sulla macchina. Questa identità viene utilizzata anche per l'autenticazione reciproca del server e la crittografia dei trasporti. 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à delle macchine possono essere revocate centralmente per rispondere a un incidente di sicurezza. Inoltre, i relativi certificati e chiavi vengono ruotati regolarmente e i vecchi vengono revocati.

Abbiamo sviluppato sistemi automatici per eseguire le seguenti operazioni:

  • Assicurati che i server eseguano versioni aggiornate dei loro stack software (incluse le patch di sicurezza).
  • Rilevare e diagnosticare problemi hardware e software.
  • Assicurati 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 a credenziali che consentano la comunicazione sulla rete di produzione.
  • Rimuovi o alloca le macchine dal servizio quando non sono più necessarie.

Deployment dei servizi sicuro

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

L'infrastruttura non assume alcuna responsabilità tra i servizi in esecuzione nell'infrastruttura. Questo modello di attendibilità è denominato modello di sicurezza Zero Trust. Un modello di sicurezza Zero Trust indica che per impostazione predefinita nessun dispositivo o utente è attendibile, all'interno o all'esterno della rete.

Poiché l'infrastruttura è progettata per essere multi-tenant, i dati dei nostri clienti (consumatori, aziende e persino dei nostri dati) sono distribuiti nell'infrastruttura condivisa. Questa infrastruttura è composta da decine di migliaia di macchine omogenee. L'infrastruttura non separa i dati dei clienti su un'unica macchina o un solo insieme 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 in materia di residenza dei dati. Per ulteriori informazioni sulla residenza dei dati e su Google Cloud, consulta i requisiti per la residenza e la sovranità dei dati. Per scoprire di più sulla residenza dei dati e su Google Workspace, vedi Aree geografiche dati: scegliere una posizione geografica per i tuoi dati.

Identità del servizio, integrità e isolamento

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

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

A ogni servizio eseguito nell'infrastruttura è associata un'identità dell'account di servizio. Un servizio viene fornito con credenziali crittografiche che può utilizzare per dimostrare la sua identità ad altri servizi quando effettua o riceve RPC. Queste identità vengono utilizzate nei criteri di sicurezza. I criteri di sicurezza consentono ai client di comunicare con il server previsto e di limitare i metodi e i dati a cui possono accedere determinati client.

Utilizziamo varie tecniche di isolamento e sandbox per proteggere un servizio da altri servizi in esecuzione sulla stessa macchina. Queste tecniche includono la separazione degli utenti Linux, la sandbox basata sul linguaggio (come l'API sandbox) e quella basata su kernel, il kernel dell'applicazione per i container (come gVisor) e la virtualizzazione hardware. In generale, utilizziamo più livelli di isolamento per i carichi di lavoro più rischiosi. I carichi di lavoro più rischiosi includono elementi forniti dall'utente che richiedono un'elaborazione aggiuntiva. Ad esempio, i carichi di lavoro più rischiosi includono l'esecuzione di convertitori di file complessi su dati forniti dagli utenti o l'esecuzione di codice fornito dagli utenti 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 per i tuoi 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 dell'accesso tra servizi

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

Gli ingegneri di Google che hanno bisogno dell'accesso ai servizi ricevono anche identità individuali. I servizi possono essere configurati per consentire o negare l'accesso in base alla loro identità. Tutte queste identità (computer, servizio e dipendente) si trovano in uno spazio dei nomi globale gestito dall'infrastruttura.

Per gestire queste identità, l'infrastruttura offre un sistema di flusso di lavoro che include catene di approvazione, logging e notifica. Ad esempio, il criterio di sicurezza può applicare l'autorizzazione di più parti. Questo sistema utilizza la regola in 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 ai processi di gestione dell'accesso sicuri di scalare fino a migliaia di servizi in esecuzione nell'infrastruttura.

L'infrastruttura inoltre fornisce servizi con il servizio canonico per la gestione di utenti, gruppi e membri, in modo da poter implementare un controllo degli accessi personalizzato e dettagliato, se necessario.

Le identità degli utenti finali vengono gestite separatamente, come descritto in Gestire i 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 di rete virtuale di Google Cloud è criptato. Tutte le comunicazioni tra i servizi di infrastruttura sono autenticate e la maggior parte delle comunicazioni tra servizi è criptata, il che aggiunge un ulteriore livello di sicurezza per proteggere la comunicazione anche se la rete viene toccata o se un dispositivo di rete viene compromesso. Eccezioni al requisito di crittografia per le comunicazioni tra servizi sono concesse solo per il traffico con requisiti di latenza bassi e che non lascia un unico tessuto di rete all'interno dei più livelli della sicurezza fisica nel nostro data center.

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

Accedere ai dati degli utenti finali in Google Workspace

Un servizio Google Workspace tipico è scritto per eseguire operazioni per un utente finale. Ad esempio, un utente finale può archiviare le sue email su Gmail. L'interazione dell'utente finale con un'applicazione come Gmail potrebbe includere altri servizi all'interno dell'infrastruttura. Ad esempio, Gmail potrebbe chiamare un'API People per accedere alla rubrica di utenti finali.

La sezione Crittografia delle comunicazioni tra servizi descrive il modo in cui un servizio (ad esempio Contatti Google) protegge le richieste RPC da un altro servizio (ad esempio Gmail). Tuttavia, questo livello di controllo dell'accesso è comunque un'ampia gamma di autorizzazioni perché Gmail è in grado di richiedere i contatti di qualsiasi utente in qualsiasi momento.

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

L'infrastruttura offre un servizio di identità utente centrale che emette questi ticket di autorizzazione dell'utente finale. Il servizio di identità verifica l'accesso dell'utente finale e invia le credenziali di un utente, ad esempio un cookie o un token OAuth, al dispositivo dell'utente. Ogni richiesta successiva inviata dal dispositivo alla nostra infrastruttura deve presentare la credenziale utente finale.

Quando riceve una credenziale utente finale, un servizio passa la credenziale al servizio di identità per la verifica. Se la credenziale dell'utente finale è verificata, il servizio di identità restituisce un ticket di autorizzazione dell'utente finale di breve durata utilizzabile per le RPC relative alla richiesta dell'utente. Nel nostro esempio, il servizio che riceve il biglietto con autorizzazione dell'utente finale è Gmail, che passa il biglietto ai Contatti Google. Da quel momento in poi, per tutte le chiamate a cascata, il servizio chiamante può inviare il ticket di autorizzazione dell'utente finale al destinatario come parte dell'RPC.

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

Diagramma che mostra come comunicano i servizi A e B.

Per informazioni sulla gestione dell'accesso in Google Cloud, consulta la panoramica IAM.

Archiviazione sicura dei dati

Questa sezione descrive il modo in 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, e un servizio centrale di gestione delle chiavi. Le applicazioni di Google accedono allo spazio di archiviazione fisico utilizzando l'infrastruttura di archiviazione. Utilizziamo diversi livelli di crittografia per proteggere i dati inattivi. Per impostazione predefinita, l'infrastruttura di archiviazione cripta tutti i dati utente prima che siano scritti nello spazio di archiviazione fisico.

L'infrastruttura esegue la crittografia al livello dell'infrastruttura dell'applicazione o dell'archiviazione. La crittografia consente all'infrastruttura di isolarsi dalle potenziali minacce ai livelli inferiori dello spazio di archiviazione, ad esempio il firmware dei dischi dannosi. Ove applicabile, abilitiamo il supporto della crittografia hardware nei nostri dischi rigidi e SSD e monitoriamo meticolosamente ogni unità durante il suo ciclo di vita. Prima che un dispositivo di archiviazione criptato disattivato venga ritirato fisicamente, il dispositivo viene pulito seguendo una procedura in più passaggi che include due verifiche indipendenti. I dispositivi che non superano questo processo di pulizia vengono fisicamente distrutti (ovvero distrutti) on-premise.

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

Eliminazione dei dati

Generalmente l'eliminazione dei dati inizia contrassegnando dati specifici come pianificati per l'eliminazione, anziché eliminare i dati. Questo approccio ci permette di recuperare in seguito a eliminazioni accidentali, a prescindere dall'avvio del cliente, dovuto a un bug o al risultato di un errore interno al processo. Una volta contrassegnati come pianificati per l'eliminazione, i dati vengono eliminati in base ai criteri specifici per il servizio.

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

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

Comunicazione sicura Internet

In questa sezione viene descritta la nostra modalità di protezione delle comunicazioni tra Internet e i servizi in esecuzione sull'infrastruttura Google.

Come spiegato in Progettazione e provenienza dell'hardware, l'infrastruttura è composta da molte macchine fisiche interconnesse tramite LAN e WAN. La sicurezza delle comunicazioni tra servizi non dipende dalla sicurezza della rete, Isolamo la nostra infrastruttura da Internet in uno spazio di indirizzi IP privati. Esponiamo un sottoinsieme di macchine direttamente al traffico Internet esterno in modo da poter implementare protezioni aggiuntive come gli attacchi di tipo denial of service (DoS).

Servizio di Google Front End

Quando un servizio deve rendersi disponibile su Internet, può registrarsi con un servizio di infrastruttura chiamato Google Front End (GFE). Il GFE garantisce che tutte le connessioni TLS vengano terminate con certificati corretti e seguendo le best practice come il supporto della perfetta Secret forward. Il GFE applica anche protezioni contro gli attacchi DoS. Il GFE quindi inoltra le richieste per il servizio utilizzando il protocollo di sicurezza RPC descritto in Accedere alla gestione dei dati degli utenti finali in Google Workspace.

In effetti, qualsiasi servizio interno che deve pubblicare autonomamente utilizza GFE come frontend proxy intelligente. Il GFE fornisce l'hosting di indirizzi IP pubblici del suo nome DNS pubblico, la protezione DoS e la terminazione TLS. I GFE vengono eseguiti nell'infrastruttura come qualsiasi altro servizio e possono essere scalati in base ai volumi delle 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 networking di Compute Engine. Cloud Front End consente alle VM dei clienti di accedere direttamente a un servizio Google utilizzando il loro indirizzo IP pubblico o privato. Gli indirizzi IP privati sono disponibili soltanto quando l'accesso privato Google è abilitato.

Protezione DoS

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

Quando la nostra rete 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 le informazioni sul traffico in entrata verso un servizio DoS centrale in esecuzione nell'infrastruttura. Quando rileva un attacco DoS, il servizio DoS centrale può configurare i bilanciatori del carico per bloccare o limitare il traffico associato all'attacco.

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

Autenticazione degli utenti

Dopo la protezione DoS, il livello successivo di difesa per una 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 nome utente e password e può anche chiedere agli utenti di ottenere ulteriori informazioni in base a fattori di rischio. I fattori di rischio di esempio includono se gli utenti hanno eseguito l'accesso dallo stesso dispositivo o da una località simile in passato. Dopo l'autenticazione dell'utente, il servizio di identità emette credenziali come cookie e token OAuth che possono essere utilizzati per le chiamate successive.

Quando gli utenti accedono, possono utilizzare secondi fattori come OTP o token di sicurezza resistenti al phishing come il token di sicurezza Titan. Il token di sicurezza Titan è un token fisico che supporta il fattore universale FIDO (U2F) FIDO. Abbiamo aiutato a sviluppare lo standard aperto U2F con FIDO Alliance. La maggior parte delle piattaforme web e dei browser ha adottato questo standard di autenticazione aperto.

Sicurezza operativa

In questa sezione viene descritto il modo in cui sviluppiamo il software dell'infrastruttura, proteggiamo i nostri dipendenti, le nostre macchine e le nostre credenziali e difendiamo le minacce all'infrastruttura da utenti interni e utenti esterni.

Sviluppo software sicuro

Oltre alle protezioni del controllo del codice sorgente e alla procedura di revisione di 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. Utilizziamo inoltre strumenti automatizzati come fuzzer, strumenti di analisi statici e scanner di sicurezza web per rilevare automaticamente i bug di sicurezza.

Come controllo finale, utilizziamo revisioni manuali sulla sicurezza che vanno da brevi valutazioni per le funzionalità meno rischiose a revisioni approfondite e di implementazione per le funzionalità più rischiose. Il team che conduce queste revisioni comprende esperti della sicurezza web, della crittografia e della sicurezza del sistema operativo. Le revisioni possono portare allo sviluppo di nuove funzionalità della libreria di sicurezza e di nuovi fuzzer che potremmo utilizzare per prodotti futuri.

Eseguiamo inoltre un Vulnerability Reward Program che premia chiunque rilevi e ci informi dei bug nella nostra infrastruttura o nelle nostre applicazioni. Per ulteriori informazioni sul programma, inclusi i premi che abbiamo ricevuto, consulta le statistiche principali sui cacciatori di bug.

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

Protezioni codice sorgente

Il nostro codice sorgente è archiviato in repository con governance e integrità delle origini integrate, in cui è possibile controllare sia la versione corrente che quella precedente del servizio. L'infrastruttura richiede che i programmi binari di un servizio siano creati a partire da un codice sorgente specifico, dopo l'esame, il controllo e il test. Autorizzazione binaria per Borg (BAB) è un controllo interno dell'applicazione che viene eseguito quando viene eseguito il deployment di un servizio. BAB comporta 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 tale codice può accedere ai dati utente.
  • Garantisce che i deployment del codice e della configurazione soddisfino determinati standard minimi.
  • Limita la capacità di un utente interno o avversario di apportare modifiche dannose al codice sorgente e fornisce anche una traccia forense da un servizio per tornare alla sua origine.

Protezione delle credenziali e dei dispositivi dei dipendenti

Implementiamo misure di salvaguardia per proteggere i nostri dipendenti da dispositivi e credenziali. Per proteggere i nostri dipendenti da tentativi di phishing sofisticati, 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 di questi dispositivi siano aggiornate con le patch di sicurezza e controlliamo le applicazioni che i dipendenti possono installare sui propri dispositivi. Abbiamo anche dei sistemi che analizzano le applicazioni installate dagli utenti, i download, le estensioni del browser e i contenuti dei browser web per determinare se sono adatti ai dispositivi aziendali.

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

Riduzione dei rischi provenienti da personale interno

Limitiamo e monitoriamo attivamente le attività dei dipendenti a cui è stato concesso l'accesso amministrativo all'infrastruttura. Lavoriamo incessantemente per eliminare la necessità di un accesso privilegiato per determinate attività utilizzando un'automazione in grado di gestire le stesse attività in modo sicuro e controllato. Ad esempio, sono richieste approvazioni da due parti per alcune azioni e utilizziamo API limitate che consentono il debug senza esporre le informazioni sensibili.

L'accesso dei dipendenti Google alle informazioni degli utenti finali può essere registrato tramite hook di infrastruttura di basso livello. Il nostro team addetto alla sicurezza monitora i modelli di accesso ed esamina gli eventi insoliti.

Monitoraggio delle minacce

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

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

Per scoprire di più sulle nostre attività di monitoraggio delle minacce, consulta il report Minori orizzonti.

Rilevamento delle intrusioni

Utilizziamo pipeline di elaborazione dati sofisticate per integrare gli indicatori basati sull'host su singoli dispositivi, gli indicatori basati sulla rete provenienti da vari punti di monitoraggio nell'infrastruttura e gli indicatori provenienti dai servizi dell'infrastruttura. Le regole e l'intelligence della macchina sviluppate su queste pipeline forniscono avvisi ai tecnici della sicurezza operativa di possibili incidenti. I nostri team di indagini e risposta agli incidenti selezionano, esaminano e rispondono a questi potenziali incidenti 24 ore su 24, 365 giorni all'anno. Diamo vita agli allenamenti dei Team rossi per misurare e migliorare l'efficacia dei nostri meccanismi di rilevamento e risposta.

Passaggi successivi