Iniziativa BeyondProd

Mantieni tutto organizzato con le raccolte Salva e classifica i contenuti in base alle tue preferenze.

Questi contenuti sono stati aggiornati l'ultima volta a novembre 2022 e rappresentano lo stato attuale del momento in cui sono stati scritti. Le norme e i sistemi di sicurezza di Google possono cambiare in futuro, in quanto miglioriamo costantemente la 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 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 le modalità di accesso ai dati utente.

Questo documento fa parte di una serie di documenti tecnici che descrivono le tecnologie, come BeyondCorp Enterprise, che abbiamo sviluppato per contribuire a difendere le piattaforme Google da minacce sofisticate. BeyondCorp Enterprise implementa un'architettura Zero Trust progettata per fornire l'accesso sicuro alle piattaforme Google e ai servizi in esecuzione. Come BeyondCorp Enterprise, BeyondProd non si basa sulle protezioni di perimetro tradizionali di rete come i firewall. Invece, BeyondProd aiuta a creare attendibilità tra i microservizi utilizzando caratteristiche come la provenienza del codice, le identità di servizio e l'hardware attendibile. Questa fiducia si estende al software eseguito in Google Cloud e al software di cui viene eseguito il deployment e che accede ai clienti Google Cloud.

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

Introduzione

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

Oggi gli utenti sono mobili e in genere operano all'esterno del perimetro di sicurezza tradizionale di un'organizzazione, ad esempio da casa, da un bar o da un aereo. Attraverso BeyondCorp Enterprise, concediamo l'accesso alle risorse aziendali tramite più fattori, tra cui l'identità dell'utente, l'identità del dispositivo utilizzata per accedere alla risorsa, lo stato del dispositivo, indicatori di attendibilità quali il comportamento dell'utente e gli elenchi di controllo dell'accesso.

BeyondProd risponde alla stessa preoccupazione 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 implementati in ambienti diversi, su host eterogenei e operano a vari livelli di affidabilità e sensibilità. Laddove BeyondCorp Enterprise afferma che l'utente la fiducia dovrebbe dipendere da caratteristiche come lo stato sensibile al contesto dei dispositivi e non la possibilità di connettersi alla rete aziendale, BeyondProd afferma che la fiducia del servizio deve dipendere da caratteristiche come la provenienza del codice, la provenienza e la provenienza dell'indirizzo,

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 la propria API, implementazione, scalabilità e gestione delle quote. 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ò contenere uno o più microservizi.

Un'infrastruttura containerizzata fa sì che venga eseguito il deployment di ogni microservizio come insieme di container spostabili e programmabili. Per gestire internamente questi container, abbiamo sviluppato un sistema di orchestrazione dei container chiamato Borg, che esegue il deployment di vari miliardi di container a settimana. Borg è il sistema di gestione dei container unificato di Google e l'ispirazione per Kubernetes.

I container semplificano la pianificazione e l'efficienza dei carichi di lavoro tra le macchine. La pacchettizzazione dei microservizi nei container consente di suddividere i carichi di lavoro in unità più piccole e più gestibili per la manutenzione e il rilevamento. Questa architettura scala i carichi di lavoro in base alle esigenze: in caso di domanda elevata per un particolare carico di lavoro, più macchine possono eseguire copie dello stesso container per gestire la scalabilità richiesta del carico di lavoro.

