Importare dati da una rete esterna in un data warehouse BigQuery protetto

Last reviewed 2023-08-15 UTC

Molte organizzazioni implementano data warehouse che archiviano informazioni riservate per poter analizzare i dati a vari scopi commerciali. Questo documento è rivolto a data engineer e amministratori della sicurezza che eseguono il deployment e la protezione dei data warehouse utilizzando BigQuery. Fa parte di un'architettura di sicurezza che include quanto segue:

  • Un repository GitHub che contiene un insieme di configurazioni e script Terraform. La configurazione Terraform imposta un ambiente in Google Cloud che supporta un data warehouse che archivia dati riservati.
  • Una guida all'architettura, al design e ai controlli di sicurezza che utilizzi per implementare questo blueprint (questo documento).

Questo documento illustra quanto segue:

  • L'architettura e i servizi Google Cloud che puoi utilizzare per contribuire a proteggere un data warehouse in un ambiente di produzione.
  • Best practice per l'importazione dei dati in BigQuery da una rete esterna, ad esempio un ambiente on-premise.
  • Best practice per la governance dei dati durante la creazione, il deployment e il funzionamento di un data warehouse in Google Cloud, inclusa la crittografia a livello di colonna, la gestione differenziale dei dati riservati e i controlli di accesso a livello di colonna.

Questo documento presuppone che tu abbia già configurato un insieme di controlli di sicurezza di base come descritto nel blueprint delle basi di Google Cloud Enterprise. Ti aiuta ad applicare controlli aggiuntivi a quelli di sicurezza esistenti per contribuire a proteggere i dati riservati in un data warehouse.

Casi d'uso dei data warehouse

Il blueprint supporta i seguenti casi d'uso:

Panoramica

I data warehouse come BigQuery consentono alle aziende di analizzare i dati aziendali per ottenere informazioni. Gli analisti accedono ai dati aziendali archiviati nei data warehouse per creare approfondimenti. Se il tuo data warehouse include dati che ritieni riservati, devi adottare misure per preservare la sicurezza, la riservatezza, l'integrità e la disponibilità dei dati aziendali durante l'importazione e lo stoccaggio, durante il transito o durante l'analisi. In questo blueprint, esegui le seguenti operazioni:

  • Crittografa i dati di origine che si trovano al di fuori di Google Cloud (ad esempio in un ambiente on-premise) e importali in BigQuery.
  • 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 delle responsabilità appropriata per diversi profili.
  • Configura i controlli di sicurezza e la registrazione appropriati per contribuire a proteggere i dati riservati.
  • Utilizza la classificazione dei dati, i tag di criteri, la mascheratura dinamica dei dati e la crittografia a livello di colonna per limitare l'accesso a colonne specifiche nel data warehouse.

Architettura

Per creare un data warehouse riservato, devi importare i dati in modo sicuro e poi archiviarli in un perimetro dei Controlli di servizio VPC. L'immagine seguente mostra come vengono importati e archiviati i dati.

L'architettura del data warehouse protetto per le reti esterne.

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

  • Dedicated Interconnect ti consente di spostare i dati tra la tua rete e Google Cloud. Puoi utilizzare un'altra opzione di connettività, come descritto in Scegliere un prodotto di connettività di rete.

  • Identity and Access Management (IAM) e Resource Manager limitano l'accesso e segmentano le risorse. I controlli di accesso e la gerarchia delle risorse rispettano il principio del privilegio minimo.

  • Controlli di servizio VPC crea perimetri di sicurezza che isolano servizi e risorse impostando l'autorizzazione, i controlli di accesso e lo scambio di dati protetti. I perimetri sono i seguenti:

    • Un perimetro di importazione dati che accetta i dati in entrata (in batch o in stream). Un perimetro separato contribuisce a proteggere il resto dei carichi di lavoro dai dati in entrata.
    • Un perimetro di dati che isola i dati di crittografia da altri carichi di lavoro.
    • Un perimetro di governance che archivia le chiavi di crittografia e definisce cosa è considerato dato riservato.

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

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

  • Le funzioni Cloud Run vengono attivate da Cloud Storage e scrivono in BigQuery i dati caricati da Cloud Storage nel bucket di importazione.

  • Una pipeline Dataflow scrive i dati in streaming in BigQuery. Per proteggere i dati, Dataflow utilizza un account di servizio e controlli di accesso univoci. Per contribuire a proteggere l'esecuzione della pipeline trasferendola al servizio di backend, Dataflow utilizza Streaming Engine. Per ulteriori informazioni, consulta Autorizzazioni e sicurezza del flusso di dati.

  • Sensitive Data Protection esegue la scansione dei dati archiviati in BigQuery per trovare eventuali dati sensibili non protetti. Per ulteriori informazioni, consulta Utilizzare Sensitive Data Protection per eseguire la scansione dei dati di BigQuery.

  • Cloud HSM ospita la chiave di crittografia della chiave (KEK). Cloud HSM è un servizio per moduli di sicurezza hardware (HSM) basato sul cloud. Utilizzi Cloud HSM per generare la chiave di crittografia che utilizzi per criptare i dati nella tua rete prima di inviarli a Google Cloud.

  • Data Catalog classifica automaticamente i dati riservati con i metadati, noti anche come tag delle norme, quando vengono rilevati in BigQuery. 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, applica i tag criterio alle colonne che includono dati riservati.

  • BigQuery memorizza i dati criptati e la chiave di crittografia con wrapping in tabelle separate.

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

  • Security Command Center monitora e esamina i risultati di sicurezza di tutto il tuo ambiente Google Cloud in un'unica posizione.

  • Cloud Logging raccoglie tutti i log dei servizi Google Cloud per l'archiviazione e il recupero da parte degli strumenti di analisi e indagine.

  • Cloud Monitoring raccoglie e archivia informazioni e metriche sul rendimento dei servizi Google Cloud.

  • Data Profiler per BigQuery cerca automaticamente i dati sensibili in tutte le tabelle e le colonne di BigQuery nell'intera organizzazione, incluse tutte le cartelle e i progetti.

