Per Google la sicurezza è un tema di fondamentale importanza: per questo di recente ha pubblicato un paper che descrive in modo dettagliato l’intera infrastruttura e i processi ideati per preservare i propri servizi internet, sia quelli consumer come Search, Gmail e Photo che quelli Enterprise come GSuite e Google Cloud Platform.

Il documento offre una panoramica sull’attuale infrastruttura tecnica, ma la doverosa premessa è che l’innovazione in questo ambito è continua, quindi molto probabilmente nel corso del tempo si registreranno dei cambiamenti.

Innanzitutto è interessante sapere che Google suddivide il proprio sistema di sicurezza in diversi layer: il livello più basso fa riferimento alla sicurezza fisica dei data center, per poi proseguire con la spiegazione di come hardware e software vengono preservati, arrivando alla descrizione dei vincoli e dei processi che garantiscono la sicurezza operativa.

Oggi vi proponiamo alcuni dei passaggi salienti, ma per leggere il documento completo potete cliccare qui.

Google Infrastructure Security Design Overview

Le misure di sicurezza presenti negli strati più bassi (low layer) fanno riferimento a:

  • Spazi fisici: Google ha progettato e costruito i propri data center. L’accesso a questi spazi è riservato solo ad un numero esiguo di persone che devono attraversare diverse procedure di controllo prima di poter entrare: videocamere e controlli di identificazione biometrica sono solo alcuni degli strumenti utilizzati a tale scopo. Big G inoltre ospita alcuni dei propri server in data center di terze parti che però seguono le medesime procedure di controllo. Nel video qui sotto, pubblicato solo 10 mesi fa, potete fare un tour (anche meglio attraverso l’utilizzo di cardboard) all’interno di un data center.
  • Design e provenienza degli hardware: I data center di Google sono costituiti da migliaia di server collegati ad una rete locale. Sia le schede madre per i server che le apparecchiature di rete sono state disegnate proprio da Big G. Inoltre le macchine vengono prodotte da vendor selezionati, seguiti dallo staff di Google per la validazione di ogni singola componente della macchina. Una volta che le macchine giungono ai data center, vengono ‘marchiate’ con dei Chip custom che consentono al team di identificare e autenticare come legittime quelle macchine.
  • Identità delle macchine e il Secure Boot Stack: per assicurarsi che il software eseguito su ogni server non sia compromesso in modo malevolo, Google opera dei controlli crittografici su ogni componente software necessaria per l’avvio delle macchine. Ogni server ha una propria identità, che viene legata al software che può esservi eseguito: questo garantisce che nessun processo non autorizzato possa essere eseguito su un qualunque server.

Il livello successivo descrive i servizi, con questo termine Big G intende: “By ‘service’ we mean an application binary that a developer wrote and wants to run on our infrastructure, for example, a Gmail SMTP server, a BigTable storage server, a YouTube video transcoder, or an App Engine sandbox running a customer application.”

Questo passaggio è particolarmente interessante perché mette in luce che l’infrastruttura è stata progettata per essere multi-tenant: ciò significa che ogni servizio è condiviso tra i diversi utenti della piattaforma (il che consente di ottimizzare le risorse hardware), ma ognuno può agire soltanto sui servizi che gli appartengono (garantendo affidabilità e sicurezza).

Tutte le linee guida applicate in questo layer hanno lo scopo di garantire l’identificabilità, l’integrità e l’isolamento dei servizi, implementati con  diverse tecniche, come la virtualizzazione dell’hardware o la separazione degli utenti Linux.

Veniamo ad un punto cruciale del Paper, che sicuramente interesserà molti di voi, come viene gestita l’identità degli utenti finali?

Nel documento si prende ad esempio l’utilizzo di Gmail da parte di un utente, un processo quotidiano e apparentemente semplice, che richiede però un complesso sistema di verifiche ed autorizzazioni nell’infrastruttura di Google. Tale sistema fa affidamento su un’autorità di identity centralizzata, per assicurarsi che ogni richiesta proveniente dai client sia opportunamente corredata da un elemento di autenticazione valido (ad esempio, un cookie o un token OAuth), come descritto nel seguente estratto:

“Since the Gmail service makes an RPC request to the Contacts service on behalf of a particular end user, the infrastructure provides a capability for the Gmail service to present an “end user permission ticket” as part of the RPC. This ticket proves that the Gmail service is currently servicing a request on behalf of that particular end user. This enables the Contacts service to implement a safeguard where it only returns data for the end user named in the ticket.

The infrastructure provides a central user identity service which issues these “end user permission tickets”. An end user login is verified by the central identity service which then issues a user credential, such as a cookie or OAuth token, to the user’s client device. Every subsequent request from the client device into Google needs to present that user credential.

When a service receives an end user credential, it passes the credential to the central identity service for verification. If the end user credential verifies correctly, the central identity service returns a short-lived “end user permission ticket” that can be used for RPCs related to the request”.

Google Infrastructure Security Design Overview

La sicurezza dei servizi di Storage

L’infrastruttura di sicurezza ideata da Google comprende naturalmente anche i servizi di Storage, anche in questo caso gestita tramite crittografia applicata su vari livelli: “Performing encryption at the application layer allows the infrastructure to isolate itself from potential threats at the lower levels of storage such as malicious disk firmware. That said, the infrastructure also implements additional layers of protection. We enable hardware encryption support in our hard drives and SSDs”.

Questo è un altro esempio di sicurezza applicata al livello fisico: ogni unità dispone di un codice di tracking grazie al quale è possibile seguire le varie fasi del ciclo di vita. Quando un hard disk necessita di essere smaltito segue una procedura definita: prima viene formattato e poi sottoposto ad accurati controlli che verificano l’avvenuta eliminazione dei dati, in caso di esito negativo, le unità vengono distrutte fisicamente sul posto.

L’autenticazione degli utenti

Come saprete, per accedere ad un qualsiasi servizio di Google, è necessario autenticarsi attraverso uno username ed una password: questo processo rappresenta esso stesso un layer di sicurezza. Infatti oltre alla richiesta di questi dati, Google segnala qualsiasi tipo di fattore di rischio, come ad esempio l’accesso del medesimo utente da luoghi o dispositivi mai incontrati in passato. Dopo l’autenticazione dell’utente il servizio emette Cookies o Token OAuth che possono essere utilizzati per le chiamate successive.

Per preservare maggiormente la sicurezza dei propri profili, gli utenti hanno a disposizione anche altre soluzioni, come le OTPs (One Time Passwords) o phishing-resistant keys. Google ritiene importante che gli utenti per primi si dotino di strumenti atti alla protezione dei dati e cerca in ogni modo di educare alla sicurezza, per questo motivo da diverso tempo collabora con FIDO Alliance unitamente ad altri vendor di dispositivi per delineare un protocollo standard chiamato Universal 2nd Factor (U2F). Già oggi è possibile trovare sul mercato dispositivi e web services che rispondono al protocollo U2F.
Questi sono solo alcune delle strategie implementate nell’infrastruttura di sicurezza ideata da Big G, una struttura complessa e certificata secondo i più diffusi standard internazionali, a cui lavorano ogni giorno più di 500 esperti dedicati.

Vuoi toccare con mano le potenzialità di Google Cloud Platform?

SCARICA IL VIDEO ON DEMAND