Autorizzazione binaria per Borg: verifica della provenienza e implementazione dell'identità del codice in Google

Google ha pubblicato vari white paper che illustrano i progetti sviluppati internamente dal nostro team addetto per migliorare la sicurezza, inclusi BeyondCorp e BeyondProd. Per una panoramica della sicurezza di Google, consulta il nostro white paper sulla progettazione dell'infrastruttura di sicurezza.

Questo white paper descrive il processo di revisione del codice di Google, la verifica della provenienza1 e la necessità di meccanismi di applicazione forzata. Si concentra sullo sviluppo di un controllo specifico per l'applicazione forzata, Autorizzazione binaria per Borg (BAB). L'obiettivo di BAB è ridurre i rischi provenienti da personale interno garantendo che il software di produzione implementato in Google venga esaminato e autorizzato in modo adeguato, in particolare se tale codice è in grado di accedere ai dati utente. Per tutti i prodotti Google, la protezione dei dati utente è di fondamentale importanza e ci impegniamo a mantenere la massima trasparenza in merito alle misure di sicurezza adottate.

I contenuti di questo white paper sono aggiornati a dicembre 2019. Questo documento rappresenta lo status quo al momento in cui è stato redatto. Criteri e sistemi di sicurezza di Google Cloud possono variare in futuro, grazie al costante miglioramento della protezione per i nostri clienti.

Riepilogo a livello di CIO

  • I rischi provenienti da personale interno rappresentano una minaccia alla sicurezza dei dati utente. Google adotta tutte le misure possibili per ridurre la possibilità che il personale Google utilizzi le proprie conoscenze dell'organizzazione o acceda ai dati utente senza autorizzazione, inclusa l'esecuzione di un job non autorizzato.
  • Autorizzazione binaria per Borg, o BAB, è un controllo interno dell'applicazione dei requisiti in fase di deployment che minimizza i rischi provenienti da personale interno garantendo che il software di produzione e la configurazione implementati in Google vengano esaminati e autorizzati in modo appropriato, in particolare se tale codice è in grado di accedere ai dati utente.
  • BAB garantisce che i deployment di codice e configurazione rispettino determinati standard minimi.
  • In aggiunta all'applicazione forzata, BAB può essere utilizzato anche in una modalità di controllo senza applicazione forzata, per segnalare il mancato rispetto di determinati requisiti.
  • L'adozione di BAB consente a Google di ridurre i rischi provenienti da personale interno, prevenire i possibili attacchi e supportare l'uniformità dei propri sistemi di produzione.

Riduzione dei rischi provenienti da personale interno in Google

Come società in cui la sicurezza è al primo posto, abbiamo adottato misure per limitare i rischi provenienti da personale interno, ovvero la possibilità che il personale Google (o qualsiasi altra persona all'interno dell'organizzazione) utilizzi le proprie conoscenze o il proprio accesso all'organizzazione per eseguire azioni dannose. I rischi provenienti da personale interno comprendono anche le situazioni in cui un utente malintenzionato ha compromesso le credenziali di un soggetto interno a Google per facilitare l'attacco. Abbiamo dedicato importanti risorse all'innovazione nel settore della protezione dai rischi provenienti da personale interno. In Google, la salvaguardia dei dati utenti è di fondamentale importanza, pertanto ci impegniamo per assicurare una protezione completa. Il nostro obiettivo è impedire che un dipendente Google acceda ai dati utente senza autorizzazione.

Autorizzazione per l'accesso ai dati utente

In Google, ci sono casi in cui i nostri servizi e il nostro personale devono accedere ai dati utente. L'interazione con i dati utente avviene nei seguenti modi:

  1. Come utente finale: un dipendente che utilizza un servizio esegue direttamente l'autenticazione al servizio e il servizio restituisce i suoi dati. Ad esempio, un dipendente che accede al suo account Gmail vedrà le sue email.
  2. Come parte del ruolo: la maggior parte del lavoro svolto dal personale Google può essere completato utilizzando dati utente anonimizzati. Tuttavia, in alcune rare occasioni, il nostro personale richiede l'accesso ai dati utente nell'ambito del proprio lavoro (ad esempio per assistenza o debug). Il nostro obiettivo è assicurare la massima trasparenza relativamente agli accessi ai dati utente. Uno dei metodi utilizzati a tale scopo è la Trasparenza degli accessi, una funzione che permette ai clienti Google Cloud di osservare gli accessi idonei ai propri dati tramite log in tempo reale.
  3. Come parte di un servizio, in modo programmatico: per eseguire un'attività, un servizio potrebbe richiedere l'accesso programmatico ai dati utente su larga scala. Ad esempio, una pipeline dati eseguirà query su migliaia di dati utente alla volta per generare statistiche sull'utilizzo aggregate. Quando emerge questo tipo di necessità, l'accesso viene concesso per un set di dati piuttosto che per i dati di un singolo utente. L'accesso ai dati dei singoli utenti non viene registrato.