Struttura dell'organizzazione

Raggruppa le risorse della tua organizzazione in modo da poterle gestire e distintamente dagli ambienti di test dall'ambiente di produzione. Resource Manager ti consente di raggruppare logicamente le risorse per progetto, cartella e organizzazione.

Il seguente diagramma mostra una gerarchia di risorse con cartelle che rappresentano diversi ambienti, come bootstrap, comuni, di produzione, non di produzione (o di staging) e di sviluppo. Questa gerarchia è in linea con la struttura dell'organizzazione utilizzata dal progetto di fondazione di un'azienda. Esegui il deployment della maggior parte dei progetti nel blueprint nella cartella di produzione e del progetto di governance dei dati nella cartella comune utilizzata per la governance.

La gerarchia delle risorse per un data warehouse sicuro per le reti esterne.

Per gerarchie di risorse alternative, consulta Decidere una gerarchia di risorse per la tua zona di destinazione Google Cloud.

Cartelle

Utilizzi le cartelle per isolare l'ambiente di produzione e i servizi di governance dagli ambienti di test e non di produzione. La tabella seguente descrive le cartelle del blueprint Enterprise Foundation utilizzate da questo blueprint.

Cartella Descrizione
Bootstrap Contiene le risorse necessarie per eseguire il deployment del blueprint Nuclei dell'azienda.
Comune Contiene servizi centralizzati per l'organizzazione, ad esempio il progetto di governance dei dati.
Produzione Contiene progetti con risorse cloud che sono state testate e sono pronte per l'uso. In questo blueprint, la cartella Produzione contiene il progetto di importazione dati e il progetto di dati.
Non di produzione Contiene progetti con risorse cloud attualmente in fase di test e di staging per il rilascio. In questo blueprint, la cartella Non di produzione contiene il progetto di importazione dei dati e il progetto Data.
Sviluppo Contiene progetti con risorse cloud attualmente in fase di sviluppo. In questo blueprint, la cartella Sviluppo contiene il progetto di importazione dati e il progetto di dati.

Puoi modificare i nomi di queste cartelle in modo che corrispondano alla struttura delle cartelle della tua organizzazione, ma ti consigliamo di mantenere una struttura simile. Per maggiori informazioni, consulta il progetto di base per le aziende con Google Cloud.

Progetti

Isolerai parti del tuo ambiente utilizzando i progetti. La tabella seguente descrive i progetti necessari all'interno dell'organizzazione. Creerai questi progetti quando esegui il codice Terraform. Puoi modificare i nomi di questi progetti, ma ti consigliamo di mantenere una struttura simile.

Progetto Descrizione
Importazione dati Contiene i servizi necessari per ricevere i dati e scriverli in BigQuery.
Governance dei dati Contiene servizi che forniscono funzionalità di gestione delle chiavi, di logging e di catalogazione dei dati.
Dati Contiene i servizi necessari per archiviare i dati.

