Iniziativa BeyondProd

Questi contenuti sono stati aggiornati a maggio 2024 e rappresentano lo status quo. al momento in cui è stata scritta. 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 in che modo Google implementa la sicurezza nella propria infrastruttura utilizzando un'architettura cloud-native chiamata BeyondProd. BeyondProd si riferisce ai servizi e ai controlli della nostra infrastruttura che lavorano insieme per proteggere i carichi di lavoro. I carichi di lavoro sono le attività uniche completato da un'applicazione. BeyondProd contribuisce a proteggere di microservizi che eseguiamo nel nostro ambiente, incluso il modo in cui modifichiamo il codice il modo in cui accediamo ai dati utente.

Il presente documento fa parte di una serie di articoli tecnici che descrivono i tecnologie come Chrome Enterprise Premium che abbiamo sviluppati per aiutare a difendere le piattaforme Google da minacce sofisticate. Chrome Enterprise Premium implementa un'architettura Zero Trust progettata per fornire un accesso sicuro alle piattaforme Google e ai servizi in esecuzione su di esse. Come Chrome Enterprise Premium, BeyondProd non si basa sul perimetro di rete tradizionale come i firewall. BeyondProd aiuta invece a creare la fiducia tra i microservizi usando caratteristiche come provenienza del codice, di identità di servizio e hardware affidabile. Questa fiducia si estende al software viene eseguito in Google Cloud e nel software di cui Google Cloud ha eseguito il deployment e che vi accede. clienti.

Questo documento descrive i vantaggi di BeyondProd, i suoi servizi e processi e come abbiamo eseguito la migrazione a questa architettura. Per una panoramica dei nostri della sicurezza dell'infrastruttura, Panoramica sulla progettazione della sicurezza dell'infrastruttura Google.

Introduzione

Le moderne architetture di sicurezza si sono allontanate di sicurezza perimetrale, in cui un firewall protegge il perimetro all'interno del perimetro sono considerati attendibili.

Oggi, gli utenti sono dispositivi mobili e operano comunemente al di fuori dell'organizzazione tradizionale, ad esempio da casa, da un bar o da un aereo. Con Chrome Enterprise Premium, concediamo l'accesso alle risorse aziendali utilizzando più fattori, tra cui l'identità dell'utente, l'identità del dispositivo utilizzato per accedere alla risorsa, l'integrità del dispositivo, gli indicatori di attendibilità come comportamento degli utenti ed elenchi di controllo dell'accesso.

BeyondProd affronta la stessa preoccupazione per i servizi di produzione Chrome Enterprise Premium serve agli utenti. In un'architettura cloud-native, non possiamo semplicemente affidarci su un firewall per proteggere la rete di produzione. I microservizi si spostano distribuiti in ambienti diversi, in host eterogenei e operano in diversi livelli di attendibilità e sensibilità. Dove Chrome Enterprise Premium indica che l'utente fiducia dovrebbe dipendere da caratteristiche come lo stato sensibile al contesto dispositivi e non la possibilità di connettersi alla rete aziendale, BeyondProd afferma che l'attendibilità dei servizi dovrebbe dipendere caratteristiche come provenienza del codice, hardware attendibile e identità del servizio, anziché la posizione nella rete di produzione, come l'indirizzo IP o dell'host.

Infrastruttura containerizzata

La nostra infrastruttura esegue il deployment dei carichi di lavoro come microservizi in container. I microservizi separano le singole attività che un'applicazione deve eseguire in diversi servizi. Ogni servizio può essere sviluppato e gestito in modo indipendente con API, implementazione, scalabilità e gestione delle quote proprie. I microservizi sono indipendenti, modulari, dinamici e temporanei. Possono essere distribuiti su diversi host, cluster o anche cloud. In un microservizio , un carico di lavoro può essere costituito da uno o più microservizi.

In un'infrastruttura containerizzata, il deployment di ogni microservizio viene eseguito un insieme di container spostabili e programmabili. Per gestire questi container internamente, abbiamo sviluppato sistema di orchestrazione dei container chiamata Borg che esegue il deployment di diversi miliardi di container a settimana. Borg è la soluzione unificata un sistema di gestione dei container e l'ispirazione Kubernetes

