Questi contenuti sono stati aggiornati per l'ultima volta a giugno 2026 e rappresentano lo status quo al momento della redazione. I criteri e i sistemi di sicurezza di Google potranno variare in futuro, in virtù del costante miglioramento della protezione per i nostri clienti.
Google gestisce un'infrastruttura di computing distribuita, multi-tenant e su scala globale per fornire prodotti e servizi a miliardi di persone in tutto il mondo. Questa infrastruttura deve bilanciare le priorità concorrenti di sicurezza, affidabilità, resilienza, efficienza, velocità di sviluppo, capacità di debug e altro ancora.
Questo documento descrive alcuni dei meccanismi che utilizziamo per mantenere una postura di sicurezza leader del settore per i servizi eseguiti nell'ambiente di produzione di Google. Questi servizi coprono l'intero spettro della sensibilità alla sicurezza, dagli esperimenti di sviluppo che non hanno accesso a dati sensibili all'infrastruttura di identità critica. Questi servizi completano attività come l'elaborazione dei dati utente, la gestione dei rollout software e il provisioning e la gestione del ciclo di vita per singole macchine fisiche.
Questo documento descrive i controlli di sicurezza che contribuiscono a proteggere i seguenti tre livelli chiave della nostra infrastruttura:
- Servizi di produzione, che includono i servizi più importanti per la sicurezza (noti anche come servizi di base)
- Macchine di produzione
- Workload di produzione
Applichiamo questi controlli in modo che il personale di Google possa accedere a servizi, macchine e carichi di lavoro solo per scopi commerciali legittimi (ad esempio, accesso per la manutenzione) e per difendersi da rischi interni e compromissione degli account del personale. Questi controlli forniscono un'ulteriore protezione in difesa approfondita che integra i controlli di sicurezza dell'infrastruttura esistenti che contribuiscono a impedire 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 livelli di controllo più recenti 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 le ultime raccomandazioni. Grazie a una cultura del miglioramento continuo, i team di Site Reliability Engineering (SRE) e di sicurezza di Google adattano costantemente i controlli di sicurezza per rispondere all'evoluzione del panorama delle minacce.
Protezione dei servizi di produzione
Google contribuisce a proteggere l'integrità dei servizi di produzione in modo che il personale di Google possa accedere ai servizi solo per uno scopo aziendale legittimo, ad esempio la manutenzione. Esistono due modi principali per accedere ai servizi eseguiti nell'ambiente di produzione: tramite l'accesso amministrativo e tramite la catena di fornitura del software.
L'elenco seguente descrive i controlli che contribuiscono a proteggere ogni percorso di accesso.
Controlli di accesso amministrativo: i servizi di produzione richiedono una manutenzione regolare (ad esempio, implementazioni binarie o di configurazione). In Google, il nostro obiettivo è che queste operazioni vengano eseguite tramite automazione, proxy sicuri o accesso di emergenza controllato, seguendo la filosofia Zero Touch Prod. La suite di controlli che rimuove l'accesso umano agli asset di produzione è chiamata No Persons (NoPe). NoPe offre a Google la flessibilità di implementare controlli dell'accesso basati sulla sensibilità di un servizio di produzione e sulla sua disponibilità a ottenere una postura ancora più solida attraverso il miglioramento continuo.
Ad esempio, Google non consente l'accesso unilaterale ai servizi di base e anche l'accesso di emergenza richiede l'approvazione di altro personale di Google. Un accesso è unilaterale se qualcuno può eseguirlo senza alcuna approvazione da parte di un'altra persona autorizzata. Un altro esempio è la disattivazione dei core dump per contribuire a impedire la perdita di segreti importanti, come le chiavi di accesso root, anche se il debug diventa più difficile.
Controlli della catena di fornitura del software: la maggior parte dei carichi di lavoro di produzione di Google, inclusi i servizi di base, esegue file binari e configurazioni dei job che vengono creati in modo verificabile a partire da codice sottoposto a revisione paritaria e che si trova in una fonte attendibile. Applichiamo questa procedura utilizzando l'Autorizzazione binaria per Borg (BAB).
Il seguente diagramma mostra i controlli che contribuiscono a proteggere un servizio di produzione.
Quando applichiamo i livelli più elevati di NoPe e BAB, contribuiamo a garantire che nessun dipendente abbia accesso unilaterale, anche in caso di emergenza, ai servizi di base e che qualsiasi accesso privilegiato che riceve abbia un ambito e una durata ben definiti. L'accesso con privilegi è un livello di accesso elevato concesso al personale per amministrare i servizi di produzione critici in circostanze uniche che non sono gestite dall'automazione. Facciamo un'eccezione a questa regola per garantire che Google abbia un modo per uscire dalle situazioni di blocco.
La maggior parte dei servizi di produzione, inclusi prodotti come Filestore o Cloud SQL e prodotti di infrastruttura interni come Borg e Spanner, sono configurati per utilizzare i livelli più elevati di NoPe e BAB e ci stiamo impegnando costantemente per semplificare l'adozione di NoPe e BAB nel tempo da parte dei proprietari dei servizi di produzione. In un registro dei rischi sono presenti eccezioni gestite con giustificazioni aziendali valide.
Controlli dell'accesso amministrativo
In Borg, i membri di un ruolo di produzione possono leggere, scrivere o eliminare i dati di proprietà del ruolo di produzione ed 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 utilizzati in modo improprio. Tuttavia, la missione di SRE richiede che i team siano autorizzati a gestire i servizi di cui sono responsabili, pertanto la rimozione completa dell'accesso potrebbe non essere una strategia praticabile.
La suite NoPe offre un modo per configurare l'accesso che bilancia le esigenze concorrenti di responsabilizzare i team e mantenere sicuri i sistemi di produzione. Con NoPe, il personale Google incontra limitazioni ai privilegi dei propri account quando tenta di accedere ai servizi di produzione. NoPe consente i seguenti vincoli:
- Le richieste di accesso richiedono un responsabile dell'approvazione e una giustificazione: un controllo chiamato autorizzazione di più parti (MPA) contribuisce a garantire che il personale di Google non possa accedere ai servizi di produzione senza una giustificazione aziendale e un'approvazione da parte di un'altra persona autorizzata a verificare la richiesta di accesso.
- Nessun accesso diretto ai ruoli di servizio di produzione: il personale può accedere ai servizi di produzione solo tramite proxy sicuri per NoPe. I proxy sicuri sono progettati in modo che possa essere eseguito solo un insieme ben definito di comandi. Anche i comandi che le organizzazioni Google Security e SRE considerano rischiosi (ad esempio, disattivare un servizio o accedere o eliminare dati) richiedono l'autenticazione MFA.
- Nessuna appartenenza permanente al ruolo di produzione: un controllo chiamato accesso on demand (AoD) richiede al personale di richiedere l'appartenenza temporanea, anziché consentire agli account del personale di disporre sempre dei privilegi di accesso. Questo controllo contribuisce a garantire che i privilegi 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 alle situazioni di risposta alle emergenze. Per i servizi di base, il numero di situazioni in cui viene concesso l'accesso è così basso che un team di sicurezza esegue un audit di ogni accesso concesso per confermarne la validità.
Le sezioni seguenti descrivono in dettaglio ciascun controllo.
Autorizzazione da più parti per NoPe
L'MPA richiede che un altro membro autorizzato del personale di Google approvi una richiesta di accesso.
Per le richieste di accesso a servizi sufficientemente sensibili, MPA richiede inoltre che il personale fornisca una motivazione aziendale che faccia riferimento a un'emergenza di produzione in corso con ogni richiesta.
Entrambe queste condizioni sono barriere contro l'abuso di accesso.
Proxy sicuri per NoPe
I proxy sicuri sono strumenti che espongono un insieme predefinito di comandi che il proxy sicuro può eseguire per conto di un chiamante. I proxy sicuri implementano criteri di autorizzazione granulari basati su regole per fornire vincoli di accesso ai servizi di produzione. Queste policy possono, ad esempio, richiedere l'approvazione di un altro individuo autorizzato per eseguire comandi che potrebbero influire negativamente sulla sicurezza o sull'affidabilità (ad esempio, comandi che eliminano file). Le policy possono anche consentire l'esecuzione di determinati comandi sicuri (ad esempio, i comandi che elencano l'utilizzo delle risorse) senza richiedere l'approvazione. Questa flessibilità è fondamentale per ridurre al minimo il lavoro operativo.
In caso di abuso dell'accesso, gli account sono comunque limitati alle operazioni consentite dal proxy sicuro. L'account può eseguire solo comandi sicuri in modo unilaterale, mentre le operazioni con privilegi richiedono l'approvazione di un altro soggetto autorizzato. Tutte le operazioni lasciano un audit trail chiaro.
Per saperne di più sui proxy sicuri, consulta la presentazione SREcon su zero touch prod e Case Study: Safe Proxies. Zero touch prod è un insieme di principi e strumenti che impongono che ogni modifica in produzione venga eseguita tramite automazione (senza coinvolgimento di persone), pre-validata da software o apportata utilizzando un meccanismo di emergenza controllato.
Accesso on demand
L'accesso on demand (AoD) consente a Google di ridurre i privilegi del personale sostituendo l'appartenenza permanente con l'appartenenza idonea.
I membri idonei di un ruolo non hanno accesso ai relativi privilegi. Se un membro di un ruolo idoneo richiede l'accesso, può richiedere l'iscrizione temporanea, nota come concessione AoD. Se approvata da un'altra persona autorizzata, una concessione di AoD rende il richiedente membro del ruolo per un periodo di tempo limitato, in genere inferiore a un giorno.
Il modello di abbonamento idoneo consente al personale di richiedere solo il sottoinsieme di accesso
di cui ha bisogno per la durata necessaria. Dal punto di vista concettuale, puoi considerare
AoD come una produzione con limiti di tempo sudo, 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 sudo di Unix, la ricezione di una concessione AoD
richiede una motivazione di business e un MPA e lascia una traccia di controllo. Anche le sovvenzioni
AoD sono a tempo limitato.
La protezione dei privilegi sensibili dietro gli abbonamenti idonei significa che, anche in casi improbabili di abuso dell'accesso, gli account possono accedere a questi privilegi solo quando esiste una concessione attiva. L'adozione di proxy sicuri elimina in gran parte la necessità di queste concessioni.
Monitoraggio delle richieste di accesso
Sebbene molte aree della 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 alla risposta alle emergenze. Inoltre, ogni evento attiva un audit manuale successivo. Lo scopo dell'audit è ridurre la frequenza delle concessioni di AoD in futuro (ad esempio, utilizzando questi eventi per motivare i miglioramenti delle API amministrative).
Google monitora continuamente le concessioni di AoD e le azioni intraprese durante il periodo di validità di queste concessioni in tutta l'azienda. Utilizziamo i dati di monitoraggio in tempo reale per rilevare potenziali compromissioni e identificare le aree in cui ridurre ulteriormente l'accesso. Se si verifica un incidente, il log di controllo supporta una risposta rapida.
Autorizzazione binaria per Borg
Proprio come NoPe contribuisce a proteggere i percorsi di accesso privilegiati, l'autorizzazione binaria per Borg (BAB) contribuisce a proteggere la catena di fornitura del software di Google. BAB contribuisce a garantire che le configurazioni di software di produzione e job vengano esaminate e approvate prima di essere implementate, in particolare quando possono accedere a dati sensibili. Originariamente ideati 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).
BAB contribuisce a garantire che il personale non possa modificare il codice sorgente, eseguire file binari o configurare job senza revisione tra pari e che qualsiasi artefatto binario o configurazione software sia creato in modo verificabile dal codice sorgente archiviato e sottoposto a revisione tra pari.
Per saperne di più, consulta Autorizzazione binaria per Borg.
Protezione delle macchine di produzione
Oltre a rafforzare i percorsi di accesso privilegiati 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 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. 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 alcuni team che lavorano su infrastrutture di basso livello mantengono l'accesso alla shell non unilaterale per poter eseguire il debug dei problemi più complessi in cui i proxy sicuri non sono pratici da usare. Un accesso è non unilaterale se richiede l'autorizzazione di una 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 contribuire a garantire che i tecnici del data center accedano alle macchine fisiche solo nel contesto di un motivo aziendale valido, Google utilizza controlli fisici-logici.
Controlli del firmware e del software di sistema: Google implementa un flusso di sicurezza di avvio misurato basato su una radice di attendibilità hardware. La radice di attendibilità hardware contribuisce a garantire l'integrità del firmware di avvio e del software di sistema di ogni macchina.
Il seguente diagramma mostra i controlli che contribuiscono a proteggere una macchina in un data center.
Controlli di accesso alla shell
SSH è uno strumento amministrativo open source molto diffuso per consentire un ampio accesso 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 alla shell a un servizio di produzione, l'account potrebbe, ad esempio, modificare il comportamento di un'attività in esecuzione, estrarre le credenziali o utilizzare le credenziali per ottenere un punto d'appoggio persistente nell'ambiente.
Per mitigare questo rischio, utilizziamo il seguente insieme di controlli che sostituisce l'accesso SSH alle macchine di produzione con metodi alternativi sicuri:
- API ristrette: per i team con flussi di lavoro ben definiti che in precedenza richiedevano SSH, sostituiamo SSH con API ristrette e verificabili.
- Proxy sicuri per SSH: per i team che richiedono un accesso più flessibile, i proxy sicuri consentono di autorizzare e controllare individualmente i comandi.
- MPA: quando i SRE hanno bisogno di accedere in emergenza a una macchina tramite SSH, Google richiede una motivazione aziendale e un individuo autorizzato ad approvare l'accesso. Vengono registrate le trascrizioni complete delle sessioni della shell.
- Scenari di blocco: l'unica eccezione in cui è consentito l'accesso SSH unilaterale. Vengono registrate le trascrizioni complete delle sessioni della shell.
Questi controlli bilanciano la necessità di un accesso shell legittimo con il rischio associato a un accesso shell eccessivamente ampio.
Contesto: SSH su Google
In passato, Google utilizzava SSH per amministrare le proprie macchine. Lo sviluppo di Borg ha consentito 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 il debug.
- L'accesso SSH è un prezioso strumento didattico per comprendere i vari livelli di astrazione.
- In scenari di ripristino di emergenza imprevisti, gli strumenti di livello superiore potrebbero non essere disponibili.
Per bilanciare questi motivi e il rischio per la sicurezza che comportavano, Google ha perseguito una serie di traguardi per eliminare gradualmente il rischio SSH e poi l'utilizzo.
Traguardo del monitoraggio centralizzato e controllo dell'accesso
Google ha investito in un sistema centrale di monitoraggio e autorizzazione SSH noto come autorizzazione di monitoraggio basata sull'identità dell'host (HIBA). HIBA fornisce visibilità su qualsiasi utilizzo di SSH e consente l'applicazione di criteri di autorizzazione rigorosi. I tentativi di 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 di comportamenti dannosi. Tuttavia, il rilevamento è intrinsecamente reattivo e vulnerabile all'elusione e all'offuscamento.
Eliminazione della milestone 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 nuovo software di basso livello, ma non per eseguire servizi di produzione) per i team di sviluppo.
API specifiche
Alcuni team di Google che in passato 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 ristretto che servono lo specifico caso d'uso e forniscono dati strutturati.
Le API specifiche hanno un numero ridotto di metodi allineati ai percorsi utente comuni e astraggono i dettagli di accesso di basso livello. Di conseguenza, sono la soluzione preferita di Google perché offrono la migliore sicurezza e controllabilità. Se li creiamo sull'infrastruttura di chiamata di procedura remota (RPC) di Google, beneficiamo di decenni di investimenti in sicurezza e audit.
Proxy sicuri per SSH
Alcuni team Google non possono determinare in anticipo i comandi di cui potrebbero aver bisogno. In questo caso, Google utilizza un daemon di esecuzione dei comandi che accetta solo richieste di esecuzione di comandi arbitrari da un proxy attendibile gestito da un team di sicurezza. Questa tecnologia è simile a quella utilizzata nei proxy sicuri per NoPe.
I proxy sicuri per SSH sono responsabili dell'autorizzazione granulare dell'esecuzione dei comandi e del controllo. L'autorizzazione si basa sull'argomento e sull'ambiente del comando, sui parametri di limitazione della frequenza, sulle giustificazioni aziendali e sull'MPA. Questa procedura di autorizzazione consente restrizioni arbitrarie e precise sui comandi che possono essere eseguiti in base ai playbook e alle best practice del team. In condizioni di errore imprevisto non acquisite nei playbook esistenti, il personale può comunque eseguire i comandi di debug necessari dopo che un altro individuo autorizzato li ha approvati.
MPA per SSH
I pochi team rimanenti che lavorano sull'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 in cui è consentito l'accesso alla shell unilaterale: per garantire che Google possa risolvere le situazioni di blocco. Le chiavi SSH utilizzate per questo scopo vengono generate con un processo di controllo distinto e archiviate offline su hardware antimanomissione. Quando vengono utilizzate queste chiavi, vengono registrate le trascrizioni complete della sessione della shell.
Controlli dell'accesso fisico
I data center di Google sono un ambiente complesso di server, dispositivi di rete e sistemi di controllo che richiedono un'ampia gamma di ruoli e competenze per la gestione, la manutenzione e il funzionamento.
Google implementa sei livelli di controlli fisici e molti controlli logici sulle macchine stesse per proteggere i carichi di lavoro nel data center. Inoltre, difendiamo uno spazio tra le macchine, che chiamiamo spazio fisico-logico.
I controlli fisico-logici forniscono ulteriori livelli di difesa tramite controlli denominati hardening della macchina, controllo dell'accesso basato sulle attività e autodifesa del sistema. I controlli fisici-logici difendono da un avversario che cerca di sfruttare l'accesso fisico a una macchina e di passare a un attacco logico ai carichi di lavoro della macchina.
Per ulteriori informazioni, consulta l'articolo In che modo Google protegge lo spazio fisico-logico in un data center.
Controlli del firmware e del software di sistema
La security posture di una macchina del data center viene stabilita al momento dell'avvio. Il processo di avvio della macchina configura l'hardware e inizializza il sistema operativo, mantenendo la macchina sicura per l'esecuzione nell'ambiente di produzione di Google.
In ogni fase della procedura di avvio, Google implementa controlli leader del settore per contribuire a imporre lo stato di avvio che ci aspettiamo e per contribuire a mantenere i dati dei clienti al sicuro. Questi controlli contribuiscono a garantire che le nostre macchine si avviano con il software previsto, consentendoci di rimuovere le vulnerabilità che potrebbero compromettere la postura di sicurezza iniziale della macchina.
Per saperne di più, consulta Come Google impone l'integrità dell'avvio sulle macchine di produzione.
Protezione dei workload
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 diversi requisiti di sicurezza. L'infrastruttura di Google utilizza una gerarchia di workload chiamata anelli di sicurezza dei workload (WSR). WSR contribuisce a garantire che i carichi di lavoro critici non vengano pianificati sulle stesse macchine dei carichi di lavoro meno sicuri, evitando al contempo un impatto negativo sull'utilizzo delle risorse. WSR raggruppa i workload in quattro classi di sensibilità: di base, sensibile, protetta e non protetta. Tenta di pianificarli in pool di macchine diversi.
Il seguente diagramma mostra come WSR raggruppa e pianifica i carichi di lavoro su macchine di base, di produzione e di sviluppo.
WSR fornisce un ulteriore livello di difesa contro l'escalation dei privilegi locali utilizzando attacchi di vulnerabilità del kernel o attacchi side-channel della CPU. WSR contribuisce a garantire che solo i carichi di lavoro con requisiti di sicurezza simili vengano pianificati congiuntamente sulle stesse macchine. Per implementare WSR, eseguiamo le seguenti operazioni:
- Classifica i workload in base ai requisiti di sicurezza. Ogni classe è nota come anello del workload.
- Distribuisci le macchine fisiche in più pool di macchine isolati 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 riducono il rischio di compromissione tramite l'escalation dei privilegi locali.
Ad esempio, WSR richiede che i workload di base vengano eseguiti su macchine dedicate e non vengano mai pianificati insieme a workload non di base. Questo vincolo fornisce un forte isolamento dai carichi di lavoro meno sicuri.
Metodi per isolare i 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 side-channel della CPU. WSR, introdotto per la prima volta in USENIX ;login:, consente a Google di ridurre il rischio associato alla collocazione condivisa dei carichi di lavoro mantenendo un elevato utilizzo delle risorse.
Per impostazione predefinita, Borg utilizza i limiti 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. 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 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 trattamento di dati non attendibili includono l'hosting di codice di terze parti o la codifica di video.
Google ottiene la fiducia nei suoi binari utilizzando BAB. Tuttavia, BAB non è sufficiente a garantire l'integrità dei workload 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 binario. Sia BAB che le sandbox presentano limitazioni.
BAB è un controllo efficace per i prodotti maturi, ma potrebbe ridurre la velocità durante le fasi iniziali dello sviluppo di nuovi sistemi e durante l'esecuzione di esperimenti senza dati sensibili (ad esempio, l'ottimizzazione della 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 a rischio più elevato di escalation dei privilegi locali (ad esempio, sfruttando una vulnerabilità del kernel per ottenere l'accesso root locale su una macchina).
Il sandboxing dei carichi di lavoro non attendibili mitiga anche il rischio per la sicurezza, ma a scapito di un maggiore utilizzo di risorse di calcolo e memoria. L'efficienza può diminuire di una percentuale a due cifre, a seconda del workload e del tipo di sandbox. Per un esempio degli effetti sulle prestazioni di un carico di lavoro in sandbox, consulta i benchmark dettagliati nella guida alle prestazioni di gVisor. WSR ci consente di risolvere le limitazioni di efficienza derivanti dall'isolamento dei carichi di lavoro.
Anelli di workload
Google definisce quattro classi di workload in base ai requisiti di sicurezza: di base, sensibili, protetti e non protetti. La tabella seguente le descrive in modo più dettagliato.
| Anello del workload | Descrizione |
|---|---|
| Di base | Un piccolo insieme di workload fondamentali per la sicurezza di Google, come i servizi di gestione di identità e accessi. I workload di base hanno i requisiti di sicurezza più elevati e sacrificano regolarmente l'efficienza per aumentare la sicurezza e l'affidabilità. |
| Riservato | Workload che possono causare interruzioni diffuse o che hanno accesso a dati sensibili specifici del prodotto, come dati utente o dati dei clienti. |
| Protezione | Supporta i carichi di lavoro non critici per la sicurezza, ma che hanno adottato BAB o sono in sandbox, in modo da rappresentare un rischio minimo per i carichi di lavoro vicini. |
| Non indurito | Tutti gli altri workload, inclusi quelli che eseguono codice non attendibile. |
In Google, classifichiamo i workload critici che supportano prodotti specifici come sensibili, mentre i workload 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 protetto in base esclusivamente ai controlli adottati e al tipo di input che elabora. Con i workload protetti, ci preoccupiamo principalmente del loro impatto su altri workload, quindi le soluzioni di protezione possono includere il sandboxing.
Pool di macchine
Per evitare la co-pianificazione di servizi sensibili con workload meno attendibili (ad esempio quelli che elaborano dati non attendibili senza una sandbox), dobbiamo eseguirli su pool isolati di macchine. L'isolamento delle macchine semplifica la comprensione degli invarianti di sicurezza, ma ogni pool di macchine aggiuntivo introduce compromessi nell'utilizzo e nella gestibilità delle risorse.
L'isolamento delle macchine comporta un utilizzo inferiore delle risorse fisiche, perché garantire che i pool di macchine siano utilizzati completamente diventa più difficile man mano che aggiungiamo altri pool. Il costo dell'efficienza potrebbe diventare significativo quando sono presenti diversi pool di macchine di grandi dimensioni isolati.
Poiché l'impronta delle risorse dei carichi di lavoro varia in ogni pool, l'isolamento rigoroso aggiunge un sovraccarico di gestione per ribilanciare e riassegnare periodicamente le macchine tra i pool. Questo ribilanciamento richiede lo svuotamento di tutti i carichi di lavoro da una macchina, il riavvio della macchina e l'esecuzione della nostra procedura di sanificazione più pesante, che contribuisce a garantire l'autenticità e l'integrità del firmware.
Queste considerazioni implicano che l'implementazione dell'isolamento delle macchine di Google deve fornire modi per ottimizzare l'utilizzo delle risorse fisiche, difendendo al contempo i carichi di lavoro fondamentali 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, Google Cloud prodotti come Compute Engine offrono il single-tenancy per fornire l'isolamento della macchina fisica.
Vincoli di pianificazione del workload
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 fondamentali e sensibili, ma questo documento presenta ciascuno come un unico pool per semplicità.
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 workload sottoposti a hardening 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 diverse classi di carichi di lavoro sia tra i pool di macchine sia al loro interno. I workload di base sono gli unici tenant di macchine di base dedicate. L'autorizzazione binaria o il sandboxing per i workload in esecuzione su macchine di produzione aiutano a prevenire attacchi di escalation dei privilegi locali. Sulle macchine di sviluppo, esiste un rischio residuo che un workload non protetto possa compromettere un altro workload, ma la compromissione è limitata alle macchine di sviluppo perché i workload protetti non possono creare nuovi job.
I workload con protezione avanzata vengono pianificati su macchine di produzione o di sviluppo in base alla disponibilità. Consentire la pianificazione in più pool potrebbe sembrare controintuitivo, ma è essenziale per alleviare il calo di utilizzo causato dai vincoli di pianificazione. I carichi di lavoro protetti colmano le lacune introdotte dall'isolamento dei job sensibili e non protetti. Inoltre, maggiore è l'impronta delle risorse protette, più fluttuazioni nell'utilizzo delle risorse delle altre due classi possono essere gestite senza la necessità di costosi spostamenti delle macchine tra gli anelli.
Il seguente diagramma mostra i vincoli di pianificazione imposti a diverse classi di carichi di lavoro. Un carico di lavoro protetto può trovarsi su una macchina di produzione o di sviluppo.
Isolando i workload di base su più pool di base, Google scambia l'efficienza delle risorse con una maggiore sicurezza. Fortunatamente, i workload di base tendono ad avere un footprint delle risorse relativamente piccolo e piccoli pool isolati di macchine dedicate hanno un impatto trascurabile sull'utilizzo complessivo.
WSR fornisce una solida garanzia che i carichi di lavoro non di base non possano mai essere eseguiti su macchine di base. Le macchine di base sono protette dal movimento laterale, in quanto 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 contribuire a proteggere servizi di produzione, macchine di produzione e carichi di lavoro. I controlli includono quanto segue:
- Controlli di accesso amministrativo e BAB per i servizi di produzione
- Controlli di accesso alla shell, controlli di accesso fisico e controlli del firmware e del software di sistema per le macchine di produzione
- WSR per diverse classi di carichi di lavoro
Insieme, questi controlli impongono vincoli che contribuiscono a proteggere gli utenti e i clienti di Google e i loro dati. Il seguente diagramma illustra come i controlli interagiscono per supportare la postura di sicurezza di Google.
Passaggi successivi
- Per ulteriori informazioni sui controlli di sicurezza dell'infrastruttura Google, leggi la Panoramica sulla progettazione della sicurezza dell'infrastruttura Google.
- Per scoprire di più sulla cultura della sicurezza di Google, leggi Building secure and reliable systems (libro di O'Reilly).
- Per saperne di più su zero-touch prod, consulta la presentazione di SREcon.