Autorizzazione binaria per Borg

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 luglio 2022 e rappresentano lo status quo del momento in cui sono stati scritti. Le norme e i sistemi di sicurezza di Google possono cambiare in futuro, in quanto miglioriamo costantemente la protezione per i nostri clienti.

Questo documento descrive in che modo utilizziamo le revisioni del codice, l'infrastruttura di sicurezza e un controllo di applicazione chiamato Autorizzazione binaria per Borg (BAB) per proteggere la catena di fornitura del software di Google dal rischio interno. BAB contribuisce a ridurre i rischi provenienti da personale interno perché garantisce che il software di produzione venga esaminato e approvato prima del deployment, in particolare quando il nostro codice può accedere ai dati sensibili. Dalla pubblicazione originale di questo documento, abbiamo incluso i concetti chiave di BAB in una specifica aperta denominata Supply Chain Levels for Software Artifacts (SLSA).

Questo documento fa parte di una serie di documenti tecnici che descrivono alcuni progetti sviluppati dal team di sicurezza di Google per migliorare la sicurezza, tra cui BeyondCorp e BeyondProd. Per una panoramica della sicurezza della nostra infrastruttura, consulta la pagina Panoramica sulla progettazione della sicurezza dell'infrastruttura Google.

Introduzione

Il rischio interno rappresenta una minaccia per la sicurezza dei dati utente, che possono includere dati sull'impiego, dati finanziari o altri dati proprietari o aziendali. Il rischio di rischio è la possibilità per un dipendente di utilizzare le proprie conoscenze o accesso dell'organizzazione per eseguire atti dannosi o di consentire a un utente esterno di utilizzare le credenziali compromesse di un dipendente per fare lo stesso.

Per ridurre al minimo i rischi provenienti da personale interno nella nostra catena di fornitura del software, utilizziamo BAB. BAB è un controllo di applicazione interna che si verifica quando viene eseguito il deployment del software. BAB garantisce che i deployment di codice e configurazione soddisfino determinati standard minimi e supportino l'uniformità nei nostri sistemi di produzione.

Contribuiamo a proteggere i dati utente all'interno dei nostri sistemi di produzione impedendo l'accesso unilaterale da parte dei nostri dipendenti. BAB contribuisce a garantire che i dipendenti, mentre agiscono da soli, non possano accedere direttamente o indirettamente o influire in altro modo sui dati utente senza un'autorizzazione e una giustificazione adeguate. BAB e i controlli associati ci aiutano a imporre il privilegio minimo, che migliora la nostra strategia di sicurezza indipendentemente da uno specifico attore della minaccia. In altre parole, BAB impedisce l'accesso unidirezionale, indipendentemente dal fatto che l'attore abbia un intento dannoso, che il suo account sia stato compromesso o che l'accesso sia stato concesso involontariamente.

Vantaggi di BAB

L'adozione di BAB e di un modello di deployment containerizzato offre molti vantaggi in termini di sicurezza all'infrastruttura di Google. I vantaggi includono:

  • BAB aiuta a ridurre il rischio interno per gli addetti ai lavori: BAB richiede che il codice soddisfi determinati standard e modifichi le pratiche di gestione delle modifiche prima che il codice possa accedere ai dati utente. Questo requisito riduce la possibilità che un dipendente che agisce da solo (o un account dipendente compromesso) non possa accedere ai dati utente in modo programmatico.
  • BAB supporta l'uniformità dei sistemi di produzione: utilizzando sistemi containerizzati e verificando i requisiti BAB prima del deployment, i nostri sistemi diventano più facili da eseguire per il debug, più affidabili e dispongono di processi di gestione dei cambiamenti ben definiti. I requisiti BAB forniscono un linguaggio comune per i requisiti del sistema di produzione.
  • BAB definisce un linguaggio comune per la protezione dei dati: BAB monitora la conformità nei sistemi Google. I dati su questa conformità sono pubblicati internamente e sono disponibili per altri team. La pubblicazione di dati BAB consente ai team di utilizzare termini comuni quando comunicano tra loro la protezione dell'accesso ai dati. Questo linguaggio comune riduce il lavoro avanti e indietro necessario quando si lavora con i dati tra team.
  • BAB consente il monitoraggio programmatico dei requisiti di conformità: BAB semplifica le attività che prima erano manuali di conformità. Alcuni processi di Google richiedono controlli più rigorosi sul modo in cui gestiamo i dati. Ad esempio, i nostri sistemi di reporting finanziario devono rispettare il Sarbanes-Oxley Act (SOX). Prima di BAB, avevamo un sistema che ci aiutava a eseguire manualmente le verifiche per garantire la nostra conformità. Con l'introduzione di BAB, molti di questi controlli sono stati automatizzati in base ai criteri BAB per i servizi. L'automazione di questi controlli ha consentito al team per la conformità di aumentare sia l'ambito dei servizi coperti, sia l'adozione di controlli appropriati su questi servizi.