Oltre a questi progetti, l'ambiente deve includere anche un progetto che ospita un job Modello flessibile di Dataflow. Il job modello flessibile è necessario per la pipeline di dati in streaming.

Mappatura di ruoli e gruppi ai progetti

Devi concedere a diversi gruppi di utenti della tua organizzazione l'accesso ai progetti che costituiscono il data warehouse riservato. Le sezioni seguenti descrivono i consigli per i blueprint per i gruppi di utenti e le assegnazioni dei ruoli nei progetti che crei. Puoi personalizzare i gruppi in base alla struttura esistente della tua organizzazione, ma ti consigliamo di mantenere una suddivisione simile dei compiti e delle assegnazioni dei ruoli.

Gruppo di analisti di dati

Gli analisti di dati visualizzano e analizzano i dati nel data warehouse. Questo gruppo può visualizzare i dati dopo che sono stati caricati nel data warehouse ed eseguire le stesse operazioni del gruppo Visualizzatore di dati criptati. Questo gruppo richiede ruoli in progetti diversi, come descritto nella tabella seguente.

Ambito del compito Ruoli
Progetto di importazione dati
Progetto di dati
Livello delle norme relative ai dati Lettore con maschera (roles/bigquerydatapolicy.maskedReader)

Gruppo di visualizzatori dei dati criptati

Il gruppo Visualizzatore di dati criptati può visualizzare i dati criptati delle tabelle di generazione di report di BigQuery tramite Cloud Looker Studio e altri strumenti di generazione di report, come SAP Business Objects. Il gruppo di visualizzatori dei dati criptati non può visualizzare i dati in testo normale delle colonne criptate.

Questo gruppo richiede il ruolo Utente BigQuery (roles/bigquery.jobUser) nel progetto di dati. Questo gruppo richiede anche il ruolo Lettore mascherato (roles/bigquerydatapolicy.maskedReader) a livello di criteri dei dati.

Gruppo di lettori di testo normale

Il gruppo Lettore di testo normale dispone dell'autorizzazione richiesta per chiamare la funzione definita dall'utente dall'utente (UDF) di decrittografia per visualizzare i dati in testo normale e l'autorizzazione aggiuntiva per leggere i dati non mascherati. Questo gruppo richiede i ruoli nel progetto di dati, come descritto nella tabella seguente.

Questo gruppo richiede i seguenti ruoli nel progetto di dati:

Inoltre, questo gruppo richiede il ruolo Lettore granulare (roles/datacatalog.categoryFineGrainedReader) a livello di Data Catalog.

Gruppo di data engineer

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

Ambito del compito Ruoli
Progetto di importazione dati
Progetto di dati
  • Editor di dati BigQuery (roles/bigquery.dataeditor)
  • Utente job BigQuery (roles/bigquery.jobUser)
  • Editor Cloud Build (roles/cloudbuild.builds.editor)
  • Cloud KMS Viewer (roles/cloudkms.viewer)
  • Utente di rete Compute (roles/compute.networkuser)
  • Dataflow Admin (roles/dataflow.admin)
  • Amministratore DLP (roles/dlp.admin)
  • Logs Viewer (roles/logging.viewer)

Gruppo di amministratori di rete

Gli amministratori di rete configurano la rete. In genere, fanno parte del team di networking.

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

  • Amministratore Compute (roles/compute.networkAdmin)
  • Logs Viewer (roles/logging.viewer)

Gruppo di amministratori della sicurezza

Gli amministratori della sicurezza gestiscono i controlli di sicurezza come accesso, chiavi, regole del firewall, Controlli di servizio VPC e il 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 relativi alla protezione dei dati sensibili.

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

Esempi di flussi di accesso ai gruppi

Le sezioni seguenti descrivono i flussi di accesso per due gruppi all'interno della soluzione di data warehouse protetta.

Flusso di accesso per il gruppo Visualizzatore di dati criptati

Il seguente diagramma mostra cosa accade quando un utente del gruppo Visualizzatore di dati criptati tenta di accedere ai dati criptati in BigQuery.

Il flusso per il gruppo di visualizzatori dei dati criptati.

I passaggi per accedere ai dati in BigQuery sono i seguenti:

  1. Il visualizzatore dei dati criptati esegue la seguente query su BigQuery per accedere ai dati riservati:

    SELECT ssn, pan FROM cc_card_table

  2. BigQuery verifica l'accesso nel seguente modo:

    • L'utente viene autenticato utilizzando credenziali Google Cloud valide e non scadute.
    • L'identità utente e l'indirizzo IP da cui è stata originata la richiesta fanno parte della lista consentita nella regola di livello di accesso/ingresso nel perimetro di Controlli di servizio VPC.
    • IAM verifica che l'utente abbia i ruoli appropriati e sia autorizzato ad accedere alle colonne criptate selezionate nella tabella BigQuery.

