Importare i dati in un data warehouse BigQuery protetto

Molte organizzazioni implementano data warehouse che archiviano dati sensibili in modo da poterli analizzare per una serie di scopi aziendali. Questo documento è destinato agli ingegneri dei dati e agli amministratori della sicurezza che eseguono il deployment e proteggono i data warehouse utilizzando BigQuery. Fa parte di un progetto composto da quanto segue:

Questo documento tratta i seguenti argomenti:

  • L'architettura e i servizi che puoi utilizzare per proteggere un data warehouse in un ambiente di produzione. Google Cloud
  • Best practice per l'importazione di 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 inGoogle Cloud, tra cui:

    • data de-identification

    • trattamento differenziale dei dati riservati

    • crittografia a livello di colonna

    • controlli di accesso a livello di colonna

Questo documento presuppone che tu abbia già configurato un insieme di base di controlli di sicurezza, come descritto nel blueprint delle fondamenta aziendali. Ti aiuta ad aggiungere controlli aggiuntivi a quelli di sicurezza esistenti per proteggere i dati riservati in un data warehouse.

Casi d'uso del data warehouse

Il progetto supporta i seguenti casi d'uso:

Panoramica

I data warehouse come BigQuery consentono alle aziende di analizzare i propri dati aziendali per ottenere insight. Gli analisti accedono ai dati aziendali archiviati nei data warehouse per creare approfondimenti. 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 durante l'archiviazione, il transito o l'analisi. In questo blueprint, imparerai a:

  • Quando importi dati da origini dati esterne, cripta i dati che si trovano al di fuori di Google Cloud (ad esempio, in un ambiente on-premise) e importali in Google Cloud.
  • 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 dei compiti appropriata per le diverse buyer persona.
  • Quando importi dati da altre origini situate in Google Cloud (note anche come origini dati interne), configura i modelli per trovare e anonimizzare i dati riservati.
  • Configura controlli di sicurezza e logging appropriati per proteggere i dati riservati.
  • Utilizza la classificazione dei dati, i tag di policy, il mascheramento dinamico 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 confidenziale, devi importare i dati in modo sicuro e poi archiviarli in un perimetro dei Controlli di servizio VPC.

Architettura durante l'importazione dei dati da Google Cloud

L'immagine seguente mostra come i dati importati vengono classificati, resi anonimi e archiviati quando importi i dati di origine da Google Cloud utilizzando il repository terraform-google-secured-data-warehouse. Mostra anche come re-identificare i dati riservati on demand per l'analisi.

L'architettura del data warehouse dei dati sensibili per le origini interne.

Architettura durante l'importazione di dati da origini esterne

L'immagine seguente mostra come vengono inseriti e archiviati i dati quando li importi da un ambiente on-premise o da un altro cloud in un data warehouse BigQuery utilizzando il repository terraform-google-secured-data-warehouse-onprem-ingest.

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

Google Cloud servizi e funzionalità

Le architetture utilizzano una combinazione dei seguenti servizi e funzionalità: Google Cloud

Servizio o funzionalità Descrizione

BigQuery

Applicabile sia alle origini dati interne che esterne. Tuttavia, esistono diverse opzioni di archiviazione, come segue:

  • Quando importi dati da Google Cloud, BigQuery archivia i dati riservati nel perimetro dei dati riservati.
  • Quando importi dati da un'origine esterna, BigQuery archivia i dati criptati e la chiave di crittografia sottoposta a wrapping in tabelle separate.

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

Cloud Key Management Service (Cloud KMS) con Cloud HSM

Applicabile sia alle fonti interne che a quelle esterne. Tuttavia, esiste un caso d'uso aggiuntivo per le origini dati esterne.

Cloud HSM è un servizio per modulo di sicurezza hardware (HSM) basato sul cloud che ospita la chiave di crittografia delle chiavi (KEK). Quando importi dati da un'origine esterna, utilizzi Cloud HSM per generare la chiave di crittografia che utilizzi per criptare i dati nella tua rete prima di inviarli a Google Cloud.

Cloud Logging

Applicabile sia alle fonti interne che a quelle esterne.

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

Cloud Monitoring

Applicabile a fonti interne ed esterne.

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

Cloud Run Functions

Applicabile solo alle origini dati esterne.

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

Cloud Storage e Pub/Sub

