Sicurezza

Questo documento fornisce una panoramica che copre i concetti principali, i livelli e i ruoli operativi per mantenere la sicurezza all'interno di Google Distributed Cloud (GDC) con air gap. GDC è progettato per ambienti disconnessi e altamente sicuri e per la conformità a rigidi requisiti di sovranità dei dati.

Questo documento è rivolto ai gruppi di operatori dell'infrastruttura, amministratori della piattaforma e operatori delle applicazioni che gestiscono la sicurezza per la propria organizzazione. Per saperne di più, consulta la documentazione relativa ai segmenti di pubblico per GDC con air gap.

Questo documento ti aiuta a comprendere gli attributi di sicurezza chiave nelle seguenti categorie:

• Conformità
• Operazioni di sicurezza
• Operazioni di affidabilità
• Crittografia
• Identity and Access Management (IAM)
• Sicurezza di rete
• Sicurezza delle applicazioni
• Sicurezza di host e nodi
• Sicurezza hardware
• Sicurezza delle strutture

Strategia di sicurezza

GDC adotta un approccio incentrato sulla sicurezza con più livelli di sicurezza per offrire il massimo controllo, rispettare le normative di legge e salvaguardare i dati riservati. È progettato per essere eseguito su hardware dedicato e protetto in un data center locale per fornire un isolamento rigoroso dei tenant.

I livelli di sicurezza forniti da GDC includono sicurezza dell'hardware, sicurezza di host e nodi, sicurezza delle applicazioni, sicurezza di rete, crittografia, Identity and Access Management (IAM), operazioni di sicurezza e affidabilità, conformità e offerte di sicurezza.

GDC ha un modello di sicurezza condivisa per proteggere l'intero stack di applicazioni. GDC fornisce Infrastructure as a Service (IaaS), Platform as a Service (PaaS) e Software as a Service (SaaS). In tutte le configurazioni di GDC, Google e l'operatore sono responsabili della protezione dei livelli dell'infrastruttura. Il cliente è responsabile della protezione della configurazione del progetto e del livello di applicazione, inclusi i container dell'applicazione, le immagini di base e le dipendenze.

Dal punto di vista della sicurezza, i seguenti gruppi di segmenti di pubblico gestiscono GDC:

• Gruppo di operatori dell'infrastruttura: gestisce le operazioni quotidiane dell'infrastruttura di sistema e non ha accesso ai dati dei clienti. Questa persona è l'amministratore di livello più alto del sistema e potrebbe essere Google, una terza parte con contratto o il cliente, a seconda della natura delle limitazioni di sovranità.

• Gruppo di amministratori della piattaforma: un utente tipo del cliente che gestisce le risorse e le autorizzazioni per i progetti. Questo è il livello più alto di privilegio amministrativo concesso al cliente ed è l'unico livello amministrativo che può concedere l'accesso ai dati dei clienti.

• Gruppo di operatori di applicazioni: sviluppa applicazioni di cui eseguire il deployment e l'esecuzione e configura risorse e autorizzazioni granulari su GDC. Questa persona opera nell'ambito delle policy stabilite dall'amministratore della piattaforma (PA) per garantire che i sistemi siano in linea con i requisiti di sicurezza e conformità del cliente.

Per saperne di più, consulta Pubblici della documentazione.

Sicurezza delle strutture

Puoi eseguire il deployment di GDC in data center con air gap designati dai clienti. La sicurezza fisica specifica per la località varia in base ai requisiti dei singoli clienti. Per rispettare le normative locali, i data center potrebbero aver bisogno di un accreditamento, ad esempio ISO 27001. Il data center deve disporre di più misure di sicurezza, come sistemi di difesa perimetrale sicuri per impedire l'accesso non autorizzato al data center, copertura completa delle telecamere per monitorare tutte le attività nel data center, autenticazione fisica per garantire che solo il personale autorizzato possa accedere al data center, personale di guardia per pattugliare il data center 24 ore su 24, 7 giorni su 7 e rispondere a eventuali incidenti di sicurezza, nonché norme rigorose di accesso e sicurezza per regolamentare il modo in cui il personale accede e utilizza il data center. Queste misure di sicurezza costituiscono un importante livello di protezione iniziale per salvaguardare i dati archiviati nel data center da accessi, usi, divulgazioni, interruzioni, modifiche o distruzioni non autorizzati.

Sicurezza hardware

