Iniziativa BeyondProd

Questi contenuti sono stati aggiornati per l'ultima volta a maggio 2024 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 Google implementa la sicurezza nella sua infrastruttura utilizzando un'architettura nativa per il cloud chiamata BeyondProd. BeyondProd si riferisce a servizi e controlli nella nostra infrastruttura che collaborano per proteggere i carichi di lavoro. I carichi di lavoro sono le attività uniche completate da un'applicazione. BeyondProd contribuisce a proteggere i microservizi che eseguiamo nel nostro ambiente, incluso il modo in cui modifichiamo il codice e accediamo ai dati utente.

Questo documento fa parte di una serie di documenti tecnici che descrivono le tecnologie, come Chrome Enterprise Premium, che abbiamo sviluppato per proteggere 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. Come Chrome Enterprise Premium, BeyondProd non si basa su protezioni perimetrali di rete tradizionali come i firewall. Al contrario, BeyondProd contribuisce a creare fiducia tra i microservizi utilizzando caratteristiche quali la provenienza del codice, le identità dei servizi e l'hardware attendibile. Questa fiducia si estende al software che viene eseguito in Google Cloud e al software distribuito e a cui accedono i clienti Google Cloud.

Questo documento descrive i vantaggi di BeyondProd, i suoi servizi e processi e la modalità di migrazione a questa architettura. Per una panoramica della sicurezza della nostra infrastruttura, consulta la panoramica sulla progettazione della sicurezza dell'infrastruttura Google.

Introduzione

Le moderne architetture di sicurezza hanno abbandonato il modello di sicurezza tradizionale basato sul perimetro, in cui un firewall protegge il perimetro e gli utenti o i servizi al suo interno sono considerati attendibili.

Oggi gli utenti sono mobili e lavorano comunemente all'esterno del tradizionale perimetro di sicurezza aziendale, ad esempio da casa, da una caffetteria o da un aereo. Utilizzando 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, indicatori di attendibilità come il comportamento dell'utente e le liste di controllo dell'accesso.

BeyondProd affronta lo stesso problema per i servizi di produzione di Chrome Enterprise Premium per gli utenti. In un'architettura cloud-native, non possiamo affidarci esclusivamente a un firewall per proteggere la rete di produzione. I microservizi si spostano e vengono implementati in ambienti diversi, su host eterogenei e operano a vari livelli di attendibilità e sensibilità. Mentre Chrome Enterprise Premium afferma che l'attendibilità dell'utente deve dipendere da caratteristiche come lo stato sensibile al contesto dei dispositivi e non dalla possibilità di connettersi alla rete aziendale, BeyondProd afferma che l'attendibilità del servizio deve dipendere da caratteristiche come la provenienza del codice, l'affidabilità dell'hardware e l'identità del servizio, piuttosto che dalla posizione nella rete di produzione, come l'indirizzo IP o il nome host.

Infrastruttura containerizzata

La nostra infrastruttura esegue il deployment dei carichi di lavoro come microservizi singoli in container. I microservizi separano le singole attività che un'applicazione deve eseguire in servizi diversi. 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'architettura di microservizi, il carico di lavoro può comprendere uno o più microservizi.

Un'infrastruttura containerizzata significa che il deployment di ogni microservizio viene eseguito come proprio set di container mobili e programmabili. Per gestire internamente questi container, abbiamo sviluppato un sistema di orchestrazione dei container chiamato Borg,, che esegue il deployment di diversi miliardi di container a settimana. Borg è il sistema di gestione dei container unificato di Google e l'ispirazione per Kubernetes.

I container rendono più semplice ed efficiente la pianificazione dei carichi di lavoro tra le macchine. Il packaging dei microservizi nei container consente di suddividere i carichi di lavoro in unità più piccole e più gestibili per la manutenzione e l'individuazione. Questa architettura scala i carichi di lavoro secondo necessità: in caso di elevata richiesta per un particolare carico di lavoro, più macchine potrebbero eseguire copie dello stesso container così da gestire la scala richiesta del carico di lavoro.