In Google, la sicurezza ha un ruolo fondamentale in ogni evoluzione della nostra architettura. L'obiettivo di questa architettura di microservizi e del processo di sviluppo è risolvere i problemi di sicurezza il prima possibile durante il 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 di automazione e sicurezza nell'infrastruttura di Google. I vantaggi includono:

  • Protezione perimetrale di rete: i carichi di lavoro sono isolati dagli attacchi di rete e dal traffico non autorizzato da Internet. Sebbene un approccio al perimetro non sia un concetto nuovo, rimane una best practice per la sicurezza delle architetture cloud. Un approccio perimetrale aiuta a proteggere la massima infrastruttura possibile dal traffico non autorizzato e dai potenziali attacchi da Internet, come gli attacchi DoS basati sul volume.
  • Nessuna attendibilità reciproca intrinseca tra i servizi: solo i chiamanti o servizi autenticati, attendibili e specificamente autorizzati possono accedere a qualsiasi altro servizio. Questo impedisce agli utenti malintenzionati di usare codice non attendibile per accedere a un servizio. Se un servizio viene compromesso, questo vantaggio aiuta l'attaccante a eseguire azioni che consentono di espandere la sua copertura. Questa mutua fiducia, unita a un controllo granulare degli accessi, aiuta a limitare i raggi di compromissioni di un compromesso.
  • Macchine attendibili che eseguono codice con provenienza nota: le identità di servizio sono vincolate all'utilizzo solo di codice e configurazioni autorizzati ed eseguite solo in ambienti verificati e autorizzati.
  • Applicazione dei criteri coerente su tutti 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 giustificazione aziendale.
  • Implementazione semplice, automatica e standardizzata delle modifiche: le modifiche apportate 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: 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 consente di assicurare che sia in esecuzione solo il codice noto e autorizzato (dal firmware alla modalità utente) prima che i carichi di lavoro siano pianificati per l'esecuzione.

Questi vantaggi significano che è possibile eseguire il deployment dei container e dei microservizi eseguiti all'interno della nostra architettura cloud, comunicare tra loro ed eseguire l'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 di BeyondProd

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

Google Front End per la protezione dei periferici sulla rete

Google Front End (GFE) fornisce protezione periferica di rete. GFE termina la connessione dall'utente finale e fornisce un punto centrale per applicare le best practice TLS.

Anche se la nostra attenzione non si limita più alla sicurezza basata sul perimetro, il 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. Dopo che un utente si connette alla nostra infrastruttura, GFE è responsabile anche del bilanciamento del carico e del reindirizzamento del traffico tra le aree geografiche secondo le 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 Compute Engine. Cloud Front End consente alle VM dei clienti di accedere direttamente a un servizio Google utilizzando il loro indirizzo IP pubblico o privato. Gli indirizzi IP privati sono disponibili solo quando è abilitato l'accesso privato Google.

Application Transport Security per l'attendibilità tra i servizi

Application Layer Transport Security (ALTS) consente di garantire la mancanza di fiducia intrinseca tra i servizi. HSM viene utilizzato per l'autenticazione di chiamata di procedura remota (RPC), l'integrità, la crittografia del traffico e le identità dei servizi. Dialogflow è un sistema di autenticazione reciproca e crittografia di trasporto per i servizi nell'infrastruttura di Google. In generale, le identità sono associate ai servizi invece che a un nome server o a un host specifico. Questa associazione aiuta a semplificare la replica dei microservizi, il bilanciamento del carico e la ripianificazione tra host.

Ogni macchina ha una credenziale HSM 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 è riuscito. La maggior parte dei servizi Google viene eseguita come microservizi su Borg e ogni microservizi ha la propria identità Dialogflow. Borg Prime, Il controller centralizzato di Borg concede queste credenziali di microservizi Dialogflow ai carichi di lavoro in base all'identità del microservizio. Le credenziali Dialogflow a livello di macchina costituiscono il canale sicuro per il provisioning delle credenziali dei microservizi, in modo che solo le macchine che abbiano superato correttamente l'avvio verificato dell'integrità dell'host possano ospitare carichi di lavoro dei microservizi. Per ulteriori informazioni sulle credenziali Dialogflow, consulta i certificati Loadload.

Autorizzazione binaria per Borg per la provenienza del codice

Autorizzazione binaria per Borg (BAB) fornisce una verifica della provenienza del codice. BAB è un controllo di applicazione in fase di deployment che aiuta a garantire che il codice soddisfi i requisiti di sicurezza interni prima del deployment del codice. Ad esempio, il controllo di applicazione BAB include la garanzia che le modifiche vengano esaminate da un secondo ingegnere prima che il codice venga inviato al nostro repository di codice sorgente e che i programmi binari siano verificabili in base all'infrastruttura dedicata. Nella nostra infrastruttura, BAB limita il deployment di microservizi non autorizzati.

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