BAB fa parte del più ampio framework BeyondProd che utilizziamo per ridurre i rischi provenienti da personale interno.

Il nostro processo di sviluppo e produzione

Il processo di sviluppo e produzione di Google include quattro passaggi obbligatori: revisione del codice, build verificabili, deployment containerizzato e identità basata sui servizi. I passaggi seguenti sono descritti in modo più dettagliato.

Passaggio 1: revisione del codice

La maggior parte del nostro codice sorgente è archiviata in un repository monolitico centrale,, che consente a migliaia di dipendenti di controllare il codice in un'unica posizione. Il codebase di Google semplifica la gestione del codice sorgente, in particolare la gestione delle nostre dipendenze dal codice di terze parti. Un codebase monolitico consente inoltre l'applicazione forzata di un singolo punto di passaggio obbligato per le revisioni del codice.

Le nostre recensioni di codice includono il controllo e l'approvazione di almeno un altro ingegnere oltre all'autore. Come minimo, la nostra procedura di revisione del codice richiede che i proprietari di un sistema debbano approvare le modifiche al codice di tale sistema. Dopo aver fatto il check-in, il codice viene creato.

Quando importi modifiche da terze parti o da codice open source, verifichiamo che la modifica sia appropriata (ad es. la versione più recente). Tuttavia, spesso non applichiamo gli stessi controlli alle recensioni per ogni modifica apportata da sviluppatori esterni al codice open source o di terze parti utilizzato.

Passaggio 2: build verificabili

Il nostro sistema di compilazione è simile a Bazelper creare un codice binario Il nostro sistema di compilazione viene eseguito in un ambiente isolato e bloccato che è separato dai dipendenti che eseguono le build. Per ogni build, il sistema produce la provenienza generata da build verificabili . Questa provenienza è un certificato firmato che descrive le origini e le dipendenze della build, gli hash crittografici di qualsiasi programma binario o altri artefatti della build e i parametri completi della build. Questa prova consente di:

  • La capacità di tracciare un programma binario nel codice sorgente utilizzato nella sua creazione. Per estensione, la provenienza può anche tracciare il processo intorno alla creazione e all'invio del codice sorgente che descrive.
  • La capacità di verificare che il programma binario non è stato modificato come qualsiasi modifica al file invaliderà automaticamente la sua firma.

Poiché le azioni di compilazione possono essere codice arbitrario, il nostro sistema di compilazione è stato protetto per l'architettura multi-tenancy. In altre parole, il nostro sistema di build è progettato per evitare che una build influenzi le altre build. Il sistema impedisce che le build apportino modifiche che potrebbero compromettere l'integrità della provenienza della build o del sistema stesso. Una volta completata la build, il deployment della modifica viene eseguito utilizzando Borg.

Passaggio 3: deployment containerizzato

Dopo che il sistema di compilazione ha creato il programma binario, viene pacchettizzato in un'immagine container ed è stato eseguito il deployment come job di Borg sul nostro sistema di orchestrazione cluster, Borg. Eseguiamo centinaia di migliaia di job di molte applicazioni diverse, in più cluster, ognuno con decine di migliaia di macchine. Nonostante questa scala, il nostro ambiente di produzione è abbastanza omogeneo. Di conseguenza, i touchpoint per l'accesso ai dati utente possono essere controllati e controllati più facilmente.

