Autorizzazione binaria per Borg

Questi contenuti sono stati aggiornati per l'ultima volta a settembre 2026 e rappresentano lo status quo al momento della redazione. I criteri e i sistemi di sicurezza di Google potranno variare in futuro, in virtù del costante miglioramento della protezione per i nostri clienti.

Questo documento descrive come utilizziamo le revisioni del codice, l'infrastruttura di sicurezza e un controllo di applicazione chiamato Autorizzazione binaria per Borg (BAB) per contribuire a proteggere la catena di fornitura del software di Google dai rischi provenienti da addetti ai lavori. Autorizzazione binaria contribuisce a ridurre il rischio 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. BAB si applica a tutti i servizi in esecuzione nei deployment dei servizi Borg. 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 documenti tecnici che descrivono alcuni progetti sviluppati dal team di sicurezza di Google per contribuire a migliorare la sicurezza, incluso BeyondProd. Per una panoramica della sicurezza dell'infrastruttura di Google, consulta la panoramica sulla progettazione della sicurezza dell'infrastruttura Google.

Rischio interno

Il rischio interno rappresenta una minaccia alla sicurezza dei dati degli utenti, che possono includere dati occupazionali, finanziari o altri dati proprietari o aziendali. Il rischio interno è la possibilità che un dipendente utilizzi le proprie conoscenze dell'organizzazione o il proprio accesso per compiere atti illeciti 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 nella nostra catena di fornitura software, utilizziamo BAB. BAB è un controllo interno dell'applicazione che viene eseguito durante la distribuzione 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 limitando l'accesso unilaterale da parte dei nostri dipendenti. BAB contribuisce a garantire che i dipendenti, pur agendo da soli, non possano accedere direttamente o indirettamente ai dati utente o influire su di essi senza un'autorizzazione e una giustificazione adeguate. BAB e i relativi controlli ci aiutano a applicare il principio del privilegio minimo, il che migliora la nostra postura di sicurezza indipendentemente da un attore delle minacce specifico. In altre parole, BAB limita l'accesso unilaterale indipendentemente dal fatto che l'attore abbia intenti dannosi, che il suo account sia stato compromesso o che gli sia stato concesso l'accesso involontariamente.

Vantaggi di Autorizzazione binaria per Borg

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

  • BAB contribuisce a ridurre il rischio interno complessivo:BAB richiede che il codice soddisfi determinati standard e pratiche di gestione delle modifiche prima che possa accedere ai dati utente. Questo requisito riduce la possibilità che un dipendente che agisce da solo (o un account dipendente compromesso) acceda ai dati utente in modo programmatico.
  • BAB supporta l'uniformità dei sistemi di produzione:l'utilizzo di sistemi in container e la verifica dei relativi requisiti BAB prima del deployment contribuiscono a garantire che i nostri sistemi siano più facili da eseguire il debug, più affidabili e includano processi di gestione delle modifiche ben definiti. I requisiti BAB forniscono un linguaggio comune per i requisiti di sistema di produzione.
  • BAB impone un linguaggio comune per la protezione dei dati:BAB monitora la conformità nei sistemi Google. I dati relativi a questa conformità vengono pubblicati internamente e sono disponibili per altri team. La pubblicazione dei dati BAB consente ai team di utilizzare termini comuni quando comunicano tra loro in merito alla protezione dell'accesso ai dati. Questo linguaggio comune riduce il lavoro iterativo necessario quando si lavora con i dati tra i team.
  • BAB consente il monitoraggio programmatico dei requisiti di conformità: BAB semplifica le attività di conformità precedentemente manuali. Alcuni processi di Google richiedono controlli più rigorosi sulla gestione dei dati. Ad esempio, i nostri sistemi di report finanziari devono essere conformi al Sarbanes-Oxley Act (SOX). Prima di BAB, avevamo un sistema che ci aiutava a eseguire manualmente le verifiche per garantire la conformità. Con l'introduzione di BAB, molti di questi controlli sono stati automatizzati in base alle norme 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 BeyondProd più ampio che utilizziamo per mitigare il rischio interno.

Processo di sviluppo e produzione di Google

Per impostazione predefinita, il processo di sviluppo e produzione di Google include quattro passaggi obbligatori: revisione del codice, build verificabili, deployment in container 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 è memorizzata in un repository monolitico centrale, e richiede la revisione e l'approvazione di almeno un ingegnere diverso dall'autore. Un codebase monolitico consente l'applicazione di un unico punto di controllo per le revisioni del codice.

Come minimo, la nostra procedura di revisione del codice richiede che i proprietari di un sistema approvino le modifiche al codice di quel sistema.