Integrità dell'host verifica l'integrità del software del sistema host attraverso una procedura di avvio protetto ed è supportata da una radice hardware di chip di sicurezza affidabile (Titan) ove supportata. I controlli di integrità dell'host includono la verifica delle firme digitali sul BIOS, sul controller di gestione di base (BMC), il bootloader e il kernel del sistema operativo. Se supportati, i controlli di integrità dell'host possono includere codice modalità utente e firmware delle periferiche (come NIC). Oltre alla verifica della firma digitale, l'integrità dell'host assicura che ogni host esegua la versione prevista di questi componenti software.

Gestione degli accessi ai servizi e ticket di contesto utente finale per l'applicazione delle norme

La gestione dell'accesso ai servizi e ticket di contesto per l'utente finale ti aiutano a garantire l'applicazione coerente dei criteri in tutti 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 necessari per i servizi per accedere ai dati del servizio di destinazione. Questo ne limita il modo in cui si accede ai dati, concede il livello di accesso minimo necessario e specifica in che modo tale accesso può essere controllato. 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 dalla loro identità di servizio. Questi ticket sono credenziali protetti da integrità, emesse a livello centrale e inoltrabili che attestano l'identità di un utente finale che ha effettuato una richiesta del servizio. Questi ticket riducono la necessità di attendibilità tra i servizi, poiché le identità di peer che utilizzano {8/} possono essere insufficienti per concedere l'accesso, quando tali decisioni di accesso in genere sono basate anche sull'identità dell'utente finale.

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

Gli strumenti Borg per i deployment blu/verde offrono un'implementazione semplice, automatica e standardizzata delle modifiche. Un deployment blu/verde è un modo per implementare una modifica in 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 parte di un'applicazione. I job vengono scalati per gestire il carico, con il deployment di nuovi job all'aumento del carico e di quelli esistenti terminati quando il carico diminuisce.

Borg strumenti è responsabile 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. Questo 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 quando aggiungiamo nuove funzionalità e per applicare aggiornamenti critici della sicurezza senza tempi di inattività (ad esempio, Heartbleed e Spectre/Meltdown). Per le modifiche che interessano la nostra infrastruttura, utilizziamo la migrazione live delle VM dei clienti, per garantire che i carichi di lavoro non vengano interessati.

Per ulteriori informazioni, vedi Autorizzazione binaria per Borg.

Kernel gVisor per l'isolamento dei carichi di lavoro

Il kernel di 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 offre la maggior parte delle funzionalità richieste per eseguire un'applicazione e limita la superficie del kernel dell'host accessibile all'applicazione. gVisor è uno dei diversi strumenti che utilizziamo per isolare i carichi di lavoro interni e i carichi di lavoro dei clienti di Google Cloud che vengono eseguiti sullo stesso host. Per ulteriori informazioni sugli altri strumenti di limitazione tramite sandbox, consulta l'articolo Limitazione tramite sandbox.

Protezione dei dati degli utenti con BeyondProd

Questa sezione descrive il modo in cui i servizi BeyondProd collaborano 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.
  • Modifica del codice dallo sviluppo alla produzione.

Non tutte le tecnologie elencate vengono utilizzate in tutte le nostre parti dell'infrastruttura, ma dipendono 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 cloud-native di Google per accedere ai dati utente.

Per accedere agli account utente:

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

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

Se questi controlli superano il controllo, i dati vengono restituiti al frontend dell'applicazione autorizzata e pubblicati per l'utente autorizzato.

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

Per saperne di più su come il traffico viene instradato all'interno della nostra infrastruttura, consulta la pagina Come viene instradato il traffico.

Esecuzione di una modifica al codice

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

Come vengono apportate le modifiche al codice.

Per apportare una modifica al codice:

  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 compilazione centrale e attendibile che produce un pacchetto con un certificato manifest manifestabile di firma di verifica.

  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 del carico di lavoro utilizzando un modello di affidabilità che garantisce la minima interruzione dei servizi, che si tratti di un'implementazione di routine o di una patch di sicurezza di emergenza.

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

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