I container rendono i carichi di lavoro più semplici ed efficienti da pianificare su più macchine. La pacchettizzazione di microservizi in container consente di suddividere i carichi di lavoro in a unità più gestibili per la manutenzione e il rilevamento. Questa architettura consente di scalare carichi di lavoro in base alle esigenze: se c'è una domanda elevata per un particolare carico di lavoro, possono essere più macchine che eseguono copie dello stesso container per del carico di lavoro.

In Google, la sicurezza svolge un ruolo fondamentale in ogni evoluzione dei nostri dell'architettura. Il nostro obiettivo con questa architettura e sviluppo di microservizi del processo consiste nel risolvere i problemi di sicurezza sin dalle fasi di sviluppo e implementazione il ciclo di vita del cliente (quando la risoluzione dei problemi è meno costosa) e farlo in un standardizzato e coerente. Il risultato finale consente agli sviluppatori di dedicare meno tempo alla sicurezza, ottenendo al contempo risultati più sicuri.

Vantaggi di BeyondProd

BeyondProd offre numerosi vantaggi in termini di automazione e sicurezza dell'infrastruttura di Google. I vantaggi includono:

  • Protezione perimetrale della rete: i carichi di lavoro sono isolati dalla rete attacchi e traffico non autorizzato da internet. Sebbene un perimetro non è un concetto nuovo, ma rimane una best practice per la sicurezza architetture cloud. L'approccio perimetrale aiuta a proteggere dell'infrastruttura contro il traffico non autorizzato e il potenziale da internet, ad esempio gli attacchi DoS basati sul volume.
  • Nessuna attendibilità reciproca intrinseca tra i servizi:solo autenticati, i chiamanti o i servizi fidati e specificamente autorizzati possono accedere a qualsiasi altro servizio. In questo modo i malintenzionati non possono usare codice non attendibile per accedere a un completamente gestito di Google Cloud. Se un servizio viene compromesso, questo vantaggio aiuta a evitare che l'aggressore non compia azioni che gli consentano di ampliare il proprio raggio d'azione. Questa sfiducia reciproca, combinata con un controllo granulare dell'accesso, contribuisce a limitare la portata dell'attacco.
  • Macchine attendibili che eseguono codice di provenienza nota: servizio le identità sono vincolate a utilizzare solo il codice e le configurazioni autorizzati, ed eseguire solo in ambienti autorizzati e verificati.
  • Applicazione coerente delle norme a tutti i servizi: norme coerenti aiuta a garantire che le decisioni di accesso siano affidabili i servizi di machine learning. Ad esempio, puoi creare un'applicazione dei criteri per verificare richieste di accesso ai dati utente. Per accedere al servizio, un utente l'utente deve presentare una richiesta convalidata e un amministratore deve fornire una giustificazione aziendale.
  • Implementazione semplice, automatica e standardizzata delle modifiche: infrastruttura le modifiche possono essere facilmente esaminate per verificare il loro impatto sulla sicurezza Le patch possono essere implementate con un impatto minimo sulla produzione.
  • Isolamento tra carichi di lavoro che condividono un sistema operativo: se un se un servizio è compromesso, non ciò può influire sulla sicurezza di un altro carico di lavoro in esecuzione sullo stesso host. Questo isolamento aiuta a limitare la portata dell'attacco di una compromissione.
  • Hardware e attestazione attendibili:una radice di attendibilità hardware consente garantire che solo il codice noto e autorizzato (dal firmware alla modalità utente) in esecuzione sull'host prima che sia pianificata l'esecuzione di qualsiasi carico di lavoro.

Questi vantaggi significano che i container e i microservizi in esecuzione nei nostri del deployment dell'architettura cloud, comunicare tra loro ed eseguire senza compromettere la sicurezza della nostra infrastruttura. Inoltre, i singoli sviluppatori di microservizi non sono gravati dalla sicurezza e i dettagli di implementazione dell'infrastruttura sottostante.

Servizi di sicurezza BeyondProd

Abbiamo progettato e sviluppato diversi servizi di sicurezza BeyondProd per creare i vantaggi discussi Vantaggi di BeyondProd. Le sezioni seguenti descrivono questi servizi di sicurezza.

Google Front End (GFE) per la protezione perimetrale della rete

Google Front End (GFE) per garantire protezione perimetrale della rete. Il GFE termina la connessione dalla fine dall'utente e fornisce un punto centrale per l'applicazione delle best practice per TLS.

