Importa dati da Google Cloud in un data warehouse BigQuery protetto

Last reviewed 2021-12-16 UTC

Molte organizzazioni eseguono il deployment di data warehouse che archiviano informazioni riservate in modo da poter analizzare i dati per vari scopi aziendali. Questo documento è rivolto ai data engineer e agli amministratori della sicurezza che eseguono il deployment e proteggono i data warehouse utilizzando BigQuery. Fa parte di un progetto di sicurezza composto da quanto segue:

  • Un repository GitHub contiene un set di configurazioni e script Terraform. La configurazione Terraform imposta un ambiente in Google Cloud che supporta un data warehouse per l'archiviazione di dati riservati.

  • Una guida all'architettura, alla progettazione e ai controlli di sicurezza utilizzati da questo progetto per l'implementazione (questo documento).

  • Una procedura dettagliata che esegue il deployment di un ambiente di esempio.

In questo documento vengono trattati i seguenti argomenti:

  • L'architettura e i servizi Google Cloud che puoi utilizzare per proteggere un data warehouse in un ambiente di produzione.

  • Best practice per la governance dei dati durante la creazione, il deployment e il funzionamento di un data warehouse in Google Cloud, tra cui l'anonimizzazione dei dati, la gestione differenziale dei dati riservati e i controlli dell'accesso a livello di colonna.

Questo documento presuppone che tu abbia già configurato un set di base di controlli di sicurezza, come descritto nel progetto di base aziendale di Google Cloud. Consente di integrare ulteriori controlli sui controlli di sicurezza esistenti per proteggere i dati riservati in un data warehouse.

Casi d'uso di data warehouse

Il progetto supporta i seguenti casi d'uso:

Panoramica

I data warehouse come BigQuery consentono alle aziende di analizzare i dati per ottenere insight. Gli analisti accedono ai dati aziendali archiviati nei data warehouse per creare insight. Se il tuo data warehouse include dati riservati, devi adottare misure per preservare la sicurezza, la riservatezza, l'integrità e la disponibilità dei dati aziendali mentre sono archiviati, mentre sono in transito o durante l'analisi. In questo progetto devi:

  • Configura i controlli che contribuiscono a proteggere l'accesso ai dati riservati.
  • Configura i controlli che contribuiscono a proteggere la pipeline di dati.
  • Configura una separazione appropriata dei compiti per diversi utenti tipo.
  • Configura i modelli per trovare e anonimizzare i dati riservati.
  • Configura controlli di sicurezza e logging adeguati per proteggere i dati riservati.
  • Usa la classificazione dei dati e i tag di criteri per limitare l'accesso a colonne specifiche nel data warehouse.

Architettura

Per creare un data warehouse riservato, devi classificare i dati come riservati e non riservati e quindi archiviare i dati in perimetri separati. L'immagine seguente mostra come vengono classificati, anonimizzati e archiviati i dati importati. Mostra inoltre come reidentificare i dati riservati on demand per l'analisi.

L'architettura di un data warehouse riservato.