Google adotta una procedura rigorosa per garantire la sicurezza del suo hardware. Tutto l'hardware GDC viene acquistato e assemblato da partner verificati e certificati per soddisfare i requisiti di sovranità e catena di fornitura specifici del cliente. L'hardware è testato e approvato per soddisfare i rigorosi standard interni di Google e le esigenze dei clienti più attenti alla sicurezza. Tutti i componenti secondari dell'hardware GDC provengono da fornitori affidabili, verificati e noti per la loro affidabilità. L'integrazione dell'hardware nei rack GDC viene eseguita presso centri certificati regionali, ovvero strutture approvate da Google per la gestione di hardware sensibile. Tutto il personale che gestisce l'hardware GDC è sottoposto a controlli dei precedenti, il che garantisce che solo il personale autorizzato abbia accesso all'hardware. Inoltre, l'implementazione effettiva di alcuni componenti hardware e firmware ad alto rischio viene sottoposta a revisione della sicurezza da parte di un team dedicato. Queste revisioni prendono in considerazione minacce quali: attacchi alla catena di fornitura, attacchi fisici e attacchi di esecuzione locale su componenti hardware e firmware, incluse le minacce persistenti. Queste revisioni ci consentono di acquisire conoscenze che informano direttamente i nostri requisiti di sicurezza hardware, tra cui firmware sicuro e aggiornamenti firmware, integrità del firmware, avvio protetto, gestione e manutenzione sicure. Google mantiene stretti rapporti con tutti i fornitori e i team che utilizzano l'hardware per garantire che vengano fornite funzionalità di sicurezza di alto livello. Ciò significa che Google collabora costantemente con i suoi partner per garantire che l'hardware sia il più sicuro possibile. Google alza l'asticella migliorando i requisiti hardware e di sicurezza, eseguendo revisioni interattive della sicurezza e collaborando con i team di prodotto per implementare nuove funzionalità di sicurezza create appositamente per GDC e profondamente integrate non solo con l'hardware e il firmware effettivi, ma anche con altre funzionalità del prodotto.

Sicurezza di host e nodi

GDC garantisce che, per impostazione predefinita, sui sistemi possa essere caricato solo il nostro sistema operativo (OS) Node sicuro e personalizzato. Le immagini e le configurazioni con protezione avanzata riducono notevolmente le superfici di attacco. I moduli crittografici che proteggono i dati at-rest e in transito sono convalidati FIPS 140-2/3, il che significa che sono stati rigorosamente testati per la sicurezza e verificati da un laboratorio indipendente e accreditato. GDC fornisce un software antimalware per il sistema operativo in esecuzione sui nodi bare metal e una soluzione per scansionare i sistemi di archiviazione. Google pacchettizza gli aggiornamenti per questi scanner, che vengono inclusi negli aggiornamenti di sistema regolari applicati dall'IO utilizzando il processo di upgrade di GDC. Gli avvisi di rilevamento vengono inviati all'IO. GDC fornisce anche strumenti di monitoraggio dell'integrità e rilevamento delle violazioni per proteggere il sistema da modifiche involontarie. Nel complesso, queste misure di sicurezza contribuiscono a proteggere il sistema da una serie di attacchi. Le misure di sicurezza rendono difficile per gli aggressori accedere al sistema, sfruttare le vulnerabilità e installare malware.

Tenancy

GDC è una piattaforma cloud gestita multi-tenant simile alla piattaformaGoogle Cloud . L'architettura è progettata per fornire un isolamento efficace tra i tenant, fornendo un livello di protezione efficace tra gli utenti del cloud e consentendo agli utenti di soddisfare standard rigorosi di accreditamento dei workload. GDC offre due livelli di isolamento dei tenant. Il primo livello, chiamato Organizzazioni, fornisce un forte isolamento fisico del computing, mentre il secondo livello, Progetti, offre opzioni di allocazione delle risorse più granulari tramite la separazione logica.

Nessun server di computing fisico è condiviso tra le organizzazioni e anche i livelli degli operatori mantengono la tenancy. Le IO non sono autorizzate ad accedere ai livelli PA. Allo stesso modo, gli AO non possono accedere ai livelli PA.

Sicurezza delle applicazioni

Per proteggersi dagli attacchi alla catena di fornitura del software, tutto il software GDC viene sviluppato in conformità con i Supply chain Levels for Software Artifacts (SLSA), un framework di sicurezza della catena di fornitura sviluppato da Google in collaborazione con organizzazioni tra cui CNCF e Linux Foundation.

