Iniziativa BeyondProd

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 Google implementa la sicurezza nella nostra infrastruttura utilizzando un'architettura cloud-native chiamata BeyondProd. BeyondProd si riferisce a servizi e controlli della nostra infrastruttura che collaborano per proteggere i carichi di lavoro. I carichi di lavoro sono le attività uniche che un'applicazione completa. 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 su queste piattaforme. Come Chrome Enterprise Premium, BeyondProd non si basa su protezioni tradizionali del perimetro di rete, come i firewall. Al contrario, BeyondProd contribuisce a creare fiducia tra i microservizi utilizzando caratteristiche come la provenienza del codice, le identità del servizio e l'hardware attendibile. Questa fiducia si estende al software 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 nostra migrazione a questa architettura. Per una panoramica della sicurezza della nostra infrastruttura, consulta la panoramica sulla progettazione della sicurezza dell'infrastruttura Google.

Connessione a Chrome Enterprise Premium

Le moderne architetture di sicurezza si sono allontanate da un modello di sicurezza tradizionale basato sul perimetro, in cui un firewall protegge il perimetro e tutti gli utenti o servizi all'interno del perimetro sono considerati attendibili.

Oggi gli utenti sono mobili e operano comunemente al di fuori del perimetro di sicurezza tradizionale di un'organizzazione, ad esempio da casa, da un bar 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 gli elenccontrollo dell'accessosso.

BeyondProd affronta lo stesso problema per i servizi di produzione di Chrome Enterprise Premium per gli utenti. In un'architettura cloud-native, non possiamo fare affidamento solo su un firewall per proteggere la rete di produzione. I microservizi vengono spostati e implementati in ambienti diversi, su host eterogenei e operano a vari livelli di attendibilità e sensibilità. In Chrome Enterprise Premium, l'attendibilità dell'utente dipende da caratteristiche come lo stato sensibile al contesto dei dispositivi e non dalla possibilità di connettersi alla rete aziendale. In BeyondProd, l'affidabilità del servizio dipende 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 singoli microservizi nei 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 la propria API, il proprio rollout, la propria scalabilità e la propria gestione delle quote. I microservizi sono indipendenti, modulari, dinamici ed effimeri. Possono essere distribuiti su molti host, cluster o persino cloud. In un'architettura di microservizi, un carico di lavoro può essere uno o più microservizi.

Un'infrastruttura containerizzata significa che ogni microservizio viene implementato come proprio insieme di container mobili e pianificabili. 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 su più macchine. Il packaging dei microservizi nei container consente di suddividere i carichi di lavoro in unità più piccole e gestibili per la manutenzione e il rilevamento. Questa architettura scala i carichi di lavoro in base alle necessità: se la domanda per un determinato carico di lavoro è elevata, possono essere presenti più macchine che eseguono copie dello stesso container per gestire la scalabilità richiesta del carico di lavoro.

In Google, la sicurezza svolge un ruolo fondamentale in ogni evoluzione della nostra architettura. Il nostro obiettivo con questa architettura e questo processo di sviluppo dei microservizi è quello di affrontare i problemi di sicurezza il prima possibile nel ciclo di vita di sviluppo e deployment (quando la risoluzione dei problemi è meno costosa) e di farlo in modo 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 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 dagli attacchi di rete e dal traffico non autorizzato da internet. Sebbene l'approccio perimetrale non sia un concetto nuovo, rimane una best practice di sicurezza per le architetture cloud. Un approccio perimetrale aiuta a proteggere la maggior parte dell'infrastruttura da traffico non autorizzato e potenziali attacchi da internet, come attacchi DoS basati sul volume.
  • Nessuna fiducia reciproca intrinseca tra i servizi: solo i chiamanti o i servizi autenticati, attendibili e specificamente autorizzati possono accedere a qualsiasi altro servizio. In questo modo, gli autori degli attacchi non possono utilizzare codice non attendibile per accedere a un servizio. Se un servizio viene compromesso, questo vantaggio impedisce all'attaccante di eseguire azioni che gli consentano di espandere la propria portata. Questa sfiducia reciproca, combinata concontrollo dell'accessoo granulare, contribuisce a limitare l'ambito e l'impatto di una compromissione.
  • Macchine attendibili che eseguono codice con provenienza nota:le identità di servizio sono vincolate a utilizzare solo codice e configurazioni autorizzati e a essere eseguite solo in ambienti autorizzati e verificati.
  • Applicazione coerente delle norme nei vari servizi:l'applicazione coerente delle norme contribuisce a garantire che le decisioni di accesso siano affidabili nei vari 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 giustificazione aziendale.
  • Implementazione delle modifiche semplice, automatizzata e standardizzata: le modifiche all'infrastruttura possono essere facilmente esaminate per verificarne l'impatto sulla sicurezza e le patch di sicurezza possono essere implementate con un impatto minimo sulla produzione.
  • Isolamento tra i workload che condividono un sistema operativo: se un servizio viene compromesso, non può influire sulla sicurezza di un altro workload in esecuzione sullo stesso host. Questo isolamento contribuisce a limitare l'impatto e la portata di un workload compromesso.
  • 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 workload.

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 protezione perimetrale della rete. GFE termina la connessione dall'utente finale e fornisce un punto centrale per l'applicazione delle best practice TLS.