Applicabile a fonti interne ed esterne.

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

  • Cloud Storage:riceve e archivia i dati batch. Per impostazione predefinita, Cloud Storage utilizza TLS per criptare i dati in transito e AES-256 per criptare i dati archiviati. La chiave di crittografia è una chiave di crittografia gestita dal cliente (CMEK). Per ulteriori informazioni sulla crittografia, vedi Opzioni di crittografia dei dati.

    Puoi contribuire a proteggere l'accesso ai bucket Cloud Storage utilizzando controlli di sicurezza come Identity and Access Management, elenchi di controllo dell'accesso (ACL) e documenti delle policy. Per ulteriori informazioni sui controlli dell'accesso supportati, consulta la panoramica del controllo dell'accesso.

Data Profiler per BigQuery

Applicabile sia alle fonti interne che a quelle esterne.

Data Profiler per BigQuery esegue automaticamente la scansione dei dati sensibili in tutte le tabelle e colonne BigQuery dell'intera organizzazione, incluse tutte le cartelle e i progetti.

Pipeline Dataflow

Applicabile sia a fonti interne che esterne; tuttavia, esistono pipeline diverse.

Le pipeline Dataflow importano i dati nel seguente modo:

  • Quando importi dati da Google Cloud, due pipeline Dataflow anonimizzano e reidentificano i dati riservati. La prima pipeline rimuove l'identificazione dei dati riservati utilizzando la pseudonimizzazione. La seconda pipeline reidentifica i dati riservati quando gli utenti autorizzati richiedono l'accesso.
  • Quando importi dati da un'origine esterna, una pipeline Dataflow scrive i dati di streaming in BigQuery.

Dataplex Universal Catalog

Applicabile a fonti interne ed esterne.

Dataplex Universal Catalog classifica automaticamente i dati riservati con i metadati, noti anche come tag delle norme, durante l'importazione. Dataplex Universal Catalog utilizza anche i metadati per gestire l'accesso ai dati riservati. Per controllare l'accesso ai dati all'interno del data warehouse, applica i tag criterio alle colonne che includono dati riservati.

Dedicated Interconnect

Applicabile solo alle origini dati esterne.

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 Scelta di un prodotto per la connettività di rete.

IAM e Resource Manager

Applicabile a fonti interne ed esterne.

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

Security Command Center

Applicabile sia alle fonti interne che a quelle esterne.

Security Command Center monitora e rivede i risultati di sicurezza provenienti da tutto il tuo ambiente Google Cloud in una posizione centrale.

Sensitive Data Protection

Applicabile sia a fonti interne che esterne; tuttavia, vengono eseguite scansioni diverse.

Sensitive Data Protection analizza i dati come segue:

  • Quando importi dati da Google Cloud, 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.
  • Quando importi dati da un'origine esterna, Sensitive Data Protection analizza i dati archiviati in BigQuery per trovare eventuali dati sensibili non protetti. Per maggiori informazioni, consulta Utilizzo di Sensitive Data Protection per scansionare i dati di BigQuery.

Controlli di servizio VPC

Applicabile sia a fonti interne che esterne; tuttavia, esistono perimetri diversi.

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

  • Un perimetro di importazione dati accetta i dati in entrata (in batch o in flusso) e li deidentifica. Una zona di destinazione separata contribuisce a proteggere il resto dei tuoi carichi di lavoro dai dati in entrata.
  • Quando importi dati da Google Cloud, un perimetro di dati riservati può identificare nuovamente i dati riservati e archiviarli in un'area con limitazioni.
  • Quando importi dati esterni, un perimetro di dati isola i dati di crittografia da altri carichi di lavoro.
  • Un perimetro di governance archivia le chiavi di crittografia e definisce quali sono i dati considerati riservati.

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

Struttura dell'organizzazione

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

I seguenti diagrammi mostrano una gerarchia di risorse con cartelle che rappresentano diversi ambienti, ad esempio bootstrap, common, produzione, non produzione (o staging) e sviluppo. La maggior parte dei progetti nell'architettura viene implementata nella cartella di produzione, mentre il progetto di governance dei dati nella cartella comune utilizzata per la governance.

Struttura dell'organizzazione durante l'importazione dei dati da Google Cloud

Il seguente diagramma mostra la struttura dell'organizzazione durante l'importazione dei dati da Google Cloud utilizzando il repository terraform-google-secured-data-warehouse.

La gerarchia delle risorse per un data warehouse di dati sensibili per le origini interne.