Questo white paper si concentra sul modello di minaccia presentato nel terzo scenario. Vogliamo essere sicuri che gli amministratori che eseguono i sistemi con accesso ai dati utente non possano abusare dei loro poteri.

Modello di minaccia

I controlli illustrati in questo white paper sono stati creati per proteggere i dati utente impedendo accessi unilaterali. Il nostro intento è impedire al personale Google che agisce per fini propri di accedere direttamente o indirettamente o di influire in qualsiasi altro modo sui dati utente senza un'autorizzazione e una giustificazione adeguata. I nostri controlli impediscono queste azioni a prescindere dall'intento negativo o meno dell'autore, dall'eventuale compromissione del suo account o dall'errata concessione dell'autorizzazione.

L'infrastruttura containerizzata di Google

La nostra infrastruttura è containerizzata tramite un sistema di gestione cluster chiamato Borg. Eseguiamo centinaia di migliaia di processi di numerose applicazioni, tra diversi cluster, ciascuno anche con decine di migliaia di macchine. Nonostante la sua vasta scala, il nostro ambiente di produzione è abbastanza omogeneo. Di conseguenza, i touchpoint per l'accesso ai dati utente possono essere controllati e sottoposti ad audit più facilmente.

Inoltre, l'uso dei container ci ha offerto rilevanti vantaggi in termini di sicurezza. I container sono destinati all'utilizzo senza variazioni, con frequenti deployment da una rigenerazione completa dell'immagine. Questa proprietà ci consente di esaminare una modifica al codice in contesto e offre un singolo punto di passaggio obbligato per tutte le modifiche implementate nella nostra infrastruttura.

Per capire come abbiamo sviluppato una soluzione che limita l'accesso programmatico ai dati utente da parte di un servizio, è importante comprendere innanzitutto il processo con cui un servizio entra in produzione in Google.

Passaggio 1: revisione del codice

Il nostro codice sorgente è archiviato in un repository centrale monolitico che consente a migliaia di dipendenti di controllare il codice in una singola posizione. L'utilizzo di un unico codebase semplifica la gestione del codice sorgente, in particolare le nostre dipendenze da codice di terze parti. Un codebase monolitico consente inoltre l'applicazione di un singolo punto di passaggio obbligato per le revisioni del codice. In Google, le revisioni del codice includono l'ispezione e l'approvazione da parte di almeno un tecnico diverso dall'autore. La nostra procedura di revisione del codice prevede l'applicazione di una regola per cui le modifiche apportate a un qualsiasi sistema devono essere approvate come minimo dal proprietario del sistema stesso. Dopo l'archiviazione del codice, il processo continua con la creazione della build.

Per l'importazione di modifiche da codice di terze parti o open source, verifichiamo che la modifica sia appropriata (ad esempio, che sia la versione più recente). Tuttavia, spesso non applichiamo gli stessi controlli di revisione per ogni modifica apportata da sviluppatori esterni al codice di terze parti o open source che utilizziamo.

Passaggio 2: build verificabili

Utilizziamo un sistema di build molto simile a Bazel che genera e compila il codice sorgente, creando un programma binario per il deployment. Il nostro sistema di build viene eseguito in un ambiente isolato e bloccato, separato dai dipendenti che eseguono le build. Per ciascuna build, il sistema produce un file manifest della build verificabile, un certificato firmato con una descrizione completa dei file sorgente inseriti nella build, degli hash crittografici di eventuali programmi binari o altri artefatti della build e dei parametri completi della build. Questo file manifest ci consente di tracciare un programma binario risalendo al codice sorgente utilizzato per crearlo e, per estensione, al processo di creazione e invio del codice sorgente descritto. Inoltre, il file manifest ci consente di verificare che il programma binario non sia stato modificato, in quanto eventuali modifiche al file comprometterebbero automaticamente la validità della firma.

Poiché le azioni di build teoricamente possono riguardare il codice arbitrario, il nostro sistema di build è stato protetto per l'architettura multi-tenancy. In altri termini, il nostro sistema di build è progettato per impedire che una build ne influenzi altre. Il sistema impedisce alle build di apportare modifiche in grado di compromettere l'integrità dei manifest verificabili della build oppure del sistema stesso. Una volta completata la build, il deployment della modifica viene eseguito tramite Borg.

Passaggio 3: job di deployment

Una volta compilato, un programma binario può essere implementato nella nostra infrastruttura containerizzata come un job Borg. Questi job utilizzano pacchetti che possono contenere programmi binari o dati, la cui installazione è gestita da Borg. Una configurazione Borg specifica i requisiti per il job da implementare: pacchetti, parametri di runtime, argomenti e flag. Borg programma il job prendendo in considerazione i vincoli, la priorità, la quota e qualsiasi altro requisito elencato nella configurazione. Dopo il deployment, il job Borg può interagire con altri job in produzione.