BigQuery restituisce i dati riservati in formato criptato.

Flusso di accesso per il gruppo di lettori di testo normale

Il seguente diagramma mostra cosa accade quando un utente del gruppo Lettori di testo normale tenta di accedere ai dati criptati in BigQuery.

Il flusso per il gruppo di lettori di testo normale.

I passaggi per accedere ai dati in BigQuery sono i seguenti:

  1. Il Lettore di testo normale esegue la seguente query su BigQuery per accedere ai dati riservati in formato decriptato:

    SELECT decrypt_ssn(ssn) FROM cc_card_table

  2. BigQuery chiama la funzione definita dall'utente (UDF) di decrittografia all'interno della query per accedere alle colonne protette.

  3. L'accesso viene verificato nel seguente modo:

    • IAM verifica che l'utente abbia i ruoli appropriati e sia autorizzato ad accedere alla UDF di decrittografia su BigQuery.
    • La UDF recupera la chiave di crittografia dei dati (DEK) con wrapping utilizzata per proteggere le colonne di dati sensibili.

    La UDF di decrittografia chiama la chiave di crittografia della chiave (KEK) in Cloud HSM per sbloccare la DEK. La UDF decrittografia utilizza la funzione di decrittografia AEAD di BigQuery per decriptare le colonne di dati sensibili.

  4. All'utente viene concesso l'accesso ai dati in testo normale nelle colonne dei dati sensibili.

Informazioni sui controlli di sicurezza di cui hai bisogno

Questa sezione illustra i controlli di sicurezza di Google Cloud che puoi utilizzare per proteggere il tuo data warehouse. I principi di sicurezza principali da considerare sono i seguenti:

  • Garantisci l'accesso adottando i principi del privilegio minimo.
  • Proteggi le connessioni di rete tramite criteri e progettazione della segmentazione.
  • Proteggi la configurazione di ciascun servizio.
  • Classifica e proteggi i dati in base al livello di rischio.
  • Comprendi i requisiti di sicurezza per l'ambiente che ospita il data warehouse.
  • Configurare un monitoraggio e un logging sufficienti per il rilevamento, l'indagine e la risposta.

Controlli di sicurezza per l'importazione dati

Per creare il tuo data warehouse, devi trasferire i dati da un'altra origine nel tuo ambiente on-premise, in un altro cloud o in un'altra origine Google Cloud. Questo documento si concentra sul trasferimento dei dati dal tuo ambiente on-premise o da un altro cloud. Se trasferisci dati da un'altra origine Google Cloud, consulta Importare dati da Google Cloud in un data warehouse BigQuery protetto.

Puoi utilizzare una delle seguenti opzioni per trasferire i dati nel data warehouse su BigQuery:

  • Un job batch che carica i dati in un bucket Cloud Storage.
  • Un job di streaming che utilizza Pub/Sub.

Per contribuire a proteggere i dati durante l'importazione, puoi utilizzare la crittografia lato client, le regole del firewall e i criteri per i livelli di accesso. Il processo di importazione viene talvolta chiamato processo di estrazione, trasformazione e caricamento (ETL).

Connessione criptata a Google Cloud

Puoi utilizzare Cloud VPN o Cloud Interconnect per proteggere tutti i dati che scorrono tra Google Cloud e il tuo ambiente. Questo blueprint consiglia Dedicated Interconnect, in quanto fornisce una connessione diretta e un throughput elevato, elementi importanti se stai eseguendo lo streaming di molti dati.

Per consentire l'accesso a Google Cloud dal tuo ambiente, devi definire gli indirizzi IP inclusi nella lista consentita nelle regole dei criteri dei livelli di accesso.

Regole di rete e firewall

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

  • Contribuisce a ridurre la superficie di attacco della rete utilizzando Accesso privato Google quando i carichi di lavoro comunicano con le API e i servizi Google.
  • Ti assicura di utilizzare solo servizi che supportano i Controlli di servizio VPC.

Per ulteriori informazioni, consulta Configurare l'accesso privato Google.

La pipeline di dati richiede di aprire le porte TCP nella firewall, come definito nel file dataflow_firewall.tf nel repository del modulo harness-projects. Per ulteriori informazioni, consulta la pagina sulla configurazione dell'accesso a internet e delle regole firewall.

