Iniziativa BeyondProd

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

Questo documento descrive in che modo Google implementa la sicurezza nella nostra infrastruttura utilizzando un'architettura cloud-native denominata 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 attività univoche completate da un'applicazione. BeyondProd contribuisce a proteggere i microservizi che esegui nel nostro ambiente, comprese le modalità con cui modifichiamo il codice e il modo in cui accediamo ai dati utente.

Questo documento fa parte di una serie di articoli tecnici che descrivono le tecnologie, quali BeyondCorp Enterprise, che abbiamo sviluppato per aiutare a difendere le piattaforme Google da minacce sofisticate. BeyondCorp Enterprise implementa un'architettura Zero Trust progettata per fornire un accesso sicuro alle piattaforme Google e ai servizi in esecuzione sulle piattaforme. Come BeyondCorp Enterprise, BeyondProd non si basa sulle tradizionali protezioni perimetrali di rete, come i firewall. BeyondProd, invece, contribuisce a creare affidabilità tra i microservizi utilizzando caratteristiche come provenienza del codice, identità di servizio e hardware affidabile. Questa attendibilità si estende al software eseguito in Google Cloud e al software di cui sono stati eseguiti il deployment e l'accesso ai clienti Google Cloud.

Questo documento descrive i vantaggi di BeyondProd, i suoi servizi e processi e il modo in cui abbiamo eseguito la 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 sono state abbandonate da un modello di sicurezza tradizionale basato sul perimetro, in cui un firewall protegge il perimetro e tutti gli utenti o i servizi al suo interno vengono considerati attendibili.

Oggi gli utenti sono mobili e operano comunemente al di fuori del tradizionale perimetro di sicurezza di un'organizzazione, ad esempio da casa, da un bar o da un aereo. Con BeyondCorp Enterprise, 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 degli utenti e gli elenchi di controllo dell'accesso.

BeyondProd risponde alla stessa domanda per i servizi di produzione di BeyondCorp Enterprise per gli utenti. In un'architettura cloud-native, non possiamo semplicemente fare affidamento su un firewall per proteggere la rete di produzione. I microservizi si spostano e vengono distribuiti in ambienti diversi, tra host eterogenei e operano a diversi livelli di attendibilità e sensibilità. Se BeyondCorp Enterprise indica che l'attendibilità degli utenti deve dipendere da caratteristiche quali lo stato sensibile al contesto dei dispositivi e non dalla capacità di connettersi alla rete aziendale, BeyondProd afferma che l'attendibilità del servizio deve dipendere da caratteristiche come la provenienza del codice, l'hardware attendibile e l'identità del servizio, anziché la località nella rete di produzione, ad esempio l'indirizzo IP o il nome host.

Infrastruttura containerizzata

La nostra infrastruttura esegue il deployment dei carichi di lavoro come microservizi singoli all'interno di 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, un carico di lavoro può comprendere uno o più microservizi.

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

I container semplificano e rendono più efficienti la pianificazione dei carichi di lavoro su più macchine. L'imballaggio di microservizi in 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 in base alle esigenze: in caso di domanda elevata per un particolare carico di lavoro, potrebbero esserci più macchine che eseguono copie dello stesso container per gestire la scalabilità richiesta del carico di lavoro.