Struttura dell'organizzazione durante l'importazione di dati da origini esterne

Il seguente diagramma mostra la struttura dell'organizzazione quando importi dati da un'origine esterna utilizzando il repository terraform-google-secured-data-warehouse-onprem-ingest.

La gerarchia delle risorse per un data warehouse sensibile per le origini esterne.

Cartelle

Utilizzi 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 blueprint delle fondamenta dell'impresa utilizzate da questa architettura.

Cartella Descrizione

Bootstrap

Contiene le risorse necessarie per il deployment del blueprint delle fondamenta dell'impresa.

Comune

Contiene servizi centralizzati per l'organizzazione, come il progetto di governance dei dati.

Produzione

Contiene progetti con risorse cloud testate e pronte all'uso. In questa architettura, la cartella Production contiene il progetto di importazione dei dati e i progetti correlati ai dati.

Non di produzione

Contiene progetti con risorse cloud in fase di test e preparazione per il rilascio. In questa architettura, la cartella Non-production contiene il progetto di importazione dei dati e i progetti correlati ai dati.

Sviluppo

Contiene i progetti con risorse cloud in fase di sviluppo. In questa architettura, la cartella Development contiene il progetto di importazione dei dati e i progetti correlati ai 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 delle fondamenta dell'impresa.

Progetti

Isoli parti del tuo 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 simile.

Progetto Descrizione

Importazione dati

Progetto comune per fonti interne ed esterne.

Contiene servizi necessari per ricevere i dati e anonimizzare quelli riservati.

Governance dei dati

Progetto comune per fonti interne ed esterne.

Contiene servizi che forniscono funzionalità di gestione delle chiavi, logging e catalogazione dei dati.

Dati non riservati

Progetto solo per fonti interne.

Contiene servizi necessari per archiviare i dati a cui è stata rimossa l'identificazione personale.

Dati riservati

Progetto solo per fonti interne.

Contiene servizi necessari per archiviare e reidentificare i dati riservati.

Dati

Proiezione solo per le sorgenti esterne.

Contiene servizi necessari per archiviare i dati.

Oltre a questi progetti, l'ambiente deve includere anche un progetto che ospita un job Dataflow Flex Template. Il job del 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 compongono il data warehouse confidenziale. Le sezioni seguenti descrivono i consigli sull'architettura per i gruppi di utenti e le assegnazioni di ruoli nei progetti che crei. Puoi personalizzare i gruppi in modo che corrispondano alla struttura esistente della tua organizzazione, ma ti consigliamo di mantenere una separazione dei compiti e un'assegnazione dei ruoli simili.

Gruppo di analisti di dati

Gli analisti di dati analizzano i dati nel warehouse. Nel repository terraform-google-secured-data-warehouse-onprem-ingest, questo gruppo può visualizzare i dati dopo che sono stati caricati nel data warehouse ed eseguire le stesse operazioni del gruppo Visualizzatore dati criptati.

La tabella seguente descrive i ruoli del gruppo in diversi progetti per il repository terraform-google-secured-data-warehouse (solo origini dati interne).

Mappatura del progetto Ruoli

Importazione dati

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

Dati riservati

Dati non riservati

La tabella seguente descrive i ruoli del gruppo in diversi progetti per il repository terraform-google-secured-data-warehouse-onprem-ingest (solo origini dati esterne).

Ambito dell'assegnazione Ruoli

Progetto di importazione dati

Progetto di dati

Livello delle norme sui dati

Lettore mascherato (roles/bigquerydatapolicy.maskedReader)

Gruppo Visualizzatore dati criptati (solo origini esterne)

Il gruppo Visualizzatore dati criptati nel repository terraform-google-secured-data-warehouse-onprem-ingest può visualizzare i dati criptati delle tabelle dei report BigQuery tramite Looker Studio e altri strumenti di generazione di report, come SAP Business Objects. Il gruppo di visualizzatori di dati criptati non può visualizzare i dati in formato leggibile dalle 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 policy dei dati.

Gruppo lettori di testo non criptato (solo fonti esterne)

Il gruppo Lettore di testo normale nel repository terraform-google-secured-data-warehouse-onprem-ingest dispone dell'autorizzazione necessaria per chiamare la funzione definita dall'utente dall'utente (UDF) di decriptazione per visualizzare i dati in testo normale e dell'autorizzazione aggiuntiva per leggere i dati non mascherati.

Questo gruppo richiede i seguenti ruoli nel progetto Data:

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

