Questi contenuti sono stati aggiornati l'ultima volta a giugno 2024 e rappresentano lo status quo come delle volte in cui è stato scritto. Le norme e i sistemi di sicurezza di Google potrebbero cambiare in futuro, grazie al costante miglioramento della protezione per i nostri clienti.
Google esegue un'elaborazione distribuita, multi-tenant e su scala globale infrastruttura per fornire prodotti e servizi a miliardi di persone in tutto il mondo nel mondo. Questa infrastruttura deve bilanciare le priorità concorrenti della sicurezza, affidabilità, resilienza, efficienza, velocità di sviluppo, debug altro ancora.
Il presente documento descrive alcuni dei meccanismi utilizzati per mantenere un livello di sicurezza leader del settore per i servizi eseguiti nell'ambiente di produzione Google completamente gestito di Google Cloud. Questi servizi occupano l'intero spettro della sensibilità della sicurezza, da esperimenti di sviluppo che non hanno accesso a dati sensibili un'infrastruttura di identità critica. Questi servizi completano attività elaborazione dei dati degli utenti, gestione delle implementazioni del software, provisioning e ciclo di vita per le singole macchine fisiche.
Questo documento descrive i controlli di sicurezza che aiutano a proteggere: 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
- Carichi di lavoro di produzione
Applichiamo questi controlli in modo che Google il personale può accedere a servizi, macchine e carichi di lavoro solo per scopi legittimi per scopi aziendali (ad esempio, accesso per la manutenzione) e difendere rischi legati agli addetti ai lavori e compromissioni dell'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 in tutte le piattaforme nell'ambiente di produzione. Molti servizi, inclusi quelli di base, utilizzano gli ultimi 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 più tempo per implementare i consigli più recenti. Attraverso una cultura di miglioramento continuo, Google SRE (Site Reliability Engineering) i team di sicurezza adattano costantemente i controlli di sicurezza 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 ottenere l'accesso ai servizi eseguiti nell'ambiente di produzione: attraverso l'accesso amministrativo e della 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 alla produzione asset è chiamato 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, anche per l'accesso di emergenza è necessaria l'approvazione di altri Google personale qualificato. Un accesso è unilaterale se qualcuno può eseguire l'accesso senza l'approvazione di un'altra persona autorizzata.
Controlli della catena di fornitura 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 tra pari e che si trova in una fonte attendibile. Applichiamo questa procedura utilizzando Autorizzazione binaria per Borg (BAB).
Il seguente diagramma mostra i controlli che contribuiscono a proteggere un servizio di produzione.
Quando applichiamo i più elevati 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 con privilegi è un livello elevato di accesso concesso da parte del personale di amministrare servizi di produzione critici in circostanze particolari non affrontati 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, tra cui prodotti come Filestore Cloud SQL e prodotti di infrastruttura interna come Borg e Spanner sono configurate per utilizzare i livelli più alti di NoPe e BAB e lavorando costantemente per rendere più facile per i proprietari dei servizi di produzione adottare NoPe e BAB 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 dei vincoli sui privilegi dei propri account quando tentano di accedere ai servizi di produzione. NoPe consente di: vincoli:
- Le richieste di accesso richiedono un approvatore e una giustificazione: un controllo che è chiamata autorizzazione multi-parte (MPA) che aiuta a garantire che il personale Google non possa accedere ai servizi di produzione senza giustificazione aziendale e l'approvazione di un altro individuo che hai l'autorizzazione a verificare la richiesta di accesso.
- Nessun accesso diretto ai ruoli del servizio di produzione: il personale può accedere solo di produzione tramite proxy sicuri per NoPe. I proxy sicuri sono progettati in modo da poter eseguire solo un insieme ben definito di comandi. Tutti i comandi presi in considerazione dalle organizzazioni che si occupano di sicurezza e SRE di Google rischioso (ad esempio, la disattivazione di un servizio oppure l'accesso o l'eliminazione di dati) richiedono anche l'opzione MPA.
- Nessuna appartenenza al ruolo di produzione permanente: un controllo chiamato accesso on demand (AoD) richiede al personale di richiedere l'adesione temporanea, anziché consentendo agli account del personale di disporre sempre di privilegi di accesso. Questo controllo contribuisce a garantire che le potenze elevate vengano concesse solo temporaneamente e per motivi.
- 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 le emergenze situazioni di risposta. Per i servizi di base, il numero di situazioni in cui l'accesso è concesso è talmente basso che un team di sicurezza esegue un controllo a cui è stato concesso l'accesso per confermarne la validità.
Le sezioni seguenti descrivono in dettaglio ogni controllo.
Autorizzazione di 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 forniscono una giustificazione aziendale che fa riferimento a una continua di produzione di emergenza per ogni richiesta.
Entrambe queste condizioni costituiscono un ostacolo all'abuso dell'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 alcuni comandi sicuri (ad esempio, comandi che elencano l'utilizzo delle risorse) vengono eseguiti senza richiedere l'approvazione. Questa flessibilità è fondamentale per ridurre lavoro manuale.
In caso di abuso dell'accesso, gli account sono comunque vincolati alle operazioni che il proxy sicuro consente. 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 Presentazione SREcon in produzione zero touch. La produzione zero-touch è un insieme di principi e strumenti che far sì che ogni cambiamento nella produzione sia eseguito dall'automazione (nessuno coinvolti), pre-convalidati dal software o realizzati utilizzando un servizio di emergenza meccanismo di attenzione.
Accesso on demand
L'accesso on demand (AoD) consente a Google di ridurre i privilegi relativi al personale sostituendo un abbonamento permanente con un abbonamento idoneo.
I membri idonei di un ruolo non hanno accesso ai suoi privilegi. Invece, se un membro con ruolo idoneo richiede l'accesso, può richiedere un'iscrizione temporanea nota come concessione di questo tipo di annunci. Se approvato da un altro privato autorizzato, un AoD la concessione rende il richiedente membro del ruolo per un periodo di tempo limitato in genere 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, riceve un AoD
richiede una giustificazione aziendale e un MPA e lascia un audit trail. AoD
anche le concessioni sono a tempo limitato.
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 dopo il fatto. 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 continuamente le concessioni AoD e le azioni intraprese mantenendo tali concessioni di donazioni in tutta l'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, 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 ne viene eseguito il deployment, 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 a mantenere l'integrità nella catena di fornitura del software, Google protegge le macchine dei servizi di produzione vengono eseguiti tutti i test delle unità. 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 manutenzione fisica regolare per funzionare correttamente. Per garantire che il data center di accesso ai macchinari fisici solo nel contesto di una per motivi commerciali, Google utilizza controlli fisico-logico.
Controlli del firmware e del software di sistema: Google implementa un flusso di sicurezza dell'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 una macchina in un Google Cloud.
Controlli di accesso alla shell
SSH è uno strumento amministrativo open source molto popolare per consentire 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 set di controlli che sostituisce SSH accesso alle macchine di produzione con metodi sicuri e alternativi:
- 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. Vengono registrate le trascrizioni di sessioni complete della shell.
- Scenari di blocco: l'unica eccezione quando l'accesso SSH unilaterale è consentito. Vengono registrate le trascrizioni complete delle sessioni shell.
Questi controlli bilanciano la necessità di un accesso shell legittimo con il rischio associato a un accesso 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 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 è un prezioso strumento didattico per comprendere i vari livelli dell'astrazione.
- In scenari di ripristino di emergenza inattesi, strumenti di livello superiore potrebbero non sarà disponibile.
Per trovare un equilibrio tra questi motivi e il rischio per la sicurezza che incorrono, Google ha perseguito una serie di traguardi per eliminare in modo incrementale il rischio associato a SSH e quindi sull'utilizzo.
Traguardo centralizzato per il monitoraggio e controllo dell'accesso
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 SSH vengono registrati, non solo dalla macchina di destinazione, ma anche dall'amministratore proxy BeyondCorp. I comandi eseguiti dalla shell vengono registrati e inseriti in comportamenti dannosi pipeline di rilevamento. 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 a basso livello, ma non per l'esecuzione di servizi di produzione) per i team di sviluppo.
API ristrette
Alcuni team di Google che storicamente si affidavano a SSH per eseguire comandi definiti in modo preciso (ad esempio, in un playbook) o ottenere dati strutturale è prevedibile, ora utilizza API ben definite che caso d'uso e fornire dati strutturati.
Le API limitate dispongono di un numero limitato di metodi allineati ai percorsi comuni degli utenti e astrarre i dettagli di accesso di basso livello. Di conseguenza, sono la soluzione preferita da Google perché offrono la massima sicurezza e possibilità di controllo. Grazie alla loro creazione sull'infrastruttura RPC (Remote Procedure Call) 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 in proxy sicuri per NoPe.
I proxy sicuri per SSH sono responsabili dell'autorizzazione granulare dei comandi per l'esecuzione e il controllo. L'autorizzazione si basa sull'argomento e ambiente, parametri di limitazione della frequenza, giustificazioni aziendali e 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 caso di condizioni di errore imprevisto 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 per 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 fatto di server, dispositivi di rete sistemi di controllo e gestione che richiedono un'ampia gamma di ruoli e competenze la manutenzione e l'operatività.
Google implementa sei livelli di controlli fisici e molti controlli logici sulle macchine stesse per proteggere i carichi di lavoro nel data center. Difendiamo anche uno spazio tra le macchine, che chiamiamo 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 fisico-logici proteggono da un avversario cercare di sfruttare l'accesso fisico a una macchina e avanzare 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 della macchina di un data center viene stabilita al momento dell'avvio. La il processo di avvio della macchina configura l'hardware della macchina e ne inizializza del sistema operativo, mantenendo la macchina sicura per l'esecuzione nella fase di produzione di Google completamente gestito di Google Cloud.
In ogni fase del processo di avvio, Google implementa controlli leader del settore per applicare lo stato di avvio previsto e per mantenere i dati dei clienti in tutta sicurezza. 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). Il 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 tra di base, di produzione e di sviluppo.
WSR fornisce un ulteriore livello di protezione l'escalation dei privilegi locali utilizzando attacchi di vulnerabilità del kernel o CPU attacchi laterali. WSR aiuta a garantire che solo i carichi di lavoro con sicurezza simile i requisiti vengono co-pianificati sulle stesse macchine. Per implementare il WSR, svolgiamo quanto segue:
- Classifica i carichi di lavoro in base ai relativi requisiti di sicurezza. Ogni corso è noto come anello del 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 ridurre il rischio di compromessi attraverso 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 l'isolamento dei 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. Esempi di elaborazione di dati non attendibili includono l'hosting di codice di terze parti o durante la codifica dei 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 un sandbox. Una sandbox è un ambiente limitato, come gVisor, che consente l'esecuzione sicura di un file binario. Sia le BAB che le sandbox presentano limitazioni.
BAB è un ottimo controllo per i prodotti maturi, ma potrebbe ridurre la velocità durante nelle prime fasi di sviluppo di nuovi sistemi e durante l'esecuzione di esperimenti senza dati sensibili (ad esempio, ottimizzando la codifica di dati già presenti pubblico). Questa limitazione significa che alcuni carichi di lavoro devono essere eseguiti sempre senza BAB. Questi carichi di lavoro sono intrinsecamente più esposti a un rischio maggiore di escalation dei privilegi locali. (ad esempio, sfruttando una vulnerabilità del kernel per ottenere la radice locale su un computer).
La limitazione tramite sandbox dei carichi di lavoro non attendibili riduce anche i rischi per la sicurezza, ma è un aspetto dell'aumento dell'uso 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. Ad esempio, gli impatti sulle prestazioni di un carico di lavoro con sandbox, vedi i benchmark dettagliati in il 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.
| Squillo del carico di lavoro | Descrizione |
|---|---|
| Di base | Carichi di lavoro critici per la sicurezza di Google, come l'identità e i servizi di gestione degli 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 temprato | 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 protetti, siamo principalmente preoccupati del loro impatto su altri carichi di lavoro, quindi le soluzioni di protezione avanzata possono includere la limitazione tramite sandbox.
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 minore utilizzo delle risorse fisiche, la garanzia che i pool di macchine siano completamente utilizzati diventa più difficile man mano che aggiungiamo piscine. Il costo dell'efficienza può diventare significativo quando ci sono grandi pool di macchine isolate.
Poiché l'impronta delle 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 offrire 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 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 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 la 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 che all'interno. I carichi di lavoro di base sono l'unico tenant di macchine di base dedicate. Autorizzazione binaria o sandbox dei carichi di lavoro in esecuzione su macchine di produzione, e l'escalation degli attacchi. Sulle macchine di sviluppo, esiste un rischio residuo che carico di lavoro non protetto potrebbe compromettere un altro carico di lavoro, ma la compromissione è solo alle macchine di sviluppo, poiché i carichi di lavoro con protezione avanzata non possono creare di lavoro.
I carichi di lavoro protetti vengono pianificati su macchine di produzione o macchine 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 è la dimensione dell'impatto delle risorse protette, maggiori sono le fluttuazioni nell'utilizzo delle risorse altre due classi possono essere alloggiate senza la necessità di macchine costose si sposta tra gli anelli.
Il seguente diagramma mostra i vincoli di pianificazione imposti diverse classi di carichi di lavoro. Un carico di lavoro rafforzato può trovarsi su una macchina di produzione o su una macchina di sviluppo.
Isolando i carichi di lavoro di base su diversi pool di base, Google 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, il mantenimento di più pool non è senza costi, quindi evolviamo costantemente il design delle nostre macchine per migliorare l'isolamento.
WSR offre una solida garanzia che i carichi di lavoro non fondamentali non vengono mai l'esecuzione su macchine di base. Le macchine di base sono protette contro lo spostamento laterale, poiché solo i carichi di lavoro di base possono essere eseguiti machine learning.
Riepilogo dei controlli
Google utilizza una serie di controlli in tutta la sua infrastruttura per proteggere di produzione, macchine di produzione e carichi di lavoro. I controlli includono le seguenti:
- Controlli dell'accesso amministrativo e BAB per i servizi di produzione
- Controlli dell'accesso alla shell, controlli dell'accesso fisico e firmware e sistema e controlli software per le macchine di produzione
- WSR per diverse classi di carichi di lavoro
Insieme, questi controlli applicano vincoli che aiutano a proteggere gli utenti di Google e dei clienti, con i relativi dati. Il seguente diagramma illustra il modo in cui interagiscono tra loro per supportare il livello 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 di O'Reilly).
- Per scoprire di più sulla produzione zero-touch, consulta la presentazione di SREcon.
Autori: Michael Czapiński e Kevin Plybon