I container offrono importanti vantaggi per la sicurezza. I container sono pensati per essere immutabili, con frequenti deployment da una ricreazione completa dell'immagine. La containerizzazione ci consente di esaminare una modifica al codice nel contesto e fornisce un singolo punto di passaggio obbligato per tutte le modifiche di cui viene eseguito il deployment nella nostra infrastruttura.

La configurazione di un job Borg specifica i requisiti del job di cui eseguire il deployment: immagini container, parametri di runtime, argomenti e flag. Borg pianifica il job, tenendo in considerazione i vincoli, la priorità, la quota e qualsiasi altro requisito del job elencato nella configurazione. Dopo il deployment del job, il job Borg può interagire con altri job in produzione.

Passaggio 4: identità basata sul servizio

Un job Borg viene eseguito come identità di servizio. Questa identità viene utilizzata per accedere ai datastore o ai metodi di chiamata di procedura remota (RPC) di altri servizi. Più job potrebbero essere eseguiti con la stessa identità. Solo i dipendenti che sono responsabili della gestione del servizio (in genere i Site Reliability Engineer (SRE)) possono eseguire il deployment o modificare i job con una specifica identità.

Quando Borg avvia un job, esegue il provisioning delle relative credenziali crittografiche. Il job utilizza queste credenziali per dimostrare la propria identità quando effettua richieste di altri servizi utilizzando ALTS (Application Layer Transport Security). Affinché un servizio possa accedere a determinati dati o a un altro servizio, deve disporre delle autorizzazioni necessarie per accedere a un servizio.

I nostri criteri richiedono la protezione BAB per le identità dei servizi che hanno accesso ai dati utente e a qualsiasi altra informazione sensibile. I job di controllo qualità e di sviluppo che non hanno accesso a dati sensibili possono essere eseguiti con meno controlli.

Come funziona BAB

BAB si integra con Borg per garantire che possano essere eseguiti solo i job autorizzati con l'identità di ciascun servizio. BAB crea anche un audit trail del codice e della configurazione utilizzati nei job abilitati per BAB per consentire il monitoraggio e la risposta agli incidenti.

BAB è progettato per garantire che tutto il software e la configurazione di produzione vengano esaminati, verificati, creati e autorizzati in modo adeguato, in particolare quando il codice può accedere ai dati utente.

Criteri specifici per il servizio

Quando i proprietari di servizi inseriscono il servizio in BAB, creano un criterio che definisce i requisiti di sicurezza per il loro servizio. Questo criterio è chiamato criterio specifico per il servizio. La definizione o la modifica di un criterio è a sua volta una modifica del codice che deve essere sottoposta a revisione.

Il criterio specifico del servizio definisce quale codice e configurazione è possibile eseguire come identità del servizio, nonché le proprietà richieste per tale codice e configurazione. Tutti i job in esecuzione con l'identità del servizio devono soddisfare il criterio specifico del servizio.

Tutti i servizi di Google devono avere norme specifiche per i servizi. I servizi che accedono a dati sensibili devono disporre di criteri sufficientemente efficaci, mentre i servizi senza accesso a dati sensibili potrebbero disporre di criteri "consenti qualsiasi" permissivi.

I criteri specifici del servizio possono applicare i seguenti requisiti:

  • Il codice deve essere verificabile: Riusciamo a far risalire l'immagine container alle sue origini leggibili da umani tramite una provenienza generata da build verificabili. Un criterio di conservazione conserva le origini leggibili del codice per almeno 18 mesi, anche se il codice non viene inviato.
  • Il codice deve essere inviato: Il codice viene creato a partire da una posizione definita specificata nel nostro repository di codice sorgente. In generale, l'invio implica che il codice sia stato sottoposto a una revisione.
  • Le configurazioni devono essere inviate: Qualsiasi configurazione fornita durante il deployment viene sottoposta alla stessa procedura di revisione e invio del codice normale. Pertanto, 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 sono strettamente controllati utilizzando i requisiti automatici più restrittivi e i controlli manuali aggiuntivi.