Anche se la nostra enfasi non è più sulla sicurezza perimetrale, GFE è rappresentano ancora una parte importante della nostra strategia di protezione dei servizi interni Attacchi DoS. GFE è il primo punto di accesso per un utente che si connette a Google dell'infrastruttura. Dopo che un utente si connette alla nostra infrastruttura, GFE viene responsabile del bilanciamento del carico e del reindirizzamento del traffico tra le regioni in base alle esigenze. GFE è il proxy perimetrale che instrada il traffico al microservizio corretto.

Le VM dei clienti su Google Cloud non vengono registrate in GFE. Invece, registrarsi con Cloud Front End, una configurazione speciale di GFE utilizza lo stack di networking di Compute Engine. Cloud Front End consente alle VM dei clienti accedere direttamente a un servizio Google utilizzando il proprio indirizzo IP pubblico o privato. Gli indirizzi IP privati sono disponibili solo quando Accesso privato Google sia abilitata).

Application Layer Transport Security per attendibilità tra i servizi

Application Layer Transport Security (ALTS) garantisce l'assenza di attendibilità reciproca intrinseca tra i servizi. ALTS è utilizzata per l'autenticazione RPC, integrità, crittografia del traffico e identità dei servizi. si tratta di un framework sistema di crittografia di autenticazione e crittografia del trasporto per i servizi di Google dell'infrastruttura. In generale, le identità sono associate ai servizi invece che un nome server o un host specifico. Questa associazione consente un microservizio senza interruzioni la replica, il bilanciamento del carico e la ripianificazione tra host.

Ogni macchina dispone di una credenziale ALTS che viene sottoposta a provisioning mediante sistema di integrità dell'host, e possono essere decriptati solo se il sistema di integrità dell'host ha verificato che è stato eseguito correttamente. La maggior parte dei servizi Google viene eseguita come microservizi su Borg, e ognuno di questi microservizi ha la propria identità Identity. Borg Prime Il controller centralizzato di Borg concede queste credenziali dei microservizi ALTS a carichi di lavoro in base all'identità del microservizio. Il ALTS a livello di macchina le credenziali costituiscono il canale sicuro per il provisioning delle credenziali dei microservizi. in modo che solo le macchine che hanno superato la verifica dell'integrità dell'host l'avvio può ospitare carichi di lavoro basati su microservizi. Per ulteriori informazioni su ALTS le credenziali, consulta Certificati per il carico di lavoro.

Autorizzazione binaria per Borg per la provenienza del codice

Autorizzazione binaria per Borg (BAB) fornisce la verifica della provenienza del codice. BAB è un controllo di applicazione forzata in fase di deployment che aiuta a garantire che il codice soddisfi i requisiti di sicurezza interna prima del codice viene eseguito il deployment. Ad esempio, il controllo di applicazione di BAB include la garanzia che vengono esaminate da un secondo tecnico prima di inviare il codice al nostro codice sorgente repository di codice e i file binari sono basati in modo verificabile su un'infrastruttura dedicata. Nella nostra infrastruttura, BAB limita il deployment di di microservizi.

Integrità dell'host per l'attendibilità delle macchine

Integrità dell'host Verifica l'integrità del software del sistema host tramite un processo di avvio protetto ed è supportato da un chip di sicurezza radice di attendibilità hardware (denominato Titan) ove supportato. I controlli di integrità dell'host includono la verifica delle firme digitali su il BIOS, il controller di gestione della scheda di base (BMC), bootloader e kernel del sistema operativo. Se supportati, i controlli dell'integrità dell'host possono includere codice in modalità utente e firmware delle periferiche (come le NIC). Oltre che per il digitale verifica della firma, l'integrità dell'host aiuta ad assicurare che ogni host sia in esecuzione la versione prevista di questi componenti software.

Gestione dell'accesso ai servizi e ticket contestuali per l'utente finale per l'applicazione dei criteri

Gestione dell'accesso ai servizi e Richieste di contesto contestuali per gli utenti finali per garantire un'applicazione omogenea dei criteri tra i vari servizi.

La gestione dell'accesso ai servizi limita la modalità di accesso ai dati tra i servizi. Quando RPC viene inviato da un servizio all'altro, Service Access Management definisce i criteri di autorizzazione e controllo richiesti dai servizi per accedere al servizio dei dati di un servizio. Ciò limita la modalità di accesso ai dati, garantisce il livello minimo di l'accesso richiesto e specifica come è possibile controllarlo. Su Google a livello di infrastruttura, Service Access Management limita l'accesso di un microservizio i dati di un altro microservizio e consente l'analisi globale dei controlli dell'accesso.

