Google: gestione della sicurezza nel cloud

Un recente white paper rivela inediti dettagli sulle strategie adottate dal provider per garantire la sicurezza dei propri data center

Google e sicurezza nel cloud - schema dei security layer

Schema con i vari layer di sicurezza dell’infrastruttura Google – fonte Google

Il paper pubblicato recentemente da Google è stato redatto per due motivi: scoraggiare eventuali malintenzionati e rassicurare gli attuali e futuri clienti. Per gli addetti ai lavori e portali come Hosting Talk, che seguono anche il mondo del cloud computing, è invece un interessante documento che illustra come venga affrontata la questione sicurezza da un provider d’alto profilo. Di seguito riportiamo alcuni estratti del paper, gli utenti possono approfondire l’argomento cliccando sul link appena fornito.

Il sistema di protezione Mountain View è suddiviso in più strati o layer. Nel paper vengono innanzitutto presentate le misure di sicurezza degli strati più bassi (low layer). In questa primo gruppo rientrano:

  • l’infrastrutturaIn base a quanto si afferma nel documento, solo un esiguo numero di persone autorizzate ha accesso ai data center. Ogni piano è inoltre protetto da una serie di avanzate tecnologie che ad alcuni lettori potrebbero ricordare uno dei tanti film di 007: identificazione biometrica, metal detector, videocamere di sorveglianza, barriere anti veicoli, sistemi anti intrusione (laser);
  • l’hardware. Google adopera migliaia di macchine “personalizzate” . Mountain View lavora inoltre a stretto contatto con una cerchia di vendor autorizzati a fornire hardware alla compagnia; ogni componente deve superare una serie di test che ne certifichino l’idoneità. Google impiega infine dei chip custom di sicurezza che vengono installati sia nei server che nelle periferiche. I chip sono una sorta di documento di identità della macchina/periferica che viene in questo modo identificata come legittima al livello dell’hardware;
  • l’identità delle macchine, software stack. Google si serve di varie tecnologie per garantire che le macchine eseguano il corretto software stack: le cryptographic signatures hanno lo scopo di identificare componenti di basso livello come bootloader, kernel, il sistema operativo. Ciascuno degli elementi appena menzionati è completamente custom, quindi ideato e pensato nei laboratori Google. Ogni macchina dispone infine di una propria identità che può essere associata all’hardware ed al software “legittimato”.

Nella sezione successiva si parla del layer servizi: “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.”

I servizi sono controllati dal cluster di orchestrazione Borg. E’ interessante notare come di default ciascun servizio in esecuzione nell’infrastruttura non consideri come “legittimo” un qualsiasi altro servizio: “the infrastructure does not assume any trust between services running on the infrastructure. In other words, the infrastructure is fundamentally designed to be multi-tenant”.

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

Gestione delle identità ed autorizzazioni

La gestione delle identità degli utenti e l’accesso a determinati dati è un altro aspetto cruciale della strategia di sicurezza Google. Il paper spiega come dietro al semplice utilizzo di Gmail vi sia dietro un complesso sistema di verifiche ed autorizzazioni:

“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”.

Service identity ed Access Management

Service Identity and Access Management – fonte Google

Sicurezza dello storage

Il paper si sofferma anche sulla gestione degli hard disk. La crittografia viene applicata anche in questo caso a 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”.

Ogni unità dispone infine di un codice di tracking grazie al quale è possibile seguirne all’occorrenza le varie fasi del ciclo di vita. Gli hard disk che per vari motivi (rottura, sostituzione etc.) si apprestano ad abbandonare le infrastrutture Google sono prima formattati e successivamente sottoposti a controlli che attestino l’avvenuta eliminazione dei dati. In caso di esito negativo, le unità sono distrutte fisicamente in loco.

 

Facci sapere cosa ne pensi!

Il tuo indirizzo email non sarà pubblicato. I campi obbligatori sono contrassegnati *