Questi contenuti sono stati aggiornati l'ultima volta a giugno 2024 e rappresentano lo status quo come del tempo 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 dell'infrastruttura che applichiamo alla produzione servizi, macchine e carichi di lavoro. Questi controlli aiutano a proteggere 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 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 offrono ulteriori una protezione con difesa in profondità che integra l’infrastruttura esistente sicurezza controlli che aiutano a prevenire la compromissione dell'account.
Miglioramento continuo
I controlli descritti in questo documento vengono utilizzati in tutte le aree geografiche di Google, nell'ambiente di produzione. Molti servizi, inclusi quelli di base, utilizzano gli ultimi livelli di controllo che offriamo. Tuttavia, a causa dell'ambito complessità dell'infrastruttura di Google, i singoli servizi di produzione spesso e potrebbero richiedere altro tempo per implementare personalizzati. 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 può accedere ai servizi solo per uno scopo commerciale legittimo, ad esempio 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.
Nell'elenco seguente sono descritti i controlli che consentono di proteggere ciascun percorso di accesso.
Controlli dell'accesso amministrativo: i servizi di produzione richiedono regolari intervalli di tempo manutenzione (ad esempio implementazioni binarie o di configurazione). In Google, le nostre è che queste operazioni vengano eseguite attraverso automazione, proxy sicuri dell'accesso di emergenza controllato, in base Produzione zero-touch la nostra filosofia. La suite di controlli che rimuove l'accesso umano alla produzione asset è chiamato Nessuna persona (NoPe). NoPe offre a Google la flessibilità necessaria per eseguire il deployment di controlli dell'accesso basati sulla sensibilità di un servizio di produzione e sulla sua prontezza a raggiungere una postura ancora più solida grazie al miglioramento continuo.
Ad esempio, Google non consente il controllo unilaterale dei modelli servizi, anche per l'accesso di emergenza è necessaria l'approvazione di altri Google personale qualificato. Un controllo è unilaterale se qualcuno può eseguire l'operazione senza che sia necessaria alcuna azione da parte 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 dei job create in modo verificabile a partire da un codice sottoposto a revisione paritaria una fonte attendibile. Applichiamo questa procedura utilizzando Autorizzazione binaria per Borg (BAB).
Il seguente diagramma mostra i controlli che aiutano a proteggere un ambiente completamente gestito di Google Cloud.
Quando applichiamo i livelli massimi di NoPe e BAB, garantiamo che il personale abbia accesso unilaterale, anche in caso di emergenza, ai servizi di base, e che ogni accesso privilegiato che ricevono abbia un ambito ben definito durata massima. L'accesso con privilegi è un livello elevato di accesso concesso il personale addetto all'amministrazione di 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
Su Borg, i membri di un ruolo di produzione possono leggere, scrivere o eliminare di produzione del ruolo e possono eseguire il codice utilizzando l'autorità competente. Un ruolo di produzione è un'identità che può eseguire carichi di lavoro nell'ambiente di produzione.
L'appartenenza permanente a ruoli di produzione comporta il rischio di danni involontari le conseguenze per la produzione e il rischio che questi privilegi vengano 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 attuabile strategia.
La suite NoPe offre un modo per configurare l'accesso in modo da bilanciare la concorrenza le esigenze di responsabilizzazione dei team e sicurezza dei 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 consentire solo un insieme ben definito di comandi eseguito. 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 dell’audit è eliminare la necessità di in futuro, attraverso il miglioramento continuo dei servizi su quelle di livello inferiore. 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 trattano in dettaglio ogni controllo.
Autorizzazione di più parti per NoPe
L'MPA richiede che un altro personale Google autorizzato approvi una richiesta di access.
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 set predefinito di comandi può eseguire per conto di un chiamante. I proxy sicuri implementano l'ottimizzazione criteri di autorizzazione basati su regole per fornire vincoli sull'accesso alla produzione i servizi di machine learning. Queste norme, ad esempio, possono richiedere l'approvazione di un altro persona autorizzata a eseguire comandi che potrebbero influire negativamente sulla sicurezza o 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 privilegiate richiedono l'approvazione di un altro una 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 appartenenza idoneo consente al personale di richiedere solo il sottoinsieme dell'accesso
necessario per la durata necessaria. Concettualmente, puoi pensare
AoD come sudo di produzione vincolata al tempo, simile al comando sudo -u in Unix,
che ti consente di eseguire alcuni comandi con autorizzazioni elevate
associati a un utente specificato. Tuttavia, a differenza di Unix sudo, riceve un AoD
richiede una giustificazione aziendale e una MPA e lascia un audit trail. AoD
anche le concessioni sono a tempo limitato.
Proteggere i privilegi sensibili dietro gli abbonamenti idonei significa che anche nelle casi improbabili di abuso dell'accesso, gli account possono accedere a questi privilegi solo quando c'è una concessione attiva. L'adozione di proxy sicuri elimina in gran parte la necessità di ricevere simili sovvenzioni.
Monitoraggio delle richieste di accesso
Sebbene molte aree della produzione Google utilizzino NoPe per ridurre l'accesso le concessioni di tipo AoD sono estremamente rare per i nostri sistemi di produzione ruoli e sono riservati esclusivamente agli interventi di emergenza. Inoltre, ogni evento attiva un controllo manuale dopo il fatto. L'obiettivo del controllo è ridurre la frequenza delle concessioni di tipo AoD in futuro (ad esempio, utilizzando questi eventi per migliorare le API amministrative).
Google monitora continuamente le concessioni AoD e le azioni intraprese mantenendo tali concessioni di donazioni in tutta l'azienda. Usiamo 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 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. In origine ideati per l'infrastruttura di produzione di Google, i concetti chiave di BAB sono ora incluse in una specifica aperta Livelli della catena di fornitura per gli artefatti software (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 software creata in modo verificabile a partire da codice sorgente archiviato e sottoposto a revisione paritaria.
Per ulteriori informazioni, vedi 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 Google non dispone di servizi (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 usare le proxy che richiedono la revisione e l'approvazione di un'altra persona autorizzata prima che venga eseguito.
Solo pochi team che lavorano su un'infrastruttura di basso livello mantengono un accesso shell non unilaterale, per 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ù account personale qualificato. Google rende un'eccezione laddove sia consentito l'accesso unilaterale alla shell, per garantire che Google abbia un modo per evitare situazioni di blocco.
Controlli dell'accesso fisico: le macchine necessitano di regolari controlli fisici e manutenzione per garantirne il corretto funzionamento. 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 software di sistema e del firmware: Google implementa una misurazione di avvio rapido basato su una radice di attendibilità hardware. Ferramenta la radice di attendibilità aiuta di 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 i controlli sull'accesso SSH, gli account con le credenziali corrette possono ottenere una shell che consente di eseguire codice arbitrario difficile da controllare.
Con l'accesso shell a un servizio di produzione, l'account potrebbe, ad esempio, modificare il comportamento di un'attività in esecuzione, esfiltrare le credenziali o utilizzare con le credenziali necessarie per un punto d'appoggio costante 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 ristrette: per i team con flussi di lavoro ben definiti che in precedenza l'SSH richiesto, sostituiamo SSH API verificabili e definite in modo ristretto.
- Proxy sicuri per SSH: per i team che richiedono un accesso più flessibile, proxy sicuri consentire di autorizzare e controllare singolarmente i comandi.
- MPA: quando gli SRE hanno bisogno dell'accesso SSH di emergenza a una macchina, Google richiede una giustificazione aziendale e una persona autorizzata per l'approvazione l'accesso. 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 di sessioni complete della shell.
Questi controlli bilanciano la necessità di un accesso legittimo alla shell con il rischio associate a un accesso troppo ampio alla shell.
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 non richiedere più l'accesso diretto Linux che eseguono i file binari, ma l'accesso alla shell è rimasto per diversi motivi:
- A volte il personale richiede l'accesso diretto a una macchina per il debug scopi.
- 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 centrale di monitoraggio e autorizzazione SSH come l'autorizzazione per il monitoraggio basata sull'identità dell'host (HIBA). HIBA offre visibilità su qualsiasi utilizzo di SSH e consente l'applicazione di restrizioni criteri di autorizzazione. 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 di evasione e 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 accessibili sulle macchine di test (ad esempio, macchine utilizzate per qualificare nuovi hardware o un nuovo software di basso livello, ma che non eseguono servizi di produzione) per team di sviluppo.
API restrittive
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 gli strumenti soluzione preferita perché offrono i migliori risultati in termini di sicurezza e verificabilità. Di creandoli sull'infrastruttura di chiamata di procedura remota (RPC) di Google, da decenni di investimenti in sicurezza e auditing.
Proxy sicuri per SSH
Alcuni team di Google non riescono a determinare i comandi di cui potrebbero aver bisogno prima nel tempo. In questo caso, Google utilizza un daemon con esecuzione di comandi che accetta richieste di esecuzione di comando arbitrarie da un proxy attendibile eseguito da un dell'assistenza clienti Google Cloud. 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. Questo il processo di autorizzazione consente restrizioni arbitrariamente precise su quali comandi puoi eseguire i seguenti playbook e best practice per i team. In caso di errore imprevisto condizioni non acquisite nei playbook esistenti, il personale può i comandi di debug necessari dopo che un altro utente autorizzato ha li ha approvati.
MPA per SSH
I pochi team rimanenti che lavorano sull'infrastruttura di basso livello mantengono una 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 dove l'accesso unilaterale alla shell è consentito: per garantire che Google possa risolvere le situazioni di blocco. Le chiavi SSH utilizzate Vengono generati con un processo verificabile distinto e archiviati offline su hardware antimanomissione. Quando vengono usate queste chiavi, completa la sessione di shell vengono registrate.
Controlli dell'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 fisico-logici forniscono ulteriori livelli di difesa attraverso chiamati hardening della macchina, controllo dell'accesso basato su attività e di 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, vedi 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 aiutano a garantire che le nostre macchine si avviino nei percorsi previsti software, il che ci consente di rimuovere le vulnerabilità che potrebbero compromettere la security posture iniziale della macchina.
Per ulteriori informazioni, vedi In che modo Google applica l'integrità in fase di avvio sulle macchine di produzione.
Protezione dei carichi di lavoro
In linea con la nostra filosofia Zero Trust, Google ha introdotto anche dei controlli che aiutano a difendersi dalle minacce di movimento laterale tra carichi di lavoro con requisiti di sicurezza diversi. Infrastruttura di Google utilizza una gerarchia dei carichi di lavoro chiamata anelli di sicurezza dei carichi di lavoro (WSR). WSR aiuta a garantire che i carichi di lavoro critici non siano pianificati sulle stesse macchine come carichi di lavoro meno sicuri, evitando un impatto negativo all'utilizzo delle risorse. WSR raggruppa i carichi di lavoro in quattro livelli di sensibilità : di base, sensibili, temprati e non temprati, e tenta di pianificarle in diversi pool di macchine.
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 WSR, eseguiamo seguenti:
- Classificare i carichi di lavoro in base ai relativi requisiti di sicurezza. Ogni corso è noto come anello del carico di lavoro.
- Distribuisci le macchine fisiche su diversi pool di macchine isolati tra loro. In altre parole, eliminiamo il movimento laterale tra i pool.
- Applica vincoli di pianificazione per evitare carichi di lavoro con sicurezza diversa l'esecuzione sulla stessa macchina. Questi vincoli di pianificazione ridurre il rischio di compromessi attraverso escalation dei privilegi locali.
Ad esempio, WSR richiede che i carichi di lavoro di base vengano eseguiti su macchine dedicate e non sono 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
I moderni software di sistema sono complessi e i ricercatori di sicurezza periodicamente
Scoprire le vulnerabilità dell'escalation dei privilegi locali, come il kernel zero-day
exploit o nuovi attacchi a canale laterale della CPU. WSR, prima
introdotto
in USENIX ;login:, consente a Google di ridurre il rischio associato a
la colocation dei carichi di lavoro,
mantenendo un elevato utilizzo delle risorse.
Per impostazione predefinita, Borg utilizza i confini dei processi a livello di sistema operativo per isolare i container. Questi di elaborazione offrono un confine di isolamento più debole rispetto alle macchine virtuali che utilizzano la virtualizzazione basata su hardware. Un isolamento così debole è in genere un buon un compromesso tra efficienza e sicurezza per gli ambienti multi-tenant che carichi di lavoro affidabili. Un carico di lavoro attendibile è un carico di lavoro in cui i file binari sono state create in modo verificabile a partire da codice sottoposto a revisione paritaria provenienza. 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 file binari utilizzando BAB. Tuttavia, BAB non è sufficiente per garantire l'integrità dei carichi di lavoro che elaborano non attendibili. Oltre a BAB, questi carichi di lavoro devono essere eseguiti anche all'interno di un 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 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 sempre essere eseguiti 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 cifra a due cifre percentuale, 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. WSR ci permette di affrontare i limiti di efficienza dovuti all'isolamento carichi di lavoro con scale out impegnativi.
Il carico di lavoro squilla
Google definisce quattro classi di carichi di lavoro in base alle loro requisiti: di base, sensibili, protetti e non temprati. Le seguenti che li descrive in modo più dettagliato.
| 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 requisiti di sicurezza più elevati e scambiano regolarmente efficienza di sicurezza e affidabilità. |
| Riservato | Carichi di lavoro che possono causare interruzioni diffuse o che hanno accesso a dati sensibili specifici dei prodotti, come i dati utente 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 carichi di lavoro vicini. |
| Non temprato | Tutti gli altri carichi di lavoro, inclusi quelli in esecuzione non attendibili le API nel tuo codice. |
In Google, classifichiamo i carichi di lavoro critici che supportano prodotti specifici come sensibili, mentre i carichi di lavoro di base sono carichi di lavoro che potrebbero prodotti di big data e machine learning.
A differenza dei carichi di lavoro di base e sensibili, possiamo classificare qualsiasi carico di lavoro come protetto esclusivamente in base ai controlli adottati e al tipo di input che i processi di machine learning. 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 di co-pianificare servizi sensibili con carichi di lavoro meno affidabili. (ad esempio quelli che elaborano dati non attendibili senza una sandbox), dobbiamo eseguire su pool di macchine isolati. L'isolamento delle macchine semplifica le varianti della 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, assicurando 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'utilizzo delle risorse dei carichi di lavoro varia in ogni pool, l'isolamento aggiunge un overhead di gestione che consente il ribilanciamento e il riutilizzo periodici tra i pool. Questo ribilanciamento richiede lo svuotamento di tutti i carichi di lavoro di macchina, riavviando la macchina ed eseguendo la nostra sanificazione che contribuisce a garantire autenticità e integrità del firmware.
Queste considerazioni indicano che l'implementazione dell'isolamento delle macchine da parte di Google devono fornire modi per ottimizzare l'utilizzo delle risorse fisiche per difendere i carichi di lavoro fondamentali 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 concentrandosi 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: di base di produzione, di sviluppo e di sviluppo. Google gestisce diverse pool isolati che ospitano carichi di lavoro sensibili e di base, ma questo documento presenta ciascuno come un pool per semplicità.
Per offrire la protezione più efficace, implementiamo la seguente programmazione vincoli 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 e 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à. Potrebbe sembrare che consentire la pianificazione in più pool ma è essenziale attenuare il calo dell'utilizzo causato i vincoli di pianificazione. I carichi di lavoro protetti colmano gli spazi vuoti introdotti isolando i job sensibili e non protetti. 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 con protezione avanzata può trovarsi in un di produzione o 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 modelli i carichi di lavoro tendono ad avere un ingombro delle risorse relativamente ridotto e pool di macchine dedicate ha 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 servizi 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 di Google, lettura 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 scoprire di più sulla produzione zero-touch, consulta le Presentazione SREcon.
Autori: Michael Czapiński e Kevin Plybon