Autorizzazione binaria per Borg

Questi contenuti sono stati aggiornati l'ultima volta a settembre 2023 e rappresentano lo status quo del momento in cui sono stati redatti. Criteri e sistemi di sicurezza di Google possono variare in futuro, grazie al costante miglioramento della protezione per i nostri clienti.

Questo documento descrive le nostre modalità di utilizzo delle revisioni del codice, dell'infrastruttura di sicurezza e di un controllo dell'applicazione denominato Autorizzazione binaria per Borg (BAB) per proteggere la catena di fornitura del software di Google dai rischi provenienti da personale interno. BAB aiuta 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 a dati sensibili. Dalla pubblicazione originale di questo documento, abbiamo incluso i concetti chiave di BAB in una specifica aperta chiamata Supply chain Levels for Software Artifacts (SLSA).

Questo documento fa parte di una serie di articoli 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 panoramica sulla progettazione della sicurezza dell'infrastruttura di Google.

Introduzione

Rischio interno rappresenta una minaccia alla sicurezza dei dati degli utenti, che può includere dati sull'impiego, dati finanziari o altri dati proprietari o aziendali. I rischi legati agli addetti ai lavori rappresentano la possibilità che un dipendente utilizzi le proprie conoscenze o il proprio accesso all'organizzazione per eseguire azioni dannose oppure che un aggressore esterno utilizzi le credenziali compromesse di un dipendente per fare lo stesso.

Per ridurre al minimo i rischi provenienti da personale interno all'interno della nostra catena di fornitura del software, utilizziamo BAB. BAB è un controllo di applicazione interno che si verifica quando viene eseguito il deployment del software. BAB garantisce che i deployment di codice e configurazione soddisfino determinati standard minimi e supporti 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 aiuta a garantire che i dipendenti, mentre agiscono da soli, non possono accedere, direttamente o indirettamente, ai dati utente o influire in altro modo sui dati utente senza un'autorizzazione e una giustificazione adeguate. BAB e i suoi controlli associati ci aiutano ad applicare privilegio minimo, migliorando così la nostra strategia di sicurezza in modo indipendente da uno specifico aggressore di minacce. In altre parole, BAB impedisce l'accesso unilaterale indipendentemente dal fatto che l'autore abbia intento malevolo, che il suo account sia stato compromesso o che gli sia stato involontariamente concesso l'accesso.

Vantaggi di BAB

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

  • BAB aiuta a ridurre i rischi complessivi provenienti da personale interno: BAB richiede che il codice soddisfi determinati standard e pratiche di gestione dei cambiamenti prima che il codice possa accedere ai dati utente. Questo requisito riduce la possibilità che un dipendente che agisca da solo (o un account dipendente compromesso) acceda ai dati utente in modo programmatico.
  • BAB supporta l'uniformità dei sistemi di produzione: utilizzando sistemi containerizzati e verificando i relativi requisiti BAB prima del deployment, i nostri sistemi diventano più semplici da eseguire il debug, più affidabili e dispongono di processi di gestione dei cambiamenti ben definiti. I requisiti BAB forniscono un linguaggio comune per i requisiti di sistema di produzione.
  • BAB determina un linguaggio comune per la protezione dei dati: BAB monitora la conformità tra i sistemi Google. I dati su questa conformità vengono pubblicati internamente e sono disponibili per altri team. La pubblicazione di dati BAB consente ai team di utilizzare termini comuni nelle comunicazioni tra loro riguardo alla protezione dell'accesso ai dati. Questo linguaggio comune riduce gli andirivieni necessari quando si lavora con i dati tra team.
  • BAB consente il monitoraggio programmatico dei requisiti di conformità: BAB semplifica quelle che in precedenza erano attività di conformità manuali. Determinati processi di Google richiedono controlli più rigidi sulle modalità di 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 aiutava a eseguire manualmente le verifiche per garantire la 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 di conformità di aumentare sia l'ambito dei servizi coperti sia l'adozione di controlli appropriati su questi servizi.

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

Il nostro processo di sviluppo e produzione

Il processo di sviluppo e produzione di Google prevede quattro passaggi obbligatori: revisione del codice, build verificabili, deployment containerizzato e identità basata sui servizi. Le sezioni seguenti descrivono questi passaggi 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 Google semplifica la gestione del codice sorgente, in particolare la gestione delle 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.

Le nostre revisioni del codice includono l'ispezione e l'approvazione di almeno un ingegnere diverso dall'autore. La nostra procedura di revisione del codice richiede come minimo l'approvazione delle modifiche apportate al codice dai proprietari di un sistema. Dopo l'archiviazione, il codice viene creato.

Quando importi modifiche da o da codice open source di terze parti, verifichiamo che la modifica sia appropriata (ad esempio, la versione più recente). Tuttavia, spesso non disponiamo degli 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