Anche se non ci concentriamo più sulla sicurezza basata sul perimetro, GFE è ancora una parte importante della nostra strategia per proteggere i servizi interni dagli attacchi DoS. GFE è il primo punto di accesso per un utente che si connette all'infrastruttura 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 in base alle esigenze. GFE è il proxy edge che instrada il traffico al microservizio corretto.

Le VM dei clienti su Google Cloud non si registrano con 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 è abilitato l'accesso privato Google.

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

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

Ogni macchina dispone di una credenziale ALTS di cui viene eseguito il provisioning utilizzando il sistema di integrità dell'host e può essere decriptata solo se il sistema di integrità dell'host ha verificato che l'avvio protetto è andato a buon fine. La maggior parte dei servizi Google viene eseguita come microservizi su Borg e questi microservizi hanno ciascuno la propria identità ALTS. Borg Prime, il controller centralizzato di Borg, concede queste credenziali del microservizio ALTS ai carichi di lavoro in base all'identità del microservizio. Le credenziali ALTS a livello di macchina formano 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à dell'host possano ospitare carichi di lavoro dei microservizi. Per saperne di più sulle credenziali ALTS, consulta Certificati workload.

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 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 di BAB include la verifica che le modifiche vengano esaminate da un secondo ingegnere prima che il codice venga inviato al nostro repository di codice sorgente e che i file binari vengano creati in modo verificabile su un'infrastruttura dedicata. Nella nostra infrastruttura, BAB limita il deployment di microservizi non autorizzati.

Integrità dell'host per l'attendibilità della macchina

Integrità host verifica l'integrità del software di sistema host tramite un processo di avvio protetto ed è supportata da un chip di sicurezza hardware radice di attendibilità (chiamato Titan) dove supportato. I controlli dell'integrità dell'host includono la verifica delle firme digitali su BIOS, baseboard management controller (BMC),

bootloader e kernel del sistema operativo. Se supportati, i controlli dell'integrità dell'host possono includere codice in modalità utente e firmware periferico (ad esempio NIC). Oltre alla verifica della firma digitale, l'integrità dell'host contribuisce a garantire che ogni host esegua la versione prevista di questi componenti software.

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

La gestione dell'accesso ai servizi e i ticket del 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 viene inviato un RPC da un servizio a un altro, la gestione dell'accesso ai servizi definisce le policy di autorizzazione e controllo richieste dai servizi per accedere ai dati del servizio ricevente. Ciò limita la modalità di accesso ai dati, concede il livello minimo di accesso necessario e specifica come può essere verificato l'accesso. Nell'infrastruttura di 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 dell'accesso.

I ticket di contesto dell'utente finale vengono emessi da un servizio di autenticazione dell'utente finale e forniscono ai servizi un'identità utente separata dall'identità del servizio. Questi ticket sono protetti dall'integrità, emessi centralmente e trasferibili credenziali che attestano l'identità di un utente finale che ha effettuato una richiesta al servizio. Questi ticket riducono la necessità di fiducia tra i servizi, perché le identità peer che utilizzano ALTS possono essere insufficienti per 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 delle modifiche semplice, automatizzata e standardizzata. Un 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à 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, con nuovi job di cui viene eseguito il deployment quando il carico aumenta e job esistenti terminati quando il carico diminuisce.

Gli strumenti Borg sono responsabili della migrazione dei workload 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. Questo processo consente di aggiornare un microservizio senza tempi di inattività e senza che l'utente se ne accorga.

Utilizziamo questo strumento anche per applicare gli upgrade del servizio quando aggiungiamo nuove funzionalità e per applicare aggiornamenti della sicurezza critici 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 maggiori informazioni, consulta Autorizzazione binaria per Borg.

Kernel gVisor per l'isolamento dei workload

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 di attacco. Questo kernel fornisce la maggior parte delle funzionalità necessarie per eseguire un'applicazione e limita la superficie del kernel host accessibile all'applicazione.