Passaggio 4: identità del job

Un job Borg viene eseguito come identità ed è questa che viene utilizzata per accedere ai datastore o ai metodi di chiamata di procedura remota (RPC) di altri servizi. Un'identità può essere un account del ruolo (ad esempio un servizio) o un account utente (ad esempio l'account individuale di un dipendente). Più job possono essere eseguiti con la stessa identità. Limitiamo la possibilità di implementare o modificare i job con una particolare identità ai soli responsabili dell'esecuzione del servizio, generalmente i nostri SRE (Site Reliability Engineer).

Quando Borg avvia un job, esegue il provisioning delle relative credenziali crittografiche. Il job utilizza queste credenziali per provare la sua identità durante l'esecuzione di richieste di altri servizi (tramite Application Layer Transport Security). Per poter accedere a determinati dati o ad altri servizi, l'identità di un servizio deve avere le autorizzazioni necessarie. Prendiamo come esempio un servizio come l'API Cloud Data Loss Prevention (Cloud DLP) di Google Cloud. Per poter accedere ai dati per la scansione, l'API DLP deve soddisfare due requisiti. In primo luogo, l'API DLP deve essere configurata per l'esecuzione con un'identità specifica, in questo caso un account del ruolo. In secondo luogo, le autorizzazioni ai dati di cui l'API DLP sta eseguendo la scansione devono includere tale account del ruolo. Senza un'identità valida e le autorizzazioni corrette, il servizio non sarebbe in grado di eseguire la scansione.

I nostri criteri richiedono che qualsiasi account del ruolo con accesso ai dati utente (o qualsiasi altro dato sensibile) sia strettamente controllato da BAB e dagli altri sistemi di sicurezza. I job di sviluppo e garanzia di qualità che non hanno accesso a dati o risorse sensibili possono essere eseguiti con meno controlli.

Riepilogo: ciclo di vita di un job

Per riassumere, di seguito sono riportati i passaggi per eseguire un job sulla nostra infrastruttura:

  1. Uno sviluppatore Google autorizza una modifica al codice. Quindi la invia a uno o più altri tecnici Google per la revisione. La revisione include controlli dell'adeguatezza di autorizzazione e logging. Dopo l'approvazione, il codice viene archiviato.
  2. Attivato dallo sviluppatore, il sistema di build genera e racchiude in pacchetti i programmi binari in modo verificabile in un ambiente limitato tramite sandbox. Questa operazione di build produce un pacchetto che viene poi firmato dal sistema di build ai fini della verifica.
  3. Il job viene distribuito su Borg da un tecnico con autorizzazione specifica alla gestione dei job in esecuzione con l'identità protetta adeguata.
  4. Quando un job Borg tenta di accedere a risorse con privilegi quali i dati utente, viene verificato che l'identità del job sia autorizzata

Dopo aver presentato l'esecuzione dei job nel nostro ambiente di produzione, è il momento di esaminare il modello di minaccia affrontato da BAB per impedire al personale interno potenzialmente malintenzionato di eseguire un job non autorizzato. A tal fine, BAB verifica che tutti i controlli di sicurezza necessari siano stati eseguiti prima del deployment di un programma binario.

In questa sezione è stata fornita una panoramica della nostra infrastruttura containerizzata. Una comprensione di base del nostro ambiente di produzione è un prerequisito necessario per capire i controlli che abbiamo adottato per l'accesso utente programmatico ai dati. Questi controlli vengono descritti in maggiore dettaglio nella sezione successiva.

Autorizzazione binaria per Borg (BAB)

Per vari anni, abbiamo intrapreso sforzi significativi per la protezione dei dati utente dall'accesso manuale. Questi sforzi includono la limitazione dell'accesso alla gestione dei job e dei dati esclusivamente ai dipendenti Google che lo richiedono per svolgere le proprie mansioni.

Il compito di BAB è garantire che la configurazione e tutto il software di produzione implementati in Google abbiano ricevuto un'adeguata revisione e autorizzazione, in particolare se tale codice è in grado di accedere ai dati utente. A tal fine, BAB fornisce un servizio di applicazione forzata in fase di deployment per prevenire l'avvio di job non autorizzati e un audit trail del codice e della configurazione utilizzati nei job abilitati da BAB.

Verifica

BAB verifica che al momento del deployment i programmi binari soddisfino determinati requisiti. Ad esempio, il proprietario di un servizio può richiedere che il programma binario del servizio sia generato da codice che abbia superato revisione, archiviazione, test e autorizzazione. Definiamo questi tipi di controlli come controlli in fase di deployment. BAB può inoltre eseguire controlli dopo il deployment di un programma binario, che definiamo controlli post-deployment. Per ulteriori informazioni su queste verifiche post-deployment, consulta la nostra sezione Modalità di applicazione forzata.