In Google, la sicurezza svolge un ruolo fondamentale in ogni evoluzione della nostra architettura. Il nostro obiettivo per questa architettura di microservizi e il processo di sviluppo è risolvere i problemi relativi alla sicurezza il prima possibile in fase di sviluppo e deployment, quando affrontarli è meno costoso, e farlo in maniera standardizzata 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 molti vantaggi in termini di automazione e sicurezza all'infrastruttura di Google. I vantaggi includono:

  • Protezione perimetrale della rete:i carichi di lavoro sono isolati da attacchi di rete e da traffico internet non autorizzato. Sebbene un approccio perimetrale non sia un concetto nuovo, rimane una best practice per la sicurezza delle architetture cloud. Un approccio perimetrale aiuta a proteggere il massimo numero di infrastrutture possibile da traffico non autorizzato e attacchi potenziali da internet, ad esempio attacchi DoS basati sui volumi.
  • Nessuna attendibilità reciproca intrinseca tra i servizi:solo chiamanti o servizi autenticati, attendibili e con autorizzazioni specifiche possono accedere a qualsiasi altro servizio. In questo modo, gli attaccanti non possono utilizzare codice non attendibile per accedere a un servizio. Se un servizio viene compromesso, questo vantaggio contribuisce a impedire all'attaccante di eseguire azioni che gli consentano di ampliare la propria portata. Questa diffidenza reciproca, combinata con controllo dell'accesso granulare, contribuisce a limitare il raggio di impatto di una compromissione.
  • Macchine attendibili che eseguono codice di provenienza nota: le identità dei servizi sono vincolate all'uso esclusivo di configurazioni e codice autorizzati e all'esecuzione solo in ambienti verificati e autorizzati.
  • Applicazione coerente dei criteri tra i servizi:l'applicazione coerente dei criteri contribuisce a garantire che le decisioni di accesso siano affidabili tra i servizi. Ad esempio, puoi creare un'applicazione dei criteri che verifichi le richieste di accesso ai dati utente. Per accedere al servizio, un utente finale autorizzato deve presentare una richiesta convalidata e un amministratore deve fornire una motivazione di business.
  • Implementazione semplice, automatica e standardizzata delle modifiche:le modifiche all'infrastruttura possono essere facilmente esaminate per valutarne l'impatto sulla sicurezza e le patch di sicurezza possono essere implementate con un impatto minimo sulla produzione.
  • Isolamento tra carichi di lavoro che condividono un sistema operativo:se un servizio viene compromesso, non può influire sulla sicurezza di un altro carico di lavoro in esecuzione sullo stesso host. Questo isolamento contribuisce a limitare il raggio di impatto di una compromissione.
  • Hardware attendibile e attestazione: una radice di attendibilità hardware contribuisce a garantire che sull'host venga eseguito solo codice noto e autorizzato (dal firmware alla modalità utente) prima che vengano pianificati i carichi di lavoro.

Questi vantaggi significano che i container e i microservizi eseguiti all'interno della nostra architettura cloud possono essere implementati, comunicare tra loro ed essere eseguiti uno accanto all'altro senza compromettere la sicurezza della nostra infrastruttura. Inoltre, i singoli sviluppatori di microservizi non sono gravati dai dettagli di sicurezza e implementazione dell'infrastruttura sottostante.

Servizi di sicurezza BeyondProd

Abbiamo progettato e sviluppato diversi servizi di sicurezza BeyondProd per creare i vantaggi descritti in 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) fornisce la protezione perimetrale della rete. GFE termina la connessione dall'utente finale e offre un punto centrale per applicare le best practice TLS.

Anche se la nostra attenzione non è più incentrata sulla sicurezza perimetrale, GFE è ancora una parte importante della nostra strategia di protezione dei servizi interni dagli attacchi DoS. GFE è il primo punto di accesso per un utente che si connette all'infrastruttura di Google. Dopo che un utente si connette alla nostra infrastruttura, GFE è anche responsabile del bilanciamento del carico e del reindirizzamento del traffico tra le regioni secondo necessità. GFE è il proxy perimetrale che indirizza il traffico al microservizio corretto.

Le VM dei clienti su Google Cloud non vengono registrate in GFE. ma si registrano con il front-end cloud, una configurazione speciale di GFE che utilizza lo stack di networking di Compute Engine. Cloud Front End consente alle VM dei clienti di accedere direttamente a un servizio Google utilizzando il proprio indirizzo IP pubblico o privato. Gli indirizzi IP privati sono disponibili solo quando l'accesso privato Google è abilitato.

Application Layer Transport Security per l'attendibilità tra i servizi

Application Layer Transport Security (ALTS) contribuisce a garantire che non esista una fiducia reciproca intrinseca tra i servizi. ALTS viene utilizzato per l'autenticazione RPC (Remote Procedure Call, chiamata di procedura remota), l'integrità, la crittografia del traffico e le identità dei servizi. ALTS è un sistema di autenticazione reciproca e crittografia di trasporto per i servizi nell'infrastruttura di Google. In generale, le identità sono associate ai servizi anziché a un nome server o host specifico. Questo binding facilita la replica, il bilanciamento del carico e la riprogrammazione dei microservizi senza problemi tra gli host.

