Questi contenuti sono stati aggiornati l'ultima volta a giugno 2024 e rappresentano lo status quo del momento in cui sono stati redatti. Le norme e i sistemi di sicurezza di Google possono variare in futuro, grazie al costante miglioramento della protezione per i nostri clienti.
Google gestisce un'infrastruttura di computing distribuita su scala globale, multi-tenant e distribuita per fornire prodotti e servizi a miliardi di persone in tutto il mondo. Questa infrastruttura deve bilanciare le priorità concorrenti in termini di sicurezza, affidabilità, resilienza, efficienza, velocità di sviluppo, debug e altro ancora.
Questo documento descrive alcuni dei meccanismi che utilizziamo per mantenere una security posture leader di settore per i servizi in esecuzione nell'ambiente di produzione di Google. Questi servizi coprono l'intero spettro della sensibilità della sicurezza, dagli esperimenti di sviluppo senza accesso a dati sensibili all'infrastruttura delle identità critica. Questi servizi completano attività come l'elaborazione dei dati degli utenti, la gestione delle implementazioni dei software, il provisioning e la gestione del ciclo di vita di singole macchine fisiche.
Questo documento descrive i controlli dell'infrastruttura che applichiamo a servizi, macchine e carichi di lavoro di produzione. Questi controlli consentono di proteggere i seguenti tre livelli chiave della nostra infrastruttura:
- Servizi di produzione, che includono i servizi più critici per la sicurezza (noti anche come servizi di base)
- Macchine di produzione
- Carichi di lavoro di produzione
Applichiamo questi controlli in modo che il personale Google possa accedere a servizi, macchine e carichi di lavoro solo per scopi aziendali legittimi (ad esempio, accesso per la manutenzione) e per difendersi dai rischi provenienti da personale interno e dalla compromissione dell'account del personale. Questi controlli forniscono un'ulteriore protezione in profondità, che integra i controlli di sicurezza dell'infrastruttura esistenti, che aiutano a prevenire la compromissione dell'account.
Miglioramento continuo
I controlli descritti in questo documento vengono utilizzati in tutto l'ambiente di produzione di Google. Molti servizi, inclusi quelli di base, utilizzano i più recenti livelli di controllo 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 tempo aggiuntivo per implementare i suggerimenti più recenti. Attraverso una cultura di miglioramento continuo, i team di Site Reliability Engineering (SRE) di Google e i team di sicurezza adattano costantemente i controlli di sicurezza per rispondere al mutevole panorama delle minacce.
Protezione dei servizi di produzione
Google contribuisce a proteggere l'integrità dei servizi di produzione in modo che il suo personale possa accedere ai servizi solo per scopi aziendali legittimi, come la manutenzione. Esistono due modi principali per ottenere l'accesso ai servizi eseguiti nell'ambiente di produzione: attraverso l'accesso amministrativo e attraverso la catena di fornitura del software.
Nell'elenco seguente sono descritti i controlli che consentono di proteggere ciascun percorso di accesso.
Controlli dell'accesso amministrativo: i servizi di produzione richiedono una manutenzione regolare (ad esempio, implementazioni di programmi binari o di configurazione). L'obiettivo di Google è che queste operazioni vengano eseguite attraverso automazione, proxy sicuri o accesso di emergenza controllato, secondo la filosofia della produzione zero-touch. La suite di controlli che rimuove l'accesso umano agli asset di produzione è denominata No Persons (NoPe). NoPe offre a Google la flessibilità necessaria per eseguire il deployment di controlli di accesso basati sulla sensibilità di un servizio di produzione e sulla sua idoneità a raggiungere una postura ancora più solida attraverso il miglioramento continuo.
Ad esempio, Google non consente il controllo unilaterale dei servizi di base e anche l'accesso di emergenza richiede l'approvazione di un altro personale Google. Un controllo è unilaterale se qualcuno può eseguire l'operazione senza che sia necessaria l'azione di un'altra persona autorizzata.
Controlli della catena di fornitura del software: la maggior parte dei carichi di lavoro di produzione in Google, inclusi i servizi di base, esegue programmi binari e configurazioni di job creati in modo verificabile a partire da codice sottoposto a revisione paritaria e situato in un'origine attendibile. Applichiamo questa procedura utilizzando Autorizzazione binaria per Borg (BAB).
Il seguente diagramma mostra i controlli che aiutano a proteggere un servizio di produzione.
Quando applichiamo i livelli più elevati di NoPe e BAB, garantiamo che nessun personale abbia accesso unilaterale, anche in caso di emergenza, ai servizi di base, e che qualsiasi accesso privilegiato abbia un ambito e una durata ben definiti. L'accesso con privilegi è un livello elevato di accesso concesso al personale per amministrare servizi di produzione critici in circostanze uniche non trattate dall'automazione. Facciamo un'eccezione a questa regola per garantire che Google abbia un modo per evitare le 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 in modo da utilizzare i livelli più elevati di NoPe e BAB e stiamo lavorando costantemente per semplificare l'adozione da parte dei proprietari dei servizi di produzione di NoPe e BAB nel tempo.
Controlli dell'accesso amministrativo
Su Borg, i membri di un ruolo di produzione possono leggere, scrivere o eliminare i dati di proprietà del ruolo di produzione e possono eseguire il 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 non intenzionali per la produzione e il rischio che questi privilegi possano essere utilizzati in modo illecito. Tuttavia, la missione di SRE richiede che i team siano in grado di mantenere i servizi di cui sono responsabili, quindi la rimozione completa dell'accesso potrebbe non essere una strategia attuabile.
La suite NoPe offre un modo per configurare l'accesso in grado di bilanciare le esigenze concorrenti di supportare i team e mantenere sicuri i sistemi di produzione. Con NoPe, il personale Google ha dei vincoli sui 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 multi-parte (MPA) aiuta a garantire che il personale Google non possa accedere ai servizi di produzione senza una giustificazione aziendale e l'approvazione di un altro privato autorizzato a verificare la richiesta di accesso.
- Nessun accesso diretto ai ruoli del servizio 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 set di comandi ben definito. Anche tutti i comandi che le organizzazioni SRE e Google Security considerano rischiosi (ad esempio, disattivazione di un servizio oppure accesso o eliminazione di dati) richiedono MPA.
- Nessuna appartenenza al ruolo di produzione permanente: un controllo chiamato accesso on demand (AoD) richiede al personale di richiedere l'iscrizione temporanea, anziché consentire agli account del personale di disporre sempre dei privilegi di accesso. Questo controllo aiuta 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 dell'audit è eliminare la necessità di tali richieste in futuro, attraverso il miglioramento continuo delle API amministrative. L'accesso ai servizi di produzione deve essere riservato solo per le 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 ciascun accesso a cui è stato concesso l'accesso per confermarne la validità.
Le sezioni seguenti trattano in dettaglio ogni controllo.
Autorizzazione di più parti per NoPe
MPA richiede che un altro personale Google autorizzato approvi una richiesta di accesso.
Per le richieste di accesso a servizi sufficientemente sensibili, MPA richiede anche che il personale fornisca una giustificazione aziendale che faccia riferimento a un'emergenza di produzione in corso con ogni richiesta.
Entrambe queste condizioni costituiscono un ostacolo all'abuso dell'accesso.
Proxy sicuri per NoPe
I proxy sicuri sono strumenti che espongono un set predefinito di comandi che il proxy sicuro può eseguire per conto di un chiamante. I proxy sicuri implementano criteri di autorizzazione granulari e basati su regole per fornire vincoli sull'accesso ai servizi di produzione. Questi criteri, ad esempio, possono 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, comandi che elencano l'utilizzo delle risorse) senza richiedere l'approvazione. Questa flessibilità è fondamentale per ridurre al minimo il lavoro manuale.
In caso di accesso illecito, gli account sono comunque vincolati alle operazioni consentite dal proxy sicuro. L'account può eseguire comandi sicuri unilateralmente, mentre le operazioni con privilegi richiedono l'approvazione di un altro privato autorizzato. Tutte le operazioni lasciano un audit trail chiaro.
Per ulteriori informazioni sui proxy sicuri, consulta la presentazione SREcon su Zero touch prod. La produzione zero touch è un insieme di principi e strumenti che assicurano che ogni modifica in produzione venga eseguita tramite automazione (nessuna persona coinvolta), pre-convalidata da un software o realizzata utilizzando un meccanismo controllato di emergenza.
Accesso on demand
L'accesso on demand (AoD) consente a Google di ridurre i privilegi di personale sostituendo l'abbonamento permanente con un abbonamento idoneo.
I membri idonei di un ruolo non hanno accesso ai suoi privilegi. Se invece un membro idoneo con il ruolo richiede l'accesso, può richiedere un'iscrizione temporanea, nota come concesso AoD. Se approvata da un'altra persona autorizzata, una concessione di AoD trasforma il richiedente a un membro del ruolo per un periodo di tempo limitato, in genere meno di un giorno.
Il modello di appartenenza idoneo consente al personale di richiedere solo il sottoinsieme di accesso
di cui ha bisogno per il periodo di tempo necessario. Concettualmente, AoD può essere considerato come un sudo di produzione vincolato al tempo, simile al comando sudo -u in Unix, che consente di eseguire alcuni comandi con autorizzazioni elevate associate a un utente specificato. Tuttavia, a differenza di Unix sudo, per ricevere una concessione di tipo AoD
sono necessari una giustificazione aziendale e un MPA e lascia un audit trail. Inoltre, le concessioni di tipo AoD
sono limitate nel tempo.
Proteggere i privilegi sensibili dietro gli abbonamenti idonei significa che anche in improbabili casi di abuso dell'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 questo tipo di concessioni.
Monitoraggio delle richieste di accesso
Anche se molte aree della produzione Google utilizzano NoPe come pratica di riduzione dell'accesso, le concessioni di tipo AoD sono estremamente rare per i nostri ruoli di produzione più sensibili e sono riservate solo per la risposta di emergenza. Inoltre, ogni evento attiva un controllo manuale dopo il fatto. L'obiettivo del controllo è ridurre la frequenza delle concessioni AoD in futuro (ad esempio, utilizzando questi eventi per motivare il miglioramento delle API amministrative).
Google monitora continuamente all'interno dell'azienda le concessioni di tipo AoD e le azioni intraprese al contempo per le sovvenzioni in questione. Utilizziamo i dati di monitoraggio in tempo reale per rilevare potenziali compromissioni e identificare le aree per un'ulteriore riduzione dell'accesso. Se si verifica un incidente, l'audit trail supporta la risposta rapida.
Autorizzazione binaria per Borg
Proprio come NoPe contribuisce a proteggere i percorsi di accesso privilegiato, Autorizzazione binaria per Borg (BAB) contribuisce a proteggere la catena di fornitura del software di Google. BAB contribuisce a garantire che il software di produzione e le configurazioni dei job vengano esaminati e approvati prima del deployment, in particolare quando possono accedere a dati sensibili. Originariamente sviluppato per l'infrastruttura di produzione di Google, i concetti chiave di BAB sono ora inclusi in una specifica aperta denominata Supply Chain Levels for Software Artifacts (SLSA).
BAB contribuisce a garantire che il personale non possa modificare il codice sorgente, eseguire programmi binari o configurare job senza peer review e che qualsiasi artefatto binario o configurazione software sia creato in modo verificabile a partire da codice sorgente sottoposto a controllo peer-revisione.
Per maggiori informazioni, vedi Autorizzazione binaria per Borg.
Protezione delle macchine di produzione
Oltre a rafforzare i percorsi di accesso privilegiato e a 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 dell'accesso alla shell: la maggior parte del personale 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. Le persone devono invece utilizzare proxy sicuri che richiedono a un'altra persona autorizzata di rivedere e approvare ogni comando prima che venga eseguito.
Solo pochi team che lavorano su un'infrastruttura di basso livello mantengono l'accesso alla shell non unilaterale, in modo da poter eseguire il debug dei problemi più complessi in cui i proxy sicuri non sono pratici. Un accesso è non unilaterale se richiede l'autorizzazione di uno o più membri autorizzati aggiuntivi. Google fa un'eccezione laddove sia consentito l'accesso unilaterale alla shell: garantire che Google abbia un modo per evitare le situazioni di blocco.
Controlli dell'accesso fisico: le macchine richiedono una manutenzione fisica regolare per garantirne il corretto funzionamento. Per garantire che i tecnici dei data center accedano alle macchine fisiche solo nel contesto di un valido motivo aziendale, Google utilizza i controlli fisico-logico.
Controlli firmware e software di sistema: Google implementa un flusso di sicurezza di avvio misurato basato su una radice di attendibilità hardware. La radice di attendibilità hardware aiuta a garantire l'integrità del firmware di avvio e del software di sistema di ogni macchina.
Il seguente diagramma mostra i controlli che consentono di proteggere una macchina in un data center.
Controlli di accesso alla shell
SSH è uno strumento amministrativo open source molto popolare per consentire l'accesso ampio ai server basati su Linux. Senza controlli sull'accesso SSH, gli account con le credenziali giuste possono ottenere una shell che consente di eseguire codice arbitrario in modo difficile da controllare.
Con l'accesso alla shell a un servizio di produzione, l'account potrebbe, ad esempio, modificare il comportamento di un'attività in esecuzione, esfiltrare le credenziali o utilizzare credenziali per ottenere un punto d'appoggio permanente nell'ambiente.
Per ridurre questo rischio, utilizziamo il seguente set di controlli che sostituisce l'accesso SSH alle macchine di produzione con metodi sicuri e alternativi:
- API ristrette: 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 necessitano dell'accesso SSH di emergenza a una macchina, Google richiede una giustificazione aziendale e una persona autorizzata ad approvare l'accesso. Vengono registrate le trascrizioni di sessioni complete della shell.
- Scenari di blocco: l'unica eccezione quando è consentito l'accesso SSH unilaterale. Vengono registrate le trascrizioni di sessioni complete della shell.
Questi controlli bilanciano la necessità di un accesso legittimo alla shell con il rischio associato a un accesso alla shell eccessivamente ampio.
Contesto: SSH di Google
In passato, Google utilizzava SSH per amministrare le proprie macchine. Lo sviluppo di Borg ha permesso alla maggior parte del personale Google di smettere di richiedere l'accesso diretto alle macchine Linux che eseguono i file binari, ma l'accesso alla shell è rimasto permanente per diversi motivi:
- A volte il personale richiede l'accesso diretto a una macchina per il debug.
- L'accesso SSH è un prezioso strumento di insegnamento per comprendere i vari livelli di astrazione.
- In scenari di ripristino di emergenza inaspettati, potrebbero non essere disponibili strumenti di livello superiore.
Per trovare un equilibrio tra questi motivi e il rischio per la sicurezza associato, Google ha perseguito una serie di traguardi per eliminare in modo incrementale il rischio associato all'SSH e quindi l'utilizzo.
Traguardo centralizzato per il monitoraggio e controllo dell'accesso
Google ha investito in un sistema di monitoraggio e autorizzazione SSH centrale noto come autorizzazione per il monitoraggio basata sull'identità dell'host (HIBA). HIBA fornisce visibilità su qualsiasi utilizzo di SSH e consente l'applicazione di criteri di autorizzazione rigorosa. I tentativi 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 all'evasione e all'offuscamento.
Eliminazione dell'obiettivo 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 sulle macchine di test (ad esempio, macchine utilizzate per qualificare nuovo hardware o software di basso livello, ma che non eseguono servizi di produzione) per i team di sviluppo.
API restrittive
Alcuni team di Google che storicamente si affidavano a 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 preciso che rispondono al caso d'uso specifico e forniscono dati strutturati.
Le API limitate dispongono di un numero limitato di metodi allineati ai percorsi comuni dell'utente e astraggono i dettagli di accesso di basso livello. Di conseguenza, sono la soluzione preferita di Google perché offrono i migliori strumenti di sicurezza e verificabilità. Creandole sull'infrastruttura RPC (chiamata di procedura remota) di Google, traiamo beneficio da 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 daemon con esecuzione di comandi che accetta solo richieste di esecuzione di comandi arbitrari da un proxy attendibile eseguito 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. Questo processo di autorizzazione consente restrizioni arbitrariamente precise sui comandi che possono essere eseguiti seguendo i playbook e le best practice del team. In condizioni di errore impreviste che non vengono acquisite nei playbook esistenti, il personale può comunque eseguire i comandi di debug necessari dopo che un altro utente autorizzato li ha approvati.
MPA per SSH
I pochi team rimanenti che lavorano su un'infrastruttura di 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 a questo scopo vengono generate con un processo verificabile distinto e archiviate offline su hardware antimanomissione. Quando vengono usate queste chiavi, vengono registrate le trascrizioni di sessioni complete della shell.
Controlli dell'accesso fisico
I data center di Google sono un ambiente complesso fatto di server, dispositivi di networking 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 proteggere i carichi di lavoro nel data center. Noi difendiamo anche lo spazio tra le macchine, che chiamiamo spazio fisico-logico.
I controlli da fisico a logico forniscono livelli aggiuntivi di difesa attraverso controlli chiamati rafforzamento delle macchine, controllo degli accessi basato su 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 e avanzano a un attacco logico ai 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 della macchina di un data center viene stabilita al momento dell'avvio. Il processo di avvio della macchina configura l'hardware della macchina e inizializza il sistema operativo, mantenendo la macchina sicura per l'esecuzione nell'ambiente di produzione di Google.
In ogni fase del processo di avvio, Google implementa controlli leader di settore per contribuire ad applicare lo stato di avvio previsto e a mantenere al sicuro i dati dei clienti. Questi controlli aiutano a garantire l'avvio delle nostre macchine nel software previsto, consentendoci di rimuovere le vulnerabilità che potrebbero compromettere la strategia di sicurezza iniziale della macchina.
Per ulteriori informazioni, consulta In che modo Google applica l'integrità in fase di avvio sulle macchine di produzione.
Protezione dei carichi di lavoro
In linea con la sua filosofia Zero Trust, Google ha introdotto anche 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 denominata workload Security Ring (WSR). WSR aiuta a garantire che i carichi di lavoro critici non siano pianificati sulle stesse macchine dei carichi di lavoro meno sicuri, evitando 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 in che modo WSR raggruppa e pianifica i carichi di lavoro nelle macchine di base, di produzione e di sviluppo.
WSR fornisce un ulteriore livello di difesa contro l'escalation dei privilegi locali tramite attacchi di vulnerabilità del kernel o attacchi lato-canale della CPU. WSR contribuisce a garantire che solo i carichi di lavoro con requisiti di sicurezza simili vengano co-pianificati sulle stesse macchine. Per implementare WSR, procedi nel seguente modo:
- Classificare i carichi di lavoro in base ai relativi requisiti di sicurezza. Ogni classe è nota come anello del carico di lavoro.
- Distribuisci macchine fisiche su 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 sulla stessa macchina di carichi di lavoro con requisiti di sicurezza diversi. Questi vincoli di pianificazione riducono il rischio di compromissione attraverso l'escalation dei privilegi locali.
Ad esempio, WSR richiede che i carichi di lavoro di base vengano eseguiti su macchine dedicate e non siano mai co-pianificati con carichi di lavoro non fondamentali. Questo vincolo offre un solido isolamento dai carichi di lavoro meno sicuri.
Metodi per l'isolamento dei carichi di lavoro
Il software di sistema moderno è complesso e i ricercatori di sicurezza scoprono periodicamente vulnerabilità di escalation dei privilegi locali, come exploit zero-day del kernel o nuovi attacchi lato-channel della CPU. WSR,
introdotto
per la prima volta in USENIX ;login:, consente a Google di ridurre il rischio associato alla
colocation 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. Questi processi offrono un limite di isolamento più debole rispetto alle macchine virtuali che utilizzano la virtualizzazione basata su hardware. Un isolamento più debole rappresenta 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 creati in modo verificabile a partire da codice sottoposto a revisione paritaria di provenienza attestata. I carichi di lavoro attendibili non elaborano dati non attendibili arbitrari. 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 file binari utilizzando BAB. Tuttavia, BAB 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 vincolato, come gVisor, che consente l'esecuzione sicura di un programma binario. Sia BAB che le sandbox hanno delle limitazioni.
BAB è un ottimo controllo per i prodotti maturi, ma potrebbe ridurre la velocità durante le prime fasi dello sviluppo di nuovi sistemi e durante l'esecuzione di esperimenti senza dati sensibili (ad esempio, ottimizzando la codifica di dati già pubblici). Questa limitazione significa che alcuni carichi di lavoro devono sempre essere eseguiti senza BAB. Questi carichi di lavoro sono intrinsecamente più a rischio di escalation dei privilegi locali (ad esempio, sfruttando una vulnerabilità del kernel per ottenere il root locale su una macchina).
Anche la limitazione tramite sandbox dei carichi di lavoro non attendibili riduce i rischi per la sicurezza, ma va a scapito dell'aumento dell'utilizzo di risorse di calcolo e di 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 dell'impatto sulle prestazioni di un carico di lavoro con sandbox, vedi i benchmark dettagliati nella Guida alle prestazioni di gVisor. WSR ci consente di risolvere i limiti di efficienza che derivano dall'isolamento dei carichi di lavoro.
Il carico di lavoro squilla
Google definisce quattro classi di carichi di lavoro in base ai requisiti di sicurezza: di base, sensibili, protetti e non protetti. Nella tabella seguente sono descritti in modo più dettagliato.
| Squillo del carico di lavoro | Descrizione |
|---|---|
| Di base | Carichi di lavoro critici 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 regolarmente scambiano 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 dei prodotti, come dati degli utenti o dei clienti. |
| Protezione | Supporta carichi di lavoro che non sono critici per la sicurezza, ma che hanno adottato BAB o sono limitati tramite sandbox, in modo da rappresentare un rischio minimo per i carichi di lavoro vicini. |
| Non temprato | Tutti gli altri carichi di lavoro, compresi 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 carichi di lavoro che potrebbero influire su tutti i prodotti.
A differenza dei carichi di lavoro di base e sensibili, possiamo classificare qualsiasi carico di lavoro come protetto in base esclusivamente ai controlli adottati e al tipo di input che elabora. Con i carichi di lavoro protetti, siamo principalmente preoccupati del loro impatto su altri carichi di lavoro, quindi le soluzioni di protezione possono includere la sandbox.
Pool di macchine
Per evitare la co-pianificazione di servizi sensibili con carichi di lavoro meno affidabili (ad esempio, quelli che elaborano dati non attendibili senza una sandbox), dobbiamo eseguirli su pool di macchine isolati. L'isolamento delle macchine semplifica la comprensione delle invarianti di sicurezza, ma ogni pool di macchine aggiuntivo introduce compromessi in termini di utilizzo e manutenibilità delle risorse.
L'isolamento delle macchine comporta un minore utilizzo delle risorse fisiche, in quanto garantire che i pool di macchine siano completamente utilizzati diventa più difficile man mano che aggiungiamo altri pool. I costi in termini di efficienza possono diventare significativi se esistono diversi pool isolati di grandi dimensioni.
Poiché l'ingombro delle risorse dei carichi di lavoro varia in ogni pool, l'isolamento rigoroso aggiunge un overhead di gestione per ribilanciare periodicamente e riadattare le macchine tra i pool. Il ribilanciamento richiede lo svuotamento di tutti i carichi di lavoro da una macchina, il riavvio della macchina e l'esecuzione del nostro processo di sanificazione delle macchine più impegnativo, che contribuisce a garantire l'autenticità e l'integrità del firmware.
Per queste considerazioni, l'implementazione dell'isolamento delle macchine da parte di Google deve fornire modi per ottimizzare l'utilizzo delle risorse fisiche difendendo al contempo i carichi di lavoro di base e sensibili contro gli utenti malintenzionati.
In Kubernetes, questo approccio è noto come isolamento dei nodi. I nodi Kubernetes possono essere mappati a macchine fisiche o virtuali. In questo documento, ci concentriamo sulle macchine fisiche. Inoltre, i prodotti Google Cloud come Compute Engine offrono il single-tenancy per fornire l'isolamento fisico delle macchine.
Vincoli di pianificazione del carico 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 sensibili e di base, ma questo documento presenta ciascuno come un unico pool, per semplicità.
Per offrire la protezione più efficace, eseguiamo il deployment dei 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 su macchine di produzione.
- I carichi di lavoro non protetti possono essere eseguiti solo su macchine di sviluppo.
- I carichi di lavoro protetti possono essere eseguiti su macchine di produzione o di sviluppo, con 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 sia tra i pool di macchine sia all'interno. I carichi di lavoro di base sono i single-tenant delle macchine di base dedicate. Autorizzazione binaria o sandbox per i carichi di lavoro in esecuzione su macchine di produzione aiutano a prevenire gli attacchi di escalation dei privilegi locali. Sulle macchine di sviluppo, c'è il rischio residuo che un carico di lavoro non protetto possa compromettere un altro carico di lavoro, ma la compromissione è limitata alle macchine di sviluppo perché i carichi di lavoro protetti non possono creare nuovi job.
I carichi di lavoro protetti vengono pianificati su macchine di produzione o di sviluppo in base alla disponibilità. Consentire la pianificazione in più pool potrebbe sembrare controintuitivo, ma è essenziale attenuare il calo dell'utilizzo causato dai vincoli di pianificazione. I carichi di lavoro protetti colmano le lacune introdotte isolando i job sensibili e non protetti. Inoltre, maggiore è l'ingombro delle risorse protette, maggiori sono le fluttuazioni nell'utilizzo delle risorse delle altre due classi senza la necessità di costosi spostamenti delle macchine tra gli anelli.
Il seguente diagramma mostra i vincoli di pianificazione imposti su diverse classi di carichi di lavoro. Un carico di lavoro protetto può trovarsi su una macchina di produzione o di sviluppo.
Isolando i carichi di lavoro di base su diversi pool di base, Google negozia l'efficienza delle risorse per una maggiore sicurezza. Fortunatamente, i carichi di lavoro di base tendono ad avere un impatto sulle risorse relativamente ridotto, mentre i pool isolati di macchine dedicate hanno un impatto trascurabile sull'utilizzo complessivo. Tuttavia, anche con un'ampia automazione, il mantenimento di più pool di macchine non è senza costi, quindi sviluppiamo costantemente le nostre progettazioni di macchine per migliorare l'isolamento.
WSR offre una solida garanzia che l'esecuzione di carichi di lavoro non fondamentali non verrà mai consentita su macchine di base. Le macchine di base sono protette dal movimento laterale, poiché solo i carichi di lavoro di base possono essere eseguiti su queste macchine.
Riepilogo dei controlli
Google utilizza una serie di controlli in tutta la sua infrastruttura per proteggere i servizi di produzione, le macchine di produzione e i carichi di lavoro. I controlli includono:
- Controlli dell'accesso amministrativo e BAB per i servizi di produzione
- Controlli dell'accesso alla shell, controlli dell'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 aiutano a proteggere gli utenti e i clienti di Google e i loro dati. Il seguente diagramma illustra l'interazione tra i controlli per supportare la security posture di Google.
Passaggi successivi
- Per ulteriori informazioni sui controlli di sicurezza sull'infrastruttura di Google, leggi la pagina Panoramica sulla progettazione della sicurezza dell'infrastruttura Google.
- Per saperne di più sulla cultura della sicurezza di Google, leggi Creazione di sistemi sicuri e affidabili (libro O'Reilly).
- Per ulteriori informazioni sulla produzione zero-touch, consulta la presentazione SREcon.
Autori: Michael Czapiński e Kevin Plybon