Una modifica al codice comporta la creazione di un nuovo programma binario. Perché le modifiche nel nuovo programma binario abbiano effetto, è necessario eseguire il deployment. BAB consente numerosi tipi di controlli in fase di deployment. Di seguito sono riportati alcuni esempi di controlli:

  • Il programma binario è stato generato da codice archiviato?

    Il codice è stato inviato e archiviato nel repository del codice sorgente di Google? Il codice da inviare generalmente deve essere revisionato da un secondo tecnico Google.

  • La build del programma binario è stata eseguita in modo verificabile?

    Questo programma binario può essere fatto risalire a sorgenti controllabili ed è stato generato da un sistema di build approvato?

  • La build del programma binario è stata eseguita a partire da codice testato?

    Il programma binario soddisfa i requisiti di test?

  • La build del programma binario è stata eseguita da codice destinato all'uso nel deployment?

    Il codice è stato inviato nell'area appropriata del nostro repository del codice sorgente, corrispondente al progetto o al team pertinente allo specifico job Borg?

Sebbene questi requisiti siano specifici del nostro ambiente di produzione, requisiti simili possono essere applicati nei tuoi ambienti CI/CD (integrazione continua/deployment continuo) in base ai tuoi specifici requisiti di sicurezza, conformità o affidabilità.

Criteri specifici per il servizio

I job con accesso ai dati sensibili generalmente richiedono l'invio del codice, con alcune eccezioni per esigenze aziendali valide. I dati sensibili includono dati utente, dati finanziari e sull'impiego e tutti gli altri dati aziendali o proprietari riservati solo a coloro che devono esserne a conoscenza. Tutti i job in Google devono avere un criterio, di conseguenza anche per un job Borg che non richiede accesso ai dati utente sarà definito un criterio, in cui tuttavia non saranno elencati requisiti specifici.

Quando i proprietari del servizio eseguono l'onboarding su BAB, definiscono un criterio con i requisiti di sicurezza del servizio. Per tutti gli account del ruolo utilizzati per implementare il servizio deve essere specificato un criterio BAB. Per ciascun account del ruolo, il criterio BAB definisce i job da avviare e i requisiti di configurazione e di codice del job. La definizione o la modifica di un criterio è a sua volta una modifica al codice che deve essere revisionata.

I requisiti che possono essere applicati forzatamente in un criterio BAB includono:

  • Build del codice generata in modo verificabile: il codice generato in modo verificabile può essere sottoposto a controllo, tuttavia ciò non significa necessariamente che il codice sia stato sottoposto a una revisione; in alcuni casi, il codice non è stato inviato. Il codice utilizzato in build verificabili può essere sottoposto a controllo per almeno 18 mesi, anche se non è stato inviato.

  • Codice inviato: la build del codice è stata creata da una posizione specifica e dedicata nel nostro repository di codice sorgente. Ciò generalmente implica che il codice sia stato sottoposto a una revisione.

  • Configurazioni inviate: le configurazioni fornite durante il deployment passano attraverso lo stesso processo di revisione e invio del codice normale. Di conseguenza, i valori flag, gli argomenti e i parametri della riga di comando non possono essere modificati senza revisione.

I sistemi e i componenti che applicano BAB devono essere strettamente controllati. Ciò si ottiene implementando i requisiti più severi possibili e controlli manuali aggiuntivi.

Modalità di applicazione

BAB intraprende azioni diverse in base al criterio specificato dal job Borg. Queste azioni, che chiamiamo modalità di applicazione, sono tre: applicazione forzata in fase di deployment, controllo in fase di deployment e verifica continua. Quando viene definito un criterio, il proprietario del servizio deve scegliere tra applicazione forzata o controllo in fase di deployment. La modalità di verifica continua è abilitata per impostazione predefinita. Nelle sezioni seguenti vengono forniti maggiori dettagli su ciascuna modalità.

Modalità di applicazione forzata in fase di deployment

Quando viene inviato un nuovo job, Borgmaster2 consulta BAB per verificare che il job soddisfi i requisiti necessari definiti dal criterio BAB. Questo controllo funge da controller di ammissione: se i requisiti sono soddisfatti, Borgmaster avvia il job. In caso contrario, Borgmaster respinge la richiesta anche se l'utente che l'ha effettuata sarebbe altrimenti autorizzato.

Nella modalità di applicazione forzata, BAB blocca il deployment di un job Borg nel caso in cui non soddisfi i requisiti definiti dal criterio BAB per il job Borg. I servizi nuovi per BAB generalmente iniziano in modalità di controllo (descritta nella sezione seguente), quindi passano alla modalità di applicazione forzata.

Procedure di risposta di emergenza

