Google Distributed Cloud (GDC) con air gap aiuta a proteggere i rack hardware, i sistemi operativi host, i confini multi-tenant, le catene di fornitura del software e il traffico di rete di cui è stato eseguito il deployment in strutture di data center accreditate.
Sicurezza delle strutture
L'hardware GDC viene distribuito all'interno di strutture di data center accreditate controllate da te o dall'operatore della struttura designato. La tua organizzazione e l'operatore dell'infrastruttura sono responsabili dell'applicazione dei controlli di accesso fisico, delle protezioni ambientali e delle procedure di gestione dei supporti per la struttura che ospita i rack GDC.
I controlli di sicurezza fisica consigliati includono:
- Controlli di accesso al perimetro e ai rack: limita l'accesso fisico al data center e ai rack GDC utilizzando lettori di badge, autenticazione biometrica, registri di accompagnamento dei visitatori, pattuglie di guardie di sicurezza 24 ore su 24, 7 giorni su 7 e porte dei rack chiuse a chiave.
- Sorveglianza e rilevamento manomissione: monitoraggio dei corridoi dei rack con televisione a circuito chiuso (TVCC) continua e allarmi di intrusione fisica.
- Isolamento di alimentazione, raffreddamento e cablaggio: forniscono alimentatori ridondanti, monitoraggio ambientale e percorsi di cablaggio protetti che soddisfano i requisiti normativi e di accreditamento (come ISO/IEC 27001 o ICD 705).
Sicurezza hardware
GDC viene eseguito su rack hardware modulari pre-integrati, realizzati con componenti commerciali pronti all'uso (COTS) di produttori di apparecchiature originali (OEM) verificati. Le strutture regionali certificate, con personale sottoposto a controlli dei precedenti, integrano i rack hardware. Anche i componenti hardware e firmware ad alto rischio vengono sottoposti a revisioni di sicurezza dedicate per rilevare minacce alla catena di fornitura e alla manomissione fisica.
I principali controlli di sicurezza dell'hardware includono:
- Server di computing: i server bare metal utilizzano radici di attendibilità hardware, Trusted Platform Module (TPM 2.0) e firmware Baseboard Management Controller (BMC) firmato per verificare l'integrità dell'hardware e dell'avvio prima di caricare il sistema operativo.
- Switch di rete e firewall perimetrali: gli switch top-of-rack e di gestione applicano i controlli degli accessi a livello di porta e la crittografia MACsec. I firewall perimetrali ridondanti forniscono un'ispezione stateful a velocità di linea e la prevenzione delle intrusioni al confine della zona.
- Appliance di archiviazione: le appliance di archiviazione di blocchi, file e oggetti aziendali applicano la crittografia at-rest AES-256 con accelerazione hardware su unità con crittografia automatica (SED) e l'isolamento logico dei tenant tramite macchine virtuali di archiviazione (SVM) dedicate.
- Moduli di sicurezza hardware (HSM): appliance HSM dedicate collegate alla rete (convalidate FIPS 140-2 livello 3 e FIPS 140-3) generano, archiviano e proteggono le chiavi di crittografia root in hardware con rilevamento di manomissioni.
Per ulteriori informazioni, leggi la seguenti documentazione:
| Argomento | Documentazione e guide alla configurazione |
|---|---|
| Gestione di hardware e HSM | Controlla le chiavi HSM e Macchine dei nodi del cluster |
Sicurezza di host e nodi
Ogni host bare metal e nodo del cluster Kubernetes in GDC esegue un'immagine del sistema operativo con protezione avanzata configurata per ridurre al minimo la superficie di attacco e impedire l'escalation dei privilegi non autorizzata.
- Sistema operativo con protezione avanzata STIG: i nodi eseguono Linux con protezione avanzata rispetto alle guide all'implementazione tecnica della sicurezza (STIG) della Defense Information Systems Agency (DISA) e ai benchmark del Center for Internet Security (CIS). I pacchetti, i compilatori e i servizi di rete non necessari vengono rimossi dall'immagine di base.
- Avvio protetto UEFI: sia gli host bare metal che le macchine virtuali (VM) utente supportano l'avvio protetto UEFI per verificare che durante l'avvio vengano eseguite solo immagini kernel e bootloader con firma crittografica.
- Controlli degli accessi obbligatori e del kernel: i nodi applicano SELinux in modalità di applicazione forzata, filtro delle chiamate di sistema seccomp, spazi dei nomi Linux e limiti delle risorse cgroups per isolare i container dal kernel host sottostante.
- Integrità dell'host e protezione degli endpoint: il monitoraggio dell'integrità dei file (FIM) controlla i file di sistema critici per rilevare eventuali modifiche non autorizzate, mentre i controlli di rilevamento e risposta degli endpoint (EDR) e anti-malware monitorano l'esecuzione dei processi e la telemetria dell'host.
Per ulteriori informazioni, leggi la seguenti documentazione:
| Argomento | Documentazione e guide alla configurazione |
|---|---|
| Isolamento dei nodi e benchmark | Panoramica dell'isolamento dei nodi e CIS Kubernetes Benchmark |
| Avvio protetto e gestione del sistema operativo delle VM | Avvia una VM in modo sicuro e Gestisci i pacchetti del sistema operativo |
Tenancy
GDC fornisce una multi-tenancy gerarchica con isolamento fisico e di rete rigido tra le organizzazioni e isolamento logico dello spazio dei nomi tra i progetti all'interno di un'organizzazione.
Isolamento logico tra organizzazioni, cluster e progetti
Il seguente diagramma mostra come il cluster root-admin, i cluster dell'infrastruttura dell'organizzazione e i cluster dei workload sono isolati tra i confini di gestione e tenant:
- Cluster root-admin: dedicato al bootstrap delle organizzazioni, alla gestione dell'inventario hardware e all'esecuzione dei servizi di sicurezza e osservabilità dell'infrastruttura.
- Organizzazione: il confine del tenant di primo livello. Ogni organizzazione ha il proprio cluster di infrastruttura dell'organizzazione dedicato, la configurazione del provider di identità, la gerarchia del sistema di gestione delle chiavi (KMS) e l'istanza di routing e forwarding virtuale (VRF).
- Cluster Kubernetes: puoi eseguire il provisioning di cluster condivisi con ambito a livello di organizzazione (che ospitano più progetti) o di cluster standard con ambito a livello di progetto (dedicati a un singolo progetto per una maggiore separazione dei workload).
- Progetto: un'unità di tenancy logica all'interno di un'organizzazione in cui esegui il deployment di VM, container, database e risorse di archiviazione. I progetti applicano l'uguaglianza degli spazi dei nomi Kubernetes, i limiti controllo dell'accesso basato su ruoli (RBAC) e le policy di rete del progetto tra i cluster.
Isolamento fisico e VRF tra i rack
Nei rack 42U fisici, GDC isola le organizzazioni su server di computing, macchine virtuali di archiviazione (SVM) e VRF di rete separati, in modo che non vengano condivisi server di computing fisici tra le organizzazioni:
Per ulteriori informazioni, leggi la seguenti documentazione:
| Argomento | Documentazione e guide alla configurazione |
|---|---|
| Gerarchia delle risorse e progetti | Gerarchia delle risorse e Gestione dei progetti |
| Cluster Kubernetes | Cluster Kubernetes in GDC e Configurazioni dei cluster |
| Progettazione di confini e workload | Progetta i confini di accesso e Progetta la separazione dei workload |
Sicurezza delle applicazioni
GDC protegge sia il software della piattaforma fornito tramite l'air gap sia le applicazioni dei clienti di cui è stato eseguito il deployment all'interno della tua organizzazione.
Catena di fornitura del software e convalida SLSA
Tutti i componenti della piattaforma GDC, i servizi proprietari e i servizi di terze parti gestiti sono creati in ambienti di build isolati ed ermetici e vengono analizzati per rilevare eventuali vulnerabilità. Gli artefatti vengono firmati sul lato connesso ("lato basso") in conformità ai requisiti di Supply chain Levels for Software Artifacts (SLSA) prima del trasferimento attraverso l'air gap ("lato alto").
Ogni release include una distinta base del software (SBOM) che descrive in dettaglio i componenti, le dipendenze e le librerie del software. Gli artefatti vengono verificati utilizzando firme crittografiche e checksum SHA-256 prima del deployment.
Artifact Registry e applicazione delle policy
GDC applica i controlli delle immagini container e delle policy prima del deployment:
- Artifact Registry locale (Harbor): le immagini container e i grafici Helm vengono archiviati in un registro Harbor locale all'interno dell'ambiente con air gap, supportando la firma delle immagini e l'analisi delle vulnerabilità senza accesso a internet esterno.
- Controllo di ammissione e policy dell'organizzazione: Open Policy Agent (OPA) Gatekeeper applica le policy dell'organizzazione ai cluster Kubernetes, impedendo l'esecuzione dei pod con escalation dei privilegi, accesso alla rete host o immagini container non attendibili.
Per ulteriori informazioni, leggi la seguenti documentazione:
| Argomento | Documentazione e guide alla configurazione |
|---|---|
| Policy e Artifact Registry | Configura le policy dell'organizzazione e Crea e gestisci le risorse Harbor |
| Workload e servizi | Workload dei container in GDC ed Esegui il deployment dei servizi Marketplace |
Sicurezza di rete
GDC applica la segmentazione della rete multilivello dalle porte degli switch fisici fino ai criteri del mesh di servizi di livello 7.
Segmentazione VRF e VXLAN del piano dati
La struttura del piano dati utilizza la VPN Ethernet (EVPN) Multiprotocol BGP (MP-BGP) con l'incapsulamento Virtual Extensible LAN (VXLAN) per isolare il traffico tra il cluster root-admin e ogni organizzazione tenant.
- Rete di gestione out-of-band (OOB): le interfacce di gestione dell'hardware operano su una rete di gestione fisicamente separata, isolata dal traffico dei tenant e accessibile solo dal cluster root-admin.
- Isolamento VRF e VXLAN: a ogni organizzazione vengono assegnati identificatori di rete virtuale (VNI) di livello 3 dedicati, VRF esterni e interni e macchine virtuali di archiviazione (SVM) isolate, in modo che il traffico dei tenant non possa superare i confini dell'organizzazione senza un attraversamento esplicito del firewall.
- Firewall di nuova generazione, IDPS e protezione dagli attacchi denial of service (DoS): i firewall perimetrali e i sistemi di rilevamento e prevenzione delle intrusioni (IDPS) applicano una postura di negazione predefinita, ispezionano il traffico in entrata e in uscita in base alle firme delle minacce e collaborano con i bilanciatori del carico per limitare i flood di sessioni. I log del firewall e dell'IDPS si integrano con lo stack di osservabilità dell'organizzazione e con il monitoraggio della sicurezza dell'infrastruttura.
- Policy di rete di progetto e Kubernetes: all'interno di un'organizzazione, puoi applicare la microsegmentazione default-deny tra progetti e pod utilizzando le risorse
ProjectNetworkPolicy,OrganizationNetworkPolicye KubernetesNetworkPolicysupportate da Cilium.
Per ulteriori informazioni, leggi la seguenti documentazione:
| Argomento | Documentazione e guide alla configurazione |
|---|---|
| Perimetro e prevenzione delle minacce | Panoramica del networking, Richiedi la prevenzione delle minacce e Controllo del traffico in uscita |
| Policy di rete e log di flusso | Policy di rete dell'organizzazione, Policy di rete del progetto, Configura le policy di rete di Kubernetes e Gestisci i log di flusso |
| Connettività esterna | Configura la VPN GDC e Stabilisci la connettività con gli interconnessioni |