L'ultimo aggiornamento di questi contenuti è stato a maggio 2024 e rappresenta lo status quo. del tempo 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 aiuta a ridurre gli addetti ai lavori a rischio perché garantisce che il software di produzione sia esaminato e approvato prima di cui viene eseguito il deployment, in particolare quando il nostro codice può accedere a dati sensibili. Si applica il BAB a tutti i servizi in esecuzione Borg. Poiché l'originale di questo documento, abbiamo incluso i concetti chiave di BAB in un denominata Supply-chain Levels for Software Artifacts (Livelli della catena di fornitura per artefatti software) (SLSA).
Questo 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
Il rischio legato agli addetti ai lavori rappresenta una minaccia alla sicurezza dei dati degli utenti, che può Includono dati sull'occupazione, dati finanziari o altri dati proprietari o aziendali. 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 i rischi provenienti da personale interno all'interno della nostra catena di fornitura del software, utilizziamo BAB. BAB è un controllo interno di applicazione delle norme che si verifica quando il software di cui è stato eseguito il deployment. 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. BAB e controlli associati ci aiutano ad applicare privilegio minimo, migliorando così il livello di sicurezza in modo indipendente da uno specifico soggetto malintenzionato. 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 molte misure di sicurezza e i vantaggi dell'infrastruttura 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 sistemi containerizzati e verificando i relativi requisiti BAB prima deployment, i nostri sistemi diventano più semplici da eseguire per il debug, più affidabili processi di gestione dei cambiamenti ben definiti. I requisiti BAB forniscono un'architettura per i requisiti del 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à sono stati pubblicati internamente ed è a disposizione degli 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. Alcuni processi di Google richiedono controlli più rigidi sul trattamento dei dati. Ad esempio: i nostri sistemi di rendicontazione finanziaria devono essere conformi al Sarbanes-Oxley Act (SOX). Prima di BAB, avevamo un sistema che ci aiutava a eseguire manualmente 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 permesso al team di conformità di aumentare sia dei servizi coperti e l'adozione di controlli appropriati su questi i servizi di machine learning.
BAB fa parte della piattaforma BeyondProd il framework che usiamo per mitigare 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 repository monolitico centrale, e richiede la revisione e l'approvazione di almeno un ingegnere diverso dall'autore. Un modello monolitico il codebase consente l'applicazione forzata di un singolo punto di passaggio per il codice le 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. Le nostre Il 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 . 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. Questo la provenienza consente:
- La capacità di tracciare un file binario fino al codice sorgente utilizzato nei suoi per la creazione di contenuti. 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 containerizzato
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 da molti in più cluster, ognuno con decine di migliaia di machine learning. Nonostante questa scala, il nostro ambiente di produzione è abbastanza omogeneo. Di conseguenza, i touchpoint per accedere ai dati utente possono essere più facilmente controllati e controllati.
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 pianifica la il job, tenendo conto dei vincoli, della priorità, della quota e di qualsiasi altra elencati 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 procedure remote. di chiamata (RPC) di altri servizi. Più job possono 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.
Le nostre norme richiedono la protezione BAB per le identità di servizio che hanno accesso Dati utente ed eventuali altre informazioni sensibili. Lavori di sviluppo e garanzia di qualità che non hanno accesso a dati sensibili possono essere pubblicati con meno risorse i controlli di sicurezza.
Come funziona BAB
BAB si integra con Borg per garantire che solo i job autorizzati possano essere eseguiti con l'identità di ogni 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 tutto il software e la configurazione di produzione correttamente esaminato, registrato, compilato in modo verificabile e autorizzato, in particolare quando il codice può accedere all'utente e i dati di Google Cloud.
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 prendono il nome di norme specifiche dei servizi. 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 quale codice e configurazione è consentito eseguito come identità del servizio, oltre alle proprietà richieste di questo codice e configurazione. Tutti i job in esecuzione come identità di servizio devono soddisfare le 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 controllabile: Possiamo far risalire l'immagine container alla sua fonti leggibili da una persona per provenienza generata da build verificabili. R il criterio di conservazione mantiene le origini leggibili del codice per almeno 18 mesi, anche se il codice non è stato inviato.
- Il codice deve essere inviato: Il codice è stato generato da una località specificata e definita in nel nostro repository di codice sorgente. L'invio implica in genere che il codice è sono state sottoposte a una revisione del codice.
- 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.
Servizi che non hanno accesso a dati sensibili o, in rari circostanze, i servizi per i quali è prevista un'eccezione valida e approvata, potrebbero criteri più permissivi, ad esempio quelli che richiedono solo la verificabilità o addirittura uno che disattivi completamente 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 in fase di deployment, che blocca il deployment dei job non conformi.
- Convalida continua, che monitora e segnala i job non conformi che di cui è stato eseguito il deployment.
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 lavoro, Borg Prime consulta BAB per verifica che il job soddisfi i requisiti dei criteri specifici del servizio prima di Borg Prime concede 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, a prescindere dalla modalità di applicazione al momento del deployment. Viene eseguito un processo BAB almeno una volta al giorno per controllare che i job siano stati avviati (e che potrebbero essere in esecuzione) siano conformi a eventuali aggiornamenti delle norme. Ad esempio, la modalità di verifica continua è il controllo dei job in esecuzione con criteri obsoleti o di cui è stato eseguito il deployment utilizzando le procedure di risposta alle emergenze. Se viene trovato un job non rispetta le norme più recenti, BAB invia una notifica ai proprietari del servizio affinché possono 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 hanno il solo scopo di potrebbe essere utilizzata solo come ultima risorsa.
Estensione di BAB ad altri ambienti
Inizialmente, BAB supportava solo la protezione dei job Borg e richiedeva il software da sviluppare utilizzando 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 per questi diversi ambienti differiscono, 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 del codice l'analisi di dati ad alta frequenza. In questi casi, disponiamo di controlli alternativi compensare la revisione umana.
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 ha utilizzato un'unica fonte di controllo, il processo di revisione del codice, il sistema di compilazione e il 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 rafforzato le garanzie che una soluzione come BAB può fornire.
Il nostro ampio utilizzo di microservizi e identità basate sui servizi (come i servizi di Compute Engine), anziché identità basate su host (come gli indirizzi IP), creiamo e 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, puoi prova 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. Potresti dover 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 nelle prime fasi di sviluppo
È difficile definire criteri esaustivi su un software senza prima sapere dove verrà eseguita 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 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 inoltre garantire che i dati siano accessibili solo da un job che soddisfa requisiti BAB specifici.
Affidati agli agenti dei cambiamenti tra i 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. Abbiamo quindi identificato i proprietari responsabili team di prodotto per implementare le modifiche.
Determinare come gestire il codice di terze parti
Se devi gestire codice di terze parti, considera come introdurre il tuo i requisiti delle norme al codebase di terze parti. Ad esempio, potresti inizia con la conservazione di tutti i codici di terze parti utilizzati. Ti consigliamo di controllare regolarmente del codice rispetto ai tuoi requisiti di sicurezza.
Per ulteriori informazioni sulla gestione del codice di terze parti, consulta Successo condiviso nella creazione di una community open source più sicura.
Passaggi successivi
- Informazioni BeyondProd che utilizziamo per creare un perimetro sicuro attorno ai nostri microservizi.
- Per adottare una pipeline CI/CD sicura, consulta Livelli della catena di fornitura per gli artefatti software (SLSA).