In caso di incidente o guasto, la nostra prima priorità consiste nel ripristinare il servizio interessato il prima possibile. In una situazione di emergenza, potrebbe essere necessario eseguire codice senza revisione o archiviazione. Di conseguenza, la modalità di applicazione forzata può essere ignorata tramite un flag di risposta di emergenza. Le procedure di risposta di emergenza fungono anche da backup in caso di errore del BAB che altrimenti bloccherebbe un deployment. Uno sviluppatore che esegue il deployment di un job tramite la procedura di risposta di emergenza deve inviare una motivazione come parte della richiesta.

Entro pochi secondi dall'utilizzo della procedura di risposta di emergenza, BAB registra i dettagli relativi al job Borg associato. Il log include il codice utilizzato e la motivazione fornita dall'utente. Pochi secondi dopo, un audit trail viene inviato al nostro team addetto alla sicurezza centralizzata. Entro qualche ora, l'audit trail viene inviato al team proprietario dell'account del ruolo. Le procedure di risposta di emergenza devono essere utilizzate solo come ultima possibilità.

Modalità di controllo in fase di deployment

Nella modalità di controllo, BAB registra quando un job Borg non soddisfa i requisiti del criterio, ma non ne blocca il deployment. Questa violazione del criterio provoca l'invio di un avviso al team proprietario dell'account del ruolo.

In Google è obbligatorio utilizzare la modalità di applicazione forzata per determinati servizi, tra cui quelli che accedono ai dati utente. Consigliamo vivamente a tutti i proprietari di servizi di utilizzare la modalità di applicazione forzata, riservando la modalità di controllo solo all'onboarding di un nuovo servizio. Per utilizzare la modalità di controllo, i proprietari dei servizi devono fornire una motivazione per ricevere un'eccezione. Ad esempio, un servizio con uno SLO (obiettivo del livello di servizio) di affidabilità notevolmente superiore rispetto a quanto fornito da BAB può utilizzare la modalità di controllo.

Pur essendo utile durante il perfezionamento di un criterio iniziale, la modalità di controllo non è pratica come stato permanente per la maggior parte dei servizi. Quando viene utilizzata la modalità di controllo, le violazioni del criterio vengono notificate al proprietario del servizio solo diverse ore dopo che si sono verificate. Ciò può determinare un flusso intenso di notifiche, in cui i reali problemi di sicurezza vengono nascosti da errori o configurazioni inadeguate del criterio introdotte dal proprietario del servizio. Con la modalità di applicazione forzata, il proprietario del servizio riceve un feedback immediato quando tenta di avviare un job non conforme al criterio. Di conseguenza, il flusso di notifiche risulta molto più snello. Inoltre, la modalità di applicazione forzata in BAB rileva errori involontari, come l'avvio accidentale di un job in un ruolo diverso da quello designato.

Verifica continua

Una volta implementato, a prescindere dall'applicazione forzata o meno in fase di deployment, un job viene sottoposto a verifica continua per tutta la sua durata. Un processo BAB viene eseguito almeno una volta al giorno per verificare che i job avviati (e potenzialmente ancora in esecuzione) siano conformi agli eventuali aggiornamenti dei rispettivi criteri. Ad esempio, la modalità di verifica continua ricerca costantemente job in esecuzione con criteri obsoleti o con un'identità implementata tramite procedure di risposta di emergenza. Se un job non è conforme al criterio aggiornato, BAB invia una notifica ai proprietari del servizio in modo da mitigare il rischio.

Pacchetti con autorizzazione globale

In Google alcuni pacchetti sono ampiamente utilizzati da molti dei nostri servizi. Piuttosto che forzare ciascun servizio a mantenere la propria versione, questi pacchetti, che chiamiamo pacchetti a gestione globale, vengono autorizzati a livello centrale. Durante la stesura del criterio BAB, il proprietario di un servizio può specificare un pacchetto con autorizzazione globale per un dato job. È inoltre disponibile un meccanismo predefinito globale per i pacchetti più utilizzati, in modo che non sia necessario elencarli singolarmente all'interno del criterio di ciascun servizio. In questo modo, Google mantiene un controllo esplicito sui componenti di sistema comuni utilizzati in tutta l'organizzazione e garantisce che siano adeguatamente revisionati e aggiornati senza coinvolgere i singoli team. Il proprietario di un servizio può consentire questi pacchetti in modo esplicito nell'ambito del criterio BAB del proprio servizio, tuttavia questo meccanismo rappresenta il percorso consigliato e supportato facilmente utilizzabile dai proprietari.

Casi limite

Google implementa solidi controlli di sicurezza per il codice implementato in produzione, incluse revisioni del codice e build verificabili. BAB funge da controllo aggiuntivo e punto di applicazione per garantire che questi controlli di sicurezza siano implementati effettivamente in modo corretto.