L'architettura utilizza una combinazione dei seguenti servizi e funzionalità di Google Cloud:

  • Identity and Access Management (IAM) e Resource Manager limitano l'accesso e la segmentazione delle risorse. I controlli dell'accesso e la gerarchia delle risorse seguono il principio del privilegio minimo.

  • Controlli di servizio VPC crea perimetri di sicurezza che isolano servizi e risorse configurando autorizzazioni, controlli dell'accesso e scambio sicuro di dati. I perimetri sono i seguenti:

    • Un perimetro di importazione dati che accetta i dati in entrata (in batch o in flusso) e li anonimizza. Una zona di destinazione separata aiuta a proteggere il resto dei carichi di lavoro dai dati in entrata.

    • Un perimetro di dati riservati in grado di re-identificare i dati riservati e di archiviarli in un'area ad accesso limitato.

    • Un perimetro di governance che archivia le chiavi di crittografia e definisce i dati riservati.

    Questi perimetri sono progettati per proteggere i contenuti in entrata, isolare i dati riservati configurando ulteriori controlli e monitoraggio dell'accesso e separare la governance dai dati effettivi nel data warehouse. La governance include la gestione delle chiavi, la gestione del catalogo dati e il logging.

  • Cloud Storage e Pub/Sub ricevono i dati come segue:

    • Cloud Storage: riceve e archivia i dati in batch prima dell'anonimizzazione. Cloud Storage usa TLS per criptare i dati in transito e cripta i dati nello spazio di archiviazione per impostazione predefinita. La chiave di crittografia è una chiave di crittografia gestita dal cliente (CMEK). Puoi proteggere l'accesso ai bucket Cloud Storage utilizzando controlli di sicurezza come Identity and Access Management, elenchi di controllo dell'accesso (ACL) e documenti relativi ai criteri. Per ulteriori informazioni sui controlli dell'accesso supportati, consulta Panoramica del controllo dell'accesso.

    • Pub/Sub: riceve e archivia i flussi di dati prima dell'anonimizzazione. Pub/Sub utilizza autenticazione, controlli dell'accesso e crittografia a livello di messaggio con una CMEK per proteggere i tuoi dati.

  • Due pipeline Dataflow anonimizzano e reidentificano i dati riservati nel modo seguente:

    • La prima pipeline anonimizza i dati riservati mediante la assegnazione di pseudonimi.
    • La seconda pipeline reidentifica i dati riservati quando gli utenti autorizzati richiedono l'accesso.

    Per proteggere i dati, Dataflow utilizza un account di servizio univoco e una chiave di crittografia per ogni pipeline, oltre ai controlli dell'accesso. Per contribuire a proteggere l'esecuzione della pipeline spostandola nel servizio di backend, Dataflow utilizza Streaming Engine. Per ulteriori informazioni, consulta Sicurezza e autorizzazioni di Dataflow.

  • Sensitive Data Protection anonimizza i dati riservati durante l'importazione.

    Sensitive Data Protection anonimizza i dati strutturati e non strutturati in base agli infoType o ai record rilevati.

  • Cloud HSM ospita la chiave di crittografia della chiave (KEK). Cloud HSM è un servizio per modulo di sicurezza hardware (HSM) basato su cloud.

  • Data Catalog classifica automaticamente i dati riservati con metadati, noti anche come tag di criterio, durante l'importazione. Data Catalog utilizza anche i metadati per gestire l'accesso ai dati riservati. Per ulteriori informazioni, consulta la panoramica di Data Catalog. Per controllare l'accesso ai dati all'interno del data warehouse, puoi applicare tag di criteri alle colonne che includono dati riservati.

  • BigQuery archivia i dati riservati nel perimetro dei dati riservati.

    BigQuery utilizza vari controlli di sicurezza per proteggere i contenuti, tra cui controlli dell'accesso, sicurezza a livello di colonna per i dati riservati e crittografia dei dati.

  • Security Command Center monitora e esamina i risultati sulla sicurezza in tutto l'ambiente Google Cloud da una posizione centrale.

Struttura organizzativa

Puoi raggruppare le risorse dell'organizzazione in modo da poterle gestire e separare gli ambienti di test dall'ambiente di produzione. Resource Manager ti consente di raggruppare le risorse in base a progetto, cartella e organizzazione.

Il seguente diagramma mostra una gerarchia di risorse con cartelle che rappresentano diversi ambienti, come bootstrap, comune, di produzione, non di produzione (o gestione temporanea) e sviluppo. Esegui il deployment della maggior parte dei progetti del progetto nella cartella di produzione e del progetto di governance dei dati nella cartella comune utilizzata per la governance.

Gerarchia delle risorse per un data warehouse riservato.

Cartelle

Puoi utilizzare le cartelle per isolare l'ambiente di produzione e i servizi di governance dagli ambienti di test e non di produzione. La seguente tabella descrive le cartelle del progetto delle basi aziendali utilizzate da questo progetto.

Cartella Descrizione
Produzione Contiene progetti con risorse cloud che sono state testate e sono pronte per l'uso.
Nome Contiene servizi centralizzati per l'organizzazione, ad esempio il progetto di governance.

Puoi modificare i nomi di queste cartelle per allinearli alla struttura delle cartelle della tua organizzazione, ma ti consigliamo di mantenere una struttura simile. Per saperne di più, consulta il progetto delle basi aziendali di Google Cloud.

Progetti

Puoi isolare le parti dell'ambiente utilizzando i progetti. La seguente tabella descrive i progetti necessari all'interno dell'organizzazione. Questi progetti vengono creati quando esegui il codice Terraform. Puoi modificare i nomi di questi progetti, ma ti consigliamo di mantenere una struttura dei progetti simile.