I ticket di contesto dell'utente finale vengono emessi da un servizio di autenticazione dell'utente finale e Fornire servizi con un'identità utente separata dai loro servizi e identità di base. Questi ticket sono protetti dall'integrità, emessi centralmente e possono essere inoltrati credenziali che attestano l'identità dell'utente finale che ha effettuato la richiesta completamente gestito di Google Cloud. Questi ticket riducono la necessità di considerare attendibilità tra i servizi, in quanto peer che le identità che utilizzano ALTS possono essere insufficienti per concedere l'accesso, le decisioni si basano in genere anche sull'identità dell'utente finale.

Strumenti Borg per l'implementazione automatica delle modifiche e la scalabilità

Borg gli strumenti per i deployment blu/verde offrono soluzioni semplici, automatizzate e standardizzate modifica l'implementazione. R deployment blu/verde è un modo per implementare una modifica a un carico di lavoro senza influire sul traffico in entrata, in modo che gli utenti finali non riscontrino tempi di inattività durante l'accesso all'applicazione.

Un job Borg è una singola istanza di un microservizio che esegue una parte di un'applicazione. I job vengono scalati per gestire il carico e ne viene eseguito il deployment all'aumentare del carico. e i job esistenti sono stati terminati quando il carico diminuisce.

Gli strumenti Borg sono responsabili della migrazione dei carichi di lavoro in esecuzione attività di manutenzione. Quando viene eseguito il deployment di un nuovo job Borg, si utilizza gradualmente il bilanciatore del carico sposta il traffico da un job esistente a quello nuovo. Questo permette a un microservizio possono essere aggiornate senza tempi di inattività e senza che l'utente se ne accorga.

Usiamo questo strumento anche per applicare upgrade del servizio quando aggiungiamo nuove funzionalità e per e applicare aggiornamenti critici della sicurezza senza tempi di inattività. Per le modifiche che interessano la nostra infrastruttura, utilizziamo migrazione live delle VM dei clienti, per garantire che non ci siano conseguenze sui carichi di lavoro.

Per ulteriori informazioni, vedi Autorizzazione binaria per Borg.

Kernel gVisor per l'isolamento dei carichi di lavoro

La Kinel gVisor consente l'isolamento tra carichi di lavoro che condividono lo stesso sistema operativo. gVisor utilizza un kernel dello spazio utente per intercettare e gestire le chiamate di sistema, riducendo interazione con l'host e la potenziale superficie di attacco. Questo kernel fornisce la maggior parte delle funzionalità necessarie per eseguire un'applicazione e limita una superficie del kernel accessibile all'applicazione. gVisor è uno dei tanti strumenti che utilizziamo per isolare i carichi di lavoro interni e i clienti Google Cloud carichi di lavoro in esecuzione sullo stesso host. Per ulteriori informazioni su altri tipi di sandbox vedi gli strumenti Sandboxing del codice.

Protezione dei dati utente con BeyondProd

Questa sezione descrive come funzionano insieme i servizi BeyondProd contribuiscano a proteggere i dati degli utenti nella nostra infrastruttura. Le sezioni seguenti descrivono due esempi:

  • Accesso alle richieste di dati degli utenti dalla loro creazione alla consegna presso destinazione.
  • Una modifica del codice dallo sviluppo alla produzione.

Non tutte le tecnologie elencate vengono utilizzate in tutte le parti del nostro infrastruttura; dipende dai servizi e dai carichi di lavoro.

Accesso ai dati utente

Il diagramma seguente mostra il processo utilizzato dalla nostra infrastruttura per verificare un utente è autorizzato ad accedere ai dati utente.

Controlli di sicurezza cloud-native di Google che accedono ai dati utente.

Per accedere agli account utente:

  1. Un utente invia una richiesta a GFE.
  2. GFE termina la connessione TLS e inoltra la richiesta al il frontend del servizio appropriato usandoALTSa.
  3. Il frontend dell'applicazione autentica la richiesta dell'utente utilizzando un centrale di autenticazione dell'utente finale (EUA) e, in caso di esito positivo, riceve un ticket contestuale crittografico di breve durata per l'utente finale.
  4. Il frontend dell'applicazione invia una RPC a un backend di archiviazione inoltrando il ticket nella richiesta di backend.
  5. Il servizio di backend utilizza la gestione degli accessi ai servizi per garantire i seguenti criteri sono veri:
    • Il frontend viene autenticato utilizzando un metodo valido, non revocato certificato. Questo controllo implica che è in esecuzione su un host attendibile e BAB controlli riusciti.
    • L'identità ALTS del servizio frontend è autorizzata a effettuare al servizio di backend e presentare un ticket EUC.
    • Il ticket contestuale dell'utente finale è valido.
    • L'utente nel ticket EUC è autorizzato ad accedere ai dati richiesti.