Tuttavia, BAB non può essere utilizzato in modo efficace in tutti i casi. BAB non supporta i seguenti casi limite: codice generato utilizzando sistemi di build non standard; codice implementato in ambienti diversi da Borg; codice di analisi dei dati e machine learning, che non si presta bene alle revisioni del codice umane prima che siano stati scelti i parametri di produzione finali. In questi casi, vengono attuate altre misure di mitigazione per la sicurezza, inclusi altri sistemi di verifica della provenienza del codice. Tuttavia, questo codice è ancora soggetto ai controlli di sicurezza generali di Google.

Implementazione dell'Autorizzazione binaria per Borg

Per implementare BAB, il team dedicato ha sviluppato varie nuove funzionalità, incluse le procedure di risposta di emergenza e la modalità di controllo. Questi strumenti hanno consentito ai proprietari di servizi di provare in prima persona BAB con facilità. Se stai prendendo in considerazione l'implementazione di un meccanismo analogo a BAB nella tua organizzazione, potresti avere bisogno di svolgere alcuni lavori aggiuntivi per facilitare la transizione. Questa sezione descrive il lavoro organizzativo e di gestione dei cambiamenti che abbiamo svolto nell'ambito del nostro piano di implementazione.

Vantaggi

BAB presenta tre vantaggi che hanno contribuito alla creazione del business case per il suo sviluppo e per l'adozione presso Google, nello specifico: riduzione dei rischi provenienti da personale interno, solida identità del codice e conformità semplificata.

Riduzione dei rischi provenienti da personale interno

BAB è stato sviluppato principalmente per impedire che singoli individui ottengano accesso programmatico non autorizzato ai dati utente. BAB rende più difficile per un singolo tecnico o un utente malintenzionato che abbia ottenuto le credenziali di un tecnico accedere ai dati sensibili in modo inadeguato e sfuggendo al rilevamento.

Solida identità del codice

Come descritto nella sezione Infrastruttura containerizzata, i job Borg vengono eseguiti come identità, generalmente un account del ruolo. Questa identità viene utilizzata da altri servizi per verificare che l'autorizzazione sia corretta prima di consentire l'accesso ai dati. Tuttavia, gli altri servizi non possono applicare forzatamente l'utilizzo di tali dati e pertanto devono considerare attendibile l'identità del job, che non metterà in atto comportamenti illeciti sui dati ricevuti. BAB lega l'identità di un job al codice specifico, garantendo che solo il codice specificato possa essere utilizzato per esercitare i privilegi dell'identità del job. Ciò consente una transizione da un'identità del job, in cui l'attendibilità viene attribuita a un'identità e, per la proprietà transitiva, ai suoi utenti umani con privilegi, a un'identità del codice, in cui l'attendibilità viene attribuita a una specifica porzione di codice, che è stata revisionata per avere una semantica specifica e che non può essere modificata senza procedure di approvazione.

Conformità semplificata

BAB ha semplificato quelle che in precedenza erano attività di conformità manuali. Alcune procedure in Google richiedono controlli più rigidi sul trattamento dei dati. Ad esempio, i nostri sistemi per rapporti finanziari devono essere conformi al Sarbanes-Oxley Act (SOX). Prima di BAB, avevamo un sistema che agevolava l'esecuzione manuale delle verifiche per garantire la conformità. Con l'adozione di BAB, molti di questi controlli sono stati automatizzati in base ai criteri BAB dei servizi. L'automazione di questi controlli ha permesso al team per la conformità di aumentare sia l'ambito dei servizi coperti, sia l'adozione di controlli adeguati su tali servizi.

Onboarding di un servizio

Il team BAB doveva garantire che il processo di onboarding fosse semplice e lineare. Inizialmente, i proprietari dei servizi in Google manifestavano preoccupazioni rispetto a due aspetti dell'adozione di BAB:

  • Se BAB non fosse stato abbastanza affidabile, la sua implementazione avrebbe potuto bloccare le modifiche in situazioni critiche.
  • BAB avrebbe potuto rallentare lo sviluppo di un servizio con frequenti archiviazioni del codice e processi iterativi.

In risposta a queste perplessità iniziali, il team BAB ha sviluppato la modalità di controllo. Utilizzando questa modalità, il team BAB è stato in grado di dimostrare ad alcuni primi utenti chiave che BAB funzionava. Per aumentare ulteriormente l'affidabilità, il team BAB ha sviluppato uno SLO di disponibilità e introdotto procedure di risposta di emergenza per la modalità di applicazione forzata.