Per negare alle risorse la possibilità di utilizzare indirizzi IP esterni, il criterio dell'organizzazione Definisci IP esterni consentiti per le istanze VM (compute.vmExternalIpAccess) è impostato su Nega tutto.

Controlli del perimetro

Come mostrato nel diagramma dell'architettura, posiziona le risorse per il data warehouse in perimetri separati. Per consentire ai servizi in perimetri diversi di condividere dati, crei ponti di perimetro.

I bridge di perimetro consentono ai servizi protetti di effettuare richieste di risorse al di fuori del loro perimetro. Questi ponti effettuano le seguenti connessioni:

  • Collega il progetto di importazione dei dati al progetto di dati in modo che i dati possano essere importati in BigQuery.
  • Collega il progetto Dati al progetto di governance dei dati in modo che Sensitive Data Protection possa eseguire la scansione di BigQuery alla ricerca di dati riservati non protetti.
  • Collega il progetto di importazione dati al progetto di governance dei dati per accedere a log, monitoraggio e chiavi di crittografia.

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

Criterio di accesso

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

Per garantire che solo determinate origini possano accedere ai progetti, devi attivare un criterio di accesso per la tua organizzazione Google. Ti consigliamo di creare un criterio di accesso che specifichi l'intervallo di indirizzi IP consentiti per le richieste provenienti dal tuo ambiente on-premise e consenta solo le richieste di utenti o account servizio specifici. Per saperne di più, consulta Attributi del livello di accesso.

Crittografia lato client

Prima di spostare i dati sensibili in Google Cloud, criptali localmente per proteggerli at-rest e in transito. Puoi utilizzare la libreria di crittografia Tink o altre librerie di crittografia. La libreria di crittografia Tink è compatibile con la crittografia AEAD di BigQuery, che il blueprint utilizza per decriptare i dati criptati a livello di colonna dopo l'importazione.

La libreria di crittografia Tink utilizza DEK che puoi generare localmente o da Cloud HSM. Per avvolgere o proteggere la DEK, puoi utilizzare una KEK generata in Cloud HSM. La KEK è un insieme di chiavi di crittografia CMEK simmetrica archiviato in modo sicuro in Cloud HSM e gestito utilizzando i ruoli e le autorizzazioni IAM.

Durante l'importazione, sia il DEK con wrapping sia i dati vengono archiviati in BigQuery. BigQuery include due tabelle: una per i dati e l'altra per il DEK con wrapping. Quando gli analisti devono visualizzare dati riservati, BigQuery può utilizzare la decrittografia AEAD per scompattare la DEK con la KEK e decriptare la colonna protetta.

Inoltre, la crittografia lato client che utilizza Tink protegge ulteriormente i tuoi dati crittografando le colonne di dati sensibili in BigQuery. Il blueprint utilizza le seguenti chiavi di crittografia Cloud HSM:

  • Una chiave CMEK per il processo di importazione utilizzata anche da Pub/Sub, dalla pipeline Dataflow per lo streaming, dal caricamento batch di Cloud Storage e dagli elementi delle funzioni Cloud Run per i caricamenti batch successivi.
  • La chiave crittografica sottoposta a wrapping da Cloud HSM per i dati criptati sulla tua rete utilizzando Tink.
  • Chiave CMEK per il data warehouse BigQuery nel progetto di dati.

Specifica la posizione CMEK, che determina la posizione geografica in cui la chiave viene archiviata e resa disponibile per l'accesso. Devi assicurarti che il CMEK si trovi nella stessa posizione delle risorse. Per impostazione predefinita, il CMEK viene ruotato ogni 30 giorni.

Se le obbligazioni di conformità della tua organizzazione richiedono di gestire le tue chiavi esternamente da Google Cloud, puoi attivare Cloud External Key Manager. Se utilizzi chiavi esterne, sei responsabile delle attività di gestione delle chiavi, tra cui rotazione della chiave.

Account di servizio e controlli di 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à utente non abbiano accesso diretto ai servizi. Per consentire la separazione delle responsabilità, crei account di servizio con ruoli diversi per scopi specifici. Questi account servizio sono definiti nel modulo data-ingestion-sa e nel modulo data-governance-sa.

Gli account di servizio sono i seguenti:

  • L'account di servizio Cloud Storage esegue il processo di caricamento automatico dei dati batch nel bucket di archiviazione di importazione.
  • L'account di servizio Pub/Sub consente lo streaming dei dati al servizio Pub/Sub.
  • L'account di servizio controller Dataflow viene utilizzato dalla pipeline Dataflow per trasformare e scrivere dati da Pub/Sub a BigQuery.
  • L'account di servizio delle funzioni Cloud Run scrive i dati batch successivi caricati da Cloud Storage in BigQuery.
  • L'account di servizio Caricamento in archiviazione consente alla pipeline ETL di creare oggetti.
  • L'account di servizio Pub/Sub Write consente alla pipeline ETL di scrivere i dati in Pub/Sub.