Tutti i carichi di lavoro devono essere isolati. Se il carico di lavoro è meno attendibile perché il codice sorgente ha origine al di fuori di Google, potrebbe essere eseguito il deployment in un ambiente protetto da gVisor o utilizzare altri livelli di isolamento. Questo isolamento contiene un utente malintenzionato che riesce a compromettere un'applicazione.

Implicazioni per la sicurezza cloud-native

Le sezioni seguenti forniscono un confronto tra gli aspetti della sicurezza tradizionale dell'infrastruttura e i relativi contropunti 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 un'architettura cloud-native da sola. Tradizionalmente, le applicazioni monolitiche utilizzavano un'architettura a tre livelli e sono state implementate in data center aziendali privati, che avevano capacità sufficiente per gestire i picchi di carico degli eventi critici. Le applicazioni con requisiti hardware o di rete specifici sono state appositamente implementate 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 interessavano contemporaneamente molte parti dell'applicazione. Ciò ha portato a applicazioni di lunga durata che vengono aggiornate con minore frequenza e dove le patch di sicurezza vengono in genere applicate con minore frequenza.

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 in hosting di terze parti. Di conseguenza, invece di un'applicazione monolitica, un'applicazione containerizzata, suddivisa in microservizi, diventa la soluzione ideale per gli ambienti cloud. I container disaccoppiano i programmi binari di cui ha bisogno la tua 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 distribuiti di nuovo frequentemente.

Con i container riavviati, arrestati o ripianificati spesso, il riutilizzo e la condivisione di hardware e networking sono più frequenti. Grazie a un processo di creazione e distribuzione standardizzato, il processo di sviluppo è più coerente e uniforme tra i team, anche se i team gestiscono in modo indipendente lo sviluppo dei microservizi. Di conseguenza, le considerazioni sulla sicurezza (come revisioni della sicurezza, scansione del codice e gestione delle vulnerabilità) possono essere affrontate in anticipo nei cicli di sviluppo.

Mesh di servizi

Creando un'infrastruttura condivisa e progettata in modo sicuro che tutti gli sviluppatori utilizzano, l'onere di dover conoscere e implementare i requisiti più comuni per la sicurezza è ridotto al minimo. La funzionalità di sicurezza dovrebbe richiedere un'integrazione minima o nulla in ciascuna applicazione e viene invece fornita come struttura che avvolge e connette tutti i microservizi. Si parla in genere di mesh di servizi. Ciò significa che la sicurezza può essere gestita e implementata separatamente rispetto alle normali attività di sviluppo o deployment.

Un mesh di servizi è un'infrastruttura condivisa a livello di infrastruttura che avvolge e connette tutti i microservizi. Un mesh di servizi consente le comunicazioni tra servizi, che possono controllare il traffico, applicare criteri e fornire un monitoraggio centralizzato delle 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 contribuire a proteggere i carichi di lavoro da minacce esterne basate sulla rete.

Con un modello di sicurezza Zero Trust, non sono presenti firewall. Altri controlli, come l'identità, l'autenticazione e l'autorizzazione del carico di lavoro, contribuiscono a proteggere i microservizi e garantiscono che le connessioni interne o esterne vengano convalidate prima che possano essere eseguite sulle transazioni. Quando rimuovi la dipendenza da firewall o controlli basati su rete, puoi implementare la segmentazione a livello di microservizi, senza alcuna 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 devi più solo confrontare il traffico interno con quello esterno.

Requisiti di sicurezza condivisi integrati negli stack dei servizi

In un modello di sicurezza tradizionale, le singole applicazioni sono responsabili di soddisfare i propri requisiti di sicurezza indipendentemente dagli altri servizi. Tali requisiti includono la gestione delle identità, la terminazione TLS e la gestione degli accessi ai dati. Ciò può causare implementazioni incoerenti o problemi di sicurezza non risolti, poiché questi problemi devono essere risolti in molti luoghi, il che rende più difficile applicare le correzioni.