Quando importiamo modifiche da codice open source o di terze parti , verifichiamo che la modifica sia appropriata (ad esempio, l'ultima versione). Tuttavia, spesso non disponiamo degli stessi controlli di revisione per ogni modifica apportata da sviluppatori esterni al codice open source o di terze parti che utilizziamo.

Passaggio 2: build verificabili

Il nostro sistema di compilazione è simile a Bazel, che crea e compila il codice sorgente per creare un file binario per il deployment. Il nostro sistema di compilazione viene eseguito in un ambiente isolato e protetto separato dai dipendenti che eseguono le build. Per ogni build, il sistema produce una provenienza generata da build verificabili . Questa provenienza è un certificato firmato che descrive le origini e le dipendenze che hanno contribuito alla build, gli hash crittografici di eventuali file binari o altri artefatti di build e i parametri di build completi. Questa provenienza consente quanto segue:

  • La possibilità di tracciare un 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 binario non sia stato modificato, poiché qualsiasi modifica al file invaliderebbe automaticamente la sua firma.

Poiché le azioni di build possono essere codice arbitrario, il nostro sistema di compilazione è stato rafforzato per il multi-tenancy. In altre parole, il nostro sistema di compilazione è progettato per impedire che una build influenzi altre build. 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, la modifica viene implementata utilizzando Borg.

Passaggio 3: deployment in contenitori

Dopo che il sistema di compilazione crea il binario, questo viene pacchettizzato in un'immagine container e 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, in più cluster, ognuno con fino a decine di migliaia di macchine. Nonostante questa scala, il nostro ambiente di produzione è abbastanza omogeneo. Di conseguenza, i punti di contatto per l'accesso ai dati utente possono essere controllati e verificati più facilmente.

I container offrono notevoli vantaggi in termini di sicurezza. I container devono essere immutabili, con frequenti redeployment da una ricostruzione completa dell'immagine. La containerizzazione ci consente di esaminare una modifica del codice nel contesto e fornisce un unico punto di controllo per le modifiche che vengono implementate nella nostra infrastruttura.

La configurazione di un job Borg specifica i requisiti per il deployment del job: le immagini container, i parametri di runtime, gli argomenti e i flag. Borg pianifica il job tenendo conto dei vincoli, della priorità, della quota e di eventuali altri requisiti elencati 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 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 propria identità quando effettua richieste ad altri servizi utilizzando Application Layer Transport Security (ALTS). Affinché un servizio possa accedere a determinati dati o a un altro servizio, la sua identità deve disporre delle autorizzazioni necessarie.

Le nostre norme richiedono la protezione BAB per le identità di servizio che hanno accesso a dati utente e altre informazioni sensibili. I lavori di garanzia di qualità e sviluppo che non hanno accesso a dati sensibili possono essere eseguiti con meno controlli.

Come funziona l'autorizzazione binaria per Borg

BAB si integra con Borg per garantire che solo i job autorizzati possano essere eseguiti con l'identità di ogni servizio. BAB crea anche una traccia di audit 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 vengano esaminati, registrati, compilati in modo verificabile e autorizzati in modo appropriato, in particolare quando il codice può accedere ai dati utente.

Criteri specifici per il servizio

Quando i proprietari del servizio eseguono l'onboarding del proprio servizio in Borg, creano una policy BAB che definisce i requisiti di sicurezza per il proprio servizio. Queste norme sono chiamate norme specifiche del servizio. La definizione o la modifica di una policy è di per sé una modifica del codice che deve essere sottoposta a revisione.

La policy specifica 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 eseguiti come identità del servizio devono rispettare le norme specifiche 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 container dalle sue origini leggibili dagli utenti tramite la provenienza generata da build verificabili. Una norma di conservazione mantiene le origini del codice leggibili dall'uomo per almeno 18 mesi, anche se il codice non viene inviato.
  • Il codice deve essere inviato: Il codice è creato da una posizione specificata e definita nel nostro repository di origine. L'invio in genere implica che il codice sia stato sottoposto a una revisione.
  • Le configurazioni devono essere inviate: Tutte le configurazioni fornite durante l'implementazione vengono sottoposte alla stessa procedura di revisione e invio del codice normale. Pertanto, i valori, gli argomenti e i parametri dei flag della riga di comando non possono essere modificati senza revisione.

I servizi che non hanno accesso a dati sensibili o, in rari casi, i servizi che dispongono di un'eccezione valida e approvata potrebbero avere una norma più permissiva, ad esempio una che richiede solo l'auditabilità del codice o anche una che disattiva completamente BAB.

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

Modalità di applicazione

BAB utilizza due modalità di applicazione forzata per garantire che i job siano conformi alle norme specifiche del servizio:

  • Applicazione in fase di deployment, che impedisce il deployment dei job non conformi.
  • Verifica continua, che monitora e invia avvisi relativi ai job non conformi che sono stati implementati.

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 ALTS. Quando viene inviato un nuovo job, Borg Prime consulta BAB per verificare che il job soddisfi i requisiti delle norme specifiche del servizio prima che Borg Prime conceda il certificato ALTS 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 è altrimenti autorizzato.

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

Modalità di verifica continua

Una volta eseguito il deployment di un job, questo viene verificato continuamente per tutta la sua durata, indipendentemente dalla modalità di applicazione al momento del deployment. Un processo BAB viene eseguito almeno una volta al giorno per verificare che i job avviati (e che potrebbero essere ancora in esecuzione) siano conformi a eventuali aggiornamenti delle relative norme. Ad esempio, la modalità di verifica continua controlla costantemente i job in esecuzione con norme obsolete o che sono stati implementati utilizzando procedure di risposta di emergenza. Se viene trovato un job che non rispetta le norme 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 priorità è ripristinare il servizio interessato il più rapidamente 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 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 alle emergenze, 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 sia al team di sicurezza centralizzato di Google sia al team proprietario dell'identità del servizio. La voce di log include un riferimento a uno snapshot del codice che è stato implementato e alla giustificazione fornita dall'utente. Le procedure di risposta alle emergenze devono essere utilizzate solo come ultima risorsa.

BAB in altri ambienti

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

Esistono alcuni casi che non si prestano bene alle revisioni del codice umano prima del deployment, in particolare lo sviluppo iterativo del codice di machine learning e l'analisi dei dati ad alta frequenza. In questi casi, disponiamo di controlli alternativi che compensano la revisione umana.

Connessione a SLSA

Il framework Supply-chain Levels for Software Artifacts (SLSA) è una specifica open source per migliorare la sicurezza delle catene di fornitura del software. I seguenti concetti di BAB sono in linea con il framework SLSA v1.2:

  • Cronologia dell'origine e revisione da parte di due persone (SLSA Source L1-L4): BAB richiede che il codice di produzione venga gestito in un sistema di controllo delle versioni che conservi la cronologia delle revisioni, applichi i controlli dei rami e richieda la revisione del codice da parte di due persone prima dell'invio delle modifiche.
  • Provenienza crittografica e identità del builder (SLSA Build L1-L2): per ogni build, il sistema di compilazione genera un'attestazione di provenienza firmata crittograficamente.
  • Build verificabili e protette (SLSA Build L3-L4): il codice viene creato su una piattaforma di build isolata e protetta, separata dai dipendenti che avviano la build.
  • Verifica degli artefatti (artefatti di verifica SLSA): SLSA definisce in che modo i verificatori convalidano le firme di provenienza e confrontano le attestazioni di provenienza con le aspettative preconfigurate. In BAB, le norme specifiche del servizio definiscono e applicano queste aspettative per ogni identità di servizio.

Adottare controlli simili nella tua organizzazione

Questa sezione descrive le best practice che abbiamo appreso durante l'implementazione di BAB in modo che tu possa adottare controlli simili nella tua organizzazione.

Crea una pipeline CI/CD omogenea e containerizzata

L'adozione di Build as Binary è 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. Le revisioni del codice facevano già parte della nostra cultura, quindi siamo stati in grado di apportare modifiche senza troppi cambiamenti significativi visibili agli utenti. Per adottare BAB, ci siamo concentrati su revisioni del codice, build verificabili, deployment in container e identità basate su 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 utilizzo di microservizi e identità basate su servizi (come gli account di servizio), anziché 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 intermedio.

Determina i tuoi obiettivi e definisci i tuoi 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, potresti dover iniziare a eseguire revisioni formali del codice prima di poterle applicare al momento del deployment.

Un ottimo incentivo per un processo di rilascio basato sulle norme è la conformità. Se puoi codificare almeno alcuni dei tuoi requisiti di conformità in una policy, puoi automatizzare i test e assicurarti che siano in vigore in modo affidabile. Inizia con un insieme di requisiti di base e codifica quelli più avanzati man mano che procedi.

Applicare i criteri durante il deployment e l'esecuzione

È difficile definire policy complete per un software senza prima sapere dove verrà eseguito e a quali dati accederà. Pertanto, l'applicazione dei criteri specifici del servizio viene eseguita quando il codice viene implementato 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 dei servizi possono inoltre assicurarsi che i dati siano accessibili solo da un job che soddisfi determinati requisiti di BAB.

Coinvolgere gli agenti del cambiamento nei vari team

Quando abbiamo creato un mandato a livello di Google per l'implementazione di BAB, ciò che ha influito maggiormente sul nostro tasso di successo è stato trovare i proprietari per promuovere il cambiamento in ogni gruppo di prodotti. Abbiamo identificato alcuni proprietari di servizi che hanno riscontrato vantaggi immediati dall'applicazione e che erano disposti a fornire feedback. Abbiamo chiesto a questi proprietari di partecipare volontariamente prima di rendere obbligatorie le modifiche. Dopo aver ricevuto il loro aiuto, abbiamo creato un team formale di gestione dei cambiamenti per monitorare le modifiche in corso. Abbiamo quindi identificato i proprietari responsabili in ogni team di prodotto per implementare le modifiche.

Determinare come gestire il codice di terze parti

Se devi gestire codice di terze parti, valuta come introdurre i requisiti delle norme nel codebase di terze parti. Ad esempio, puoi iniziare creando un repository di tutto il codice di terze parti utilizzato. Puoi anche controllare regolarmente il codice in base ai tuoi requisiti di sicurezza.

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

Passaggi successivi