La tabella seguente elenca i ruoli assegnati a ciascun account di servizio:

Nome Ruoli Ambito del compito
Account di servizio del controller Dataflow Progetto di importazione dati
Progetto di dati
Governance dei dati
Account di servizio Cloud Run Functions Progetto di importazione dati
  • BigQuery Data Editor (roles/bigquery.dataEditor)
  • Visualizzatore metadati BigQuery (roles/bigquery.metadataViewer)
 Progetto di dati
Account di servizio di caricamento in Storage Progetto di importazione dati
Account di servizio Pub/Sub Write Progetto di importazione dati

Controlli di sicurezza per l'archiviazione dei dati

Configura i seguenti controlli di sicurezza per contribuire a proteggere i dati nel data warehouse BigQuery:

  • Controlli di accesso a livello di colonna
  • Service account con ruoli limitati
  • Mascheramento dinamico dei dati dei campi sensibili
  • Criteri dell'organizzazione
  • Scansione automatica e profiler dei dati di Sensitive Data Protection
  • Perimetri dei Controlli di servizio VPC tra il progetto di importazione dati e il progetto di dati, con bridge di perimetro appropriati
  • Crittografia e gestione delle chiavi, come segue:
    • Crittografia dei dati inattivi con chiavi CMEK archiviate in Cloud HSM
    • Crittografia a livello di colonna utilizzando la crittografia AEAD di Tink e BigQuery

Mascheramento dei dati dinamico

Per facilitare la condivisione e l'applicazione dei criteri di accesso ai dati su larga scala, puoi configurare la mascheratura dinamica dei dati. Il mascheramento dei dati dinamico consente alle query esistenti di mascherare automaticamente i dati delle colonne utilizzando i seguenti criteri:

  • Le regole di mascheramento applicate alla colonna al momento dell'esecuzione della query.
  • I ruoli assegnati all'utente che esegue la query. Per accedere ai dati delle colonne non mascherate, l'analista dei dati deve disporre del ruolo Lettore granulare.

Per definire l'accesso alle colonne in BigQuery, crei tag di criteri. Ad esempio, la tassonomia creata nell'esempio autonomo crea il tag di criteri 1_Sensitive per le colonne che includono dati che non possono essere resi pubblici, come il massimale di credito. La regola di mascheramento dei dati predefinita viene applicata a queste colonne per nascondere il valore della colonna.

Tutto ciò che non è taggato è disponibile per tutti gli utenti che hanno accesso al data warehouse. Questi controlli dell'accesso assicurano che, anche dopo la scrittura dei dati in BigQuery, i dati nei campi sensibili non possano essere letti finché l'accesso non viene concesso esplicitamente all'utente.

Crittografia e decriptazione a livello di colonna

La crittografia a livello di colonna ti consente di criptare i dati in BigQuery a un livello più granulare. Anziché criptare un'intera tabella, seleziona le colonne che contengono dati sensibili in BigQuery e solo queste vengono criptate. BigQuery utilizza le funzioni di crittografia e decrittografia AEAD per creare i set di chiavi contenenti le chiavi per la crittografia e la decrittografia. Queste chiavi vengono poi utilizzate per criptare e decriptare i singoli valori di una tabella e per ruotare le chiavi all'interno di un insieme di chiavi. La crittografia a livello di colonna fornisce controllo dell'accesso doppio sui dati criptati in BigQuery, perché l'utente deve disporre delle autorizzazioni sia per la tabella sia per la chiave di crittografia per leggere i dati in testo non cifrato.

Profiler dei dati per BigQuery con Cloud DLP

Data Profiler ti consente di identificare le posizioni dei dati sensibili e ad alto rischio nelle tabelle BigQuery. Lo strumento di profilazione dei dati esegue automaticamente la scansione e l'analisi di tutte le tabelle e le colonne di BigQuery nell'intera organizzazione, incluse tutte le cartelle e tutti i progetti. Il profiler dei dati genera quindi metriche come gli infoTypes previsti, i livelli di rischio e sensibilità dei dati valutati e i metadati delle tabelle. Grazie a questi approfondimenti, puoi prendere decisioni consapevoli su come proteggere, condividere e utilizzare i tuoi dati.