Gruppo di data engineer

I data engineer configurano e gestiscono la pipeline di dati e il data warehouse.

La seguente tabella descrive i ruoli del gruppo in diversi progetti per il repository terraform-google-secured-data-warehouse.

Punteggio del compito Ruoli

Progetto di importazione dati

Progetto di dati riservati

Progetto dei dati non riservati

La seguente tabella descrive i ruoli del gruppo in diversi progetti per il repository terraform-google-secured-data-warehouse-onprem-ingest.

Ambito dell'assegnazione Ruoli

Progetto di importazione dati

Progetto di dati

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:

Gruppo di amministratori della sicurezza

Gli amministratori della sicurezza gestiscono i controlli di sicurezza come 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 di Sensitive Data Protection.

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

Flussi di accesso ai gruppi di esempio per origini esterne

Le sezioni seguenti descrivono i flussi di accesso per due gruppi durante l'importazione di dati da origini esterne utilizzando il repository terraform-google-secured-data-warehouse-onprem-ingest.

Flusso di accesso per il gruppo Visualizzatore dati criptati

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

Il flusso per il gruppo di visualizzatori di dati criptati.

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

  1. Il visualizzatore di 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 Cloudvalide e non scadute.
    • L'identità dell'utente e l'indirizzo IP da cui ha avuto origine la richiesta fanno parte della lista consentita nel livello di accesso o nella regola di ingresso del perimetro di Controlli di servizio VPC.
    • IAM verifica che l'utente disponga dei 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 lettura Plaintext

Il seguente diagramma mostra cosa succede quando un utente del gruppo Lettore 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 decriptazione all'interno della query per accedere alle colonne protette.

  3. L'accesso viene verificato nel seguente modo:

    • IAM verifica che l'utente disponga dei ruoli appropriati e sia autorizzato ad accedere alla UDF di decriptografia su BigQuery.
    • La funzione definita dall'utente recupera la chiave di crittografia dei dati (DEK) sottoposta a wrapping utilizzata per proteggere le colonne di dati sensibili.

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

  5. All'utente viene concesso l'accesso ai dati in testo non crittografato nelle colonne dei dati sensibili.

Controlli di sicurezza comuni

Le sezioni seguenti descrivono i controlli che si applicano sia alle origini interne che a quelle esterne.

Controlli di importazione dei dati

Per creare il data warehouse, devi trasferire i dati da un'altra Google Cloud origine (ad esempio un data lake), dal tuo ambiente on-premise o da un altro cloud. 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 streaming che utilizza Pub/Sub.

Per proteggere i dati durante l'importazione, puoi utilizzare la crittografia lato client, regole firewall e policy di livello di accesso. Il processo di importazione a volte viene definito estrazione, trasformazione e caricamento (ETL).

Regole di rete e firewall

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

  • Consente di 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 che utilizzi solo i servizi che supportano i Controlli di servizio VPC.

Per ulteriori informazioni, vedi Configurazione dell'accesso privato Google.

Quando utilizzi il repository terraform-google-secured-data-warehouse, devi configurare subnet separate per ogni job Dataflow. Le subnet separate garantiscono che i dati sottoposti a deidentificazione siano separati correttamente da quelli sottoposti a reidentificazione.

La pipeline di dati richiede l'apertura delle porte TCP nel firewall, come definito nel file dataflow_firewall.tf nei rispettivi repository. Per ulteriori informazioni, consulta la pagina Configurazione dell'accesso a internet e delle regole firewall.

Per impedire alle risorse di utilizzare indirizzi IP esterni, la policy dell'organizzazione Definisci IP esterni consentiti per le istanze VM (compute.vmExternalIpAccess) è impostata su Nega tutto.

Controlli perimetrali

Come mostrato nel diagramma dell'architettura, inserisci le risorse per il data warehouse in perimetri separati. Per consentire ai servizi in perimetri diversi di condividere i dati, crea ponti perimetrali.

I bridge di perimetro consentono ai servizi protetti di effettuare richieste di risorse al di fuori del loro perimetro. Questi ponti stabiliscono le seguenti connessioni per il repository terraform-google-secured-data-warehouse:

  • Collegano il progetto di importazione dati al progetto di governance in modo che la deidentificazione possa avvenire durante l'importazione.
  • Collegano il progetto per i dati non riservati e il progetto per i dati riservati in modo che i dati riservati possano essere reidentificati quando un analista dei dati lo richiede.
  • Collegano il progetto riservato al progetto di governance dei dati in modo che la reidentificazione possa avvenire quando un analista dei dati lo richiede.