Borg viene in genere utilizzato per carichi di lavoro interni attendibili di Google creati da ingegneri Google, pertanto questi carichi di lavoro non richiedono un sandbox di sicurezza. gVisor viene utilizzato per i carichi di lavoro Borg che eseguono codice di terze parti o elaborano dati non attendibili. Alcuni esempi includono la scansione antivirus di Gmail, l'elaborazione dei video di YouTube e le query personalizzate sui dati utente.

gVisor è uno dei vari strumenti che utilizziamo per isolare i workload interni e quelli dei clienti che vengono eseguiti sullo stesso host. Google Cloud Per saperne di più su altri strumenti di sandboxing, consulta Sandboxing del codice.

Proteggere i 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 alla destinazione.
  • Una modifica del codice dallo sviluppo alla produzione.

Non tutte le tecnologie elencate vengono utilizzate in tutte le parti della nostra infrastruttura, ma dipende dai servizi e dai 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 nativi del cloud di Google che accedono ai dati degli utenti. I passaggi per accedere agli account utente sono i seguenti:

  1. Un utente invia una richiesta a 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 centrale di autenticazione utente finale (EUA) e, se l'autenticazione va a buon fine, riceve un ticket di contesto utente finale crittografico di breve durata.
  4. Il frontend dell'applicazione esegue una RPC su ALTS a un servizio di backend di archiviazione, inoltrando il ticket nella richiesta di backend.
  5. Il servizio di backend utilizza la gestione dell'accesso al servizio per garantire che vengano soddisfatti i seguenti criteri:
    • L'autenticazione del frontend viene eseguita utilizzando un certificato valido e non revocato. Questo controllo implica che l'app viene eseguita su un host attendibile e che i controlli BAB sono stati completati correttamente.
    • L'identità ALTS del servizio frontend è autorizzata a effettuare richieste al servizio di backend e a presentare 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 dell'applicazione autorizzata e mostrati all'utente autorizzato.

In molti casi, esiste una catena di chiamate di 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 saperne di più su come viene indirizzato il traffico all'interno della nostra infrastruttura, consulta la pagina 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.

I passaggi per apportare una modifica al codice sono i seguenti:

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

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

  3. Borg gestisce tutti gli aggiornamenti dei workload 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 nel nuovo deployment utilizzando il bilanciamento del carico per garantire la continuità delle operazioni.

Per saperne di più su questo processo, consulta la sezione Il nostro processo di sviluppo e produzione.

Tutti i carichi di lavoro devono essere isolati. Se il workload è meno attendibile perché il codice sorgente proviene da un'origine esterna a Google, viene eseguito il deployment con livelli di isolamento più elevati, ad esempio in un ambiente protetto da gVisor. Questo isolamento aiuta 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 loro punti di contrasto in un'architettura cloud-native.

Architettura dell'applicazione

Un modello di sicurezza più tradizionale, incentrato sulla sicurezza basata sul perimetro, non può 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 capacità sufficiente a gestire il carico di picco per eventi critici. Le applicazioni con requisiti hardware o di rete specifici sono state implementate intenzionalmente su macchine specifiche che in genere mantengono indirizzi IP fissi. I rollout erano poco frequenti, 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 applicate in genere 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 di terze parti. Pertanto, anziché un'applicazione monolitica, un'applicazione containerizzata suddivisa in microservizi diventa ideale per gli ambienti cloud. I container separano i file binari necessari per l'applicazione dal sistema operativo host sottostante e rendono le applicazioni più portatili. I nostri container sono immutabili, il che significa che non cambiano dopo il deployment. ma vengono ricompilati e ridistribuiti di frequente.

Con i container riavviati, arrestati o riprogrammati spesso, l'hardware e la rete vengono riutilizzati e condivisi più frequentemente. Con un processo di compilazione e distribuzione standardizzato comune, il processo di sviluppo è più coerente e uniforme tra i team, anche se i team gestiscono in modo indipendente lo sviluppo dei propri microservizi. Di conseguenza, le considerazioni sulla 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

La creazione di un'infrastruttura condivisa e progettata in modo sicuro, utilizzata da tutti gli sviluppatori, riduce al minimo l'onere per gli sviluppatori di conoscere e implementare i requisiti di sicurezza comuni. La funzionalità di sicurezza dovrebbe richiedere un'integrazione minima o nulla in ogni applicazione e viene invece fornita come tessuto che avvolge e collega tutti i microservizi. Questo è comunemente chiamato service mesh. Ciò significa anche che la sicurezza può essere gestita e implementata separatamente dalle normali attività di sviluppo o deployment.