Ogni macchina dispone di credenziali ALTS fornite tramite il sistema di integrità host, che possono essere decriptate solo se il sistema di integrità host ha verificato che l'avvio sicuro è avvenuto correttamente. La maggior parte dei servizi Google viene eseguita come microservizi su Borg e ognuno di questi microservizi ha la propria identità ALTS. Borg Prime, il controller centralizzato di Borg, concede queste credenziali dei microservizi ALTS ai carichi di lavoro in base all'identità del microservizio. Le credenziali ALTS di livello macchina costituiscono il canale sicuro per il provisioning delle credenziali dei microservizi, in modo che solo le macchine che hanno superato correttamente l'avvio verificato dell'integrità host possano ospitare i carichi di lavoro dei microservizi. Per saperne di più sulle credenziali ALTS, consulta Certificati dei carichi 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 dell'applicazione forzata in fase di deployment che contribuisce a garantire che il codice soddisfi i requisiti di sicurezza interni prima del deployment. Ad esempio, il controllo dell'applicazione forzata di BAB include la verifica che le modifiche vengano esaminate da un secondo tecnico prima che il codice venga inviato al nostro repository di codice sorgente e che i file binari vengano compilati in modo verificabile su un'infrastruttura dedicata. Nella nostra infrastruttura, BAB limita il deployment di microservizi non autorizzati.

Integrità host per l'attendibilità della macchina

Integrità host verifica l'integrità del software di sistema host tramite una procedura di avvio protetto ed è supportata da un chip di sicurezza hardware radice di attendibilità (chiamato Titan) dove supportato. I controlli di integrità host includono la verifica delle firme digitali su BIOS, baseboard management controller (BMC), bootloader e kernel del sistema operativo. Dove supportato, i controlli di integrità host possono includere codice in modalità utente e firmware periferico (ad esempio NIC). Oltre alla verifica della firma digitale, l'integrità host contribuisce a garantire che ogni host esegua la versione prevista di questi componenti software.

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

La gestione dell'accesso ai servizi e i ticket di contesto utente finale contribuiscono a garantire l'applicazione coerente delle norme nei vari servizi.

La gestione dell'accesso ai servizi limita la modalità di accesso ai dati tra i servizi. Quando una RPC viene inviata da un servizio a un altro, la gestione dell'accesso ai servizi definisce le norme di autorizzazione e controllo richieste dai servizi per accedere ai dati del servizio ricevente. Si limita così la modalità di accesso ai dati, viene garantito il livello minimo di accesso necessario e viene specificata la modalità di controllo dell'accesso. Nell'infrastruttura Google, la gestione dell'accesso ai servizi limita l'accesso di un microservizio ai dati di un altro microservizio e consente analisi globali dei controlli di accesso.

I ticket di contesto utente finale vengono emessi da un servizio di autenticazione dell'utente finale e forniscono ai servizi un'identità utente separata dall'identità servizio. Questi ticket sono credenziali con integrità protetta, emesse a livello centrale e inoltrabili che attestano l'identità di un utente finale che ha richiesto il servizio. Questi ticket riducono la necessità di relazioni trust tra i servizi, poiché le identità peer che utilizzano ALTS possono essere insufficienti a concedere l'accesso, quando queste decisioni di accesso si basano in genere anche sull'identità dell'utente finale.

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

Gli strumenti Borg per i deployment blu/verde forniscono un'implementazione semplice, automatica e standardizzata delle modifiche. Un deployment blu/verde è un modo per implementare una modifica a un carico di lavoro senza influenzare il traffico in entrata, in modo che gli utenti finali non rilevino alcun tempo di inattività nell'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, viene eseguito il deployment di nuovi job all'aumentare del carico e i job esistenti vengono terminati quando il carico diminuisce.

Gli strumenti Borg sono responsabili della migrazione dei carichi di lavoro in esecuzione quando eseguiamo attività di manutenzione. Quando viene eseguito il deployment di un nuovo job Borg, un bilanciatore del carico sposta gradualmente il traffico da un job esistente a quello nuovo. Ciò consente di aggiornare un microservizio senza tempi di inattività e senza che l'utente se ne accorga.

