Best practice per la sicurezza

Questa pagina descrive le best practice per proteggere l'installazione di Google Distributed Cloud.

Sicurezza dell'hardware fisico

Sei responsabile della sicurezza fisica dell'hardware connesso a Distributed Cloud, ad esempio limitando l'accesso al personale autorizzato.

Il fattore di forma del rack connesso a Distributed Cloud ha le seguenti funzionalità di sicurezza:

  • L'accesso all'hardware installato sul rack è possibile solo tramite gli sportelli anteriori e posteriori del rack.
  • Il rack non può essere smontato facilmente. Non sono presenti elementi di fissaggio strutturali accessibili esternamente, come viti, dadi, chiusure o rivetti.
  • Gli sportelli del rack sono dotati di serrature a chiave. Google ti fornisce una copia della chiave e ne conserva una per la custodia sicura.
  • Per le installazioni multi-rack, tutte le serrature dei rack sono identiche.
  • Gli sportelli del rack sono dotati di una rete metallica antimanomissione perforata per la ventilazione.
  • Durante l'installazione, il rack viene fissato saldamente al pavimento del sito di installazione utilizzando i rinforzi e le staffe di spedizione.

Il fattore di forma del server connesso a Distributed Cloud ha le seguenti funzionalità di sicurezza:

  • Un sensore di intrusione. Se una parte non autorizzata apre fisicamente la macchina, tu e Google ricevete immediatamente una notifica dell'intrusione fisica.

Se hai ulteriori domande sulla sicurezza del rack fisico, contatta il tuo Google Cloud rappresentante di vendita.

Sicurezza della piattaforma

La piattaforma hardware connessa a Distributed Cloud ha le seguenti funzionalità di sicurezza:

  • Trusted Platform Module (TPM). Il TPM è la radice di attendibilità che genera e archivia le chiavi di crittografia per tutti i dati archiviati, ricevuti e trasmessi da Distributed Cloud connesso.

  • Certificato della piattaforma. Il certificato della piattaforma è un record crittograficamente sicuro dell'identità di produzione e TPM. Il certificato funge da prova dell'integrità della catena di fornitura per l'hardware connesso a Distributed Cloud.

  • Blocco delle porte. Tutte le porte esterne e interne diverse dalle porte Ethernet, come le porte USB e RS-232 della console, sono disattivate a livello di firmware e attivate solo per la manutenzione.

Sicurezza dello spazio di archiviazione locale

L'hardware connesso a Distributed Cloud viene fornito con unità disco auto-criptanti (SED). I rack connessi a Distributed Cloud spediti prima di ottobre 2023 sono stati forniti con unità disco a stato solido (SSD).

Distributed Cloud connesso utilizza Linux Unified Key Setup (LUKS) per criptare i volumi logici su ogni nodo connesso a Distributed Cloud. Puoi utilizzare le chiavi di crittografia gestite dal cliente (CMEK) o Google-owned and managed keys eseguire il wrapping della chiave di crittografia del disco LUKS (DEK). Quando assegni un nodo a un pool di nodi, il nodo genera una DEK LUKS ed esegue il wrapping in una passphrase LUKS gestita da Google, nota anche come chiave di crittografia della chiave (KEK), o in una fornita da te tramite Cloud KMS. Puoi scegliere se utilizzare Cloud KMS durante la creazione di un pool di nodi. Distributed Cloud connesso si integra con Cloud KMS utilizzando il modello di crittografia envelope.

Distributed Cloud connesso ruota automaticamente le passphrase LUKS e SED in base a una pianificazione regolare.

Inoltre, ogni macchina connessa a Distributed Cloud esegue le seguenti operazioni a ogni avvio a freddo:

  • Se non utilizzi Cloud KMS, la macchina genera una nuova KEK (passphrase LUKS) e configura lo spazio di archiviazione criptato dall'inizio.

  • Se utilizzi Cloud KMS, la macchina recupera la KEK da Cloud KMS e sblocca i volumi logici esistenti che contengono i tuoi dati.

Configurare il supporto per le chiavi di crittografia gestite dal cliente (CMEK) per lo spazio di archiviazione locale

Per impostazione predefinita, Google Distributed Cloud connesso, versione 1.11.0, cripta i contenuti inattivi dei clienti at rest. Distributed Cloud connesso gestisce la crittografia per conto tuo senza che tu debba fare altro. Questa opzione è denominata crittografia predefinita di Google.