Un mesh di servizi è un tessuto condiviso a livello di infrastruttura che avvolge e connette tutti i microservizi. Un mesh di servizi consente la comunicazione tra servizi, che può controllare il traffico, applicare policy e fornire un monitoraggio centralizzato per le chiamate di servizio.

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 rimuovi la dipendenza da firewall o controlli basati sulla rete, puoi implementare la segmentazione a livello di microservizio, senza alcuna attendibilità intrinseca tra i servizi. Con la segmentazione a livello di microservizio, il traffico può avere livelli di attendibilità variabili con controlli diversi e non si confronta più solo 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 di soddisfare i propri requisiti di sicurezza indipendentemente dagli altri servizi. Questi requisiti includono la gestione delle identità, la terminazione TLS e la gestione dell'accesso ai dati. Ciò può portare a implementazioni incoerenti o a problemi di sicurezza non risolti perché questi problemi devono essere corretti in molti punti, il che rende più difficile l'applicazione delle correzioni.

In un'architettura cloud-native, i servizi riutilizzano i componenti molto più spesso. I punti di strozzatura consentono l'applicazione coerente dei criteri tra i servizi. È possibile applicare policy diverse utilizzando servizi di sicurezza diversi. Anziché richiedere a ogni applicazione di implementare separatamente i servizi di sicurezza critici, puoi dividere le varie policy 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, i rollout 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, ciò può portare ad applicazioni con un ciclo di vita estremamente lungo.

Dal punto di vista della sicurezza, poiché 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, i rollout sono frequenti e standardizzati. Questo processo consente di spostare la sicurezza nelle fasi iniziali del ciclo di vita dello sviluppo software. Lo shift left si riferisce allo spostamento dei passaggi all'inizio del ciclo di vita dello sviluppo del software, che può includere passaggi come codifica, build, test, convalida e deployment. Lo spostamento a sinistra consente un'applicazione più semplice e coerente della sicurezza, incluso l'applicazione regolare di patch di sicurezza.

Eseguire il passaggio a BeyondProd

La transizione di Google a BeyondProd ha richiesto modifiche in due aree principali: nella nostra infrastruttura e nel nostro processo di sviluppo. Abbiamo apportato queste modifiche contemporaneamente, ma puoi gestirle 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 esserefare lo scale ine come 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 eccezionale, non di routine, e gli interventi devono essere verificabili quando si verificano. Possiamo quindi autenticare un servizio in base al codice e alla configurazione distribuiti per il servizio, anziché in base alle persone che hanno distribuito il servizio.

Abbiamo iniziato dalla costruzione di solide fondamenta di identificazione, autenticazione e autorizzazione dei servizi. Un microservizio utilizza un'identità di servizio per autenticarsi con altri servizi in esecuzione nell'infrastruttura. Avere una base di identità di servizio attendibili ci ha permesso di implementare funzionalità di sicurezza di livello superiore che dipendono dalla convalida di queste identità di servizio, come la gestione dell'accesso ai servizi e i ticket di contesto dell'utente finale. Per semplificare questa transizione sia per i servizi nuovi che per quelli esistenti, ALTS è stato inizialmente fornito come libreria con un unico daemon helper. Questo daemon veniva eseguito sull'host chiamato da ogni servizio e nel tempo si è evoluto in una libreria che utilizza le credenziali di servizio. La libreria ALTS è stata integrata perfettamente nella libreria RPC principale. Questa integrazione ha semplificato l'adozione su larga scala, senza gravare in modo significativo sui singoli team di sviluppo. L'implementazione di ALTS è stata un prerequisito per l'implementazione della gestione dell'accesso ai servizi e dei ticket di contesto per gli utenti finali.

Modifica dei nostri processi di sviluppo

Per Google era fondamentale stabilire una solida procedura di build e revisione del codice per garantire l'integrità dei servizi in esecuzione. Abbiamo creato un processo di build centrale in cui abbiamo potuto iniziare a imporre requisiti come la revisione del codice da parte di due persone e i test automatici durante la build e il deployment. Per maggiori dettagli sul deployment, vedi Autorizzazione binaria per Borg.

Dopo aver stabilito le basi, abbiamo iniziato ad affrontare la necessità di eseguire codice esterno non attendibile nei nostri ambienti. Per raggiungere questo obiettivo, abbiamo iniziato a utilizzare la sandbox, prima con ptrace, poi con gVisor. Analogamente, i deployment blu/verde hanno fornito vantaggi significativi in termini di sicurezza (ad esempio, applicazione di patch) e affidabilità.

Abbiamo scoperto rapidamente che era più semplice se un servizio iniziava registrando le violazioni delle norme anziché bloccarle. Il vantaggio di questo approccio era duplice:

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

Ad esempio, quando un servizio viene integrato in BAB, i proprietari del servizio attivano la modalità di solo controllo. Tale modalità consente di identificare codice o carichi di lavoro che non soddisfano i requisiti. Dopo aver risolto i problemi segnalati dalla modalità solo controllo, 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