In fase di onboarding di un servizio esistente in BAB, il proprietario del servizio generalmente abilita prima la modalità di solo controllo. In questo modo si facilita l'identificazione e la risoluzione di eventuali problemi prima di attivare la modalità di applicazione forzata. Il criterio predefinito per qualsiasi job che utilizza BAB in produzione prevede la modalità di applicazione forzata. Per il deployment del job, il proprietario del servizio deve inviare un criterio che richieda, come minimo, l'invio del codice e la generazione in modo verificabile. Un proprietario del servizio può eseguire il deployment del relativo job senza rispettare questo standard minimo, ma solo dopo aver ricevuto la concessione per un'eccezione. Se il servizio richiede l'accesso a più servizi e/o dati sensibili, il proprietario può passare a requisiti più rigidi. La definizione di un criterio iniziale può essere difficile, quindi il team BAB ha creato strumenti automatizzati per assistere i proprietari dei servizi nella stesura dei propri criteri. Gli strumenti rilevano le parti del repository di codice sorgente utilizzate per un job esistente e suggeriscono un criterio appropriato.

Durante l'onboarding di un nuovo servizio in BAB, il proprietario del servizio abilita la modalità di applicazione forzata dall'inizio. Il proprietario del servizio redige una bozza di criterio iniziale ed esegue rapidamente iterazioni per aggiungere requisiti aggiuntivi. I criteri stessi vengono gestiti come modifiche al codice e quindi richiedono la revisione di tutti gli aggiornamenti da parte di un secondo tecnico Google.

Impatto

L'adozione di BAB e di un modello di deployment containerizzato ha offerto a Google numerosi vantaggi in termini di sicurezza e supportabilità:

  • BAB aiuta a ridurre i rischi complessivi provenienti da personale interno: richiedendo che il codice soddisfi determinati standard e pratiche di gestione dei cambiamenti prima di poter accedere ai dati utente, BAB riduce la possibilità che un Googler che agisca per propri fini (o il cui account sia stato compromesso) ottenga accesso programmatico ai dati utente.
  • BAB supporta l'uniformità dei sistemi di produzione: utilizzando i sistemi containerizzati e verificandone i requisiti BAB prima del deployment, i nostri sistemi facilitano il debug, sono più affidabili e hanno una gestione dei cambiamenti più chiara. I requisiti BAB offrono un linguaggio comune per i requisiti dei sistemi di produzione.
  • BAB determina il linguaggio comune per la protezione dei dati: BAB traccia la conformità tra i nostri sistemi. I dati relativi a questa conformità vengono pubblicati internamente e possono essere consultati da altri team. Questa modalità di pubblicazione dei dati BAB consente ai team di utilizzare una terminologia comune nelle loro comunicazioni relative alla protezione dei dati. Questo linguaggio comune riduce la necessità di chiarimenti reciproci durante il lavoro sui dati che coinvolge più team.
  • BAB consente il monitoraggio programmatico dei requisiti di conformità: alcuni processi, tra cui quelli per i rapporti finanziari, devono soddisfare determinati requisiti di gestione dei cambiamenti per scopi di conformità. L'uso di BAB consente di automatizzare questi controlli, offrendo un risparmio di tempo e un ampliamento dell'ambito di copertura.

BAB è una delle diverse tecnologie utilizzate da Google per ridurre i rischi provenienti da personale interno.

Adozione di controlli simili nella propria organizzazione

Implementando BAB in Google abbiamo appreso molte lezioni importanti. Apportare una modifica di tale entità può sembrare un'impresa ardua. In questa sezione condividiamo quanto appreso nel tempo, nella speranza di aiutarti ad applicare i principi di BAB alla tua organizzazione.

Lavora per realizzare una pipeline CI/CD containerizzata più omogenea.

L'adozione di BAB in Google è stata resa possibile dalla coerenza e dall'integrazione degli strumenti che utilizziamo nello sviluppo del codice. Questo lavoro ha incluso revisioni del codice, build verificabili, deployment containerizzati e identità basate sui servizi per il controllo degli accessi. Le build verificabili permettono di controllare come sono stati compilati i programmi binari; i container consentono di separare i programmi binari dai dati e offrono un singolo punto di passaggio obbligato per garantire che vengano rispettati i requisiti per l'uso. Questo approccio ha semplificato l'adozione di BAB e ha rafforzato le garanzie che una soluzione come BAB è in grado di fornire.

L'introduzione di microservizi ha consentito l'adozione di identità basate sui servizi (come un account di servizio), piuttosto che basate su host (come un indirizzo IP). Passando a un'identità basata sul servizio è possibile modificare la gestione dell'autenticazione e dell'autorizzazione tra i servizi. Ad esempio, se utilizzi un token di identità integrato in un'immagine container per attestare l'identità, le garanzie fornite dalla provenienza del codice non saranno così solide. Se non sei in grado di adottare direttamente un'identità di servizio, come passaggio intermedio potresti provare a proteggere in modo più rigoroso i token di identità.

Determina gli obiettivi e definisci i criteri in base ai requisiti.