Utilizziamo questo strumento anche per applicare upgrade dei servizi in occasione dell'aggiunta di nuove funzionalità e per applicare aggiornamenti critici della sicurezza senza tempi di inattività. Per le modifiche che interessano la nostra infrastruttura, utilizziamo la migrazione live delle VM dei clienti per garantire che i carichi di lavoro non siano interessati.

Per saperne di più, consulta Autorizzazione binaria per Borg.

Kernel gVisor per l'isolamento dei carichi di lavoro

Il kernel gVisor consente l'isolamento tra i carichi di lavoro che condividono un sistema operativo. gVisor utilizza un kernel dello spazio utente per intercettare e gestire le chiamate di sistema, riducendo l'interazione con l'host e la potenziale superficie esposta ad attacchi. Questo kernel fornisce la maggior parte delle funzionalità necessarie per eseguire un'applicazione e limita la superficie del kernel host accessibile all'applicazione. gVisor è uno dei vari strumenti che utilizziamo per isolare i carichi di lavoro interni e Google Cloud quelli dei clienti che vengono eseguiti sullo stesso host. Per saperne di più su altri strumenti di sandboxing, consulta Sandboxing del codice.

Protezione dei dati utente con BeyondProd

Questa sezione descrive il funzionamento combinato dei servizi BeyondProd per proteggere i dati degli utenti nella nostra infrastruttura. Le sezioni seguenti descrivono due esempi:

  • Accesso alle richieste di dati utente dalla creazione alla consegna a destinazione.
  • Una modifica del codice dallo sviluppo alla produzione.

Non tutte le tecnologie elencate vengono utilizzate in tutte le parti della nostra infrastruttura, in base ai servizi e ai carichi di lavoro.

Accesso ai dati utente

Il diagramma seguente mostra la procedura utilizzata dalla nostra infrastruttura per verificare che un utente sia autorizzato ad accedere ai dati utente.

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

Ecco i passaggi per accedere agli account utente:

  1. Un utente invia una richiesta al GFE.
  2. GFE termina la connessione TLS e inoltra la richiesta al frontend del servizio appropriato utilizzando ALTS.
  3. Il frontend dell'applicazione autentica la richiesta dell'utente utilizzando un servizio di autenticazione dell'utente finale (EUA) centrale e, in caso di esito positivo, riceve un ticket di contesto utente finale crittografico a breve durata.
  4. Il frontend dell'applicazione invia una RPC tramite ALTS a un servizio di backend di archiviazione, inoltrando il ticket nella richiesta al backend.
  5. Il servizio di backend utilizza la gestione dell'accesso ai servizi per garantire che il seguente criterio sia vero:
    • L'autenticazione del frontend viene eseguita utilizzando un certificato valido e non revocato. Questo controllo implica che il frontend venga eseguito su un host attendibile e che i controlli BAB siano riusciti.
    • L'identità ALTS del servizio frontend sia autorizzata a inviare richieste al servizio di backend e presenti un ticket EUC.
    • Il ticket contesto 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 al frontend applicazione autorizzato e forniti all'utente autorizzato.

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

Per ulteriori informazioni sul routing del traffico all'interno della nostra infrastruttura, consulta la sezione Crittografia in transito all'interno delle reti Google.

Esecuzione di una modifica al codice

Il diagramma seguente mostra come viene implementata una modifica del codice.

Come vengono apportate le modifiche al codice.

Ecco i passaggi per apportare una modifica al codice:

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

  2. Al momento del deployment, BAB verifica che la procedura sia stata seguita convalidando il certificato firmato dalla pipeline di compilazione.

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

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

Per ulteriori informazioni su questa procedura, consulta La nostra procedura di sviluppo e produzione.

Tutti i carichi di lavoro devono essere isolati. Se il carico di lavoro ha un'affidabilità inferiore perché il codice sorgente ha origine all'esterno di Google, il deployment viene eseguito con livelli di isolamento più elevati, ad esempio in un ambiente protetto da gVisor. Questo isolamento contribuisce a contenere un malintenzionato che riesce a compromettere un'applicazione.

Implicazioni per la sicurezza cloud-native

Le sezioni seguenti forniscono un confronto tra gli aspetti della sicurezza dell'infrastruttura tradizionale e i relativi contrappunti in un'architettura cloud-native.

Architettura dell'applicazione