Questi ponti stabiliscono le seguenti connessioni per il repository terraform-google-secured-data-warehouse-onprem-ingest:

  • Collegano il progetto di importazione dei dati al progetto di dati in modo che i dati possano essere importati in BigQuery.
  • Collegano il progetto di dati al progetto di governance dei dati in modo che Sensitive Data Protection possa analizzare BigQuery alla ricerca di dati riservati non protetti.
  • Collegano il progetto di importazione dati al progetto di governance dei dati per l'accesso a logging, monitoraggio e chiavi di crittografia.

Oltre ai bridge di perimetro, utilizzi le regole di uscita per consentire alle risorse protette dai perimetri di servizio di accedere alle risorse che si trovano al di fuori del perimetro. In questa soluzione, configuri le regole di uscita per ottenere i job del modello flessibile esterno di Dataflow che si trovano in Cloud Storage in un progetto esterno. Per saperne di più, vedi Accedere a una risorsa Google Cloud al di fuori del perimetro.

Policy di accesso

Per garantire che solo identità specifiche (utente o servizio) possano accedere a risorse e dati, devi attivare 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 consentito per le richieste e consenta solo le richieste di utenti o service account specifici. Per saperne di più, consulta Attributi del livello di accesso.

Service account e controlli dell'accesso

I service account sono identità che Google Cloud possono utilizzare per eseguire richieste API per tuo conto. Gli account di servizio garantiscono che le identità utente non abbiano accesso diretto ai servizi. Per consentire la separazione dei compiti, crea service account con ruoli diversi per scopi specifici. Questi account di servizio sono definiti nel modulo data-ingestion e nel modulo confidential-data in ogni architettura.

Per il repository terraform-google-secured-data-warehouse, gli account di servizio sono i seguenti:

  • Un account di servizio controller Dataflow per la pipeline Dataflow che anonimizza i dati riservati.
  • Un account di servizio 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 di streaming.
  • Un account di servizio Cloud Scheduler per eseguire il job batch Dataflow che crea la pipeline Dataflow.

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

Service account Nome Progetto Ruoli

Controller Dataflow

Questo account viene utilizzato per la deidentificazione.

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

Pub/Sub

sa-pubsub-writer

Importazione dati

Cloud Scheduler

sa-scheduler-controller

Importazione dati

Per il repository terraform-google-secured-data-warehouse-onprem-ingest, gli account di servizio sono i seguenti:

  • L'account di servizio Cloud Storage esegue il processo di caricamento batch automatico dei dati nel bucket di archiviazione di importazione.
  • L'account di servizio Pub/Sub consente lo streaming dei dati al servizio Pub/Sub.
  • Il account di servizio del controller Dataflow viene utilizzato dalla pipeline Dataflow per trasformare e scrivere i 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.
  • Il account di servizio Storage Upload consente alla pipeline ETL di creare oggetti.
  • Il service account di scrittura Pub/Sub consente alla pipeline ETL di scrivere dati in Pub/Sub.

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

Nome Ruoli Ambito dell'assegnazione

Account di servizio controller Dataflow

Progetto di importazione dati

Progetto di dati

Governance dei dati

Account di servizio Cloud Run Functions

Progetto di importazione dati

Progetto di dati

Account di servizio Storage Upload

Progetto di importazione dati

Account di servizio Pub/Sub Write

Progetto di importazione dati

Policy dell'organizzazione

Questa architettura include i vincoli dei criteri dell'organizzazione utilizzati dal blueprint delle fondamenta dell'impresa e aggiunge vincoli aggiuntivi. Per saperne di più sui vincoli utilizzati dal progetto della piattaforma aziendale, consulta Vincoli delle policy dell'organizzazione.

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

Norme Nome vincolo Valore consigliato

Limitare i deployment delle risorse a posizioni fisiche specifiche. Per altri valori, vedi Gruppi di valori.

gcp.resourceLocations

Uno dei seguenti valori:

in:us-locations

in:eu-locations

in:asia-locations

Disattivare account di servizio account

iam.disableServiceAccountCreation

true

Attiva OS Login per le VM create nel progetto.

compute.requireOsLogin

true

Limita le nuove regole di forwarding in modo che siano solo interne, in base all'indirizzo IP.