In un'architettura cloud-native, i componenti vengono riutilizzati molto più spesso tra i servizi. I punti di passaggio obbligato consentono di applicare i criteri in modo coerente in tutti i servizi. Criteri diversi possono essere applicati 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 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 viene spesso duplicato e accoppiato allo sviluppo locale. Una condivisione limitata rende più difficile determinare l'impatto di una modifica e il modo in cui 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 ogni componente (ad esempio, aprendo le connessioni SSH a ogni macchina virtuale per aggiornare una configurazione). Nel complesso, ciò può portare ad applicazioni di lunga durata.

Dal punto di vista della sicurezza, poiché il codice è spesso duplicato, è più difficile da esaminare e ancora più difficile garantire che una vulnerabilità venga risolta ovunque.

In un'architettura cloud-native, le implementazioni sono frequenti e standardizzate. Questo processo consente alla sicurezza di passare a sinistra nel ciclo di vita di sviluppo del software. Lo spostamento a sinistra si riferisce allo spostamento dei passaggi all'inizio del ciclo di vita dello sviluppo del software, che può 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 l'applicazione regolare delle patch di sicurezza.

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 affrontato questi cambiamenti contemporaneamente, ma puoi gestirli in modo indipendente se vuoi configurare elementi simili nel tuo ambiente.

Modifica della nostra infrastruttura

Il nostro obiettivo è automatizzare la sicurezza nell'intera infrastruttura perché riteniamo che la sicurezza debba essere scalata nello stesso modo in cui scalano i servizi. I servizi devono essere sicuri per impostazione predefinita e non sicuri in via eccezione. L'intervento umano diretto nella nostra infrastruttura dovrebbe essere un'eccezione, non la routine, e gli interventi devono essere verificabili quando si verificano. Possiamo quindi autenticare un servizio in base al codice e alla configurazione di cui viene eseguito il deployment per il servizio, invece che in base alle persone che hanno eseguito il deployment del servizio.

Abbiamo iniziato dalla costruzione di solide fondamenta di identificazione, autenticazione e autorizzazione dei servizi. Un microservizio utilizza un'identità di servizio per autenticarsi ad altri servizi in esecuzione nell'infrastruttura. Avere una base di identità di servizio attendibili ci ha consentito di implementare funzionalità di sicurezza di livello superiore che dipendono dalla convalida di tali identità, come la gestione dell'accesso ai servizi e i ticket di contesto dell'utente finale. Per semplificare questa transizione, sia per i servizi nuovi sia per quelli esistenti, per prima cosa abbiamo fornito Dialogflow come libreria con un singolo daemon helper. Questo daemon è stato eseguito sull'host chiamato da ogni servizio e si è evoluto nel tempo in una libreria che utilizza le credenziali del servizio. La libreria AltS è stata integrata perfettamente nella libreria RPC principale. Questa integrazione ha consentito di ottenere un'ampia adozione, senza gravare troppo sui team di sviluppo individuali. L'implementazione di Dialogflow è stata un prerequisito per l'implementazione della gestione degli accessi ai servizi e dei ticket contestuali.

Modifica dei nostri processi di sviluppo

È stato fondamentale per Google stabilire una solida procedura di revisione delle build e del codice per garantire l'integrità dei servizi in esecuzione. Abbiamo creato un processo di compilazione centrale dove potremmo iniziare ad applicare requisiti come la revisione del codice per due persone e i test automatici al momento della build e del deployment. Per ulteriori dettagli sul deployment, consulta Autorizzazione binaria per Borg.

Dopo aver appreso le nozioni di base, abbiamo iniziato a rispondere alla necessità di eseguire codice esterno e non attendibile nei nostri ambienti. Per raggiungere questo obiettivo, abbiamo iniziato la limitazione tramite sandbox, prima con ptrace, quindi in seguito utilizzando gVisor. Analogamente, i deployment blu/verde hanno fornito vantaggi significativi in termini di sicurezza (ad esempio, applicazione delle 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 è stato di due volte:

  • 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 proprio servizio.
  • Ci hanno permesso di correggere eventuali bug e di identificare le eventuali funzionalità aggiuntive che potremmo dover fornire ai team di assistenza.

Ad esempio, quando un servizio è onboarding di BAB, i proprietari dei servizi 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 di 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