SLSA è un elenco di controllo di standard e controlli per prevenire le manomissioni, migliorare l'integrità e proteggere i pacchetti all'interno della catena di fornitura del software. Questo elenco di controllo è progettato per prevenire exploit che attaccano i repository di codice sorgente, i sistemi di build e i pacchetti di dipendenze di terze parti.

Tutto il codice sorgente e le dipendenze di GDC sono archiviati in un sistema di controllo della versione di Google isolato e criptato in data center Google sicuri. Tutto il codice ha una cronologia verificata e richiede che una seconda persona esamini le modifiche al codice prima che vengano accettate nel sistema di controllo della versione.

Le build vengono distribuite utilizzando un sistema di orchestrazione delle release di Google che sfrutta Google Cloud Build e gli strumenti di test automatici di Google per la creazione, il test e il rilascio completamente automatici di immagini container e file binari. Tutte le build sono isolate, ermetiche e definite utilizzando il principio build-as-code e nessun individuo ha accesso unilaterale al processo di distribuzione del software.

Tutte le immagini vengono analizzate per rilevare eventuali vulnerabilità utilizzando più scanner di sicurezza delle applicazioni e vengono convalidate in più punti utilizzando una combinazione di firme crittografiche e checksum SHA256. Ogni release contiene una distinta base del software (SBOM) che include dettagli sui componenti software, sulle dipendenze e sulle librerie, nonché sui dati forniti.

Sicurezza di rete

Questa sezione fornisce una panoramica della sicurezza di rete di GDC.

Rete fisica

Sebbene GDC sia progettato per essere utilizzato in ambienti disconnessi, in pratica è probabile che i sistemi GDC siano connessi a un ambiente protetto più ampio, connesso tramite la rete privata interna di un cliente, pur rimanendo disconnesso dalla rete internet pubblica.

Tutto il traffico di rete tra la rete privata del cliente e i sistemi GDC passa attraverso firewall e sistemi di rilevamento e prevenzione delle intrusioni (IDS/IPS). Il firewall fornisce la prima linea di difesa per controllare l'accesso al sistema. Il firewall e l'IDS/IPS controllano il traffico in entrata e in uscita in base a policy di sicurezza configurabili e utilizzano il machine learning per analizzare automaticamente il traffico e bloccare l'accesso non autorizzato. Per impostazione predefinita, il sistema IDS/IPS ispeziona tutte le comunicazioni in entrata e in uscita per l'infrastruttura. I PA possono anche utilizzare il sistema IDS/IPS per l'ispezione del traffico dei propri workload. Sia i firewall che i sistemi IDS/IPS sono integrati anche con lo stack di osservabilità dell'organizzazione per i workload dei clienti e con lo stack SIEM dell'IO per l'infrastruttura, al fine di consentire ulteriori analisi di sicurezza e indagini forensi.

I firewall applicano regole di negazione predefinite come security posture iniziale per impedire accessi involontari e fughe di dati. L'IO e il PA dispongono di metodi per definire ulteriori regole di accesso in base alle esigenze. All'interno di GDC, sono presenti due reti fisicamente separate per isolare le funzioni di amministrazione e controllo dai dati dei workload dei clienti.

La rete di gestione out-of-bound (OOB) viene utilizzata esclusivamente per funzioni amministrative, come le modifiche alla configurazione dei dispositivi di rete, delle appliance di archiviazione e di altri componenti hardware. Solo l'IO ha accesso alla rete OOB e solo in casi eccezionali. Le ACL di rete sono configurate in modo che solo i server che si trovano nel cluster root-admin controllato dall'IO possano accedere a questa rete. La rete del piano dati connette i server dei workload tra loro ed è accessibile dall'AP e dagli OA.

Networking software-defined

La rete del piano dati è una rete overlay basata su Virtual Routing and Forwarding (VRF) per l'isolamento del traffico dei tenant. Ogni organizzazione tenant ha una rete VRF esterna e una interna. I servizi rivolti all'esterno, ad esempio il bilanciatore del carico esterno e il NAT in uscita, si troverebbero nel dominio esterno. I workload dei clienti risiedono nella VRF interna.