compute.restrictProtocolForwardingCreationForTypes

INTERNAL

Definisci l'insieme di VPC condiviso condivise che le risorse Compute Engine possono utilizzare.

compute.restrictSharedVpcSubnetworks

projects//regions//s ubnetworks/.

Sostituisci con l'ID risorsa della subnet privata che vuoi che l'architettura utilizzi.

Disattiva la registrazione dell'output della porta seriale in Cloud Logging.

compute.disableSerialPortLogging

true

Richiedi la protezione CMEK (solo terraform-google-secured-data-warehouse-onprem-ingest)

gcp.restrictNonCmekServices

bigquery.googleapis.com

Disattiva creazione chiavi account di servizio (terraform-google-secured-data-warehouse-onprem-ingest only)

disableServiceAccountKeyCreation

true

Attiva OS Login per le VM create nel progetto (terraform-google-secured-data-warehouse-onprem-ingest only)

compute.requireOsLogin

true

Disabilita l'assegnazione automatica di ruoli al service account predefinito (terraform-google-secured-data-warehouse-onprem-ingest only)

automaticIamGrantsForDefaultServiceAccounts

true

Impostazioni di traffico in entrata consentite (Cloud Run Functions) (terraform-google-secured-data-warehouse-onprem-ingest only)

cloudfunctions.allowedIngressSettings

ALLOW_INTERNAL_AND_GCLB

Controlli di sicurezza per origini dati esterne

Le sezioni seguenti descrivono i controlli che si applicano all'importazione di dati da fonti esterne.

Connessione criptata a: Google Cloud

Quando importi dati da origini esterne, puoi utilizzare Cloud VPN o Cloud Interconnect per proteggere tutti i dati che fluiscono tra Google Cloud e il tuo ambiente. Questa architettura aziendale consiglia Dedicated Interconnect, perché fornisce una connessione diretta e un throughput elevato, importanti se trasmetti in streaming molti dati.

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

Crittografia lato client

Prima di spostare i dati sensibili in Google Cloud, criptali localmente per proteggerli quando sono inattivi 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 l'architettura 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 eseguire il wrapping o proteggere la DEK, puoi utilizzare una KEK generata in Cloud HSM. La KEK è un set di chiavi di crittografia CMEK simmetrica archiviato in modo sicuro in Cloud HSM e gestito utilizzando ruoli e autorizzazioni IAM.

Durante l'importazione, sia la DEK sottoposta a wrapping sia i dati vengono archiviati in BigQuery. BigQuery include due tabelle: una per i dati e l'altra per la DEK sottoposta a wrapping. Quando gli analisti devono visualizzare dati riservati, BigQuery può utilizzare il decryption AEAD per decrittografare 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. L'architettura 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 artefatti delle funzioni Cloud Run per i successivi caricamenti batch.
  • La chiave di crittografia sottoposta a wrapping da Cloud HSM per i dati criptati sulla tua rete utilizzando Tink.
  • Chiave CMEK per il warehouse BigQuery nel progetto dati.

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

Se gli obblighi di conformità della tua organizzazione richiedono di gestire le tue chiavi esternamente a Google Cloud, puoi attivare Cloud External Key Manager. Se utilizzi chiavi esterne, sei responsabile delle attività di gestione delle chiavi, inclusarotazione della chiavei.

Mascheramento dinamico dei dati

Per facilitare la condivisione e l'applicazione su larga scala delle norme di accesso ai dati, puoi configurare il mascheramento dinamico dei dati. Il mascheramento dinamico dei dati 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 mascherati, l'analista dei dati deve disporre del ruolo Lettore granulare.

Per definire l'accesso alle colonne in BigQuery, crea 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, ad esempio il massimale di credito. A queste colonne viene applicata la regola di mascheramento dei dati predefinita 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 garantiscono 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 decrittografia 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 colonne vengono criptate. BigQuery utilizza funzioni di crittografia e decrittografia AEAD che creano i keyset contenenti le chiavi per la crittografia e la decrittografia. Queste chiavi vengono poi utilizzate per criptare e decriptare i singoli valori in una tabella e per ruotare le chiavi all'interno di un keyset. 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 criptato.

Data Profiler per BigQuery con Sensitive Data Protection

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

Controlli di sicurezza per le origini dati interne

Le sezioni seguenti descrivono i controlli che si applicano all'importazione dei dati dalle origini Google Cloud .