Se uno di questi controlli ha esito negativo, la richiesta viene rifiutata.

Se questi controlli vengono superati, i dati vengono restituiti all'account il frontend dell'applicazione e fornito all'utente autorizzato.

In molti casi, esiste una catena di chiamate backend e ogni servizio intermedio esegue un controllo di accesso al servizio sulle RPC in entrata e il ticket viene inoltrato e gli RPC in uscita.

Per ulteriori informazioni su come il traffico viene instradato all'interno della nostra infrastruttura, vedi Modalità di routing del traffico.

Esecuzione di una modifica al codice

Il diagramma seguente mostra come viene eseguito il deployment di una modifica al codice.

Come vengono apportate le modifiche al codice.

Per apportare una modifica al codice, procedi nel seguente modo:

  1. Uno sviluppatore apporta una modifica a un microservizio protetto da BAB. La una modifica viene inviata al nostro repository centrale di codice, che applica la revisione del codice. Dopo l'approvazione, la modifica viene inviata alla build centrale attendibile sistema che produce un pacchetto con un manifest di build verificabile firmato certificato.

  2. Al momento del deployment, BAB verifica che il processo sia stato seguito convalidando il certificato firmato dalla pipeline di build.

  3. Borg gestisce tutti gli aggiornamenti dei carichi di lavoro utilizzando un modello di affidabilità che garantisce e un'interruzione minima dei servizi, che si tratti di un'implementazione di routine o patch di sicurezza di emergenza.

  4. GFE trasferisce il traffico al nuovo deployment utilizzando il bilanciamento del carico per garantire la continuità delle operazioni.

Per ulteriori informazioni su questo processo, consulta Il nostro processo di sviluppo e produzione.

Tutti i carichi di lavoro devono essere isolati. Se il carico di lavoro è meno affidabile perché ha origine al di fuori di Google, potrebbe essere implementato in una protetto da gVisor o utilizzare altri livelli di isolamento. Questo isolamento aiuta a contenere un avversario che riesce a compromettere un’applicazione.

Implicazioni per la sicurezza cloud-native

Le seguenti sezioni forniscono un confronto tra gli aspetti della sicurezza dell'infrastruttura e dei relativi contrappunti in un ambiente dell'architettura.

Architettura dell'applicazione

Un modello di sicurezza più tradizionale, incentrato sulla sicurezza perimetrale, non può di proteggere autonomamente un'architettura cloud-native. Tradizionalmente, le applicazioni monolitiche utilizzavano un'architettura a tre livelli e il deployment delle applicazioni è stato eseguito di data center aziendali dotati di capacità sufficiente per gestire i picchi di carico per eventi critici. Applicazioni con requisiti di rete o hardware specifici sono stati intenzionalmente distribuiti su macchine specifiche che in genere mantengono e gli indirizzi IP esterni. Le implementazioni erano poco frequenti, grandi e difficili da coordinare come le modifiche risultanti hanno interessato contemporaneamente molte parti dell'applicazione. Ciò ha portato alle applicazioni a lunghissima durata che vengono aggiornate con minore frequenza le patch di sicurezza vengono in genere applicate con minore frequenza.

Tuttavia, in un modello cloud-native, le applicazioni devono essere portabili in ambienti diversi, perché possono essere eseguite in cloud pubblici, center o servizi in hosting di terze parti. Di conseguenza, invece di un modello un'applicazione containerizzata, suddivisa in microservizi diventa ideale per gli ambienti cloud. I container disaccoppiano i file binari le esigenze delle applicazioni dal sistema operativo host sottostante e la portabilità delle applicazioni. I nostri container sono immutabili, ovvero non cambiano dopo il deployment. Vengono invece ricompilati e sottoposti nuovamente a deployment spesso.