Progetto Descrizione
Importazione dati Contiene i servizi necessari per ricevere dati e anonimizzare i dati riservati.
Governance Contiene servizi che forniscono funzionalità di gestione delle chiavi, logging e catalogazione dei dati.
Dati non riservati Contiene i servizi necessari per archiviare i dati anonimizzati.
Dati riservati Contiene i servizi necessari per archiviare e reidentificare i dati riservati.

Oltre a questi progetti, l'ambiente deve includere anche un progetto che ospita un job di modello flessibile di Dataflow. Il job del modello flessibile è richiesto per la pipeline di dati in modalità flusso.

Mappatura di ruoli e gruppi ai progetti

Devi concedere a gruppi di utenti diversi dell'organizzazione l'accesso ai progetti che compongono il data warehouse riservato. Le seguenti sezioni descrivono i suggerimenti relativi ai progetti per i gruppi di utenti e le assegnazioni dei ruoli nei progetti creati. Puoi personalizzare i gruppi in modo che corrispondano alla struttura esistente della tua organizzazione, ma ti consigliamo di mantenere una separazione simile dei compiti e dell'assegnazione dei ruoli.

Gruppo di analisti di dati

Gli analisti di dati analizzano i dati nel data warehouse. Questo gruppo richiede ruoli in progetti diversi, come descritto nella tabella seguente.

Mappatura di progetti Ruoli
Importazione dati

Ruolo aggiuntivo per gli analisti di dati che richiedono l'accesso a dati riservati:

Dati riservati
  • roles/bigquery.dataViewer
  • roles/bigquery.jobUser
  • roles/bigquery.user
  • roles/dataflow.viewer
  • roles/dataflow.developer
  • roles/logging.viewer
Dati non riservati
  • roles/bigquery.dataViewer
  • roles/bigquery.jobUser
  • roles/bigquery.user
  • roles/logging.viewer

Gruppo di data engineer

I data engineer configurano e gestiscono pipeline di dati e data warehouse. Questo gruppo richiede ruoli in progetti diversi, come descritto nella tabella seguente.

Mappatura di progetti Ruoli
Importazione dati
Dati riservati
  • roles/bigquery.dataEditor
  • roles/bigquery.jobUser
  • roles/cloudbuild.builds.editor
  • roles/cloudkms.viewer
  • roles/compute.networkUser
  • roles/dataflow.admin
  • roles/logging.viewer
Dati non riservati
  • roles/bigquery.dataEditor
  • roles/bigquery.jobUser
  • roles/cloudkms.viewer
  • roles/logging.viewer

Gruppo di amministratori di rete

Gli amministratori di rete configurano la rete. In genere, sono membri del team di networking.

Gli amministratori di rete richiedono i seguenti ruoli a livello di organizzazione:

Gruppo di amministratori della sicurezza

Gli amministratori della sicurezza gestiscono i controlli di sicurezza, ad esempio accesso, chiavi, regole firewall, Controlli di servizio VPC e Security Command Center.

Gli amministratori della sicurezza richiedono i seguenti ruoli a livello di organizzazione:

Gruppo di analisti della sicurezza

Gli analisti della sicurezza monitorano e rispondono agli incidenti di sicurezza e ai risultati del Sensitive Data Protection.

Gli analisti della sicurezza richiedono i seguenti ruoli a livello di organizzazione:

Comprensione dei controlli di sicurezza necessari

Questa sezione illustra i controlli di sicurezza all'interno di Google Cloud che utilizzi per proteggere il tuo data warehouse. I principi di sicurezza chiave da considerare sono i seguenti:

  • Proteggi l'accesso adottando i principi del privilegio minimo.

  • Proteggi le connessioni di rete mediante la progettazione e le norme di segmentazione.

  • Proteggi la configurazione di ogni servizio.

  • Classificare e proteggere i dati in base al loro livello di rischio.

  • Comprendere i requisiti di sicurezza per l'ambiente che ospita il data warehouse.

  • Configura un monitoraggio e un logging sufficienti per rilevamento, indagine e risposta.

Controlli di sicurezza per l'importazione dati

Per creare il tuo data warehouse, devi trasferire i dati da un'altra origine Google Cloud, ad esempio un data lake. Puoi utilizzare una delle seguenti opzioni per trasferire i dati nel data warehouse su BigQuery:

  • Un job batch che utilizza Cloud Storage.

  • un job di flussi di dati che utilizza Pub/Sub. Per proteggere i dati durante l'importazione, puoi utilizzare le regole del firewall, i criteri di accesso e la crittografia.