Gestione delle chiavi e crittografia per l'importazione

Entrambe le opzioni di importazione (Cloud Storage o Pub/Sub) utilizzano Cloud HSM per gestire la CMEK. Utilizzi le chiavi CMEK per proteggere i tuoi dati durante l'importazione. La protezione dei dati sensibili protegge ulteriormente i tuoi dati criptando quelli riservati, utilizzando i rilevatori che configuri.

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

  • Una chiave CMEK per il processo di importazione utilizzata anche dalla pipeline Dataflow e dal servizio Pub/Sub.
  • La chiave di crittografia con wrapping di Cloud HSM per il processo di deidentificazione dei dati utilizzando Sensitive Data Protection.
  • Due chiavi CMEK, una per il warehouse BigQuery nel progetto di dati non riservati e l'altra per il warehouse nel progetto di dati riservati. Per saperne di più, consulta Gestione delle chiavi.

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

Se gli obblighi di conformità della tua organizzazione richiedono di gestire le tue chiavi esternamente a Google Cloud, puoi attivare Cloud EKM. Se utilizzi chiavi esterne, sei responsabile delle attività di gestione delle chiavi, inclusa rotazione della chiave.

Anonimizzazione dei dati

Utilizzi Sensitive Data Protection per anonimizzare i tuoi dati strutturati e non strutturati durante la fase di importazione. Per i dati strutturati, utilizzi le trasformazioni dei record in base ai campi per rimuovere l'identificazione dei dati. Per un esempio di questo approccio, consulta la cartella /examples/de_identification_template/. Questo esempio controlla i dati strutturati per rilevare eventuali numeri di carte di credito e PIN delle carte. Per i dati non strutturati, utilizzi i tipi di informazioni per deidentificare i dati.

Per rimuovere l'identificazione dei dati taggati come riservati, utilizza Sensitive Data Protection e una pipeline Dataflow per tokenizzarli. Questa pipeline acquisisce i dati da Cloud Storage, li elabora e poi li invia al data warehouse BigQuery.

Per ulteriori informazioni sulla procedura di anonimizzazione dei dati, consulta la governance dei dati.

Controlli di accesso a livello di colonna

Per proteggere i dati riservati, utilizzi i controlli dell'accesso per colonne specifiche nel data warehouse BigQuery. Per accedere ai dati in queste colonne, un analista dei dati deve disporre del ruolo Lettore granulare.

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

  • Un tag di criteri 3_Confidential per le colonne che includono informazioni molto sensibili, come i numeri di carte di credito. Gli utenti che hanno accesso a questo tag hanno accesso anche alle colonne contrassegnate con i tag di policy 2_Private o 1_Sensitive.
  • Un tag di criteri 2_Private per le colonne che includono informazioni personali sensibili che consentono l'identificazione personale (PII), ad esempio il nome di una persona. Gli utenti che hanno accesso a questo tag hanno accesso anche alle colonne taggate con iltag di criteriy 1_Sensitive. Gli utenti non hanno accesso alle colonne contrassegnate con iltag di criterio 3_Confidential.
  • Un tag di criteri 1_Sensitive per le colonne che includono dati che non possono essere resi pubblici, ad esempio ilmassimale di creditoo. Gli utenti che hanno accesso a questo tag non hanno accesso alle colonne contrassegnate con i tag di policy 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 reidentificazione dei dati, questi non possano essere letti finché l'accesso non viene concesso esplicitamente all'utente.

Nota: puoi utilizzare le definizioni predefinite per eseguire gli esempi. Per altre best practice, consulta Best practice per l'utilizzo dei tag di criteri in BigQuery.

Service account con ruoli limitati

Devi limitare l'accesso al progetto di dati riservati in modo che solo gli utenti autorizzati possano visualizzare i dati riservati. A questo scopo, crea un account di servizio con il ruolo Utente service account (roles/iam.serviceAccountUser) che gli utenti autorizzati devono simulare. L'impersonificazione del service account consente agli utenti di utilizzare i service account senza scaricare le chiavi del account di servizio, il che migliora la sicurezza complessiva del progetto. La rappresentazione crea un token a breve termine che gli utenti autorizzati con il ruolo Creatore token account di servizio (roles/iam.serviceAccountTokenCreator) possono scaricare.

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