Realizza il processo di release basato su criteri un passo alla volta. Potrebbe essere necessario implementare alcune modifiche prima di altre nella pipeline CI/CD. Ad esempio, potrebbe essere necessario avviare revisioni del codice formali prima di poterne richiedere l'applicazione forzata in fase di deployment.

Uno dei motivi principali per l'adozione di un processo di release basato su criteri è la conformità: se è possibile codificare almeno alcuni dei requisiti di conformità in un criterio, questo può facilitare l'automazione dei test e assicurare che siano sempre attivi. Inizia con un set di requisiti di base e codifica man mano i requisiti più avanzati.

Applica i criteri fin dalle prime fasi dello sviluppo.

È difficile definire criteri esaurienti su un software senza prima sapere dove verrà eseguito e a quali dati avrà accesso. Questo è il motivo per cui l'applicazione forzata del criterio BAB viene eseguita durante il deployment del codice e l'accesso ai dati e non in fase di build. Un criterio BAB viene definito in termini di identità di runtime, quindi lo stesso codice può essere eseguito in ambienti diversi ed essere soggetto a criteri differenti.

BAB viene utilizzato in aggiunta ad altri meccanismi di accesso per limitare l'accesso ai dati utente. Utilizzando BAB in questo modo, i proprietari dei servizi possono garantire ulteriormente che ai dati possa accedere solo un job che soddisfi particolari requisiti BAB, di fatto trattando il codice come un'identità.

Determina come eseguire l'onboarding dei proprietari di servizi esistenti.

Identifica un gruppo di proprietari di servizi che riceva vantaggi immediati dall'applicazione e che sia disposto a fornire feedback. Un metodo può essere chiedere ai proprietari di offrirsi come volontari prima di rendere obbligatoria qualsiasi modifica.

Se possibile, richiedi la modalità di applicazione forzata rispetto alla modalità di controllo, oppure imponi un periodo di tolleranza entro cui consentire l'utilizzo della modalità di controllo. La modalità di controllo consente ai proprietari di velocizzare l'onboarding e comprendere meglio i rischi provenienti da personale interno. Lo svantaggio della modalità di controllo è che può richiedere tempo perché si inizi a vedere una riduzione tangibile dei rischi provenienti da personale interno. Questo ritardo può creare delle difficoltà nel mostrare il valore e convincere altri ad adottare l'applicazione forzata. Quando il team BAB ha fornito le procedure di risposta di emergenza per l'applicazione forzata, i proprietari dei servizi si sono mostrati più favorevoli alla sua adozione, perché avevano un'uscita di sicurezza in caso di necessità.

Elenca gli agenti dei cambiamenti nei vari team.

Quando abbiamo reso obbligatorio il deployment di BAB nell'intera organizzazione di Google, ciò che ha favorito maggiormente il nostro successo è stato trovare proprietari disposti a guidare il cambiamento in ciascun gruppo di prodotti. Una volta ottenuto il loro aiuto, abbiamo definito un team ufficiale per la gestione dei cambiamenti per monitorare i cambiamenti in corso. Quindi, abbiamo identificato i proprietari responsabili per ciascun team di prodotto per l'implementazione dei cambiamenti.

Determina come gestire il codice di terze parti.

Molti dei controlli CI/CD descritti in questo white paper vengono eseguiti laddove il codice viene sviluppato, rivisto e mantenuto da una singola organizzazione. Se è questa la tua situazione, considera come includere il codice di terze parti nell'ambito dei requisiti del tuo criterio. Ad esempio, inizialmente potresti prevedere un'esenzione per il codice mentre completi il passaggio a uno stato ideale con un repository di tutto il codice di terze parti in uso, esaminando regolarmente tale codice a fronte dei tuoi requisiti di sicurezza.

Conclusioni

L'implementazione di un controllo con applicazione forzata in fase di deployment come parte dell'infrastruttura containerizzata di Google e del processo CI/CD ci ha permesso di verificare che il codice e la configurazione che implementiamo soddisfino determinati standard minimi per la sicurezza. Si tratta di un controllo cruciale utilizzato per limitare la capacità di personale interno potenzialmente malintenzionato di eseguire job non autorizzati che potrebbero accedere a dati utente. L'adozione di BAB ha consentito a Google di ridurre i rischi provenienti da personale interno, prevenire possibili attacchi e supportare l'uniformità dei nostri sistemi di produzione.

Ulteriori riferimenti

Per ulteriori informazioni sulla sicurezza complessiva di Google e sull'infrastruttura containerizzata, consulta queste risorse:

Note

1 La provenienza (provenance) descrive i componenti, le modifiche apportate ai componenti e la relativa origine. Consulta https://csrc.nist.gov/glossary/term/Provenance.

2 Borgmaster è il controller centralizzato di Borg. Gestisce la programmazione dei job e comunica lo stato dei job in esecuzione.