In Google, la sicurezza gioca un ruolo fondamentale in ogni evoluzione della nostra architettura. Il nostro obiettivo con questa architettura di microservizi e il processo di sviluppo è risolvere i problemi di sicurezza il prima possibile nel ciclo di vita dello sviluppo e del deployment (quando la risoluzione dei problemi è meno costosa) e di farlo in un 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 numerosi vantaggi in termini di automazione e sicurezza all'infrastruttura di Google. I vantaggi includono:

  • Protezione perimetrale della rete. I carichi di lavoro vengono isolati dagli attacchi di rete e dal traffico Internet non autorizzato. 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 il più possibile l'infrastruttura da traffico non autorizzato e potenziali attacchi da internet, come attacchi DoS basati sul volume.
  • Nessuna attendibilità 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 utenti malintenzionati non possono utilizzare codice non attendibile per accedere a un servizio. Se un servizio viene compromesso, questo vantaggio aiuta a impedire all'utente malintenzionato di eseguire azioni che gli consentano di espandere la propria copertura. Questa diffidenza reciproca, combinata con un controllo granulare degli accessi, aiuta a limitare la portata dell'attacco di una compromissione.
  • Macchine attendibili che eseguono codice di provenienza nota: le identità di servizio sono vincolate all'utilizzo solo di configurazioni e codice autorizzati ed eseguite solo in ambienti verificati e autorizzati.
  • Applicazione coerente dei criteri nei vari servizi: l'applicazione coerente dei criteri contribuisce a garantire che le decisioni di accesso siano affidabili tra i vari servizi. Ad esempio, puoi creare un'applicazione forzata dei criteri per verificare 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 semplice, automatica e standardizzata delle modifiche: le modifiche all'infrastruttura possono essere facilmente esaminate per valutare il loro impatto sulla sicurezza ed è possibile implementare le patch di sicurezza con un impatto minimo sulla produzione.
  • Isolamento dei carichi di lavoro che condividono lo stesso sistema operativo: la compromissione di un servizio non può influire sulla sicurezza di un altro carico di lavoro in esecuzione sullo stesso host. Ciò consente di limitare la portata dell'attacco di una potenziale compromissione.
  • Hardware e attestazione attendibili: una radice di attendibilità hardware aiuta ad assicurare che solo il codice noto e autorizzato (dal firmware alla modalità utente) sia in esecuzione sull'host prima che venga pianificata l'esecuzione di qualsiasi carico di lavoro.

Questi vantaggi consentono di eseguire il deployment dei container e dei microservizi in esecuzione all'interno della nostra architettura cloud, nonché di comunicare tra loro ed essere eseguiti uno accanto all'altro senza indebolire la sicurezza della nostra infrastruttura. Inoltre, i singoli sviluppatori di microservizi non sono sovraccaricati dai dettagli di sicurezza e implementazione dell'infrastruttura sottostante.

Servizi di sicurezza BeyondProd

Abbiamo progettato e sviluppato diversi servizi di sicurezza di BeyondProd per creare i vantaggi illustrati nella pagina Vantaggi di BeyondProd. Le sezioni seguenti descrivono i servizi di sicurezza.

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

Google Front End (GFE) fornisce una protezione perimetrale della rete. GFE termina la connessione per l'utente finale e fornisce un punto centrale per applicare le best practice TLS.

Anche se la nostra enfasi non è più sulla sicurezza perimetrale, GFE è ancora una parte importante della nostra strategia per la protezione dei servizi interni dagli attacchi DoS. GFE è il primo punto di accesso per un utente che si connette all'infrastruttura di Google. Quando 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 perimetrale che instrada il traffico al microservizio corretto.

Le VM dei clienti su Google Cloud non vengono registrate con GFE. Si registrano invece con Cloud Front End, una configurazione speciale di GFE che utilizza lo stack di networking di Compute Engine. Cloud Front End consente alle VM dei clienti di accedere a un servizio Google direttamente 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. Inoltre, vengono utilizzati per ALTS;autenticazione delle chiamata di procedura remota (RPC), l'integrità, la crittografia del traffico e le identità dei servizi. ALTS tratta di 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 a un host specifico. Questa associazione consente la replica perfetta di microservizi, il bilanciamento del carico e la ripianificazione tra host.

Ogni macchina dispone di credenziali ALTS di cui viene eseguito il provisioning mediante il sistema di integrità host e che può essere decriptata solo se il sistema ha verificato che l'avvio protetto è riuscito. 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 a livello di 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à dell'host possano ospitare i carichi di lavoro dei microservizi. Per ulteriori informazioni sulle credenziali ALTSk, consulta la pagina relativa ai 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 di applicazione forzata in fase di deployment che aiuta a garantire che il codice soddisfi i requisiti di sicurezza interni prima che venga eseguito il deployment. Ad esempio, il controllo dell'applicazione forzata di BAB include la garanzia che le modifiche vengano esaminate da un secondo tecnico prima che il codice venga inviato al nostro repository del codice sorgente e che i programmi binari siano creati in modo verificabile nell'infrastruttura dedicata. Nella nostra infrastruttura, BAB limita il deployment di microservizi non autorizzati.