Modalità di applicazione

BAB utilizza due modalità di applicazione per garantire che tutti i job siano conformi al criterio specifico del servizio:

  • Applicazione in tempo del deployment, che impedisce il deployment dei job non conformi.
  • Convalida continua, che monitora e crea avvisi su job non conformi di cui è stato eseguito il deployment.

Inoltre, in caso di emergenza, le procedure di risposta alle emergenze possono ignorare l'applicazione al momento del deployment.

Modalità di applicazione forzata in fase di deployment

Borg Prime è il controller centralizzato di Borg, che funge da autorità di certificazione per Dialogflow. Quando viene inviato un nuovo job, Borg Prime consulta BAB per verificare che il job soddisfi i requisiti dei criteri specifici del servizio prima che Borg Prime conceda il certificato Dialogflow al job. Questo controllo funge da controller di ammissione: Borg avvia il job solo se soddisfa il criterio specifico del servizio. Questo controllo viene eseguito anche quando il dipendente o il servizio che effettua la richiesta di deployment è autorizzato in altro modo.

In rari casi, i servizi possono disattivare l'applicazione al momento del deployment con una giustificazione adeguata.

Modalità di verifica continua

Dopo il deployment, un job viene continuamente verificato per tutta la sua durata, indipendentemente dalla modalità di applicazione forzata al momento del deployment. Un processo BAB viene eseguito almeno una volta al giorno per verificare che i job avviati (e che siano ancora in esecuzione) corrispondano a qualsiasi aggiornamento dei loro criteri. Ad esempio, la modalità di verifica continua verifica costantemente la presenza di job in esecuzione con criteri obsoleti o di cui è stato eseguito il deployment mediante procedure di risposta di emergenza. Se viene riscontrato un job che non rispetta il criterio più recente, BAB invia una notifica ai proprietari del servizio in modo che possano ridurre il rischio.

Procedure di risposta di emergenza

Quando si verifica un incidente o un'interruzione, la nostra prima priorità è ripristinare il servizio interessato il prima possibile. In una situazione di emergenza, potrebbe essere necessario eseguire codice che non è stato esaminato o creato in modo verificabile. Di conseguenza, la modalità di applicazione forzata può essere sostituita utilizzando un flag di risposta di emergenza. Anche le procedure di risposta di emergenza fungono da backup in caso di errore di BAB che altrimenti bloccherebbe un deployment. Quando uno sviluppatore esegue il deployment di un job utilizzando la procedura di risposta alle emergenze, deve inviare una motivazione nell'ambito della propria richiesta.

Entro pochi secondi dall'utilizzo della procedura di risposta alle emergenze, BAB registra i dettagli sul job Borg associato. Il log include il codice utilizzato e la motivazione fornita dall'utente. Alcuni secondi dopo, un audit trail viene inviato al team di sicurezza centralizzato di Google. Entro poche ore, l'audit trail viene inviato al team che possiede l'identità dell'offerta di lavoro. Le procedure di risposta alle emergenze devono essere utilizzate solo come ultima risorsa.

Estensione di BAB ad altri ambienti

Inizialmente, BAB supportava solo la protezione dei job Borg e richiedeva lo sviluppo del software utilizzando la pipeline di controllo, build e pacchettizzazione tradizionale di Google. Ora BAB ha aggiunto il supporto per la protezione di altri ambienti di distribuzione e deployment del software e il supporto per sistemi di controllo, creazione e pacchettizzazione del codice sorgente alternativi. I dettagli di implementazione per questi diversi ambienti sono diversi, ma i vantaggi di BAB rimangono.

Ci sono alcuni casi in cui non si prestano bene alle revisioni del codice umano prima del deployment, in particolare allo sviluppo iterativo del codice di machine learning e all'analisi dei dati ad alta frequenza. In questi casi, disponiamo di controlli alternativi che compensano le revisioni da parte di persone fisiche.

