Autorizzazione binaria per Borg

Questi contenuti sono stati aggiornati a maggio 2024 e rappresentano lo status quo. delle volte in cui è stato scritto. Le norme e i sistemi di sicurezza di Google potrebbero cambiare in futuro, grazie al costante miglioramento della protezione per i nostri clienti.

Questo documento descrive il modo in cui utilizziamo le revisioni del codice, l'infrastruttura di sicurezza e un controllo dell'applicazione chiamato Autorizzazione binaria per Borg (BAB) per proteggere La catena di fornitura del software di Google contro i rischi provenienti da personale interno. BAB contribuisce a ridurre i rischi provenienti da personale interno perché garantisce che il software di produzione venga esaminato e approvato prima di essere implementato, in particolare quando il nostro codice può accedere a dati sensibili. BAB si applica a tutti i servizi in esecuzione su Borg. Dalla pubblicazione originale di questo documento, abbiamo incluso i concetti chiave del BAB in una specifica aperta chiamata Supply-chain Levels for Software Artifacts (SLSA).

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

Introduzione

I rischi provenienti da personale interno rappresentano una minaccia alla sicurezza dei dati utente, che possono includere dati sull'impiego, dati finanziari o altri dati aziendali o proprietari. Il rischio interno è la possibilità che un dipendente utilizzi il proprio le conoscenze organizzative o l'accesso per commettere azioni dannose o per un a usare le credenziali compromesse di un dipendente per fare lo stesso.

Per ridurre al minimo il rischio proveniente da personale interno all'interno della nostra catena di approvvigionamento software, utilizziamo BAB. BAB è un controllo dell'applicazione forzata interno che si verifica quando viene eseguito il deployment del software. BAB garantisce che i deployment di codice e configurazione soddisfino determinate standard minimi e l'uniformità del supporto nei nostri sistemi di produzione.