Service account con ruoli limitati

Devi limitare l'accesso al progetto di dati in modo che solo gli utenti autorizzati possano visualizzare i campi dei dati sensibili. A tale scopo, crea un account di servizio con il ruolo roles/iam.serviceAccountUser che gli utenti autorizzati devono simulare. La simulazione dell'identità degli account di servizio consente agli utenti di utilizzare gli account di servizio senza scaricare le relative chiavi, migliorando la sicurezza complessiva del progetto. L'impersonificazione crea un token a breve termine che gli utenti autorizzati con il ruolo roles/iam.serviceAccountTokenCreator possono scaricare.

Criteri dell'organizzazione

Questo blueprint include i vincoli dei criteri dell'organizzazione utilizzati dal blueprint Nuclei aziendali e aggiunge vincoli aggiuntivi. Per ulteriori informazioni sui vincoli utilizzati dal progetto della piattaforma di base aziendale, consulta Vincoli dei criteri dell'organizzazione.

La tabella seguente descrive i vincoli aggiuntivi dei criteri dell'organizzazione definiti nel modulo organization-policies.

Norme Nome vincolo Valore consigliato
Limitare i deployment delle risorse a località fisiche specifiche gcp.resourceLocations Uno dei seguenti:
in:us-locations
in:eu-locations
in:asia-locations
Richiedi la protezione CMEK gcp.restrictNonCmekServices bigquery.googleapis.com
Disattivare la creazione di account di servizio iam.disableServiceAccountCreation true
Disattiva la creazione di chiavi dell'account di servizio disableServiceAccountKeyCreation true
Abilita OS Login per le VM create nel progetto compute.requireOsLogin true
Disattivare le concessioni automatiche dei ruoli all'account di servizio predefinito automaticIamGrantsForDefaultServiceAccounts true
Impostazioni di traffico in entrata consentite (funzioni Cloud Run) cloudfunctions.allowedIngressSettings ALLOW_INTERNAL_AND_GCLB
Limita le nuove regole di inoltro a essere solo interne, in base all'indirizzo IP compute.restrictProtocolForwardingCreationForTypes INTERNAL
Disattiva il logging dell'output della porta seriale in Cloud Logging compute.disableSerialPortLogging true
Definire l'insieme di subnet VPC condivise che le risorse Compute Engine possono utilizzare compute.restrictSharedVpcSubnetworks projects/PROJECT_ID/regions/REGION/subnetworks/SUBNETWORK-NAME

Sostituisci SUBNETWORK-NAME con l'ID risorsa della sottorete privata che vuoi che venga utilizzata dal blueprint.

Controlli operativi

Puoi attivare il logging e le funzionalità del livello Premium di Security Command Center, come Security Health Analytics ed Event Threat Detection. Questi controlli ti consentono di:

  • Monitora chi accede ai tuoi dati.
  • Assicurati che sia implementato un controllo adeguato.
  • Generare risultati per le risorse cloud configurate in modo errato.
  • Supporta la capacità dei team di gestione degli incidenti e delle operazioni di rispondere ai problemi che potrebbero verificarsi.

Access Transparency

Access Transparency ti 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 ai contenuti e solo il personale Google con motivazioni 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 informazioni sui tuoi progetti, configura Google Cloud Observability con i log dei dati per i servizi che vuoi monitorare. Il modulo harness-logging configura le seguenti best practice:

Per tutti i servizi all'interno dei progetti, i log devono includere informazioni sulle letture e sulle scritture dei dati e sulle informazioni lette dagli amministratori. Per altre best practice sul logging, consulta Controlli di rilevamento nel blueprint delle basi aziendali.

Avvisi e monitoraggio

Dopo aver implementato il blueprint, puoi configurare avvisi per notificare al tuo Centro operativo di sicurezza (SOC) la possibile presenza di un incidente di sicurezza. Ad esempio, puoi utilizzare gli avvisi per comunicare all'analista della sicurezza quando un'autorizzazione IAM è stata modificata. Per ulteriori informazioni sulla configurazione degli avvisi di Security Command Center, consulta Configurare le notifiche dei risultati. Per avvisi aggiuntivi non pubblicati da Security Command Center, puoi configurare avvisi con Cloud Monitoring.

Considerazioni sulla sicurezza aggiuntive

