Best practice per la sicurezza

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

Sicurezza hardware fisica

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 Distributed Cloud connected ha le seguenti funzionalità di sicurezza:

  • L'accesso all'hardware installato sul rack è possibile solo attraverso gli sportelli anteriore e posteriore del rack.
  • Il rack non può essere smontato facilmente. Non sono presenti elementi di fissaggio strutturali accessibili esternamente, come viti, dadi, chiusure o rivetti.
  • Le porte del rack sono dotate di serrature con chiave. Google ti fornisce una copia della chiave e ne conserva una copia per la custodia sicura.
  • Per le installazioni multirack, tutte le serrature del rack hanno la stessa chiave.
  • Le porte del rack sono dotate 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 suoi rinforzi e le staffe di spedizione.

Il fattore di forma del server Distributed Cloud connected 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 altre 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 Connected.

  • Certificato della piattaforma. Il certificato della piattaforma è un record crittograficamente sicuro dell'identità di produzione e del TPM. Il certificato funge da prova dell'integrità della supply chain 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 disabilitate a livello di firmware e abilitate solo per la manutenzione.

Sicurezza dello spazio di archiviazione locale

L'hardware connesso a Distributed Cloud viene fornito con i seguenti tipi di spazio di archiviazione interno a seconda del fattore di forma:

  • I rack di Distributed Cloud connected vengono spediti con unità a stato solido (SSD).
  • I server Distributed Cloud connected vengono forniti con unità Self-Encrypting Drive (SED).

Distributed Cloud Connected utilizza Linux Unified Key Setup (LUKS) per criptare i volumi logici su ogni nodo Distributed Cloud Connected. Puoi utilizzare chiavi di crittografia gestite dal cliente (CMEK) o Google-owned and managed keys per 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 e la racchiude 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 connected 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 Distributed Cloud connected 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 fin 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.

Configura il supporto per le chiavi di crittografia gestite dal cliente (CMEK) per l'archiviazione locale

Per impostazione predefinita, Google Distributed Cloud connected, versione 1.9.0 cripta i contenuti inattivi dei clienti. 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 servizi integrati con CMEK, incluso Distributed Cloud connetted. 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 Distributed Cloud Connected è 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 Connected, completa i seguenti passaggi:

  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 regione dell'installazione di Distributed Cloud connessa. Google Cloud 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 progettoGoogle Cloud . 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 connected con Cloud KMS, perdi l'accesso ai dati memorizzati sulle macchine Distributed Cloud connected.

  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 ricongiungersi al cluster mentre il cluster è in esecuzione in modalità di sopravvivenza del nodo. Se non specifichi questa finestra, i nodi riavviati non possono rientrare nel cluster finché non esce dalla modalità di sopravvivenza.

    ATTENZIONE: se specifichi una finestra di timeout per il riavvio, i nodi che sono andati offline possono riavviarsi e ricongiungersi al cluster anche se disattivi o elimini la chiave di archiviazione per il periodo di tempo specificato.

Per ripristinare l'utilizzo di un Google-owned and Google-managed encryption keyper un cluster o un pool di nodi, utilizza il flag --use-google-managed-key come descritto in uno dei seguenti modi:

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

Recupero dei dati e backup

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 all'integratore di sistemi (SI) certificato da Google che ti ha venduto l'hardware.

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

Se hai acquistato l'hardware 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à tutto il software Google e i tuoi dati dall'hardware Distributed Cloud durante il ritiro.

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 di rete della tua organizzazione dettano i passaggi necessari per proteggere il traffico di rete in entrata e in uscita dall'installazione connessa di Distributed Cloud. Inoltre, ti consigliamo quanto segue:

  • Consenti solo le connessioni in entrata ai pool di indirizzi IP virtuali esposti dal bilanciatore del carico integrato di Distributed Cloud connesso 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ù, consulta la sezione Modalità di sopravvivenza.

Per saperne di più su come preparare la rete locale per la connessione dell'hardware Distributed Cloud, consulta Networking.

Per le implementazioni multirack, Distributed Cloud connesso supporta la sicurezza Media Access Control (MAC) di livello 2 (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 Distributed Cloud connected. Non può essere abilitato dopo il deployment di Distributed Cloud Connected nei tuoi locali.

Distributed Cloud connected 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 delle 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 ricevimento di ogni frame.

Ogni dispositivo configurato per MACsec deve essere autenticato e associato a un'associazione di connettività (CA). I membri della CA utilizzano chiavi CA (CAK) a lunga durata 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.

Norme MACsec di Distributed Cloud connected

Distributed Cloud connected applica i seguenti criteri MACsec a tutti i collegamenti Ethernet tra gli switch di aggregazione del rack di base e gli switch ToR del rack autonomo. Questi criteri non possono essere modificati o disattivati.

Configurazione MACsec

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

Distributed Cloud connesso non consente pacchetti non criptati su tutti i collegamenti Ethernet interni. Se una sessione MACsec non può essere negoziata correttamente, il link Ethernet interessato viene interrotto automaticamente.

Portachiavi MACsec

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

Fallback MACsec

Distributed Cloud connected configura una chiave di fallback MACsec oltre a quattro chiavi principali per ogni collegamento Ethernet interno. Se Distributed Cloud Connected non riesce a negoziare una sessione MACsec utilizzando le chiavi primarie, tenta di negoziare una sessione di riserva utilizzando la chiave di riserva. La chiave di riserva non scade.

Rotazione della chiave MACsec

Gli aggregatori e gli switch ToR connessi a Distributed Cloud ruotano immediatamente le chiavi MACsec principali quando scadono. 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 connected 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 riassegnazione delle chiavi in base al volume utilizzando la numerazione estesa dei pacchetti (XPN). La SAK viene rigenerata ogni 6 ore.

Utilizza il seguente comando per controllare lo stato di MACsec di un collegamento 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 regione Google Cloud in cui è stato creato il progettoGoogle Cloud di destinazione.
  • ZONE_NAME: il nome della zona Distributed Cloud connessa di destinazione.

Il comando restituisce un output simile al seguente:

result:
  macsecStatusInternalLinks: SECURE

I possibili valori di stato del collegamento sono:

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

Passaggi successivi