Con i container che vengono riavviati, arrestati o ripianificati spesso, c'è di riutilizzo e condivisione frequenti di hardware e networking. Con un comune di creazione e distribuzione standardizzati, il processo di sviluppo è coerente e uniforme tra i team, anche se i team gestiscono in modo indipendente lo sviluppo dei propri microservizi. Di conseguenza, considerazioni sulla sicurezza (come come revisioni della sicurezza, scansione del codice e gestione delle vulnerabilità), possono essere affrontati nelle prime fasi dei cicli di sviluppo.

Mesh di servizi

Creando un'infrastruttura condivisa e progettata in modo sicuro che tutti gli sviluppatori l'onere per gli sviluppatori di conoscere e implementare requisiti di sicurezza comuni ridotto al minimo. Le funzionalità di sicurezza dovrebbero richiedere un'integrazione minima o nulla in ogni applicazione ed è invece fornita come un tessuto che avvolge e e la connessione di tutti i microservizi. Viene comunemente chiamato mesh di servizi. Questo significa anche che la sicurezza può essere gestita e implementata separatamente rispetto alle normali attività di sviluppo e deployment.

Un mesh di servizi è una struttura condivisa a livello dell'infrastruttura che avvolge e connette tutti i microservizi. Un mesh di servizi consente comunicazione, che può controllare il traffico, applicare criteri il monitoraggio centralizzato per le chiamate ai servizi.

Sicurezza Zero Trust

In un modello di sicurezza tradizionale che utilizza data center privati, delle applicazioni dipendono da un firewall per contribuire a proteggere i carichi di lavoro minacce esterne basate sulla rete.

Con un modello di sicurezza Zero Trust, le decisioni di autorizzazione non dipendono dai firewall. Invece, altri di controllo, come Workload Identity, l'autenticazione e l'autorizzazione, proteggere i microservizi assicurando che le connessioni interne o esterne siano convalidate prima di poter effettuare transazioni. Quando rimuovi la dipendenza dai firewall basati sulla rete, puoi implementare la segmentazione a livello di microservizi, nessuna attendibilità intrinseca tra i servizi. Con la segmentazione a livello di microservizi, traffico può avere diversi livelli di attendibilità con controlli diversi e tu non solo confrontando il traffico interno con quello esterno.

Requisiti di sicurezza condivisi integrati negli stack di servizi

In un modello di sicurezza tradizionale, le singole applicazioni sono responsabili soddisfare i propri requisiti di sicurezza, indipendentemente da altri servizi. Tale I requisiti includono la gestione delle identità, la terminazione TLS e l'accesso ai dati. gestione dei dispositivi. Ciò può portare a implementazioni incoerenti o problemi di sicurezza, poiché devono essere risolti in molti punti, il che rende correzioni più difficili da applicare.

In un'architettura cloud-native, i componenti vengono riutilizzati con maggiore frequenza tra i servizi. I punti di passaggio consentono un'applicazione coerente dei criteri tra servizi. È possibile applicare criteri diversi utilizzando sistemi di sicurezza diversi. i servizi di machine learning. Anziché richiedere che ogni applicazione implementi una sicurezza critica separatamente i vari criteri, puoi suddividerli in criteri di microservizi. Ad esempio, puoi creare un unico criterio per garantire l'accesso ai dati utente e creare un altro criterio per garantire l'uso di suite di crittografia TLS.

Processi standardizzati con implementazioni più frequenti