Oltre ai controlli di sicurezza descritti in questa soluzione, devi esaminare e gestire la sicurezza e il rischio nelle aree chiave che si sovrappongono e interagiscono con il tuo utilizzo di questa soluzione. Queste considerazioni sulla sicurezza includono quanto segue:

  • La sicurezza del codice utilizzato per configurare, eseguire il deployment ed eseguire i job Dataflow e le funzioni Cloud Run.
  • La tassonomia di classificazione dei dati utilizzata con questa soluzione.
  • Generazione e gestione delle chiavi di crittografia.
  • I contenuti, 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, inclusi quanto segue:
    • La progettazione, la segmentazione e la sicurezza delle reti collegate a questa soluzione.
    • La sicurezza e la governance dei controlli IAM della tua organizzazione.
    • Le impostazioni di autenticazione e autorizzazione per gli attori a cui concedi l'accesso all'infrastruttura che fa parte di questa soluzione e che hanno accesso ai dati archiviati e gestiti in quell'infrastruttura.

Riepilogo

Per implementare l'architettura descritta in questo documento:

  1. Determina se implementare il blueprint con il blueprint delle basi dell'azienda o da solo. Se scegli di non implementare il blueprint Nuclei dell'azienda, assicurati che nel tuo ambiente sia implementata una base di riferimento per la sicurezza simile.
  2. Configura una connessione Dedicated Interconnect con la tua rete.
  3. Esamina il file README del blueprint e assicurati di soddisfare tutti i prerequisiti.
  4. Verifica che la tua identità utente disponga dei ruoli iam.serviceAccountUser e iam.serviceAccountTokenCreator per la cartella di sviluppo dell'organizzazione, come descritto nella sezione Struttura organizzativa. Se non disponi di una cartella per i test, creane una e configura l'accesso.
  5. Registra l'ID account di fatturazione, il nome visualizzato dell'organizzazione, l'ID cartella per la cartella di prova o della demo e gli indirizzi email per i seguenti gruppi di utenti:
    • Analisti di dati
    • Visualizzatore dei dati criptati
    • Lettore di testo normale
    • Data engineer
    • Amministratori rete
    • Amministratori sicurezza
    • Analisti sicurezza
  6. Crea i progetti Data, Governance dei dati, Importazione dati e Modello flessibile. Per un elenco delle API da abilitare, consulta il file README.
  7. Crea l'account di servizio per Terraform e assegna i ruoli appropriati per tutti i progetti.
  8. Configura il criterio di controllo dell'accesso.

  9. Nell'ambiente di test, esegui il deployment della soluzione:

    1. Clona ed esegui gli script Terraform per configurare un ambiente in Google Cloud.
    2. Installa la libreria di crittografia Tink sulla tua rete.
    3. Configura le credenziali predefinite dell'applicazione in modo da poter eseguire la libreria Tink sulla tua rete.
    4. Crea chiavi di crittografia con Cloud KMS.
    5. Genera insiemi di chiavi criptati con Tink.

    6. Crittografa i dati con Tink utilizzando uno dei seguenti metodi:

    7. Carica i dati criptati in BigQuery utilizzando caricamenti in streaming o batch.

  10. Verifica che gli utenti autorizzati possano leggere i dati non criptati da BigQuery utilizzando la funzione di decrittografia AEAD di BigQuery. Ad esempio, esegui la seguente funzione di decrittografia:

    CREATE OR REPLACE FUNCTION `{project_id}.{bigquery_dataset}.decrypt`(encodedText STRING) RETURNS STRING AS
(
AEAD.DECRYPT_STRING(
KEYS.KEYSET_CHAIN('gcp-kms://projects/myProject/locations/us/keyRings/myKeyRing/cryptoKeys/myKeyName', b'\012\044\000\321\054\306\036\026…..'),
FROM_BASE64(encodedText), "")
);

    Esegui la query di creazione della vista:

    CREATE OR REPLACE VIEW `{project_id}.{bigquery_dataset}.decryption_view` AS

SELECT
 Card_Type_Code,
 Issuing_Bank,
 Card_Number,
 `bigquery_dataset.decrypt`(Card_Number) AS Card_Number_Decrypted
FROM `project_id.dataset.table_name`

    Esegui la query di selezione dalla visualizzazione:

    SELECT
  Card_Type_Code,
  Issuing_Bank,
  Card_Number,
  Card_Number_Decrypted
FROM
`{project_id}.{bigquery_dataset}.decrypted_view`

    Per altre query e casi d'uso, consulta Crittografia a livello di colonna con Cloud KMS.

  11. Utilizza Security Command Center per eseguire la scansione dei progetti appena creati in base ai tuoi requisiti di conformità.

  12. Esegui il deployment del blueprint nell'ambiente di produzione.

Passaggi successivi