Regole firewall e di rete

Le regole firewall Virtual Private Cloud (VPC) controllano il flusso di dati nei perimetri. Puoi creare regole firewall che negano tutto il traffico in uscita, ad eccezione delle connessioni TCP sulla porta 443 specifiche dai nomi di dominio speciali restricted.googleapis.com. Il dominio restricted.googleapis.com offre i seguenti vantaggi:

  • Aiuta a ridurre la superficie di attacco della rete utilizzando l'accesso privato Google quando i carichi di lavoro comunicano con le API e i servizi Google.
  • Garantisce di utilizzare solo i servizi che supportano i Controlli di servizio VPC.

Per ulteriori informazioni, leggi come configurare l'accesso privato Google.

Devi configurare subnet separate per ogni job Dataflow. Le subnet separate assicurano che i dati anonimizzati siano correttamente separati dai dati che vengono nuovamente identificati.

La pipeline di dati richiede di aprire le porte TCP nel firewall, come definito nel file dataflow_firewall.tf nel repository del modulo dwh-networking. Per ulteriori informazioni, consulta Configurare l'accesso a internet e le regole firewall.

Per impedire alle risorse di utilizzare indirizzi IP esterni, il criterio dell'organizzazione compute.vmExternalIpAccess è impostato in modo da rifiutare tutto.

Controlli del perimetro

Come mostrato nel diagramma dell'architettura, le risorse per il data warehouse riservato vengono posizionate in perimetri separati. Per consentire ai servizi in perimetri diversi di condividere dati, puoi creare bridge perimetri. I bridge perimetri consentono ai servizi protetti di effettuare richieste di risorse al di fuori del loro perimetro. Questi bridge creano le seguenti connessioni:

  • Collegano il progetto di importazione dati al progetto di governance in modo che l'anonimizzazione possa avvenire durante l'importazione.

  • Collegano il progetto relativo ai dati non riservati e il progetto relativo ai dati riservati in modo che i dati riservati possano essere identificati nuovamente quando un analista di dati li richiede.

  • Collegano il progetto riservato al progetto di governance dei dati in modo che la reidentificazione possa avvenire su richiesta di un analista di dati.

Oltre ai bridge del perimetro, puoi utilizzare le regole in uscita per consentire alle risorse protette dai perimetri di servizio di accedere alle risorse che si trovano all'esterno del perimetro. In questa soluzione, configurerai le regole in uscita per ottenere i job esterni al modello flessibile di Dataflow che si trovano in Cloud Storage in un progetto esterno. Per maggiori informazioni, consulta Accedere a una risorsa Google Cloud all'esterno del perimetro.

Criterio di accesso

Per garantire che solo identità specifiche (utente o servizio) possano accedere a risorse e dati, abilita i gruppi e i ruoli IAM.

Per assicurarti che solo origini specifiche possano accedere ai progetti, attiva un criterio di accesso per la tua organizzazione Google. Ti consigliamo di creare un criterio di accesso che specifichi l'intervallo di indirizzi IP consentito per le richieste e consenta solo quelle provenienti da utenti o account di servizio specifici. Per maggiori informazioni, vedi Attributi del livello di accesso.

Gestione delle chiavi e crittografia per l'importazione

Entrambe le opzioni di importazione utilizzano Cloud HSM per gestire CMEK. Puoi usare le chiavi CMEK per proteggere i tuoi dati durante l'importazione. Sensitive Data Protection protegge ulteriormente i tuoi dati criptando i dati riservati tramite i rilevatori che configuri.

Per importare i dati, utilizzi le seguenti chiavi di crittografia:

  • Una chiave CMEK per il processo di importazione utilizzata anche dalla pipeline Dataflow e dal servizio Pub/Sub. Il processo di importazione è a volte indicato come processo ETL (Extract, Transform, Load).

  • La chiave di crittografia sottoposta a wrapping da Cloud HSM per il processo di anonimizzazione dei dati mediante Sensitive Data Protection.

  • Due chiavi CMEK: una per il warehouse BigQuery nel progetto relativo ai dati non riservati e l'altra per il warehouse nel progetto relativo ai dati riservati. Per ulteriori informazioni, consulta Gestione delle chiavi.