Integrità host per l'attendibilità delle macchine

Integrità host verifica l'integrità del software del sistema host tramite un processo di avvio protetto ed è supportata da un chip di sicurezza radice di attendibilità hardware (chiamato Titan) se supportato. I controlli di integrità dell'host includono la verifica delle firme digitali sul BIOS, sul controller di gestione del baseboard (BMC), sul bootloader e sul kernel del sistema operativo. Se supportati, i controlli di integrità dell'host possono includere codice in modalità utente e firmware delle periferiche (ad esempio le 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 di contesto per l'utente finale per l'applicazione dei criteri

Gestione dell'accesso ai servizi e richieste di contesto dell'utente finale contribuiscono a fornire un'applicazione dei criteri coerente tra i 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 i criteri di autorizzazione e controllo richiesti dai servizi per accedere ai dati del servizio ricevente. Questo limita le modalità di accesso ai dati, garantisce il livello minimo di accesso necessario e specifica come può essere controllato 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 degli accessi.

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 da quella del servizio. Questi ticket sono credenziali protette dall'integrità, emesse a livello centrale e inoltrabili che attestano l'identità di un utente finale che ha presentato una richiesta del servizio. Questi ticket riducono la necessità di rapporti di attendibilità tra i servizi, poiché le identità peer che utilizzano ALTS possono essere insufficienti per concedere l'accesso, quando tali 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 subiscano 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, viene eseguito il deployment di nuovi job all'aumentare del carico e quelli esistenti vengono terminati quando il carico diminuisce.

Gli strumenti Borg sono responsabili della migrazione dei carichi di lavoro in esecuzione quando eseguiamo le 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.

Usiamo questo strumento anche per applicare upgrade dei servizi quando aggiungiamo nuove funzionalità e per applicare aggiornamenti critici della sicurezza senza tempi di inattività (ad esempio, Heartbleed e Spectre/Meltdown). Per 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 ulteriori informazioni, consulta Autorizzazione binaria per Borg.

Kernel gVisor per l'isolamento dei carichi di lavoro

Il kernel gVisor consente l'isolamento tra 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. gVisor è uno dei numerosi strumenti che utilizziamo per isolare i carichi di lavoro interni e quelli dei clienti Google Cloud eseguiti sullo stesso host. Per ulteriori informazioni su altri strumenti di sandboxing, consulta Sandboxing codice.

Protezione dei dati utente con BeyondProd

Questa sezione descrive in che modo i servizi BeyondProd interagiscono per proteggere i dati utente nella nostra infrastruttura. Le sezioni seguenti descrivono due esempi:

  • Accesso alle richieste di dati degli utenti dalla creazione alla consegna a destinazione.
  • Un passaggio al codice dallo sviluppo alla produzione.

Non tutte le tecnologie elencate sono utilizzate in tutte le parti della nostra infrastruttura; questo dipende dai servizi e dai carichi di lavoro.

Accesso ai dati utente

Il diagramma seguente mostra il processo utilizzato 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 degli utenti.

Per accedere agli account utente, procedi nel seguente modo:

  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 crittografico di breve durata per l'utente finale.
  4. Il frontend dell'applicazione invia una RPC tramite 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 ai servizi per garantire che i seguenti criteri siano veri:
    • Il frontend è autenticato utilizzando un certificato valido e non revocato. Questo controllo indica che è in esecuzione su un host attendibile e che i controlli BAB sono riusciti.
    • L'identità ALTS del servizio di frontend è autorizzata a inviare richieste al servizio di backend e presentare un ticket EUC.
    • Il ticket di contesto per l'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 inviati 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 su come il traffico viene instradato all'interno della nostra infrastruttura, vedi In che modo il traffico viene instradato.

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 modifica viene inviata al nostro repository di codice centrale, , che applica la revisione del codice. Dopo l'approvazione, la modifica viene inviata al sistema di build centrale affidabile che produce un pacchetto con un certificato firmato per il manifest di build verificabile.

  2. Al momento del deployment, BAB verifica che questo 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 interruzioni minime ai servizi, che si tratti di un'implementazione di routine o di una 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 la pagina Il nostro processo di sviluppo e produzione.