Contribuiamo a proteggere i dati degli utenti all'interno dei nostri sistemi di produzione limitando accesso dai nostri dipendenti. BAB aiuta a garantire che i dipendenti, agire da solo, non può accedere direttamente o indirettamente ai dati utente o influire in altro modo senza un'autorizzazione e una giustificazione adeguate. Il BAB e i relativi controlli ci aiutano a applicare il privilegio minimo, il che migliora la nostra postura di sicurezza indipendentemente da un attore di minacce specifico. In altre parole, i limiti BAB unilaterale, indipendentemente dal fatto che l'autore dell'attacco abbia intento malevolo, dell'account è stato compromesso oppure all'utente è stato concesso involontariamente 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 legati agli addetti ai lavori: BAB richiede il codice per soddisfare alcuni standard e pratiche di gestione dei cambiamenti prima che il codice accedere ai dati utente. Questo requisito riduce il potenziale agire per conto mio (o con la compromissione dell'account di un dipendente) per impedire l'accesso ai dati utente in modo programmatico.
  • BAB supporta l'uniformità dei sistemi di produzione: utilizzando i sistemi containerizzati e verificandone i requisiti BAB prima del deployment, i nostri sistemi diventano più facili da eseguire il debug, più affidabili e hanno processi di gestione dei cambiamenti ben definiti. 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 sistemi di Google. I dati relativi a questa conformità vengono pubblicati internamente e sono disponibili per altri team. La pubblicazione di dati BAB consente ai team di usare termini comuni quando comunicano tra loro protezione dell'accesso ai dati. Questo linguaggio comune riduce gli andirivieni il lavoro necessario quando si lavora con i dati tra diversi team.
  • BAB consente il monitoraggio programmatico dei requisiti di conformità: BAB semplifica 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 i report 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'introduzione di BAB, molti di questi controlli sono stati automatizzati in base ai criteri BAB per i 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 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

Per impostazione predefinita, il processo di sviluppo e produzione di Google include quattro passaggi: revisione del codice, build verificabili, deployment containerizzato e e l'identità basata sui servizi. Le seguenti sezioni descrivono questi passaggi in maggiore dettaglio dettaglio.

Passaggio 1: revisione del codice

La maggior parte del nostro codice sorgente è archiviata in un repository monolitico centrale, e richiede la revisione e l'approvazione da parte di almeno un altro ingegnere oltre all'autore. Un modello monolitico il codebase consente l'applicazione forzata di un singolo punto di passaggio per il codice recensioni.

Come minimo, il nostro processo di revisione del codice richiede i proprietari di un sistema devono approvare le modifiche al codice di tale sistema.

Quando importi modifiche da codice open source o di terze parti, verifichiamo che la modifica sia appropriata (ad es. l'ultima versione). Tuttavia, spesso non disponiamo degli stessi controlli per le revisioni. per ogni modifica apportata da sviluppatori esterni a sistemi di terze parti o open source il codice 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 build viene eseguito in un ambiente isolato e bloccato separato dai dipendenti che eseguono le build. Per ogni build, il sistema genera la provenienza generata dalle build verificabili . La provenienza è un certificato firmato che descrive le origini e le dipendenze inserite nella build, gli hash di crittografia binari o altri artefatti della build e i parametri di build completi. Questa provenienza consente quanto segue:

  • La possibilità di risalire da un programma binario al codice sorgente utilizzato per crearlo. Per estensione, la provenienza può anche tracciare il processo intorno alla creazione e invio del codice sorgente che descrive.
  • La possibilità di verificare che il file binario non sia stato modificato mentre automaticamente la firma del file.

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

Passaggio 3: deployment in contenitori

Dopo che il sistema di compilazione ha creato il file binario, questo viene pacchettizzato in un'immagine container e di cui è stato eseguito il deployment come job Borg sul nostro sistema di orchestrazione dei cluster, Borg. Eseguiamo centinaia di migliaia di job 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.

I container offrono notevoli vantaggi in termini di sicurezza. I container sono pensati per immutabile, con frequenti rideployment da una ricreazione completa di un'immagine. La containerizzazione ci consente di esaminare le modifiche apportate al codice nel contesto e fornisce per 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 programma il job tenendo conto dei vincoli, della priorità, della quota e di qualsiasi altro requisito elencato nella configurazione. Dopo il deployment del job, il job Borg può interagire con altri job in produzione.

Passaggio 4: identità basata sui servizi

Un job Borg viene eseguito come identità di servizio. Questa identità viene utilizzata per accedere a datastore o procedura remota. di chiamata (RPC) di altri servizi. Più job potrebbero essere eseguiti con la stessa identità. Solo i dipendenti responsabile dell'esecuzione del servizio (in genere SRE (Site Reliability Engineer)) eseguire il deployment o modificare i job con una particolare identità.

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

I nostri criteri richiedono la protezione BAB per le identità di servizio che hanno accesso ai dati utente e a qualsiasi altra informazione sensibile. 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 anche un audit trail del codice e della configurazione utilizzati nei job abilitati per BAB per consentire per il monitoraggio e la risposta agli incidenti.

BAB è progettato per garantire che tutta la configurazione e il software di produzione vengano esaminati, sottoposti a check-in, compilati in modo verificabile e autorizzati, in particolare quando il codice può accedere ai dati utente.

Criteri specifici per il servizio

Quando i proprietari dei servizi eseguono l'onboarding del loro servizio in Borg, creano un criterio BAB che definisce i requisiti di sicurezza per il loro servizio. Queste norme sono chiamate norme specifiche per il servizio. Definizione o modifica in corso un criterio è di per sé una modifica al codice che deve essere sottoposta a revisione.

Il criterio specifico del servizio definisce il codice e la configurazione che possono essere eseguiti come identità del servizio, nonché le proprietà richieste di questo codice e di questa configurazione. Tutti i job in esecuzione come identità di servizio devono soddisfare il criterio specifico del servizio.

Tutti i servizi Borg di Google devono configurare un criterio specifico per il servizio.

Per impostazione predefinita, questa pratica applica i seguenti requisiti:

  • Il codice deve essere verificabile: Possiamo risalire all'immagine del contenitore alle sue origini leggibili da persone tramite la provenienza generata dalle build verificabili. Un piano di conservazione mantiene le sorgenti leggibili del codice per almeno 18 mesi, anche se il codice non viene inviato.
  • Il codice deve essere inviato: Il codice viene compilato da una posizione specificata e definita nel nostro repository di codice sorgente. L'invio generalmente implica che il codice sia stato sottoposto a una revisione.
  • Le configurazioni devono essere inviate: Qualsiasi configurazione fornita durante il deployment tramite la stessa procedura di revisione e invio del codice normale. Pertanto, i valori, gli argomenti e i parametri del flag della riga di comando non possono essere modificati senza revisione.

I servizi che non hanno accesso a dati sensibili o, in rare circostanze, i servizi che dispongono di un'eccezione valida e approvata, potrebbero avere norme più permissive, ad esempio quelle che richiedono solo la verificabilità del codice o addirittura disattivano completamente il BAB.

I sistemi e i componenti che applicano BAB sono strettamente controllati utilizzando requisiti automatici e controlli manuali aggiuntivi.

Modalità di applicazione

BAB utilizza due modalità di applicazione per garantire che i job rispettino norme specifiche per i servizi:

  • Applicazione forzata al momento del deployment, che impedisce il deployment dei job non conformi.
  • Convalida continua, che monitora e genera avvisi sui job non conformi che sono stati dipiamente.

Inoltre, in caso di emergenza, le procedure di risposta possono bypassare in fase di deployment.

Modalità di applicazione forzata in fase di deployment

Borg Prime è il controller centralizzato di Borg, che funge da certificato l'autorità competente per ALTS. Quando viene inviato un nuovo job, Borg Prime consulta BAB per verificare che il job soddisfi i requisiti dei criteri specifici del servizio prima di concedere il certificato ALTS al job. Questo controllo funge da ammissione controller: Borg avvia il job solo se soddisfa le specifiche . Questo controllo si verifica anche quando il dipendente o il servizio che esegue il deployment richiesta è altrimenti autorizzata.

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

Modalità di verifica continua

Dopo 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 agli eventuali aggiornamenti dei rispettivi criteri. Ad esempio, la modalità di verifica continua ricerca costantemente job in esecuzione con criteri obsoleti o che sono stati implementati utilizzando procedure di risposta di emergenza. Se viene rilevato un job che non è conforme alle norme più recenti, BAB invia una notifica ai proprietari del servizio in modo che possano mitigare il rischio.

Procedure di risposta di emergenza

In caso di incidente o guasto, la nostra prima priorità è ripristinare il più rapidamente possibile. In una situazione di emergenza, necessarie per 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. Anche le procedure di risposta di emergenza fungono da backup nel caso si verifica un errore di BAB che altrimenti bloccherebbe un deployment. Quando se uno sviluppatore esegue il deployment di un job utilizzando la procedura di risposta di emergenza, deve inviare una giustificazione nell'ambito della richiesta.

Durante una risposta di emergenza, BAB registra i dettagli del job Borg associato e invia una notifica a entrambi i team di sicurezza centralizzata di Google e il team proprietario dell'identità del servizio. The la voce di log include un riferimento a uno snapshot del codice di cui è stato eseguito il deployment e la giustificazione fornita dall'utente. Le procedure di risposta di emergenza devono essere utilizzate solo come ultima possibilità.

Estensione di BAB ad altri ambienti

Inizialmente, BAB supportava solo la protezione dei job Borg e richiedeva il software per lo sviluppo mediante i tradizionali controlli del codice sorgente, creazione e pacchettizzazione di Google una pipeline o un blocco note personalizzato. BAB ha aggiunto ora il supporto per la protezione della distribuzione di altri software ambienti di deployment e supporto per il controllo dell'origine, la creazione e sistemi di imballaggio dei dati. I dettagli di implementazione di questi vari ambienti differiscono, ma i vantaggi del BAB rimangono invariati.

Alcuni casi non si prestano bene alle revisioni del codice da parte di persone fisiche prima del deployment, in particolare lo sviluppo iterativo del codice l'analisi di 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 appreso con l'implementazione di BAB in modo da poter adottare controlli simili nella tua organizzazione.

Crea una pipeline CI/CD containerizzata e omogenea

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

Il nostro uso diffuso di microservizi e identità basate su servizi (come gli account di servizio), anziché di identità basate su host (come gli indirizzi IP), ci consente di creare un controllo granulare sul software a cui è consentito eseguire ciascun servizio.

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

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. Per Ad esempio, potrebbe essere necessario iniziare a condurre revisioni formali del codice prima di poter in modo da applicarle in modo forzato al momento del deployment.

Un ottimo motivo per un processo di rilascio guidato dalle norme è la conformità. Se puoi codificare almeno alcuni dei tuoi requisiti di conformità in un criterio, automatizzare i test e assicurarsi che siano efficaci. Inizia con una base un insieme di requisiti e di codificare man mano che requisiti più avanzati.

Applica i criteri fin dalle prime fasi dello sviluppo

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

BAB viene utilizzato in aggiunta ad altri meccanismi di accesso per limitare l'accesso ai dati utente. I proprietari dei servizi possono garantire ulteriormente che ai dati possa accedere solo un job che soddisfi particolari requisiti BAB.

Elenca gli agenti dei cambiamenti nei vari team

Quando abbiamo creato un mandato a livello Google per il deployment di BAB, ciò che ha influito maggiormente sul nostro tasso di successo è stato trovare proprietari per promuovere il cambiamento in ciascun gruppo di prodotti. Abbiamo identificato un proprietari di servizi che hanno riscontrato vantaggi immediati dall'applicazione delle norme disponibili a fornire feedback. Abbiamo chiesto a questi proprietari di fare volontariato prima di e non è obbligatorio apportare modifiche. Dopo aver ricevuto il loro aiuto, abbiamo istituito un cambiamento formale il team di gestione di Google Cloud per tenere traccia delle modifiche in corso. Quindi, abbiamo identificato i proprietari responsabili in ogni team di prodotto per l'implementazione delle modifiche.

Determinare come gestire il codice di terze parti

Se devi gestire il codice di terze parti, valuta come introdurre i requisiti previsti dalle norme nella base di codice di terze parti. Ad esempio, inizialmente potresti iniziare mantenendo un repository di tutto il codice di terze parti utilizzato. Ti consigliamo di controllare regolarmente il codice rispetto ai tuoi requisiti di sicurezza.

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

Passaggi successivi