Tu specifichi la località CMEK, che determina la posizione geografica in cui è archiviata la chiave e viene resa disponibile per l'accesso. Devi assicurarti che la CMEK si trovi nella stessa località delle risorse. Per impostazione predefinita, CMEK viene ruotata ogni 30 giorni.

Se gli obblighi di conformità della tua organizzazione richiedono di gestire le tue chiavi esternamente da Google Cloud, puoi abilitare Cloud External Key Manager. Se utilizzi chiavi esterne, sei responsabile delle attività di gestione delle chiavi, inclusa rotazione della chiave.

Account di servizio e controlli dell'accesso

Gli account di servizio sono identità che Google Cloud può utilizzare per eseguire richieste API per tuo conto. Gli account di servizio assicurano che le identità degli utenti non abbiano accesso diretto ai servizi. Per consentire la separazione dei compiti, crea account di servizio con ruoli diversi per scopi specifici. Questi account di servizio sono definiti nel modulo data-ingestion e nel modulo confidential-data. Gli account di servizio sono i seguenti:

  • Un account di servizio del controller Dataflow per la pipeline Dataflow che anonimizza i dati riservati.

  • Un account di servizio del controller Dataflow per la pipeline Dataflow che reidentifica i dati riservati.

  • Un account di servizio Cloud Storage per importare i dati da un file batch.

  • Un account di servizio Pub/Sub per importare i dati da un servizio in modalità flusso.

  • Un account di servizio Cloud Scheduler per eseguire il job batch Dataflow che crea la pipeline Dataflow.

Nella tabella seguente sono elencati i ruoli assegnati a ciascun account di servizio:

Account di servizio Nome Progetto Ruoli

Controller Dataflow

Questo account viene utilizzato per l'anonimizzazione.

sa-dataflow-controller Importazione dati

Controller Dataflow

Questo account viene utilizzato per la reidentificazione.

sa-dataflow-controller-reid Dati riservati
Cloud Storage sa-storage-writer Importazione dati
  • roles/storage.objectViewer
  • roles/storage.objectCreator
Per le descrizioni di questi ruoli, vedi Ruoli IAM per Cloud Storage.
Pub/Sub sa-pubsub-writer Importazione dati
  • roles/pubsub.publisher
  • roles/pubsub.subscriber
Per le descrizioni di questi ruoli, consulta Ruoli IAM per Pub/Sub.
Cloud Scheduler sa-scheduler-controller Importazione dati
  • roles/compute.viewer
  • roles/dataflow.developer

Anonimizzazione dei dati

Puoi utilizzare Sensitive Data Protection per anonimizzare i tuoi dati strutturati e non strutturati durante la fase di importazione. Per i dati strutturati, registri le trasformazioni in base ai campi per anonimizzare i dati. Per un esempio di questo approccio, vedi la cartella /examples/de_identification_template/. Questo esempio controlla i dati strutturati per verificare la presenza di eventuali numeri di carte di credito e PIN di carte. Per i dati non strutturati, vengono utilizzati tipi di informazioni per anonimizzare i dati.

Per anonimizzare i dati contrassegnati come riservati, puoi utilizzare la protezione dei dati sensibili e una pipeline Dataflow per tokenizzarli. Questa pipeline prende i dati da Cloud Storage, li elabora e li invia al data warehouse BigQuery.

Per ulteriori informazioni sul processo di anonimizzazione dei dati, consulta la pagina relativa alla governance dei dati.

Controlli di sicurezza per l'archiviazione dei dati

Puoi configurare i seguenti controlli di sicurezza per proteggere i dati nel warehouse BigQuery:

  • Controlli di accesso a livello di colonna

  • Account di servizio con ruoli limitati

  • Criteri dell'organizzazione

  • Perimetri Controlli di servizio VPC tra il progetto riservato e il progetto non riservato, con bridge perimetri appropriati

  • Crittografia e gestione delle chiavi

Controlli di accesso a livello di colonna

Per proteggere i dati riservati, puoi utilizzare i controlli di accesso per colonne specifiche nel warehouse BigQuery. Per accedere ai dati in queste colonne, un analista di dati deve disporre del ruolo Lettore granulare.