Il nostro sistema di compilazione è simile a Bazel, che crea e compila il codice sorgente per creare un programma binario per il deployment. Il nostro sistema di compilazione viene eseguito in un ambiente isolato e bloccato 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 inserite nella build, gli hash di crittografia di qualsiasi codice binario o altri artefatti della build e i parametri completi della build. Questa prova consente di:

  • Possibilità di tracciare un programma binario fino al codice sorgente utilizzato per la sua creazione. Per estensione, la provenienza può anche tracciare il processo di creazione e invio del codice sorgente che descrive.
  • La possibilità di verificare che il programma binario non sia stato modificato in quanto eventuali modifiche al file ne renderebbero automaticamente la firma non valida.

Poiché le azioni di build possono essere codice arbitrario, il nostro sistema di compilazione è stato protetto per la multitenancy. In altre parole, il nostro sistema di compilazione è progettato per impedire che una build ne influenzi altre. Il sistema impedisce alle build di apportare modifiche che potrebbero compromettere l'integrità della provenienza della build o del sistema stesso. Al termine della build, il deployment della modifica viene eseguito utilizzando Borg.

Passaggio 3: deployment containerizzato

Dopo che il sistema di compilazione ha creato il programma binario, il programma viene pacchettizzato in un'immagine container e ne viene eseguito il deployment come job Borg nel nostro sistema di orchestrazione dei cluster, Borg. Eseguiamo centinaia di migliaia di job da molte applicazioni diverse, su più cluster, ciascuno con decine di migliaia di macchine. Nonostante le dimensioni ridotte, 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 notevoli vantaggi in termini di sicurezza. I container sono pensati per essere immutabili, con deployment frequenti da una rigenerazione completa dell'immagine. La containerizzazione ci consente di esaminare le modifiche al codice nel contesto e di fornire un singolo punto di passaggio obbligato per tutte le modifiche di cui viene eseguito il deployment nell'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, prendendo in considerazione i vincoli, la priorità, la quota del job e qualsiasi altro requisito elencato nella configurazione. Dopo il deployment, 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 a datastore o metodi RPC (remote procedure call) di altri servizi. Più job possono essere eseguiti con la stessa identità. Solo i dipendenti responsabili dell'esecuzione del servizio (in genere Site Reliability Engineer (SRE)) possono eseguire il deployment o modificare i job con una determinata identità.

Quando Borg avvia un job, esegue il provisioning delle relative credenziali crittografiche. Il job utilizza queste credenziali per dimostrare la sua identità durante l'esecuzione di richieste di altri servizi utilizzando Application Layer Transport Security (ALTS). Per poter accedere a determinati dati o ad altri servizi, un servizio deve avere le autorizzazioni necessarie.

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

Come funziona BAB

BAB si integra con Borg per garantire che solo i job autorizzati possano essere eseguiti con l'identità di ciascun servizio. BAB crea inoltre 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 di produzione e la configurazione siano correttamente rivisti, archiviati, creati in modo verificabile e autorizzato, in particolare quando il codice può accedere ai dati utente.

Criteri specifici per il servizio

Quando i proprietari del servizio eseguono l'onboarding del servizio in BAB, , creano un criterio che definisce i requisiti di sicurezza del loro servizio. Questa norma è chiamata norma specifica 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 per il servizio definisce il codice e la configurazione autorizzati a essere eseguiti come identità del servizio, nonché le proprietà obbligatorie di quel codice e configurazione. Tutti i job in esecuzione come identità di servizio devono soddisfare il criterio specifico del servizio.

Tutti i servizi Google devono avere norme specifiche per i servizi. I servizi che accedono ai dati sensibili devono avere criteri sufficientemente efficaci, mentre i servizi che non hanno accesso a dati sensibili potrebbero avere un criterio "Consenti tutto" permissivo.

I criteri specifici per i servizi possono applicare i seguenti requisiti:

  • Il codice deve essere controllabile: Possiamo far risalire l'immagine container alle sue origini leggibili dalle persone mediante la provenienza generata da build verificabili. I criteri di conservazione mantengono le origini del codice leggibili per almeno 18 mesi, anche se il codice non viene inviato.
  • Il codice deve essere inviato: Il codice viene creato da una posizione specificata e definita nel nostro repository di codice sorgente. L'invio implica generalmente che il codice sia stato sottoposto a una revisione.
  • Le configurazioni devono essere inviate: Le configurazioni fornite durante il deployment vengono sottoposte allo stesso processo di revisione e invio del codice normale. Pertanto, i valori dei 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 rigorosamente controllati mediante l'applicazione dei requisiti automatici più rigorosi possibili e 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 fase di deployment, che impedisce il deployment dei job non conformi.
  • Convalida continua, che monitora e segnala i job non conformi di cui è stato eseguito il deployment.

Inoltre, in caso di emergenza, le procedure di risposta di emergenza possono bypassare l'applicazione forzata in fase di deployment.

Modalità di applicazione forzata in fase di deployment

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

In rari casi, i servizi possono disattivare l'applicazione forzata in fase di deployment con una giustificazione adeguata.

Modalità di verifica continua

