Preparatevi ad una recensione dai toni entusiastici su un articolo recentemente pubblicato, in cui Google spiega per sommi capi i principi progettuali alla base della sua architettura di sicurezza. Quali lezioni può trarre chi si occupa di sicurezza IT in azienda? In serbo per il lettore, alcune curiose sorprese…
di Giulia di Rienzo
Come ogni giorno scorrevo la mia personale rassegna stampa tecnica, imbattendomi in un promettente whitepaper di Google: Google Infrastructure Security Design Overview. “Essential reading”, dicevano, e io mi sono fidata. Ormai gli ingegneri di Google sono quasi alla stregua degli ingegneri della Sun (prima dell’acquisizione da parte di Oracle, ça va sans dire), assurti a creature mitologiche che per la mia generazione hanno rappresentato un ideale a cui aspirare: innovativi, creativi, ma anche metodici ed eleganti. Quando all’università si doveva consegnare un progetto, ci si chiedeva: “un ingegnere della Sun lo farebbe così?”; “Ah, che forza le API degli ingegneri della Sun!” — si commentava a mensa, mangiando un piatto di pasta scotta, lo sguardo sognante al cielo, ripensando a quella Concurrent Collection che ti aveva salvato l’esercitazione.
Ma dicevamo degli ingegneri di Google. Dopo aver letto Site Reliability Engineering non ho più guardato agli ingegneri di Google con gli stessi occhi. Non potevo quindi perdermi una lettura così interessante come questa, dedicata tutta all’architettura di sicurezza.
L’articolo descrive i mattoni che compongono architettura da quelli di più basso a quelli di più alto livello, e chiude con un capitolo dedicato alla sicurezza della Google Cloud Platform.
La protezione dello strato fisico
Le prime pagine descrivono i dispositivi di sicurezza fisica che regolano l’accesso ai datacenter e la loro protezione: nulla che non mi sia già capitato di toccare con mano — barriere anti-sfondamento, videosorveglianza, metal detector, identificazione biometrica — con la sola eccezione, temo, dei raggi laser.
Quindi si passa all’hardware: Google si fa costruire da partner fidati e controllati tutto il “ferro”, che è progettato autonomamente in casa. Si tratta di un approccio piuttosto radicale che in pochissimi al mondo sono in grado di permettersi; ma qui Mountain View ha ragione da vendere. Prendete nota, pubbliche amministrazioni tutte, che comprate server e apparati di rete tramite gare al ribasso!
Ognuna di queste macchine è equipaggiata con software di basso livello (dal BIOS al sistema operativo) controllato e firmato, e la sua identità all’interno dell’infrastruttura è collegata all’accoppiata hardware-software. Paranoia? No, quando devi gestire milioni di apparecchi in giganteschi datacenter sparsi per il mondo…
L’epica caduta dei firewall
Dopo averci stupito con la sicurezza al livello fisico, Google ci racconta come fa ad assicurare la sicurezza al livello logico/applicativo (o al livello del servizio, per usare la terminologia dell’articolo originale). E qui arriva il bello!
❝Non ci affidiamo alla segmentazione di rete o ai firewall come meccanismi di sicurezza principali❞
Ammetto di aver avuto un istante di mancamento. Metà della mia vita lavorativa, l’ho passata a configurare router e firewall; l’altra metà, l’ho passata “sull’altra sponda del fiume”, a combattere con gli incartamenti bizantini necessari per farsi configurare una manciata di regole (scartoffie e red tape a non finire per farsi approvare un change di apertura di un flusso attraverso una mezza dozzina di apparati). Poi un bel giorno arriva Google, e allude con apparente nonchalance a una rete praticamente piatta e senza barriere?!
- Ok, aspetta, un attimo, respira, rileggi — mi dico — non si affidano alla segmentazione o ai firewall come meccanismo di sicurezza primario. Ma di certo ci si affidano in qualche modo. — “… ma in effetti usiamo filtri in ingresso e uscita in vari punti della nostra rete per prevenire lo spoofing di indirizzi IP e come ulteriore strato di sicurezza. Questo ci permette anche di massimizzare le performance e la disponibilità della nostra rete”. Ne deduco che è come pensavo all’inizio: il ricorso ai filtri di rete è minimale, solo in “vari punti” della rete (quanti, quali?). La chiosa finale mi fa immaginare una situazione in cui i firewall di Google in una configurazione tradizionale non reggevano alla botta del carico trasformandosi in colli di bottiglia. Forse corro troppo con la fantasia?
Fatto sta che non implementano in maniera tradizionale nemmeno le difese perimetrali e l’accesso dei client aziendali. Illuminante a proposito l’articolo BeyondCorp: a new approach in Enterprise Security, citato tra gli approfondimenti.
Defence in depth, portata all’estremo
In effetti, la strategia complessiva di Google consiste nel non permettere che alcun livello della sua infrastruttura consideri un altro strato fidato (trusted) “a prescindere”. Ecco perché lo strato applicativo è capace di implementare tutti i presidi di sicurezza a tutela di integrità, riservatezza e disponibilità dei servizi. Il traffico è criptato a livello applicativo, non solo al livello del trasporto; ogni applicazione è tenuta ad autenticarsi con credenziali crittografiche quando accede alle API esposte da altre applicazioni; le identità (delle applicazioni come degli impiegati) e le chiavi sono gestite centralmente da infrastrutture che supportano workflow di approvazione e rotazione automatica delle chiavi; le API sono protette da ACL in modo che ne sia garantito un accesso molto selettivo; tutti i servizi supportano l’impersonation, in modo che i dati che passano da un’applicazione all’altra siano solo quelli effettivamente autorizzati in base all’utente che sta usando l’applicazione. Tutti i meccanismi citati sono ben noti, ma è raro trovarli applicati così pervasivamente e sistematicamente.
E anche a livello di storage non si scherza: i dati sono criptati sia a livello applicativo che a livello hardware — come abbiamo detto, non ci si fida di nessuno; e ogni disco che lascia i datacenter di Google, o è stato cancellato con procedure sicure passando due verifiche indipendenti, oppure è stato ridotto in pezzi.
Ci sono infine altri due presìdi tra quelli descritti nell’articolo che mi piacerebbe menzionare: io ritengo che siano ottime pratiche, ma sorprendentemente le trovo disattese o sottovalutate anche in aziende che affermano di essere molto attente alla sicurezza.
Prevenire è meglio che curare: lo sviluppo del codice
Innanzitutto, il cosiddetto “safe software development” — sviluppo sicuro del codice o sviluppo di codice sicuro, la lingua inglese non ci dà di sapere; a me piace pensare che valgano entrambe le interpretazioni contemporaneamente.
Le tecniche di safe software development consistono in:
- controllo delle librerie;
- utilizzo di tool automatici: static code analysis, security scanning;
- source control management centralizzato (quindi, audit trail implicito su ogni modifica al codice sorgente) e manual code review sistematica (obbligatoria per ogni commit).
Non mi stancherò mai di sottolineare quanta differenza può fare la revisione manuale del codice. L’investimento in termini di tempo si ripaga ampiamente quando ci si ritrova, proprio malgrado, a caccia di heisenbug introdotti chissà quanti sprint fa; per non parlare di tutte le vulnerabilità che riuscirebbero a passare le maglie dell’analisi statica e che invece non sfuggono ad un secondo paio di occhi mediamente allenato. Non c’è nulla da fare: noi umani siamo ancora i migliori quando c’è da usare la penna rossa. In letteratura si trovano molti interessanti argomenti al riguardo: per chi fosse interessato, i riferimenti della pagina inglese di Wikipedia sull’argomento sono un buon punto di partenza.
Proteggere l’anello debole: l’autenticazione a più fattori
Il secondo presidio di cui vorrei raccontare è l’autenticazione a due fattori obbligatoria per i dipendenti. E’ noto che la catena è tanto forte quanto il suo anello più debole, e che l’anello debole è quasi sempre l’utente; i dipendenti di Google forse sono in grado di stimare in meno di un minuto il numero di finestre esistenti a Chicago con un margine di errore del 5%, ma quando si tratta di cadere vittime di tecniche di social engineering non fanno eccezione: sono fagiani come tutti.
Il secondo dispositivo di autenticazione distribuito ai dipendenti non è nel caro vecchio badge, come si potrebbe ingenuamente pensare, bensì un dispositivo U2F (non a caso, Google ha contribuito a progettarne le specifiche). Rispetto a una smartcard è più facilmente interoperabile, perché non richiede un lettore apposito; rispetto a un OTP è più sicuro perché non soggetto a phishing. Inoltre è molto semplice da usare: si collega, ad esempio tramite una presa USB, e si sfiora un bottone. Il limite più evidente di questa tecnologia per una impresa “tradizionale” è nell’applicabilità alle sole applicazioni web, che in ambito enterprise non hanno ancora del tutto soppiantato i fat client. Indipendentemente dal tipo di dispositivo utilizzato, tuttavia, l’autenticazione a più fattori è un’ottima idea e ne possiamo usufruire anche noi utenti comuni di Internet: molti servizi — da poco anche Facebook — supportano già i dispositivi U2F, e vale la pena farci un pensierino, visto l’investimento contenuto. Il modello base di YubiKey costa 20€, ma si trovano altri modelli anche per meno di 10€.
Conclusioni
Le conclusioni che si possono trarre da questa interessante — e a tratti sorprendente — panoramica sulla sicurezza a marchio Google sono molteplici, ma io ne porto a casa una in particolare:
❝non accettare caramelle da chicchessia, amico o sconosciuto.❞
Trovo che il punto di forza di questa architettura di sicurezza sia proprio il principio, portato all’estremo, di non concedere trust implicito ad alcun componente, progettando i dispositivi di sicurezza di ciascun componente come se non si avesse alcun controllo su tutti gli altri. Non solo si ottengono prodotti complessivamente più sicuri, ma si può talvolta scoprire di poter fare a meno di difese normalmente considerate imprescindibili, quando i vantaggi ripagano del maggior rischio: basti vedere quello che Google riesce a ottenenere rinunciando all’(ab)uso dei firewall, una rinuncia che sarebbe praticamente un tabù in qualsiasi altra azienda “normale”.
Imagine there’s no segment…
Giulia Di Rienzo
Appassionata di tecnologia, lavoro nell’IT di una grande azienda pubblica. Mi interesso di fantascienza, AI e musica nel mio tempo libero.