Per definire l'accesso per le colonne in BigQuery, devi creare tag di criteri. Ad esempio, il file taxonomy.tf nel modulo bigquery-confidential-data di esempio crea i seguenti tag:

  • Un tag di criteri 3_Confidential per le colonne che includono informazioni molto sensibili, come numeri di carte di credito. Gli utenti che hanno accesso a questo tag hanno accesso anche alle colonne codificate con i tag di criterio 2_Private o 1_Sensitive.

  • Un tag di criteri 2_Private per le colonne che includono informazioni sensibili che consentono l'identificazione personale (PII), come il nome di una persona. Gli utenti che hanno accesso a questo tag hanno accesso anche alle colonne codificate con il tag di criteri 1_Sensitive. Gli utenti non hanno accesso alle colonne codificate con il tag di criteri 3_Confidential.

  • Un tag di criteri 1_Sensitive per le colonne che includono dati che non possono essere resi pubblici, come il massimale di credito. Gli utenti che hanno accesso a questo tag non hanno accesso alle colonne codificate con i tag di criterio 2_Private o 3_Confidential.

Tutto ciò che non è taggato è disponibile per tutti gli utenti che hanno accesso al data warehouse.

Questi controlli dell'accesso garantiscono che, anche dopo la nuova identificazione dei dati, non possano essere letti finché l'accesso non viene concesso esplicitamente all'utente.

Account di servizio con ruoli limitati

Devi limitare l'accesso al progetto relativo ai dati riservati in modo che solo gli utenti autorizzati possano visualizzare i dati riservati. Per farlo, crea un account di servizio con il ruolo roles/iam.serviceAccountUser che deve essere rappresentato dagli utenti autorizzati. La simulazione dell'identità degli account di servizio consente agli utenti di utilizzare gli account di servizio senza scaricare le chiavi degli account di servizio, migliorando la sicurezza complessiva del progetto. La rappresentazione crea un token a breve termine che gli utenti autorizzati con il ruolo roles/iam.serviceAccountTokenCreator possono scaricare.

Criteri dell'organizzazione

Questo progetto include i vincoli dei criteri dell'organizzazione utilizzati dal progetto di base aziendale e aggiunge vincoli aggiuntivi. Per saperne di più sui vincoli utilizzati dal progetto base aziendale, consulta Vincoli dei criteri dell'organizzazione.

La tabella seguente descrive i vincoli aggiuntivi dei criteri dell'organizzazione definiti nel modulo org_policies:

Criterio Nome vincolo Valore consigliato
Limita i deployment delle risorse a località fisiche specifiche. Per ulteriori valori, consulta Gruppi di valori. gcp.resourceLocations
Uno dei seguenti:
in:us-locations
in:eu-locations
in:asia-locations
Disabilita la creazione di account di servizio iam.disableServiceAccountCreation true
Abilita OS Login per le VM create nel progetto. Per ulteriori informazioni, vedi Gestire OS Login in un'organizzazione e OS Login. compute.requireOsLogin true
Limita le nuove regole di forwarding a solo per uso interno, in base all'indirizzo IP. compute.restrictProtocolForwardingCreationForTypes INTERNAL
Definisci l'insieme di subnet VPC condivise che le risorse Compute Engine possono utilizzare. compute.restrictSharedVpcSubnetworks projects/PROJECT_ID/regions/REGION/s ubnetworks/SUBNETWORK-NAME.

Sostituisci SUBNETWORK-NAME con l'ID risorsa della subnet privata che deve essere utilizzata dal progetto base.
Disabilita il logging dell'output della porta seriale in Cloud Logging. compute.disableSerialPortLogging true

Gestione delle chiavi e crittografia per l'archiviazione e la reidentificazione

Gestisci chiavi CMEK separate per i tuoi dati riservati in modo da poter re-identificare i dati. Per proteggere le chiavi, puoi utilizzare Cloud HSM. Per identificare nuovamente i tuoi dati, utilizza le seguenti chiavi:

  • Una chiave CMEK utilizzata dalla pipeline Dataflow per il processo di reidentificazione.

  • La chiave di crittografia originale utilizzata da Sensitive Data Protection per anonimizzare i tuoi dati.

  • Una chiave CMEK per il warehouse BigQuery nel progetto relativo ai dati riservati.

Come accennato in precedenza in Gestione delle chiavi e crittografia per l'importazione, puoi specificare la posizione e i periodi di rotazione CMEK. Puoi utilizzare Cloud EKM se richiesto dalla tua organizzazione.

Controlli operativi