Se vuoi controllare le tue chiavi di crittografia, puoi utilizzare le chiavi di crittografia gestite dal cliente (CMEK) in Cloud KMS con i servizi integrati con CMEK, incluso Distributed Cloud connesso. L'utilizzo delle chiavi Cloud KMS ti consente di controllare il livello di protezione , la località, la pianificazione della rotazione, le autorizzazioni di utilizzo e di accesso e i limiti crittografici. Con Cloud KMS puoi inoltre visualizzare gli audit log e controllare i cicli di vita delle chiavi. Invece di Google, sei tu ad avere la proprietà e la gestione delle chiavi di crittografia della chiave (KEK) simmetriche che proteggono i tuoi dati. Puoi controllare e gestire queste chiavi in Cloud KMS.

Dopo aver configurato le risorse con le CMEK, l'esperienza di accesso alle risorse connesse a Distributed Cloud è simile all'utilizzo della crittografia predefinita di Google. Per saperne di più sulle opzioni di crittografia, vedi Chiavi di crittografia gestite dal cliente (CMEK).

Per abilitare l'integrazione di Cloud KMS con Distributed Cloud connesso:

  1. Crea un keyring, una chiave simmetrica e una o più versioni della chiave da utilizzare con Distributed Cloud connesso. Devi creare questi artefatti nella stessa Google Cloud regione dell'installazione di Distributed Cloud connesso. Per le istruzioni, vedi Creare una chiave.

  2. Concedi il ruolo Autore crittografia/decrittografia CryptoKey Cloud KMS (roles/cloudkms.cryptoKeyEncrypterDecrypter) al service account connesso a Distributed Cloud nel tuo Google Cloud progetto. Devi eseguire questa operazione per ogni versione della chiave che vuoi utilizzare con Distributed Cloud connesso. Se revochi questo ruolo dopo aver integrato l'installazione di Distributed Cloud connesso con Cloud KMS, perdi l'accesso ai dati archiviati sulle macchine connesse a Distributed Cloud.

  3. Crea un node pool utilizzando il flag --local-disk-kms-key e fornisci il percorso completo della versione della chiave che vuoi utilizzare con quel pool di nodi.

  4. Crea un cluster utilizzando il flag --control-plane-kms-key e fornisci il percorso completo della versione della chiave che vuoi utilizzare con il nodo che esegue il control plane del cluster.

  5. (Facoltativo) Utilizza il flag --offline-reboot-ttl durante la creazione del cluster per specificare un intervallo di tempo durante il quale i nodi riavviati possono rientrare nel cluster mentre il cluster è in esecuzione in modalità di sopravvivenza. Se non specifichi questa finestra, i nodi riavviati non possono rientrare nel cluster finché non esce dalla modalità di sopravvivenza.

    ATTENZIONE: se specifichi un intervallo di timeout per il riavvio, i nodi che sono andati offline possono essere riavviati e rientrare nel cluster anche se disabiliti o elimini la chiave di archiviazione per il periodo di tempo specificato.

Per ripristinare un cluster o un pool di nodi in modo che utilizzi una chiave gestita da Google Google-owned and Google-managed encryption key, utilizza il flag --use-google-managed-key come descritto in una delle seguenti sezioni:

Per saperne di più, consulta Chiavi di crittografia gestite dal cliente (CMEK) nella documentazione di Cloud KMS.

Recupero e backup dei dati

Sei responsabile della manutenzione di backup ridondanti funzionanti di tutti i dati che scegli di archiviare sull'hardware connesso a Distributed Cloud e dell'esportazione di questi dati quando scegli di restituire l'hardware connesso a Distributed Cloud a Google o al System Integrator (SI) certificato da Google che ti ha venduto l'hardware.

Se si verifica un guasto dell'hardware connesso a Distributed Cloud e Google o un SI certificato da Google esegue riparazioni in loco, tutti i supporti di archiviazione vengono rimossi dalla macchina connessa a Distributed Cloud in manutenzione e vengono consegnati a te per la durata della riparazione o vengono cancellati in modo sicuro e poi inviati per la distruzione.

Se hai acquistato l'hardware di Distributed Cloud da un SI certificato da Google e non utilizzi più Distributed Cloud, ma hai scelto di conservare e riutilizzare l'hardware, il SI cancellerà tutti i software Google e i tuoi dati dall'hardware di Distributed Cloud durante il deprovisioning.

Sicurezza della rete

Il traffico di rete tra l'hardware connesso a Distributed Cloud e Google Cloud viene criptato utilizzando tunnel MASQUE o TLS che utilizzano certificati per macchina. Distributed Cloud connesso ruota automaticamente questi certificati in base a una pianificazione regolare.

I requisiti aziendali e le norme di sicurezza della rete della tua organizzazione determinano i passaggi necessari per proteggere il traffico di rete in entrata e in uscita dall'installazione di Distributed Cloud connesso. Inoltre, ti consigliamo di:

  • Consentire solo le connessioni in entrata ai pool di indirizzi IP virtuali esposti dal bilanciatore del carico integrato connesso a Distributed Cloud e alle subnet di Distributed Cloud.

  • Non consentire le connessioni in entrata dalle risorse di rete esterne alle subnet che gestiscono i livelli di gestione del sistema e gestione dei servizi.

  • Non consentire le connessioni in entrata dalle risorse di rete esterne agli indirizzi IP degli endpoint del control plane locale. Per saperne di più, vedi Modalità di sopravvivenza.