Adozione di controlli simili nella propria organizzazione

Questa sezione descrive le best practice apprese dall'implementazione di BAB, in modo da poter adottare controlli simili nella tua organizzazione.

Creare una pipeline CI/CD omogenea e containerizzata

L'adozione di BAB è stata semplificata perché la maggior parte dei team utilizzava un unico sistema di controllo di origine, un processo di revisione del codice, un sistema di compilazione e un sistema di deployment. Le revisioni del codice facevano già parte della nostra cultura, quindi siamo riusciti ad apportare modifiche senza troppe modifiche significative visibili agli utenti. Per adottare BAB, ci siamo concentrati su revisioni del codice, build verificabili, deployment containerizzati e identità basate sui servizi per il controllo dell'accesso. Questo approccio ha semplificato l'adozione di BAB e ha rafforzato le garanzie che una soluzione come BAB può fornire.

Il nostro ampio utilizzo di microservizi e identità basate sui servizi (come gli account di servizio), anziché le identità basate su host (come gli indirizzi IP), ci consente di creare un controllo granulare sul software autorizzato a eseguire ogni servizio.

Se la tua organizzazione non è in grado di adottare direttamente un'identità di servizio, puoi provare a proteggere i token di identità utilizzando altre misure come passaggio temporaneo.

Determina i tuoi obiettivi e definisci i criteri in base ai tuoi requisiti

Realizza il processo di release basato su criteri un passo alla volta. Potresti dover implementare alcune modifiche prima di altre nella pipeline CI/CD. Ad esempio, potrebbe essere necessario iniziare a eseguire revisioni formali del codice prima di applicarle al momento del deployment.

Uno dei motivi principali per l'adozione di un processo di rilascio basato su criteri è la conformità. Se riesci a codificare almeno alcuni dei tuoi requisiti di conformità in un criterio, questo può aiutarti ad automatizzare i test e assicurarti che siano sempre attivi. Inizia con un set di requisiti di base e codifica man mano i requisiti più avanzati.

Applicazione forzata dei criteri all'inizio dello sviluppo

È difficile definire criteri completi per un software senza prima sapere dove verrà eseguito e a quali dati avrà accesso. Pertanto, l'applicazione dei criteri specifici del servizio viene eseguita quando viene eseguito il deployment del codice e quando accede ai dati, non quando viene creato. Un criterio è definito in termini di identità di runtime, quindi lo stesso codice potrebbe essere eseguito in ambienti diversi ed essere soggetto a criteri diversi.

BAB viene utilizzato in aggiunta ad altri meccanismi di accesso per limitare l'accesso ai dati utente. I proprietari di servizi possono inoltre garantire che i dati siano accessibili solo da un job che soddisfa requisiti di BAB specifici.

Coinvolgi gli agenti di modifica nei vari team

Quando abbiamo creato un mandato Google per il deployment BAB, ciò che ha influito maggiormente sulla nostra percentuale di successo è stato trovare proprietari per guidare la modifica in ogni gruppo di prodotti. Abbiamo identificato alcuni proprietari di servizi che hanno beneficiato immediatamente dell'applicazione e sono stati disposti a fornire un feedback. Abbiamo chiesto a questi proprietari di fare volontariato prima di rendere obbligatoria qualsiasi modifica. Dopo aver ottenuto l'aiuto, abbiamo creato un team formale per la gestione dei cambiamenti per monitorare le modifiche in corso. Abbiamo quindi identificato i proprietari responsabili di ogni team di prodotto per implementare le modifiche.

Stabilire come gestire il codice di terze parti

Se devi gestire il codice di terze parti, valuta come introdurre i requisiti delle norme nel codebase di terze parti. Ad esempio, inizialmente potresti esentare il codice mentre ti sposti verso uno stato ideale in cui conservare un repository di tutto il codice di terze parti utilizzato. Ti consigliamo di controllare regolarmente tale codice in base ai tuoi requisiti di sicurezza.

Per ulteriori informazioni sulla gestione del codice di terze parti, consulta Creazione di una community più open source più sicura.

Passaggi successivi