Una volta eseguito il deployment, il job viene verificato continuamente per 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 potenzialmente ancora in esecuzione) siano conformi a eventuali aggiornamenti dei rispettivi 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 utilizzando procedure di risposta di emergenza. Se un job non rispetta i criteri più recenti, BAB invia una notifica ai proprietari del servizio in modo che possano mitigare il rischio.

Procedure di risposta di emergenza

Quando si verifica un incidente o un'interruzione, la nostra prima priorità è ripristinare il servizio interessato il più rapidamente possibile. In una situazione di emergenza, potrebbe essere necessario eseguire codice che non è stato rivisto o creato in modo verificabile. Di conseguenza, la modalità di applicazione forzata può essere ignorata utilizzando un flag di risposta di emergenza. Le procedure di risposta di emergenza fungono anche 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 di emergenza, deve inviare una giustificazione 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 che è stato utilizzato e la giustificazione fornita dall'utente. Pochi secondi dopo, un audit trail viene inviato al team per la sicurezza centralizzata di Google. In poche ore, l'audit trail viene inviato al team proprietario dell'identità del job. Le procedure di risposta di emergenza 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 tradizionale di Google per il controllo del codice sorgente, la build e la pacchettizzazione. Ora, BAB ha aggiunto il supporto per la protezione di altri ambienti di distribuzione e deployment del software, nonché il supporto per sistemi di pacchettizzazione, build e controllo del codice sorgente alternativi. I dettagli di implementazione per questi vari ambienti sono diversi, ma i vantaggi di BAB rimangono.

Alcuni casi non si prestano bene alle revisioni del codice da parte di persone fisiche prima del deployment, in particolare lo sviluppo iterativo di codice per il machine learning e l'analisi dei dati ad alta frequenza. In questi casi, disponiamo di controlli alternativi che compensano la revisione da parte di persone fisiche.

Adozione di controlli simili nella propria organizzazione

Questa sezione descrive le best practice che abbiamo imparato con l'implementazione di BAB per consentirti di adottare controlli simili nella tua organizzazione.

Crea una pipeline CI/CD containerizzata omogenea

L'adozione di BAB è stata semplificata perché la maggior parte dei team utilizzava un unico sistema di controllo del codice sorgente, processo di revisione del codice, sistema di compilazione e sistema di deployment. Le revisioni del codice facevano già parte della nostra cultura, pertanto 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#39;accesso. Questo approccio ha semplificato l'adozione di BAB e ha rafforzato le garanzie che una soluzione come BAB può fornire.

Il nostro ampio uso di microservizi e identità basate sui servizi (come gli account di servizio) anziché di identità basate su host (come gli indirizzi IP) ci permettono di creare un controllo granulare sul software autorizzato a eseguire ciascun 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.

Stabilisci i tuoi obiettivi e definisci i criteri in base ai tuoi 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 iniziare a eseguire revisioni formali del codice prima di poterle applicare in fase di deployment.

Un grande motivo che incentiva un processo di rilascio basato sulle norme è la conformità. Se puoi codificare almeno alcuni requisiti di conformità in un criterio, potrebbe essere utile automatizzare i test e garantire che siano sempre attivi. Inizia con un insieme di requisiti di base e codifica man mano i requisiti più avanzati.

Applica i criteri fin dalle prime fasi di sviluppo

È difficile definire criteri completi su un software senza prima sapere dove verrà eseguito e a quali dati avrà accesso. Pertanto, l'applicazione di criteri specifici per il servizio viene eseguita durante il deployment del codice e quando questo accede ai dati, non quando viene creato. Un criterio viene 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 dei servizi possono inoltre garantire che i dati siano accessibili solo da un job che soddisfa specifici requisiti BAB.

Coinvolgere gli agenti del cambiamento nei vari team

Quando abbiamo creato un mandato per l'intera Google per il deployment di BAB, ciò che ha maggiormente influenzato la nostra percentuale di successo è stato trovare proprietari che guidassero il cambiamento in ciascun gruppo di prodotti. Abbiamo identificato alcuni proprietari di servizi che avevano visto vantaggi immediati dall'applicazione delle norme e che erano disposti a fornire feedback. Abbiamo chiesto loro di offrirsi volontari prima di rendere obbligatorie le modifiche. Abbiamo creato un team formale di gestione dei cambiamenti per monitorare le modifiche in corso. Abbiamo poi identificato i proprietari responsabili di ogni team di prodotto per l'implementazione delle modifiche.

Determinare come gestire il codice di terze parti

Se devi gestire codice di terze parti, valuta come introdurre i requisiti dei criteri al tuo codebase di terze parti. Ad esempio, inizialmente potresti escludere il codice mentre ti sposti verso uno stato ideale di conservazione di un repository di tutto il codice di terze parti utilizzato. Ti consigliamo di controllare regolarmente il codice in base ai tuoi requisiti di sicurezza.

Per scoprire di più sulla gestione del codice di terze parti, consulta Successo condiviso nella creazione di una community open source più sicura.

Passaggi successivi