Per saperne di più su come preparare la rete locale per la connessione all'hardware di Distributed Cloud, vedi Rete.

Per i deployment multi-rack, Distributed Cloud connesso supporta la sicurezza del livello 2 Media Access Control (MAC) (L2 MACsec) a livello di frame Ethernet tra gli switch di aggregazione nel rack di base e gli switch ToR nei rack autonomi.

Devi richiedere questa funzionalità quando ordini l'hardware connesso a Distributed Cloud. Non può essere abilitata dopo che Distributed Cloud connesso è stato sottoposto a deployment on-premise.

Distributed Cloud connesso utilizza MACsec per autenticare i dispositivi Ethernet, verificare l'integrità di ogni frame Ethernet trasmesso e criptare ogni frame trasmesso.

Ciò comporta la creazione di un insieme di chiavi che vengono verificate tra tutti i dispositivi coinvolti in una sessione di trasporto Ethernet prima che il traffico Ethernet possa fluire. Una volta verificato l'accordo sulle chiavi, il mittente inizia a taggare ogni frame Ethernet trasmesso con tag di sicurezza e valori di controllo dell'integrità che il destinatario verifica al momento della ricezione di ogni frame.

Ogni dispositivo configurato con MACsec deve essere autenticato e associato a un'associazione di connettività (CA). I membri della CA utilizzano chiavi CA a lunga durata (CAK) per identificarsi sulla rete. La CAK viene utilizzata per generare chiavi di crittografia della sessione ogni volta che un membro della CA deve scambiare dati con un altro membro della CA sulla rete.

Policy MACsec connesse a Distributed Cloud

Distributed Cloud connesso applica le seguenti policy MACsec a tutti i link Ethernet tra gli switch di aggregazione del rack di base e gli switch ToR del rack autonomo. Queste policy non possono essere modificate o disattivate.

Configurazione MACsec

Tutta la configurazione MACsec connessa a Distributed Cloud, incluse le chiavi di crittografia, è gestita da Google.

Distributed Cloud connesso non consente pacchetti non criptati su tutti i link Ethernet interni. Se non è possibile negoziare correttamente una sessione MACsec, il link Ethernet interessato viene disattivato automaticamente.

Keychain MACsec

Un keychain MACsec è l'archivio di chiavi che contiene tutte le chiavi richieste per un link Ethernet specifico. Viene creato un keychain univoco per un'interfaccia bundle. Ogni keychain contiene 4 chiavi primarie più una chiave di fallback. Ogni chiave primaria ha una validità del 25%.

Fallback MACsec

Distributed Cloud connesso configura una chiave di fallback MACsec oltre a 4 chiavi primarie per ogni link Ethernet interno. Se Distributed Cloud connesso non riesce a negoziare una sessione MACsec utilizzando le chiavi primarie, tenta di negoziare una sessione di fallback utilizzando la chiave di fallback. La chiave di fallback non scade.

Rotazione della chiave MACsec

Gli switch di aggregazione e ToR connessi a Distributed Cloud ruotano immediatamente le chiavi MACsec primarie alla scadenza. Per garantire una rotazione sicura delle chiavi, ogni chiave precedente e successiva nella rotazione ha una sovrapposizione di durata di 5 giorni.

Chiave di associazione sicura MACsec

Distributed Cloud connesso utilizza una chiave di associazione sicura (SAK) MACsec generata in modo casuale per criptare tutti i frame Ethernet trasportati dai link Ethernet interni. Distributed Cloud connesso esegue la nuova chiave basata sul volume utilizzando la numerazione estesa dei pacchetti (XPN). La SAK viene rigenerata ogni 6 ore.

Utilizza il seguente comando per controllare lo stato MACsec di un link Ethernet specifico tra uno switch di aggregazione del rack di base e uno switch ToR in un rack autonomo:

gcloud edge-cloud networking networks get-status default --location=REGION --zone=us-ZONE_NAME

Sostituisci quanto segue:

  • REGION: la Google Cloud regione in cui è stato creato il progetto di destinazione Google Cloud .
  • ZONE_NAME: il nome della zona connessa a Distributed Cloud di destinazione.

Il comando restituisce un output simile al seguente:

result:
  macsecStatusInternalLinks: SECURE

I possibili valori di stato del link sono:

  • SECURE : la sessione MACsec è attiva sul link di destinazione.
  • UNSECURE - la sessione MACsec non è attiva sul link di destinazione.

Passaggi successivi