Un modello di sicurezza più tradizionale, incentrato sulla sicurezza del perimetro, non è in grado di proteggere da solo un'architettura cloud-native. Tradizionalmente, le applicazioni monolitiche utilizzavano un'architettura a tre livelli e venivano implementate in data center aziendali privati, con una capacità sufficiente a gestire picchi di carico in caso di eventi critici. Le applicazioni con requisiti di rete o hardware specifici venivano appositamente implementate su macchine specifiche, che di solito mantengono indirizzi IP fissi. I rollout erano rari, di grandi dimensioni e difficili da coordinare, poiché le modifiche risultanti interessavano contemporaneamente molte parti dell'applicazione. Ciò ha portato ad applicazioni di lunga durata che vengono aggiornate meno frequentemente e in cui le patch di sicurezza vengono in genere applicate meno spesso.

Tuttavia, in un modello cloud-native, le applicazioni devono essere portabili tra diversi ambienti, perché possono essere eseguite in cloud pubblici, data center privati o servizi ospitati da terze parti. Pertanto, invece di un'applicazione monolitica, un'applicazione containerizzata suddivisa in microservizi diventa ideale per gli ambienti cloud. I container disaccoppiano i programmi binari necessari per l'applicazione dal sistema operativo host sottostante e rendono le applicazioni più portabili. I nostri container sono immutabili, il che significa che non cambiano dopo il deployment. ma vengono ricreati e ridistribuiti di frequente.

Con i container riavviati, arrestati o riprogrammati spesso, il riutilizzo e la condivisione di hardware e networking è più frequente. Grazie a un processo di creazione e distribuzione comune standardizzato, il processo di sviluppo è più coerente e uniforme tra i team, anche se i team gestiscono lo sviluppo dei propri microservizi in maniera indipendente. Di conseguenza, le considerazioni relative alla sicurezza (come revisioni della sicurezza, scansione del codice e gestione delle vulnerabilità) possono essere affrontate nelle prime fasi dei cicli di sviluppo.

Mesh di servizi

Creando un'infrastruttura condivisa e progettata in modo sicuro che tutti gli sviluppatori utilizzano, il carico sugli sviluppatori per conoscere e implementare i requisiti di sicurezza comuni viene ridotto al minimo. La funzionalità di sicurezza dovrebbe richiedere un'integrazione minima o nulla in ogni applicazione e agire piuttosto da rete che avvolge e connette tutti i microservizi. Questa è comunemente definita service mesh. Ciò significa anche che la sicurezza può essere gestita e implementata separatamente rispetto alle normali attività di sviluppo o deployment.

Un mesh di servizi è una struttura condivisa a livello di infrastruttura che include e collega tutti i microservizi. Un mesh di servizi consente la comunicazione service-to-service, che può controllare il traffico, applicare criteri e fornire un monitoraggio centralizzato per le chiamate ai servizi.

Sicurezza Zero Trust

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

Con un modello di sicurezza zero-trust, le decisioni di autorizzazione non dipendono dai firewall. Altri controlli, come l'identità del workload, l'autenticazione e l'autorizzazione, contribuiscono a proteggere i microservizi garantendo che le connessioni interne o esterne vengano convalidate prima di poter eseguire transazioni. Quando elimini la dipendenza dai firewall o dai controlli basati sulla rete, puoi implementare la segmentazione a livello di microservizio, senza attendibilità intrinseca tra i servizi. Con la segmentazione a livello di microservizio, il traffico può avere diversi livelli di attendibilità con controlli differenti e non si confronta più solo il traffico interno con quello esterno.

Requisiti di sicurezza condivisi integrati negli stack dei servizi

In un modello di sicurezza tradizionale, ogni singola applicazione è responsabile della conformità ai propri requisiti di sicurezza, indipendentemente dagli altri servizi. Tali requisiti includono la gestione dell'identità, la terminazione TLS e la gestione degli accessi ai dati. Ciò può portare a implementazioni incoerenti o problemi di sicurezza irrisolti, in quanto questi problemi devono essere corretti in molti punti, il che rende più difficile l'applicazione delle correzioni.

In un'architettura cloud-native, i componenti vengono riutilizzati tra i servizi con maggiore frequenza. I punti di passaggio obbligato consentono un'applicazione coerente dei criteri nei diversi servizi. Possono essere applicati criteri differenti utilizzando servizi di sicurezza diversi. Invece di richiedere che ogni applicazione implementi i servizi di sicurezza critici separatamente, si possono suddividere i diversi criteri in microservizi separati. Ad esempio, puoi creare una policy per garantire l'accesso autorizzato ai dati utente e un'altra policy per garantire l'utilizzo di suite di crittografia TLS aggiornate.

Processi standardizzati con implementazioni più frequenti