La rete interna viene utilizzata per la comunicazione all'interno del tenant, ad esempio il traffico dei workload tra i nodi e verso l'archiviazione di file e l'archiviazione a blocchi all'interno dell'organizzazione. La rete esterna viene utilizzata per comunicare all'esterno di un'organizzazione. Il traffico di gestione dei tenant verso le funzioni di controllo dell'accesso o il traffico dei clienti verso i progetti di accesso deve passare attraverso la rete esterna. Ogni workload del cliente ha bilanciatori del carico e gateway NAT da configurare per il traffico in entrata e in uscita.

Rete virtuale

Il networking virtuale di GDC Virtual è un livello di networking a livello di organizzazione basato sulla rete overlay. È basato sul driver CNI (Container Network Interface) gestito da GDC, il piano dati di networking di Anthos.

Il livello di networking virtuale in GDC fornisce un isolamento leggero all'interno dell'organizzazione, denominato "progetto". Questo livello fornisce le seguenti funzionalità di sicurezza di rete:

• Policy di rete del progetto: per la protezione dei confini del progetto.
• Policy di rete dell'organizzazione: per la protezione del perimetro dell'organizzazione.

Le policy di rete del progetto e dell'organizzazione hanno una configurazione di negazione predefinita come punto di partenza per proteggere da accessi indesiderati e fughe di dati.

Protezione dagli attacchi DoS (Denial of Service)

Tutto il traffico verso GDC passa attraverso l'IDS/IPS e un insieme di bilanciatori del carico. L'IDS/IPS rileva ed elimina il traffico non autorizzato e protegge le risorse dai flood di sessione. I bilanciatori del carico possono limitare il traffico in modo appropriato per evitare l'interruzione del servizio. Poiché la connettività esterna viene gestita tramite la rete privata del cliente, quest'ultimo può fornire un livello aggiuntivo di protezione dagli attacchi denial of service distribuiti.

Crittografia

Questa sezione fornisce una panoramica della crittografia di GDC.

PKI

GDC fornisce un'infrastruttura a chiave pubblica (PKI) per la gestione centralizzata delle CA X.509 per i servizi dell'infrastruttura. Per impostazione predefinita, GDC dispone di CA radice private per installazione e di intermedi e foglie distribuiti da queste. Inoltre, GDC può supportare l'installazione di certificati emessi dai clienti negli endpoint rivolti ai clienti, il che aumenta la flessibilità nell'utilizzo dei certificati. GDC coordina centralmente la distribuzione degli archivi di attendibilità, semplificando l'autenticazione e la crittografia del traffico delle applicazioni per i workload e i servizi di sistema. In generale, GDC fornisce una soluzione PKI efficace per proteggere una serie di servizi di infrastruttura per una gestione del trust comoda, ma rigorosamente controllata.

Key Management Service

GDC fornisce un servizio Key Management Service (KMS) supportato da moduli di sicurezza hardware (HSM). Il KMS è un servizio proprietario. Il materiale della chiave rimane all'interno di KMS, che a sua volta è supportato dagli HSM. Le definizioni di risorse personalizzate (CRD) contengono materiale della chiave crittografato. Solo il KMS ha accesso al materiale della chiave non elaborato in memoria. Esiste un KMS per organizzazione. Tutti i dati at-rest sono criptati per impostazione predefinita utilizzando chiavi supportate da HSM. I clienti possono anche scegliere di gestire le proprie chiavi di crittografia. KMS supporta algoritmi approvati da FIPS e moduli convalidati da FIPS. Il KMS supporta l'importazione e l'esportazione delle chiavi in modo sicuro per i casi d'uso di key escrow, eliminazione o ripristino di emergenza. Queste funzionalità rendono KMS un modo sicuro e affidabile per gestire le chiavi di crittografia.

GDC offre anche chiavi di crittografia gestite dal cliente (CMEK). CMEK offre ai clienti il controllo sulle chiavi che proteggono i loro dati at-rest in GDC. Uno dei motivi principali per l'adozione di CMEK è la cancellazione crittografica, un metodo di distruzione dei dati ad alta affidabilità per la correzione della perdita di dati e l'offboarding. Le chiavi possono essere eliminate fuori banda rispetto ai dati che proteggono. Tutti i dati della tua organizzazione sono protetti da un insieme di CMEK che i tuoi operatori della piattaforma possono monitorare, controllare ed eliminare in base alle esigenze. Le chiavi CMEK sono chiavi di crittografia che puoi gestire utilizzando le API HSM. Le CMEK possono essere utilizzate per criptare i dati per l'archiviazione a blocchi, i dischi delle macchine virtuali, il servizio di database e i workload dei container degli utenti.