Tutti i carichi di lavoro devono essere isolati. Se il carico di lavoro è meno attendibile perché il codice sorgente proviene dall'esterno di Google, potrebbe essere stato eseguito il deployment in un ambiente protetto da gVisor oppure utilizzare altri livelli di isolamento. Questo isolamento aiuta a contenere un utente malintenzionato 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 tradizionale e i relativi contrappunti in un'architettura cloud-native.

Architettura dell'applicazione

Un modello di sicurezza più tradizionale, incentrato sulla sicurezza basata sul perimetro, non è in grado di proteggere da solo un'architettura cloud-native. Tradizionalmente, le applicazioni monolitiche utilizzavano un'architettura a tre livelli e venivano distribuite in data center aziendali privati che avevano una capacità sufficiente per gestire i picchi di carico in caso di eventi critici. Le applicazioni con requisiti hardware o di rete specifici sono state appositamente distribuite su macchine specifiche che in genere mantengono indirizzi IP fissi. Le implementazioni erano poco frequenti, di grandi dimensioni e difficili da coordinare poiché le modifiche risultanti hanno interessato contemporaneamente molte parti dell'applicazione. Ciò ha portato ad applicazioni di lunga durata che vengono aggiornate con minore frequenza e a cui le patch di sicurezza vengono generalmente applicate meno frequentemente.

Tuttavia, in un modello cloud-native, le applicazioni devono essere portabili tra ambienti diversi, perché possono essere eseguite in cloud pubblici, data center privati o servizi ospitati di terze parti. Di conseguenza, 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 la tua applicazione dal sistema operativo host sottostante e rendono le applicazioni più portabili. I nostri container sono immutabili, ovvero non cambiano dopo il deployment. ma vengono ricreati ed eseguiti di nuovo di frequente.