Gestisci chiavi CMEK separate per i tuoi dati riservati in modo da poter reidentificare i dati. Utilizzi Cloud HSM per proteggere le tue chiavi. Per reidentificare i tuoi dati, utilizza le seguenti chiavi:

  • Una chiave CMEK utilizzata dalla pipeline Dataflow per il processo di reidentificazione.
  • La chiave crittografica originale utilizzata da Sensitive Data Protection per de-identificare i tuoi dati.
  • Una chiave CMEK per il warehouse BigQuery nel progetto di dati riservati.

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

Operazioni

Puoi attivare la registrazione e le funzionalità di Security Command Center Premium o Enterprise, come Security Health Analytics ed Event Threat Detection. Questi controlli ti aiutano a:

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

Access Transparency

Access Transparency ti invia una notifica in tempo reale quando il personale Google richiede 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 giustificazioni aziendali valide (ad esempio, una richiesta di assistenza) può ottenere l'accesso.

Logging

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

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

Avvisi e monitoraggio

Dopo aver implementato l'architettura, puoi configurare gli avvisi per comunicare al tuo Centro operativo di sicurezza 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, vedi Configurazione delle notifiche dei risultati. Per gli avvisi aggiuntivi non pubblicati da Security Command Center, puoi configurare avvisi con Cloud Monitoring.

Considerazioni aggiuntive sulla sicurezza

Oltre ai controlli di sicurezza descritti in questo documento, devi esaminare e gestire la sicurezza e i rischi nelle aree chiave che si sovrappongono e interagiscono con il tuo utilizzo di questa soluzione. Di seguito sono elencati alcuni esempi:

  • La sicurezza del codice che utilizzi per configurare, eseguire il deployment ed eseguire i job Dataflow e le funzioni Cloud Run.
  • La tassonomia di classificazione dei dati che utilizzi con questa soluzione.
  • Generazione e gestione delle chiavi di crittografia.
  • I contenuti, la qualità e la sicurezza dei set di dati che archivi e analizzi nel data warehouse.
  • L'ambiente complessivo in cui esegui il deployment della soluzione, tra cui:
    • La progettazione, la segmentazione e la sicurezza delle reti a cui ti connetti 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 questa infrastruttura.

Riepilogo

Per implementare l'architettura descritta in questo documento:

  1. Determina se vuoi eseguire il deployment dell'architettura con il blueprint delle fondamenta aziendali o separatamente. Se scegli di non eseguire il deployment del blueprint delle fondamenta dell'impresa, assicurati che il tuo ambiente disponga di una base di sicurezza simile.
  2. Per importare dati da origini esterne, configura una connessione Dedicated Interconnect con la tua rete.
  3. Esamina il terraform-google-secured-data-warehouse README o il terraform-google-secured-data-warehouse-onprem-ingest README e assicurati di soddisfare tutti i prerequisiti.

  4. Verifica che la tua identità utente disponga dei ruoli Utente del service account (roles/iam.serviceAccountUser) e Creatore token service account Creatore token service account (roles/iam.serviceAccountTokenCreator) per la cartella di sviluppo dell'organizzazione, come descritto nella sezione Struttura organizzativa. Se non disponi di una cartella che utilizzi 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. Per un elenco delle API che devi abilitare, consulta il file README.

  7. Crea il account di servizio per Terraform e assegna i ruoli appropriati per tutti i progetti.

  8. Configura il criterio di controllo dell'accesso.

  9. Per le origini dati Google Cloud che utilizzano il repositoryterraform-google-secured-data-warehouse, nell'ambiente di test, esegui il deployment della procedura dettagliata per vedere la soluzione in azione. Nell'ambito della procedura di test, tieni presente quanto segue:

    1. Aggiungi i tuoi dati di esempio al warehouse BigQuery.
    2. Collabora con un analista dei dati della tua azienda per verificare il suo accesso ai dati riservati e se può interagire con i dati di BigQuery nel modo previsto.

  10. Per le origini dati esterne che utilizzano il repository terraform-google-secured-data-warehouse-onprem-ingest, nell'ambiente di test, implementa la 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 keyset criptati con Tink.

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

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

  11. Per le origini dati esterne, verifica che gli utenti autorizzati possano leggere i dati non criptati da BigQuery utilizzando la funzione di decriptaggio BigQuery AEAD. Ad esempio, esegui la seguente funzione di creazione della decriptazione:

    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 SELECT dalla vista:

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

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

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

  13. Esegui il deployment dell'architettura nell'ambiente di produzione.

Passaggi successivi