Crittografia

Questa sezione fornisce una panoramica della crittografia di GDC.

Dati at-rest

Tutti i dati GDC archiviati in file, blocchi e oggetti sono criptati at-rest utilizzando più livelli di crittografia. In ambienti multi-tenant, i dati di ogni tenant vengono criptati con una chiave specifica per il tenant prima di essere scritti nell'archiviazione di file, blocchi e oggetti:

• L'archiviazione a blocchi (volumi di applicazioni, dischi VM, archiviazione di database) è crittografata a tre livelli:
  • Livello software: crittografia Linux Unified Key Setup (LUKS) eseguita all'interno dell'hardware di computing dedicato al tenant con chiavi per volume supportate da HSM, gestite dal cliente.
  • Livello appliance: crittografia a livello di aggregato di volumi (NVE/NAE) eseguita all'interno dell'appliance di archiviazione con chiavi per tenant supportate da HSM, gestite dal cliente.
  • Livello disco: unità con crittografia automatica (SED) con chiavi per unità supportate da HSM, gestite dall'IO.
• L'archiviazione di oggetti è criptata su due livelli
  • Livello bucket: crittografia dei dati degli oggetti coordinata all'interno dell'hardware di computing dedicato al tenant con chiavi supportate da HSM per bucket, gestite dal cliente.
  • Livello disco: SED con chiavi per unità supportate da HSM, gestite dall'IO.
• L'archiviazione su disco del server, ovvero i dati di configurazione del sistema per un singolo tenant, viene criptata a un livello:
  • Livello disco: SED con chiavi per unità supportate da HSM, gestite dal cliente.

Dati in transito

Tutto il traffico GDC è criptato per impostazione predefinita utilizzando moduli di crittografia certificati FIPS 140-2 e protocolli standard di settore come TLS 1.2+, HTTPS e tunnel IPSec. In base al modello di responsabilità condivisa, i clienti devono anche utilizzare algoritmi crittografati sul livello di applicazione per garantire che i requisiti di crittografia siano soddisfatti per tutte le applicazioni di cui è stato eseguito il deployment su GDC.

Identity and Access Management (IAM)

L'accesso al sistema si basa sul principio del privilegio minimo. Gli utenti hanno accesso solo alle risorse di cui hanno bisogno. Questo processo protegge il sistema da accessi non autorizzati e usi impropri. Inoltre, il sistema applica la separazione dei compiti, ad esempio l'assenza di accesso unilaterale. Nessuna persona ha il controllo completo su un sistema o un processo. Questa procedura aiuta a prevenire frodi ed errori. GDC può integrarsi con l'identity provider esistente dei clienti. Il sistema supporta SAML 2.0 e OIDC per la federazione degli IdP. Questo supporto consente agli utenti di autenticare gli utenti all'interno del sistema utilizzando il proprio provider di identità esistente per gestire gli utenti in un'unica posizione. Tutti gli utenti e i workload vengono autenticati prima di accedere al sistema. RBAC e ABAC vengono utilizzati per autorizzare tutti gli accessi al control plane e ai dati. Gli utenti possono accedere alle risorse ed eseguire azioni solo se sono autenticati e autorizzati. Tutti gli accessi vengono registrati nei log di controllo, il che consente agli amministratori di monitorare chi ha eseguito l'accesso a una risorsa e quando. Questo processo aiuta a identificare accessi non autorizzati e usi impropri.

Operazioni di sicurezza

GDC Security Operations (SecOps) fornisce l'assurance delle informazioni per le entità con requisiti rigorosi di sicurezza, conformità e sovranità per offrire la massima riservatezza, integrità e disponibilità operative dei workload con air gap dei clienti regolamentati. Questa architettura di sicurezza è progettata per raggiungere i seguenti obiettivi:

• Correlare il logging della piattaforma GDC per l'analisi e la risposta della sicurezza.
• Identifica, segnala e monitora tempestivamente le vulnerabilità di sicurezza.
• Difendere tutti gli asset OIC e GDC tramite Endpoint Detection & Response (EDR).
• Fornire strumenti, processi e runbook per consentire al centro operativo SecOps di monitorare continuamente l'identificazione, il contenimento, l'eradicazione e il recupero dagli incidenti di cybersicurezza.