Con i container che vengono riavviati, arrestati o riprogrammati spesso, il riutilizzo e la condivisione di hardware e networking sono più frequenti. Con un processo di creazione e distribuzione standardizzato e 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 relative alla sicurezza (come le revisioni della sicurezza, la scansione del codice e la 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, utilizzata da tutti gli sviluppatori, il carico per gli sviluppatori di conoscere e implementare requisiti di sicurezza comuni è ridotto al minimo. La funzionalità di sicurezza dovrebbe richiedere un'integrazione minima o nulla in ogni applicazione e viene invece fornita come un'infrastruttura che avvolge e connette tutti i microservizi. Questo è comunemente chiamato mesh di servizi. Ciò significa anche che la sicurezza può essere gestita e implementata separatamente dalle normali attività di sviluppo o deployment.

Un mesh di servizi è un fabric condiviso a livello di infrastruttura che avvolge e connette tutti i microservizi. Un mesh di servizi consente la comunicazione tra servizi, in grado di 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, non esistono firewall. Altri controlli, come l'identità, l'autenticazione e l'autorizzazione dei carichi di lavoro, contribuiscono invece a proteggere i microservizi garantendo che le connessioni interne o esterne vengano convalidate prima che possano essere eseguite transazioni. Quando rimuovi la dipendenza dai firewall o dai controlli basati sulla rete, puoi implementare la segmentazione a livello di microservizi senza attendibilità intrinseca tra i servizi. Con la segmentazione a livello di microservizi, il traffico può avere diversi livelli di attendibilità con controlli diversi e non viene più confrontato 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 del soddisfazione dei propri requisiti di sicurezza, indipendentemente dagli altri servizi. Tali requisiti includono gestione delle identità, terminazione TLS e gestione dell'accesso ai dati. Ciò può portare a implementazioni incoerenti o problemi di sicurezza non risolti, poiché questi problemi devono essere risolti in molti punti, il che rende più difficile l'applicazione delle correzioni.

In un'architettura cloud-native, i componenti vengono riutilizzati molto più spesso tra i servizi. I punti di passaggio obbligato consentono l'applicazione coerente dei criteri nei vari servizi. È possibile applicare criteri diversi utilizzando servizi di sicurezza diversi. Anziché richiedere a ogni applicazione di implementare separatamente i servizi di sicurezza critici, puoi suddividere i vari criteri in microservizi separati. Ad esempio, puoi creare un criterio per garantire l'accesso autorizzato ai dati utente e creare un altro criterio 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 è spesso duplicato e abbinato allo sviluppo locale. Una condivisione limitata rende più difficile determinare l'impatto di una modifica e in che modo la modifica potrebbe interessare 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 ciascun componente (ad esempio, aprendo le connessioni SSH a ogni macchina virtuale per aggiornare una configurazione). Nel complesso, ciò può portare a applicazioni di durata estremamente lunga.

Dal punto di vista della sicurezza, poiché il codice è 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 alla sicurezza di abbassare il ciclo di vita dello sviluppo del software. Lo spostamento a sinistra si riferisce all'anticipazione di fasi nel ciclo di vita dello sviluppo del software, che possono includere passaggi come il codice, la creazione, il test, la convalida e il deployment. Lo spostamento a sinistra consente un'applicazione della sicurezza più semplice e coerente, inclusa la regolare applicazione delle patch di sicurezza.

Apportare la modifica a BeyondProd

La transizione di Google a BeyondProd ha richiesto modifiche in due aree principali: nell'infrastruttura e nel processo di sviluppo. Abbiamo affrontato queste modifiche contemporaneamente, 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 nell'intera infrastruttura perché riteniamo che la sicurezza debba essere scalata allo stesso modo in cui scalano i servizi. I servizi devono essere sicuri per impostazione predefinita e non sicuri per eccezione. L'intervento umano diretto nella nostra infrastruttura dovrebbe essere un'eccezione, non di routine e gli interventi devono essere verificabili quando si verificano. Possiamo quindi autenticare un servizio in base al codice e alla configurazione di cui è stato eseguito il deployment, invece che sulle 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à di servizio per autenticarsi ad altri servizi in esecuzione nell'infrastruttura. La presenza di una base di identità di servizio attendibili ci ha consentito di implementare funzionalità di sicurezza di livello superiore dipendenti dalla convalida di tali identità di servizio, come la gestione dell'accesso ai servizi e i ticket di contesto per l'utente finale. Per rendere semplice questa transizione per i servizi nuovi ed esistenti, dapprima è stato fornito ALTS come libreria con un singolo daemon helper. Questo daemon veniva eseguito sull'host chiamato da ogni servizio e si è evoluto nel tempo in una libreria che utilizza le credenziali di servizio. La libreria AltS è stata integrata perfettamente nella libreria RPC principale. Questa integrazione ha reso più facile un'ampia adozione, senza oneri significativi per i singoli team di sviluppo. L'implementazione del ALTS) era 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 è stato fondamentale stabilire una solida procedura di build e revisione del codice per garantire l'integrità dei servizi in esecuzione. Abbiamo creato un processo di compilazione centrale in cui potevamo iniziare ad applicare requisiti come la revisione del codice da parte di due persone e i test automatici durante le fasi di creazione e deployment. Per ulteriori dettagli sul deployment, consulta Autorizzazione binaria per Borg.

Dopo aver messo a punto le basi, abbiamo iniziato a occuparci della necessità di eseguire codice esterno non attendibile nei nostri ambienti. Per raggiungere questo obiettivo, abbiamo avviato il sandboxing, prima con ptrace e, successivamente, utilizzando gVisor. Allo stesso modo, i deployment blu/verde hanno offerto vantaggi significativi 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 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 sul loro servizio.
  • Ci ha consentito di correggere eventuali bug e di identificare eventuali funzionalità aggiuntive che potremmo dover fornire ai team di servizio.

Ad esempio, quando un servizio viene inizializzato 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. Dopo aver risolto 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