In un modello di sicurezza tradizionale, i servizi condivisi sono limitati e il codice viene spesso duplicato e accoppiato allo sviluppo locale. La condivisione limitata rende più difficile determinare l'impatto di una modifica e il modo in cui la modifica potrebbe influire su 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 ogni componente (ad esempio, aprendo connessioni SSH a ogni macchina virtuale per aggiornare una configurazione). Nel complesso, questo può portare ad applicazioni di lunga durata.

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

In un'architettura cloud-native, le implementazioni sono frequenti e standardizzate. Questo processo consente di spostare la sicurezza nelle fasi iniziali del ciclo di vita di sviluppo del software. Il termine "shifting left" si riferisce all'anticipazione di fasi nel ciclo di vita di sviluppo del software come creazione del codice, compilazione, test, convalida e deployment. Lo spostamento a sinistra consente un'applicazione più coerente e semplice della sicurezza, compresa la regolare applicazione delle patch di sicurezza.

Realizzare il passaggio a BeyondProd

Il passaggio di Google a BeyondProd ha richiesto modifiche in due aree principali: nella nostra infrastruttura e nel nostro processo di sviluppo. Abbiamo gestito queste modifiche simultaneamente, ma puoi affrontarle in modo indipendente se vuoi configurare qualcosa di simile nel tuo ambiente.

Modifica della nostra infrastruttura

Il nostro obiettivo è automatizzare la sicurezza in tutta la nostra infrastruttura perché riteniamo che la sicurezza debba essere scalata così come vengono scalati i servizi. I servizi devono essere sicuri per impostazione predefinita e non sicuri solo dopo che è stata presa una decisione esplicita di accettare i rischi. L'intervento umano diretto sulla nostra infrastruttura deve essere un'eccezione e non la regola e, quando avviene, deve essere verificabile. Possiamo quindi autenticare un servizio in base al codice e alla configurazione di deployment del servizio stesso, invece che alle persone che ne hanno eseguito il deployment.

Abbiamo iniziato dalla costruzione di solide fondamenta di identificazione, autenticazione e autorizzazione dei servizi. Un microservizio utilizza un'identità del servizio per autenticarsi ad altri servizi in esecuzione nell'infrastruttura. Una solida base di identità di servizio attendibili ci ha consentito di implementare funzioni di sicurezza di massimo livello dipendenti dalla convalida di tali identità, quali la gestione dell'accesso al servizio e i ticket contesto utente finale. Per semplificare la transizione per i servizi nuovi ed esistenti, per prima cosa abbiamo fornito ALTS sotto forma di una libreria con un singolo daemon helper. Questo daemon veniva eseguito sull'host richiamato da ogni servizio e, nel corso del tempo, si è evoluto in una libreria che utilizza le credenziali di servizio. La libreria ALTS è stata perfettamente integrata nella libreria RPC principale. Questa integrazione ha semplificato l'ampia adozione senza imporre carichi significativi ai singoli team di sviluppo. Il lancio del sistema ALTS è stato un prerequisito per l'implementazione della gestione dell'accesso ai servizi e dei ticket di contesto utente finale.

Modifica dei nostri processi di sviluppo

Per Google, è stato fondamentale stabilire un robusto processo di compilazione e revisione del codice per garantire l'integrità dei servizi in esecuzione. Abbiamo creato un processo di compilazione centrale in cui abbiamo potuto iniziare ad applicare requisiti quali la revisione del codice da parte di due persone e la verifica automatica nelle fasi di compilazione e deployment. (Consulta Autorizzazione binaria per Borg per maggiori dettagli sul deployment.)

Una volta organizzate le basi, abbiamo iniziato a occuparci dei requisiti per eseguire codice esterno non attendibile nei nostri ambienti. Per raggiungere questo obiettivo, abbiamo avviato la limitazione tramite sandbox, prima con ptrace, poi utilizzando gVisor. Analogamente, i deployment blu/verde hanno offerto importanti vantaggi in termini di sicurezza (ad esempio nell'applicazione di patch) e di 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 è stato duplice:

  • Offriva ai proprietari dei servizi un'opportunità di testare le modifiche e valutare l'eventuale impatto sul loro servizio del passaggio a un ambiente cloud-native.
  • Ci ha permesso di correggere eventuali bug e di identificare le funzionalità aggiuntive necessarie per i team dei servizi.

Ad esempio, durante l'onboarding di un servizio in BAB, i proprietari del servizio abilitano la 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, i proprietari dei servizi 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