In un modello di sicurezza tradizionale, i servizi condivisi sono limitati e il codice spesso duplicati e abbinati allo sviluppo locale. Grazie alla condivisione limitata, più difficile determinare l'impatto di una modifica e in che modo interessano molte parti di un'applicazione. Di conseguenza, le implementazioni sono poco frequenti e difficili da coordinare. Per apportare una modifica, gli sviluppatori potrebbero dover aggiornare direttamente il componente (ad esempio, l'apertura di connessioni SSH a ogni macchina virtuale per aggiornare una configurazione). Nel complesso, questo può portare a una durata estremamente lunga diverse applicazioni.

Dal punto di vista della sicurezza, dato che il codice è spesso duplicato, è più difficile e ancora più difficile garantire che quando una vulnerabilità venga fisso, è corretto ovunque.

In un'architettura cloud-native, le implementazioni sono frequenti e standardizzate. Questo consente alla sicurezza di spostarsi verso sinistra nel ciclo di vita di sviluppo del software. Per spostarsi verso sinistra si intende fare un passo avanti nello sviluppo del software del ciclo di vita, che possono includere passaggi come il codice, la creazione, il test, la convalida e il deployment. Il passaggio a sinistra consente un'applicazione più semplice e coerente della sicurezza, inclusa la regolare applicazione delle patch di sicurezza.

Il passaggio a BeyondProd

La transizione di Google a BeyondProd ha richiesto modifiche in due nella nostra infrastruttura e nel nostro processo di sviluppo. Abbiamo affrontato questi problemi modifiche contemporaneamente, ma puoi intervenire in modo indipendente se desideri configurare qualcosa di simile nel tuo ambiente.

Modifica della nostra infrastruttura

Il nostro obiettivo è automatizzare la sicurezza nell’intera infrastruttura perché ritiene che la sicurezza debba adattarsi allo stesso modo in cui vengono scalati i servizi. I servizi devono essere sicuri per definizione e non sicuri solo dopo che è stata presa una decisione esplicita di accettare i rischi. L'intervento umano diretto alle nostre dovrebbe essere un'eccezione, non di routine, e gli interventi dovrebbero verificabili nel momento in cui si verificano. Possiamo quindi autenticare un servizio in base il codice e la configurazione di cui viene eseguito il deployment per il servizio, anziché in base chi ha eseguito il deployment del servizio.

Abbiamo iniziato dalla costruzione di solide fondamenta di identificazione, autenticazione e autorizzazione dei servizi. Un microservizio utilizza un'identità di servizio per l'autenticazione ad altri servizi in esecuzione nell'infrastruttura. Avere una base di identità di servizio attendibili ci ha permesso di implementare funzionalità di sicurezza che dipendono dalla convalida di queste identità di servizio, gestione dell'accesso ai servizi e ticket di contesto per l'utente finale. Per eseguire questa transizione sia per i servizi nuovi che per quelli esistenti, abbiamo fornito inizialmente una libreria sotto forma di libreria con un singolo daemon helper. Questo daemon correva sull'host chiamato da ogni di servizio, per poi evolversi nel tempo in una libreria che utilizza le credenziali di servizio. La La libreria ALTS è stata integrata perfettamente nella libreria RPC principale. Questo integrazione ne ha facilitato l'ampia adozione, senza oneri significativi singoli team di sviluppo. L'implementazione di ALTS è stata un prerequisito per l'implementazione gestione dell'accesso ai servizi e ticket di contesto per l'utente finale.

Modifica dei nostri processi di sviluppo

Per Google era fondamentale stabilire un solido processo di compilazione e revisione del codice per garantire l'integrità dei servizi in esecuzione. Abbiamo creato una build centrale un processo in cui possiamo iniziare ad applicare requisiti quali un codice per due persone la revisione e i test automatizzati in fase di creazione e deployment. (Vedi Autorizzazione binaria per Borg per maggiori dettagli sul deployment).

Una volta definite le basi, abbiamo iniziato a occuparci della necessità di eseguire codice esterno non attendibile nei nostri ambienti. Per raggiungere questo obiettivo, abbiamo iniziato la sandbox, prima con ptrace, e successivamente utilizzando gVisor. Allo stesso modo, i deployment blu/verde hanno fornito vantaggi in termini di sicurezza (ad esempio, applicazione di patch) e affidabilità.

Abbiamo presto scoperto che era più semplice se un servizio cominciava registrando le violazioni delle norme invece di bloccarle. Il vantaggio di questo approccio era duplice:

  • Ha fornito ai proprietari dei servizi la possibilità di testare la modifica e l'eventuale impatto che il passaggio a un ambiente cloud-native avrebbe il loro servizio.
  • Ci ha permesso di correggere eventuali bug e identificare eventuali funzionalità aggiuntive. che potremmo dover fornire ai team di assistenza.

Ad esempio, durante l'onboarding di un servizio in BAB, i proprietari del servizio abilitano modalità di solo controllo. Tale modalità consente di identificare codice o carichi di lavoro che non soddisfano i requisiti. Una volta risolti i problemi segnalati dalla modalità di solo controllo, se i proprietari del servizio passano alla modalità di applicazione forzata. In gVisor, questa operazione è stata eseguita partendo dalla limitazione tramite sandbox dei carichi di lavoro, anche in presenza di problemi di compatibilità con le funzioni sandbox, procedendo quindi a risolvere sistematicamente questi problemi per migliorare la capacità di limitazione.

Passaggi successivi