Funzionalità	Descrizione
Security Information & Event Management	Elastic Security è una piattaforma di security information and event management (SIEM) che raccoglie, indicizza e analizza i dati di sicurezza provenienti da una serie di fonti per aiutare le organizzazioni a rilevare e rispondere alle minacce.
Gestione delle vulnerabilità	Tenable Security Center è una piattaforma di gestione delle vulnerabilità che aiuta le organizzazioni a identificare e correggere le vulnerabilità di sicurezza.
Rilevamento e risposta degli endpoint	Elastic Security, Windows Defender e ClamAV. Piattaforme di sicurezza unificate che forniscono alle organizzazioni una visione completa della loro security posture per rilevare e rispondere alle minacce in modo più efficace.
Secure Case Management	Una soluzione software che consente alle organizzazioni di gestire il ciclo di vita degli incidenti di sicurezza.

GDC SecOps consente agli IO di fornire funzioni di operazioni di sicurezza. Il team GDC SecOps fornisce processi basati sulle persone, tra cui risposta agli incidenti, gestione delle vulnerabilità, ingegneria della sicurezza e gestione del rischio della catena di fornitura. GDC SecOps consente a un Security Operations Center (SOC) di ottenere quanto segue:

Capacità	Descrizione
Rilevamento	La nostra infrastruttura di sicurezza monitora costantemente potenziali minacce e vulnerabilità. Quando viene rilevata una minaccia o una vulnerabilità, il team delle operazioni di sicurezza riceve immediatamente un report.
Triage	Il team delle operazioni di sicurezza esamina ogni incidente per determinare la gravità della minaccia e la risposta appropriata.
Contenimento	Il team delle operazioni di sicurezza adotta misure per contenere la minaccia e impedirne la diffusione.
Indagine	Il team delle operazioni di sicurezza indaga sull'incidente per determinare la causa principale e identificare eventuali punti deboli nella nostra security posture.
Risposta	Il team delle operazioni di sicurezza adotta misure per rispondere all'incidente e mitigare eventuali danni causati.
Recupero	Il team delle operazioni di sicurezza adotta misure per rimediare all'incidente e ripristinare lo stato normale dei nostri sistemi e delle nostre reti.

Gestione delle vulnerabilità

GDC esegue più processi di identificazione delle vulnerabilità nell'ambiente di pre-produzione prima di qualsiasi release per tenere sotto controllo eventuali potenziali vulnerabilità ed esposizioni comuni (CVE). GDC fornisce anche l'analisi delle vulnerabilità nell'ambiente di produzione per scopi di monitoraggio e reporting di routine. Tutti i risultati sull'ambiente di produzione sono integrati nei processi di operazioni di sicurezza per monitorare e mitigare gli scopi di ricerca delle minacce.

Risposta agli incidenti di sicurezza

Quando vengono rilevate vulnerabilità nel codice di cui è stato eseguito il deployment in GDC o si verifica un incidente all'interno del sistema, l'IO e il team di sicurezza di GDC hanno a disposizione ed eseguono una serie di processi di risposta agli incidenti per mitigare, creare e applicare patch di sicurezza e comunicare con le parti interessate. Questa procedura di gestione degli incidenti è simile a quella standard di Google, con modifiche per la natura non connessa di GDC.

Per ogni CVE o incidente scoperto, viene assegnato un Incident Commander (IC) per eseguire il processo di risposta. L'IC è responsabile della gestione del processo, che include la verifica e la convalida dell'incidente, l'assegnazione alla vulnerabilità di un punteggio del sistema di valutazione delle vulnerabilità comuni (CVSS), la gestione del processo di creazione e preparazione di una patch per la distribuzione e la creazione delle comunicazioni appropriate.

Operazioni di affidabilità

Questa sezione fornisce una panoramica delle operazioni di affidabilità di GDC.

Logging e monitoraggio

GDC viene fornito con una piattaforma di osservabilità che fornisce funzionalità di monitoraggio, logging, tracciamento e reporting per la piattaforma, i servizi e i workload GDC.

Il sottosistema di logging importa e aggrega i log di tutte le piattaforme e i servizi GDC principali e dei workload dei clienti in un database di serie temporali e rende questi dati disponibili tramite un'interfaccia utente (UI) interattiva e le API.

Gli eventi critici dell'audit log includono le seguenti aree:

• Richieste di autenticazione e autorizzazione degli utenti.
• Generazione e revoca dei token di autenticazione.
• Tutti gli accessi amministrativi e le modifiche.
• Tutte le azioni dell'API del control plane.
• Tutti gli eventi di sicurezza, inclusi IDS, IPS, firewall e antivirus.

Accesso di emergenza

L'IO non ha accesso ai dati dei clienti. Tuttavia, in situazioni di emergenza, potrebbero esserci casi in cui l'IO ha bisogno di accedere ai dati dei clienti. In questi casi, GDC dispone di una serie di procedure di accesso di emergenza che un PA utilizza per concedere esplicitamente l'accesso all'IO per la risoluzione dei problemi.

Tutte le credenziali di deployment di emergenza sono archiviate offline in una cassaforte o criptate con chiavi con root nell'HSM. L'accesso a queste credenziali è un evento controllabile che può attivare avvisi.

Ad esempio, nel caso in cui la configurazione IAM sia stata danneggiata e impedisca l'accesso degli utenti, l'IO utilizza un'autenticazione basata su certificati SSH tramite workstation protette e richiede l'approvazione da più parti per stabilire l'accesso. Tutte le azioni intraprese vengono monitorate e sono verificabili. Le chiavi SSH cambiano dopo un incidente di accesso di emergenza.

Disaster recovery

GDC viene fornito con un sistema di backup che consente ai PA di creare e gestire policy di backup per cluster, spazi dei nomi o VM. Il sistema di backup contiene i sistemi tipici per la pianificazione, l'esecuzione dei backup, il ripristino dei dati e la generazione di report.

Esegui l'upgrade e l'aggiornamento del sistema

Poiché GDC è un ambiente con air gap, l'operatore dell'infrastruttura elabora tutti gli aggiornamenti ai sistemi dei clienti. Google firma e pubblica gli aggiornamenti dei file binari in una posizione sicura per il download da parte dell'IO. L'IO convalida i file binari e li sposta in GDC per la distribuzione e il deployment.

Questo sistema include tutti gli aggiornamenti software e firmware, inclusi gli aggiornamenti al software GDC, al sistema operativo a livello di nodo, alle definizioni e alle firme antivirus e antimalware, all'appliance di archiviazione e di rete, agli aggiornamenti dei dispositivi e a qualsiasi altro aggiornamento binario.

Gestione delle modifiche - Infrastructure as Code

GDC utilizza l'infrastructure as code (IaC) per automatizzare il provisioning e il deployment delle configurazioni GDC. L'IaC separa le responsabilità tra i team delle operazioni dell'infrastruttura. Ad esempio, proporre una modifica alla configurazione rispetto all'autorizzazione della modifica, per rendere l'intero processo più sicuro. Con GDC IAC, tutte le modifiche alla configurazione vengono convalidate tramite processi di revisione e approvazione da più parti per garantire che vengano implementate solo le configurazioni autorizzate. Queste revisioni creano un processo trasparente e controllabile, migliorano la coerenza delle modifiche e riducono la deviazione della configurazione.

Processi di conformità

GDC è conforme ai regimi comuni come NIST 800-53, SOC 2 e supporta certificazioni come FIPS 140-2 e 3. GDC viene inoltre sottoposto a vari processi di certificazione e soddisfa gli standard di sicurezza di Google. La conformità è un processo continuo. Per supportare clienti e operatori in questo percorso, GDC fornisce monitoraggio e test continui. Nell'ambito delle pratiche di sicurezza per il processo di monitoraggio continuo, GDC monitora le modifiche all'inventario, come software e hardware sconosciuti o l'aggiunta di nuovo software o hardware. GDC esegue regolarmente test di penetrazione simulando attacchi da parte di malintenzionati. GDC esegue periodicamente la scansione dei sistemi alla ricerca di malware e avvisa GDC di eventuali infezioni. Il processo di test di ripristino di emergenza verifica la capacità di GDC di riprendersi da una situazione che comporta un disastro. Questi processi garantiscono la sicurezza dei dati e dei sistemi GDC.

Conformità alla guida all'implementazione tecnica della sicurezza (STIG)

In base alla regola STIG RHEL-08-040320, il pacchetto xorg-x11-server-common è una dipendenza di sistema approvata richiesta per i driver GPU NVIDIA e le librerie di accelerazione hardware (come Vulkan e Mesa). Il servizio di gestione della visualizzazione grafica è disattivato e non attivo sulle immagini sistema operativo dei nodi.