Questi contenuti sono stati aggiornati a giugno 2024 e rappresentano lo status quo al momento della loro 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.
Google gestisce un'infrastruttura di calcolo distribuita e multi-tenant su scala globale per fornire prodotti e servizi a miliardi di persone in tutto il mondo. Questa infrastruttura deve bilanciare le priorità in concorrenza di sicurezza, affidabilità, resilienza, efficienza, velocità di sviluppo, possibilità di debug e altro ancora.
Questo documento descrive alcuni dei meccanismi che utilizziamo per mantenere una postura di sicurezza leader del settore per i servizi in esecuzione nell'ambiente di produzione di Google. Questi servizi occupano l'intero spettro della sensibilità alla sicurezza, dagli esperimenti di sviluppo che non hanno accesso a dati sensibili all'infrastruttura di identità critica. Questi servizi completano attività come l'elaborazione dei dati utente, la gestione degli implementamenti del software e il provisioning e la gestione del ciclo di vita per le singole macchine fisiche.
Questo documento descrive i controlli di sicurezza che contribuiscono a proteggere i seguenti tre livelli chiave della nostra infrastruttura:
- Servizi di produzione, che includono i servizi più importanti per la sicurezza (noti anche come servizi di base)
- Macchine di produzione
- Workload di produzione
Applichiamo questi controlli in modo che il personale di Google possa accedere a servizi, macchine e carichi di lavoro solo per scopi commerciali legittimi (ad esempio, accesso per la manutenzione) e per proteggersi dai rischi legati agli addetti ai lavori e dalla compromissione degli account del personale. Questi controlli forniscono un'ulteriore protezione di difesa in profondità che integra i controlli di sicurezza dell'infrastruttura esistenti che contribuiscono a prevenire la compromissione dell'account.
Miglioramento continuo
I controlli descritti in questo documento vengono utilizzati nell'ambiente di produzione di Google. Molti servizi, inclusi quelli di base, utilizzano i livelli più recenti di controlli che offriamo. Tuttavia, a causa dell'ambito e della complessità dell'infrastruttura di Google, i singoli servizi di produzione spesso hanno requisiti unici e potrebbero richiedere più tempo per implementare i consigli più recenti. Grazie a una cultura del miglioramento continuo, i team di Site Reliability Engineering (SRE) e di sicurezza di Google adattano costantemente i controlli di sicurezza per soddisfare l'evoluzione del panorama delle minacce.
Protezione dei servizi di produzione
Google contribuisce a proteggere l'integrità dei servizi di produzione in modo che il personale di Google possa accedere ai servizi solo per scopi commerciali legittimi, come la manutenzione. Esistono due modi principali per accedere ai servizi in esecuzione nell'ambiente di produzione: tramite l'accesso amministrativo e tramite la catena di fornitura del software.
L'elenco seguente descrive i controlli che contribuiscono a proteggere ogni percorso di accesso.
Controlli di accesso amministrativo: i servizi di produzione richiedono una manutenzione regolare (ad esempio, implementazioni di file binari o di configurazione). Noi di Google abbiamo come obiettivo che queste operazioni vengano eseguite tramite automazione, proxy sicuri o accesso di emergenza sottoposto a controllo, seguendo la filosofia di �� La suite di controlli che rimuove l'accesso umano alle risorse di produzione si chiama Nessuna persona (NoPe). NoPe offre a Google la flessibilità di implementare controlli di accesso basati sulla sensibilità di un servizio di produzione e sulla sua idoneità a raggiungere una posizione ancora più solida attraverso il miglioramento continuo.
Ad esempio, Google non consente l'accesso unilaterale ai servizi di base: anche l'accesso di emergenza richiede l'approvazione di altro personale di Google. Un accesso è unilaterale se qualcuno può eseguire l'accesso senza l'approvazione di un'altra persona autorizzata.
Controlli della catena di approvvigionamento del software: la maggior parte dei carichi di lavoro di produzione di Google, inclusi i servizi di base, esegue binari e configurazioni di job che sono stati creati in modo verificabile a partire da codice sottoposto a revisione paritaria e che si trova in una fonte attendibile. Applichiamo questa procedura utilizzando l'Autorizzazione binaria per Borg (BAB).
Il seguente diagramma mostra i controlli che contribuiscono a proteggere un servizio di produzione.
Quando applichiamo i massimi livelli di NoPe e BAB, contribuiamo a garantire che nessun personale abbia accesso unilaterale, anche in caso di emergenza, ai servizi di base, e che qualsiasi accesso privilegiato che riceva abbia un ambito e una durata ben definiti. L'accesso privilegiato è un livello elevato di accesso concesso al personale per amministrare servizi di produzione critici in circostanze uniche che non sono affrontate dall'automazione. Facciamo un'eccezione a questa regola per assicurarci che Google abbia un modo per uscire da situazioni di blocco.
Molti altri servizi di produzione, inclusi prodotti come Filestore o Cloud SQL e prodotti di infrastruttura interna come Borg e Spanner, sono configurati per utilizzare i livelli più elevati di NoPe e BAB e ci adoperiamo costantemente per semplificare l'adozione di NoPe e BAB da parte dei proprietari di servizi di produzione nel tempo.
Controlli dell'accesso amministrativo
In Borg, i membri di un ruolo di produzione possono leggere, scrivere o eliminare i dati di proprietà del ruolo e possono eseguire codice utilizzando l'autorità del ruolo. Un ruolo di produzione è un'identità che può eseguire carichi di lavoro nell'ambiente di produzione di Google.
L'appartenenza permanente ai ruoli di produzione comporta il rischio di conseguenze indesiderate per la produzione e il rischio che questi privilegi possano essere abusati. Tuttavia, la missione di SRE richiede che i team siano in grado di gestire i servizi di cui sono responsabili, pertanto la rimozione completa dell'accesso potrebbe non essere una strategia valida.
La suite NoPe offre un modo per configurare l'accesso che bilancia le esigenze contrastanti di potenziare i team e mantenere al sicuro i sistemi di produzione. Con NoPe, il personale Google riscontra limitazioni ai privilegi dei propri account quando tenta di accedere ai servizi di produzione. NoPe consente i seguenti vincoli:
- Le richieste di accesso richiedono un approvatore e una giustificazione: un controllo chiamato autorizzazione di più parti (MPA) contribuisce a garantire che il personale di Google non possa accedere ai servizi di produzione senza una giustificazione commerciale e l'approvazione di un'altra persona autorizzata a verificare la richiesta di accesso.
- Nessun accesso diretto ai ruoli dei servizi di produzione: il personale può accedere ai servizi di produzione solo tramite proxy sicuri per NoPe. I proxy sicuri sono progettati in modo da poter eseguire solo un insieme ben definito di comandi. Anche tutti i comandi considerati rischiosi dalle organizzazioni di Google Security e SRE (ad esempio, la disattivazione di un servizio o l'accesso o l'eliminazione di dati) richiedono l'autorizzazione MPA.
- Nessuna appartenenza permanente al ruolo di produzione: un controllo chiamato accesso on demand (AoD) richiede al personale di richiedere l'appartenenza temporanea, anziché consentire agli account del personale di avere sempre i privilegi di accesso. Questo controllo contribuisce a garantire che i poteri elevati vengano concessi solo temporaneamente e per motivi specifici.
- Monitoraggio delle richieste di accesso del personale ai servizi di produzione: Google richiede un controllo periodico dei pattern di accesso ai ruoli di produzione che eseguono un servizio di produzione. L'obiettivo del controllo è eliminare la necessità di queste richieste in futuro, attraverso il miglioramento continuo delle API amministrative. L'accesso ai servizi di produzione deve essere riservato solo per situazioni di risposta di emergenza. Per i servizi di base, il numero di situazioni in cui viene concesso l'accesso è così basso che un team di sicurezza esegue un controllo di ogni accesso concesso per confermarne la validità.
Le sezioni seguenti descrivono in dettaglio ogni controllo.
Autorizzazione da più parti per NoPe
L'MPA richiede l'approvazione di un altro personale Google autorizzato per una richiesta di accesso.
Per le richieste di accesso a servizi sufficientemente sensibili, MPA richiede inoltre che il personale fornisca una motivazione aziendale che faccia riferimento a un'emergenza di produzione in corso con ogni richiesta.
Entrambe queste condizioni rappresentano barriere contro gli abusi di accesso.
Proxy sicuri per NoPe
I proxy sicuri sono strumenti che espongono un insieme predefinito di comandi che il proxy sicuro può eseguire per conto di un chiamante. I proxy sicuri implementano criteri di autorizzazione granulari basati su regole per applicare vincoli all'accesso ai servizi di produzione. Questi criteri possono, ad esempio, richiedere l'approvazione di un'altra persona autorizzata per eseguire comandi che potrebbero influire negativamente sulla sicurezza o sull'affidabilità (ad esempio, comandi che eliminano file). I criteri possono anche consentire l'esecuzione di determinati comandi sicuri (ad esempio, i comandi che elencano l'utilizzo delle risorse) senza richiedere l'approvazione. Questa flessibilità è fondamentale per ridurre al minimo il lavoro operativo.
In caso di abuso di accesso, gli account rimangono vincolati alle operazioni consentite dal proxy sicuro. L'account può eseguire solo comandi sicuri unilateralmente, mentre le operazioni con privilegi richiedono l'approvazione di un'altra persona autorizzata. Tutte le operazioni lasciano un audit trail chiaro.
Per ulteriori informazioni sui proxy sicuri, consulta la presentazione di SREcon sulla produzione zero-touch. La produzione zero-touch è un insieme di principi e strumenti che impongono che ogni modifica nella produzione venga eseguita tramite automazione (senza persone coinvolte), pre-confermata dal software o eseguita utilizzando un meccanismo di emergenza sottoposto a verifica.
Accesso on demand
L'accesso on demand (AoD) consente a Google di ridurre i privilegi del personale sostituendo l'abbonamento permanente con un abbonamento idoneo.
I membri idonei di un ruolo non hanno accesso ai relativi privilegi. Se invece un membro del ruolo idoneo richiede l'accesso, può richiedere l'iscrizione temporanea, nota come concessione AoD. Se approvata da un'altra persona autorizzata, la concessione di un ruolo di accesso diretto rende il richiedente membro del ruolo per un periodo di tempo limitato, tipicamente meno di un giorno.
Il modello di abbonamento idoneo consente al personale di richiedere solo il sottoinsieme di accessi di cui ha bisogno per la durata necessaria. A livello concettuale, puoi considerare la funzionalità AoD come una produzione sudo limitata nel tempo, simile al comando sudo -u in Unix, che ti consente di eseguire alcuni comandi con le autorizzazioni elevate associate a un utente specificato. Tuttavia, a differenza di Unix sudo, la ricezione di un contributo AoD richiede una motivazione commerciale e un MPA e lascia una traccia di controllo. Anche i contributi AoD
sono limitati nel tempo.
La protezione dei privilegi sensibili dietro gli abbonamenti idonei significa che anche in casi improbabili di abuso di accesso, gli account possono accedere a questi privilegi solo se è presente una concessione attiva. L'adozione di proxy sicuri elimina in gran parte la necessità di queste autorizzazioni.
Monitoraggio delle richieste di accesso
Sebbene molte aree di produzione di Google utilizzino NoPe come pratica di riduzione dell'accesso, le concessioni AoD sono estremamente rare per i nostri ruoli di produzione più sensibili e sono riservate solo per le risposte di emergenza. Inoltre, ogni evento attiva un controllo manuale a posteriori. L'obiettivo del controllo è ridurre la frequenza delle concessioni AoD in futuro (ad esempio utilizzando questi eventi per motivare i miglioramenti alle API di amministrazione).
Google monitora costantemente le sovvenzioni AoD e le azioni intraprese durante la loro gestione all'interno dell'azienda. Utilizziamo i dati di monitoraggio in tempo reale per rilevare potenziali compromessi e identificare aree in cui ridurre ulteriormente l'accesso. In caso di evento, la traccia di controllo supporta una risposta rapida.
Autorizzazione binaria per Borg
Proprio come NoPe aiuta a proteggere i percorsi di accesso privilegiato, l'Autorizzazione binaria per Borg (BAB) aiuta a proteggere la catena di approvvigionamento del software di Google. BAB contribuisce a garantire che il software di produzione e le configurazioni dei job vengano esaminati e approvati prima di essere implementati, in particolare quando possono accedere a dati sensibili. Originariamente progettati per l'infrastruttura di produzione di Google, i concetti chiave di BAB sono ora inclusi in una specifica aperta chiamata Supply Chain Levels for Software Artifacts (SLSA).
Il BAB contribuisce a garantire che il personale non possa modificare il codice sorgente, eseguire programmi binari o configurare i job senza la revisione tra pari e che qualsiasi artefatto binario o configurazione software sia stato compilato in modo verificabile da codice sorgente sottoposto a revisione tra pari e archiviato.
Per ulteriori informazioni, consulta Autorizzazione binaria per Borg.
Protezione delle macchine di produzione
Oltre a rafforzare i percorsi di accesso privilegiato e mantenere l'integrità della catena di fornitura del software, Google protegge le macchine su cui vengono eseguiti i servizi di produzione. In particolare, implementiamo quanto segue:
Controlli di accesso alla shell: la maggior parte del personale di Google non ha accesso alla shell (ad esempio tramite SSH) alle macchine di produzione o ai carichi di lavoro in esecuzione su Borg, il sistema di gestione dei cluster di Google. Gli utenti devono invece utilizzare proxy sicuri che richiedono a un'altra persona autorizzata di esaminare e approvare ogni comando prima dell'esecuzione.
Solo alcuni team che si occupano dell'infrastruttura a basso livello mantengono accesso non unilaterale alla shell per poter eseguire il debug dei problemi più complessi in cui non è pratico utilizzare proxy sicuri. Un accesso è non unilaterale se richiede l'autorizzazione di uno o più persone autorizzate aggiuntive. Google fa un'eccezione in cui è consentito l'accesso unilaterale alla shell: per garantire che Google abbia un modo per uscire da situazioni di blocco.
Controlli di accesso fisico: le macchine richiedono una regolare manutenzione fisica per funzionare correttamente. Per contribuire ad assicurare che i tecnici dei data center accedano alle macchine fisiche solo per motivi commerciali validi, Google utilizza controlli da fisico a logico.
Controlli del firmware e del software di sistema: Google implementa un flusso di sicurezza di avvio misurato basato su una radice di attendibilità hardware. La radice di attendibilità hardware contribuisce a garantire l'integrità del firmware di avvio e del software di sistema di ogni macchina.
Il seguente diagramma mostra i controlli che aiutano a proteggere un computer in un centro dati.
Controlli di accesso alla shell
SSH è uno strumento di amministrazione open source molto utilizzato per consentire un accesso ampio ai server basati su Linux. Senza controlli sull'accesso SSH, gli account con le credenziali giuste possono ottenere una shell che consente loro di eseguire codice arbitrario in modo difficile da controllare.
Con l'accesso shell a un servizio di produzione, l'account potrebbe, ad esempio, cambiare il comportamento di un'attività in esecuzione, esfiltrare le credenziali o utilizzarle per ottenere un punto d'appoggio permanente nell'ambiente.
Per ridurre questo rischio, utilizziamo il seguente insieme di controlli che sostituisce l'accesso SSH alle macchine di produzione con metodi alternativi sicuri:
- API limitate: per i team con flussi di lavoro ben definiti che in precedenza richiedevano SSH, sostituiamo SSH con API verificabili e definite in modo limitato.
- Proxy sicuri per SSH: per i team che richiedono un accesso più flessibile, i proxy sicuri consentono di autorizzare e controllare singolarmente i comandi.
- MPA: quando gli SRE hanno bisogno di accedere tramite SSH a una macchina in caso di emergenza, Google richiede una motivazione aziendale e l'approvazione di una persona autorizzata. Le trascrizioni complete delle sessioni della shell vengono registrate.
- Scenari di blocco: l'unica eccezione in cui è consentito l'accesso SSH unilaterale. Le trascrizioni complete delle sessioni della shell vengono registrate.
Questi controlli bilanciano la necessità di un accesso shell legittimo con il rischio associato a un accesso shell eccessivamente ampio.
Informazioni generali: SSH in Google
In passato, Google utilizzava SSH per amministrare le proprie macchine. Lo sviluppo di Borg ha permesso alla maggior parte del personale di Google di non richiedere più l'accesso diretto alle macchine Linux che eseguono i loro binari, ma l'accesso alla shell è rimasto per diversi motivi:
- A volte il personale richiede l'accesso diretto a una macchina per scopi di debugging.
- L'accesso SSH è uno strumento didattico prezioso per comprendere i vari livelli di astrazione.
- In scenari di ripristino di emergenza imprevisti, gli strumenti di livello superiore potrebbero non essere disponibili.
Per trovare un equilibrio tra questi motivi e il rischio per la sicurezza che comportavano, Google ha perseguito una serie di traguardi per eliminare gradualmente il rischio e poi l'utilizzo di SSH.
Traguardo: monitoraggio e controllo dell'accesso centralizzati
Google ha investito in un sistema di monitoraggio e autorizzazione SSH centralizzato noto come autorizzazione di monitoraggio basata sull'identità dell'host (HIBA). HIBA offre visibilità su qualsiasi utilizzo di SSH e consente l'applicazione di criteri di autorizzazione rigorosi. I tentativi di accesso SSH vengono registrati non solo dalla macchina di destinazione, ma anche dal proxy BeyondCorp centralizzato. I comandi eseguiti dalla shell vengono registrati e inseriti nelle pipeline di rilevamento dei comportamenti dannosi. Tuttavia, il rilevamento è intrinsecamente reattivo e vulnerabile a offuscamento ed evasione.
Eliminazione del traguardo di accesso unilaterale
Per la maggior parte del personale, Google ha rimosso l'accesso alla shell (ad esempio tramite SSH) alle macchine di produzione o ai carichi di lavoro in esecuzione su Borg. Tuttavia, rimane accessibile alle macchine di test (ad esempio, le macchine utilizzate per la qualifica del nuovo hardware o del nuovo software di basso livello, ma non per l'esecuzione di servizi di produzione) per i team di sviluppo.
API ristrette
Alcuni team di Google che in passato si basavano su SSH per eseguire un numero limitato di comandi definiti con precisione (ad esempio in un playbook) o per ottenere dati la cui struttura è prevedibile, ora utilizzano API definite in modo limitato che soddisfano il caso d'uso specifico e forniscono dati strutturati.
Le API ristrette hanno un numero ridotto di metodi in linea con i percorsi utente comuni e mettono in primo piano i dettagli di accesso a basso livello. Di conseguenza, sono la soluzione preferita da Google perché offrono la massima sicurezza e possibilità di controllo. Grazie alla loro evoluzione sull'infrastruttura RPC (chiamata di procedura remota) di Google, possiamo usufruire di decenni di investimenti in sicurezza e controllo.
Proxy sicuri per SSH
Alcuni team di Google non sono in grado di determinare in anticipo i comandi di cui potrebbero aver bisogno. In questo caso, Google utilizza un demone di esecuzione dei comandi che accetta solo richieste di esecuzione di comandi arbitrari da un proxy attendibile gestito da un team di sicurezza. Questa tecnologia è simile a quella utilizzata nei proxy sicuri per NoPe.
I proxy sicuri per SSH sono responsabili dell'autorizzazione granulare dell'esecuzione dei comandi e del controllo. L'autorizzazione si basa sull'argomento e sull'ambiente del comando, sui parametri di limitazione della frequenza, sulle giustificazioni aziendali e sull'MPA. Questa procedura di autorizzazione consente limitazioni arbitrariamente precise sui comandi che possono essere eseguiti in base alle best practice e ai playbook del team. In condizioni di errori imprevisti che non sono acquisite nei playbook esistenti, il personale può comunque eseguire i comandi di debug necessari dopo che un'altra persona autorizzata li ha approvati.
MPA per SSH
I pochi team rimanenti che lavorano sull'infrastruttura a basso livello mantengono una forma non unilaterale di accesso alla shell per eseguire il debug dei problemi più complessi.
SSH in scenari di blocco
Google fa un'eccezione quando è consentito l'accesso unilaterale alla shell: per garantire che Google possa risolvere le situazioni di blocco. Le chiavi SSH utilizzate per questo scopo vengono generate con una procedura di controllo distinta e archiviate offline su hardware a prova di manomissione. Quando vengono utilizzate queste chiavi, vengono registrate trascrizioni complete della sessione di shell.
Controlli di accesso fisico
I data center di Google sono un ambiente complesso di server, dispositivi di rete e sistemi di controllo che richiedono un'ampia gamma di ruoli e competenze per la gestione, la manutenzione e il funzionamento.
Google implementa sei livelli di controlli fisici e molti controlli logici sulle macchine stesse per contribuire a proteggere i carichi di lavoro nel data center. Difendiamo anche uno spazio tra le macchine, che chiamiamo spazio da fisico a logico.
I controlli da fisico a logico forniscono livelli di difesa aggiuntivi tramite controlli chiamati hardening della macchina, controllo dell'accesso basato sulle attività e autodifesa del sistema. I controlli da fisico a logico proteggono da un avversario che cerca di sfruttare l'accesso fisico a una macchina ed eseguire l'escalation a un attacco logico sui carichi di lavoro della macchina.
Per ulteriori informazioni, consulta In che modo Google protegge lo spazio fisico-logico in un data center.
Controlli del firmware e del software di sistema
La Security posture di una macchina del data center viene stabilita all'avvio. Il processo di avvio della macchina configura l'hardware e inizializza il sistema operativo, garantendo al contempo la sicurezza dell'esecuzione della macchina nell'ambiente di produzione di Google.
In ogni fase della procedura di avvio, Google implementa controlli di primo livello per contribuire a applicare lo stato di avvio previsto e a proteggere i dati dei clienti. Questi controlli contribuiscono a garantire che le nostre macchine vengano avviate con il software previsto, consentendoci di rimuovere le vulnerabilità che potrebbero compromettere la postura di sicurezza iniziale della macchina.
Per ulteriori informazioni, consulta In che modo Google applica l'integrità del boot sulle macchine di produzione.
Protezione dei carichi di lavoro
In linea con la nostra filosofia zero trust, Google ha anche introdotto controlli che aiutano a difendersi dalle minacce di movimento laterale tra carichi di lavoro con requisiti di sicurezza diversi. L'infrastruttura di Google utilizza una gerarchia dei carichi di lavoro chiamata anelli di sicurezza dei carichi di lavoro (WSR). WSR contribuisce a garantire che i carichi di lavoro critici non vengano pianificati sulle stesse macchine dei carichi di lavoro meno sicuri, evitando al contempo un impatto negativo sull'utilizzo delle risorse. WSR raggruppa i carichi di lavoro in quattro classi di sensibilità: di base, sensibili, protetti e non protetti e tenta di pianificarli in pool di macchine diversi.
Il seguente diagramma mostra come WSR raggruppa e pianifica i carichi di lavoro sulle macchine di base, di produzione e di sviluppo.
I WSR forniscono un ulteriore livello di difesa contro l'escalation dei privilegi locali utilizzando attacchi di vulnerabilità del kernel o attacchi lato canale della CPU. La pianificazione in base ai rischi consente di garantire che solo i carichi di lavoro con requisiti di sicurezza simili vengano pianificati in modo collaborativo sulle stesse macchine. Per implementare il WSR, svolgiamo quanto segue:
- Classifica i carichi di lavoro in base ai relativi requisiti di sicurezza. Ogni classe è nota come anello di carico di lavoro.
- Distribuisci le macchine fisiche in più pool di macchine isolate tra loro. In altre parole, eliminiamo i percorsi di movimento laterale tra i pool.
- Applica vincoli di pianificazione per impedire l'esecuzione di carichi di lavoro con requisiti di sicurezza diversi sulla stessa macchina. Questi vincoli di pianificazione mitigano il rischio di compromissione tramite l'escalation dei privilegi locali.
Ad esempio, il WSR richiede che i carichi di lavoro di base vengano eseguiti su macchine dedicate e che non vengano mai pianificati in modo simultaneo con i carichi di lavoro non di base. Questo vincolo offre un isolamento efficace dai carichi di lavoro meno sicuri.
Metodi per isolare i carichi di lavoro
Il software di sistema moderno è complesso e i ricercatori in materia di sicurezza scoprono periodicamente vulnerabilità di escalation dei privilegi locali, come exploit zero-day del kernel o nuovi attacchi lato canale della CPU. La WSR, inizialmente introdotta in USENIX ;login:, consente a Google di ridurre il rischio associato alla co-localizzazione dei carichi di lavoro, mantenendo al contempo un elevato utilizzo delle risorse.
Per impostazione predefinita, Borg utilizza i confini dei processi a livello di sistema operativo per isolare i container. Queste procedure offrono un confine di isolamento meno efficace rispetto alle macchine virtuali che utilizzano la virtualizzazione basata su hardware. Questo isolamento più debole è in genere un buon compromesso tra efficienza e sicurezza per gli ambienti multi-tenant che eseguono carichi di lavoro attendibili. Un carico di lavoro attendibile è un carico di lavoro in cui il programma binario e la configurazione sono stati generati in modo verificabile da codice sottoposto a revisione paritaria di provenienza attestata. I carichi di lavoro attendibili non elaborano dati non attendibili arbitrari. Alcuni esempi di elaborazione di dati non attendibili includono l'hosting di codice di terze parti o la codifica di video.
Google ottiene la fiducia nei propri binari utilizzando BAB. Tuttavia, la crittografia lato client non è sufficiente per garantire l'integrità dei carichi di lavoro che elaborano dati non attendibili. Oltre a BAB, questi carichi di lavoro devono essere eseguiti anche all'interno di una sandbox. Una sandbox è un ambiente limitato, come gVisor, che consente l'esecuzione sicura di un file binario. Sia le BAB che le sandbox presentano dei limiti.
Il BAB è un controllo efficace per i prodotti maturi, ma potrebbe ridurre la velocità nelle prime fasi di sviluppo dei nuovi sistemi e quando vengono eseguiti esperimenti senza dati sensibili (ad esempio, l'ottimizzazione della codifica di dati già pubblici). Questa limitazione significa che alcuni carichi di lavoro devono essere eseguiti sempre senza BAB. Questi carichi di lavoro sono intrinsecamente a rischio maggiore di escalation dei privilegi locali (ad esempio, sfruttando una vulnerabilità del kernel per ottenere l'accesso come utente root locale su una macchina).
La sandbox dei carichi di lavoro non attendibili riduce anche il rischio per la sicurezza, ma comporta un aumento dell'utilizzo di risorse di calcolo e memoria. L'efficienza può diminuire di una percentuale a due cifre, a seconda del carico di lavoro e del tipo di sandbox. Per un esempio degli impatti delle prestazioni su un carico di lavoro in sandbox, consulta i benchmark dettagliati nella Guida alle prestazioni di gVisor. La WSR ci consente di risolvere le limitazioni di efficienza derivanti dall'isolamento dei carichi di lavoro.
Anelli di carico di lavoro
Google definisce quattro classi di carichi di lavoro in base ai relativi requisiti di sicurezza: di base, sensibili, con misure di protezione e non protetti. La tabella seguente li descrive in maggiore dettaglio.
| Anello di carico di lavoro | Descrizione |
|---|---|
| Di base | Carichi di lavoro fondamentali per la sicurezza di Google, come i servizi di gestione di identità e accessi. I carichi di lavoro di base hanno i requisiti di sicurezza più elevati e di solito sacrificano l'efficienza per una maggiore sicurezza e affidabilità. |
| Riservato | Carichi di lavoro che possono causare interruzioni diffuse o che hanno accesso a dati sensibili specifici del prodotto, come dati utente o dei clienti. |
| Protezione | Supporta i carichi di lavoro non critici per la sicurezza, ma che hanno adottato BAB o sono in sandbox, in modo che rappresentino un rischio ridotto per i carichi di lavoro vicini. |
| Non rafforzato | Tutti gli altri carichi di lavoro, inclusi quelli che eseguono codice non attendibile. |
In Google, classifichiamo come sensibili i carichi di lavoro critici che supportano prodotti specifici, mentre i carichi di lavoro di base sono quelli che potrebbero influire su tutti i prodotti.
A differenza di quelli di base e sensibili, possiamo classificare qualsiasi carico di lavoro come rafforzato in base esclusivamente ai controlli adottati e al tipo di input che elabora. Con i carichi di lavoro rafforzati, siamo principalmente preoccupati per il loro impatto su altri carichi di lavoro, pertanto le soluzioni di rafforzamento possono includere la sandboxing.
Pool di macchine
Per evitare la pianificazione in co-scheduling di servizi sensibili con carichi di lavoro meno attendibili (ad esempio quelli che trattano dati non attendibili senza una sandbox), dobbiamo eseguirli su pool di macchine isolate. L'isolamento delle macchine semplifica la comprensione delle invarianti di sicurezza, ma ogni pool di macchine aggiuntivo introduce compromessi in termini di utilizzo delle risorse e manutenibilità.
L'isolamento delle macchine comporta un utilizzo inferiore delle risorse fisiche, perché garantire che i pool di macchine vengano utilizzati al massimo diventa più difficile man mano che ne aggiungiamo altri. Il costo dell'efficienza potrebbe diventare significativo quando sono presenti diversi pool di macchine grandi e isolate.
Poiché l'impronta di risorse dei carichi di lavoro varia in ogni pool, l'isolamento rigoroso aggiunge un overhead di gestione per riequilibrare e riutilizzare periodicamente le macchine tra i pool. Questo riequilibrio richiede lo svuotamento di tutti i carichi di lavoro da una macchina, il riavvio della macchina ed esecuzione del nostro processo di sanificazione della macchina più oneroso, che contribuisce a garantire l'autenticità e l'integrità del firmware.
Queste considerazioni significano che l'implementazione dell'isolamento delle macchine da parte di Google deve fornire modi per ottimizzare l'utilizzo delle risorse fisiche e difendere al contempo i carichi di lavoro di base e sensibili dagli avversari.
In Kubernetes, questo approccio è noto come isolamento dei nodi. I nodi Kubernetes possono essere mappati a macchine fisiche o virtuali. In questo documento, ci concentreremo sulle macchine fisiche. Inoltre, i prodotti Google Cloud come Compute Engine offrono la proprietà esclusiva per garantire l'isolamento delle macchine fisiche.
Vincoli di pianificazione dei carichi di lavoro
Google esegue il provisioning delle macchine in tre tipi di pool isolati: macchine di base, macchine di produzione e macchine di sviluppo. Google gestisce diversi pool isolati che ospitano carichi di lavoro di base e sensibili, ma per semplicità questo documento li presenta come un unico pool.
Per offrire la protezione più efficace, implementiamo i seguenti vincoli di pianificazione per WSR:
- I carichi di lavoro di base possono essere eseguiti solo su macchine di base.
- I carichi di lavoro sensibili possono essere eseguiti solo sulle macchine di produzione.
- I carichi di lavoro non rafforzati possono essere eseguiti solo su macchine di sviluppo.
- I carichi di lavoro rafforzati possono essere eseguiti su macchine di produzione o di sviluppo, con una preferenza per le macchine di produzione.
Il seguente diagramma mostra i vincoli di pianificazione.
In questo diagramma, i confini di isolamento separano classi diverse di carichi di lavoro tra e all'interno dei pool di macchine. I carichi di lavoro di base sono gli unici tenant delle macchine di base dedicate. L'autorizzazione binaria o il sandboxing per i workload in esecuzione su macchine di produzione aiutano a prevenire gli attacchi di escalation dei privilegi locali. Sulle macchine di sviluppo esiste un rischio residuo che un carico di lavoro non rafforzato possa compromettere un altro carico di lavoro, ma la compromissione è limitata alle macchine di sviluppo perché i carichi di lavoro rafforzati non possono creare nuovi job.
I carichi di lavoro con protezione avanzata vengono pianificati su macchine di produzione o di sviluppo in base alla disponibilità. Consentire la pianificazione in più pool potrebbe sembrare controintuitivo, ma è essenziale per ridurre il calo dell'utilizzo causato dai vincoli di pianificazione. I carichi di lavoro rafforzati colmano le lacune introdotte dall'isolamento dei job sensibili e non rafforzati. Inoltre, maggiore è l'impronta delle risorse rafforzate, maggiori sono le fluttuazioni nell'utilizzo delle risorse delle altre due classi che possono essere gestite senza la necessità di costosi spostamenti delle macchine tra gli anelli.
Il seguente diagramma mostra le limitazioni di pianificazione imposte a diverse classi di carichi di lavoro. Un carico di lavoro rafforzato può trovarsi su una macchina di produzione o su una macchina di sviluppo.
Separando i carichi di lavoro di base in più pool di base, Google scambia l'efficienza delle risorse con una maggiore sicurezza. Fortunatamente, i carichi di lavoro di base tendono ad avere un ingombro di risorse relativamente ridotto e piccoli pool isolati di macchine dedicate hanno un impatto trascurabile sull'utilizzo complessivo. Tuttavia, anche con un'ampia automazione, la gestione di più pool di macchine non è priva di costi, pertanto stiamo costantemente evolvendo i nostri progetti di macchine per migliorare l'isolamento.
La WSR offre una solida garanzia che i carichi di lavoro non di base non siano mai autorizzati a essere eseguiti sulle macchine di base. Le macchine di base sono protette contro i movimenti laterali, poiché solo i carichi di lavoro di base possono essere eseguiti su queste macchine.
Riepilogo dei controlli
Google utilizza una serie di controlli nell'intera infrastruttura per contribuire a proteggere i servizi di produzione, le macchine di produzione e i carichi di lavoro. I controlli includono quanto segue:
- Controlli di accesso amministrativo e BAB per i servizi di produzione
- Controlli di accesso alla shell, controlli di accesso fisico e controlli del firmware e del software di sistema per le macchine di produzione
- WSR per diverse classi di carichi di lavoro
Insieme, questi controlli applicano vincoli che contribuiscono a proteggere gli utenti e i clienti di Google, nonché i loro dati. Il seguente diagramma illustra il funzionamento dei controlli per supportare la posizione di sicurezza di Google.
Passaggi successivi
- Per ulteriori informazioni sui controlli di sicurezza nell'infrastruttura Google, leggi Panoramica sulla progettazione della sicurezza dell'infrastruttura Google.
- Per scoprire di più sulla cultura della sicurezza di Google, leggi Building Secure & Reliable Systems (libro O'Reilly).
- Per scoprire di più sulla produzione zero-touch, consulta la presentazione di SREcon.
Autori: Michael Czapiński e Kevin Plybon