Puoi abilitare il logging e le funzionalità del livello Premium di Security Command Center, come l'analisi dello stato della sicurezza e il rilevamento delle minacce. Questi controlli ti consentono di:

  • Monitora chi accede ai tuoi dati.

  • Assicurarsi che venga messo in atto un controllo adeguato.

  • Supporta la capacità dei team operativi e di gestione degli incidenti di rispondere ai problemi che potrebbero verificarsi.

Access Transparency

Access Transparency fornisce una notifica in tempo reale nel caso in cui il personale dell'Assistenza Google richieda l'accesso ai tuoi dati. I log di Access Transparency vengono generati ogni volta che una persona accede a contenuti e solo il personale di Google con giustificazioni aziendali valide (ad esempio, una richiesta di assistenza) può ottenere l'accesso. Ti consigliamo di abilitare Access Transparency.

Logging

Per aiutarti a soddisfare i requisiti di controllo e ottenere insight sui tuoi progetti, configura Google Cloud Observability con i log di dati per i servizi che vuoi monitorare. Il modulo centralized-logging configura le seguenti best practice:

Per tutti i servizi all'interno dei progetti, i log devono includere informazioni sulle letture e scritture dei dati e su ciò che leggono gli amministratori. Per ulteriori best practice di logging, vedi Controlli di rilevamento.

Avvisi e monitoraggio

Dopo aver eseguito il deployment del progetto base, puoi configurare degli avvisi per notificare al centro operativo di sicurezza (SOC) che potrebbe verificarsi un incidente di sicurezza. Ad esempio, puoi utilizzare gli avvisi per comunicare al tuo analista della sicurezza quando un'autorizzazione IAM è stata modificata. Per ulteriori informazioni sulla configurazione degli avvisi di Security Command Center, consulta Configurare le notifiche sui risultati. Per avvisi aggiuntivi non pubblicati da Security Command Center, puoi configurare avvisi con Cloud Monitoring.

Ulteriori considerazioni sulla sicurezza

I controlli di sicurezza in questo progetto sono stati esaminati sia dal team Google Cybersecurity Action che da un team per la sicurezza di terze parti. Per richiedere l'accesso in conformità con l'NDA sia a un modello di minaccia STRIDE sia al report di valutazione di riepilogo, invia un'email all'indirizzo secured-dw-blueprint-support@google.com.

Oltre ai controlli di sicurezza descritti in questa soluzione, devi rivedere e gestire la sicurezza e i rischi nelle aree chiave che si sovrappongono e interagiscono con l'uso di questa soluzione. Sono inclusi:

  • Il codice che utilizzi per configurare, sottoporre a deployment ed eseguire job Dataflow.

  • La tassonomia di classificazione dei dati che utilizzi con questa soluzione.

  • Il contenuto, la qualità e la sicurezza dei set di dati archiviati e analizzati nel data warehouse.

  • L'ambiente complessivo in cui esegui il deployment della soluzione, tra cui:

    • La progettazione, la segmentazione e la sicurezza delle reti che colleghi a questa soluzione.
    • La sicurezza e la governance dei controlli IAM della tua organizzazione.
    • Le impostazioni di autenticazione e autorizzazione per gli utenti a cui concedi l'accesso all'infrastruttura che fa parte di questa soluzione e che hanno accesso ai dati archiviati e gestiti in tale infrastruttura.

Riepilogo

Per implementare l'architettura descritta in questo documento, segui questi passaggi:

  1. Stabilisci se eseguire il deployment del progetto base con quello dei concetti di base dell'azienda o da solo. Se scegli di non eseguire il deployment del progetto base aziendale, assicurati che il tuo ambiente abbia una base di sicurezza simile.

  2. Esamina il file Readme per il progetto e assicurati di soddisfare tutti i prerequisiti.

  3. Nell'ambiente di test, esegui il deployment della procedura dettagliata per vedere la soluzione in azione. Come parte del processo di test, considera quanto segue:

    1. Usa Security Command Center per eseguire la scansione dei progetti appena creati in base ai requisiti di conformità.

    2. Aggiungi i tuoi dati di esempio al warehouse BigQuery.

    3. Collabora con un analista di dati della tua azienda per testare il suo accesso ai dati riservati e se è in grado di interagire con i dati di BigQuery nel modo previsto.

  4. Esegui il deployment del progetto nell'ambiente di produzione.

Passaggi successivi