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

Last reviewed 2023-08-15 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 è destinato ai data engineer e agli amministratori della sicurezza che implementano e proteggono data warehouse usando BigQuery. Fa parte di un progetto di sicurezza che include:

  • 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).

In questo documento vengono trattati i seguenti argomenti:

  • 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 di dati in BigQuery da un una rete esterna, ad esempio un ambiente on-premise.
  • Best practice per governance dei dati durante la creazione, il deployment e il funzionamento di un data warehouse Google Cloud, tra cui crittografia a livello di colonna, differenziale gestione dei dati riservati e controlli dell'accesso a livello di colonna.

Questo documento presuppone che tu abbia già configurato un set di base controlli di sicurezza come descritto Progetto delle basi aziendali di Google Cloud. Ti aiuta a integrare controlli aggiuntivi nei controlli di sicurezza esistenti. per 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 progetto devi:

  • Criptare i dati di origine che si trovano all'esterno di Google Cloud (ad esempio, in un ambiente on-premise) e importarlo in 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 controlli di sicurezza e logging adeguati per proteggere e la riservatezza dei dati.
  • 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 di data warehouse sicura per reti esterne.

L'architettura utilizza una combinazione dei seguenti Google Cloud di Google Cloud:

  • Interconnessione dedicata consente di spostare i dati tra la tua rete e Google Cloud. Puoi utilizzare la modalità un'altra opzione di connettività, come descritto in Scelta di un prodotto per la connettività di rete.

  • Identity and Access Management (IAM) e Resource Manager limitano l'accesso e segmentano le risorse. I controlli dell'accesso e le risorse della gerarchia seguono 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 ti aiuta a proteggere il resto 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 in cui sono archiviate le chiavi di crittografia definisce cosa sono considerati dati riservati.

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

  • Cloud Storage e Pub/Sub ricevono i dati nel seguente modo:

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

  • R Dataflow scrive i flussi di dati in BigQuery. Per proteggere i dati, Dataflow utilizza un account di servizio e controlli di accesso univoci. Per proteggere l'esecuzione della pipeline spostandola nel servizio di backend, Dataflow utilizza Motore di flussi di dati. Per ulteriori informazioni, consulta Autorizzazioni e sicurezza del flusso di dati.

  • Cloud Data Loss Prevention (Cloud DLP) scansiona i dati archiviati in BigQuery per trovare eventuali dati sensibili non protetti. Per ulteriori informazioni, vedi Utilizzo di Cloud DLP per la scansione dei dati di BigQuery.

  • Cloud HSM che 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 offre inoltre utilizza i metadati per gestire l'accesso ai dati riservati. Per ulteriori informazioni, vedi 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 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 le informazioni sulle prestazioni e le metriche relative 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

Devi raggruppare le risorse dell'organizzazione in modo da poterle gestire e separa gli 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 per diversi ambienti, come bootstrap, comune, di produzione, non di produzione (o gestione temporanea) e 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 del progetto nella cartella di produzione e il 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 progetto delle basi aziendali utilizzate progetto.

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 che dispongono di risorse cloud attualmente in fase di test e in fase di implementazione graduale per il rilascio. In questo progetto, La cartella non di produzione contiene il progetto di importazione dati e i dati progetto.
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 ulteriori informazioni, consulta Progetto delle basi aziendali di Google Cloud.

Progetti

Puoi isolare le parti dell'ambiente utilizzando i progetti. La tabella seguente descrive i progetti necessari all'interno dell'organizzazione. Sei tu a creare questi dei 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 e scrivere i dati in BigQuery.
Governance dei dati Contiene servizi che forniscono gestione delle chiavi, logging e dati di catalogazione.
Dati Contiene i servizi necessari per archiviare i dati.

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

Mappatura di ruoli e gruppi ai progetti

Devi concedere a diversi gruppi di utenti 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 ai 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 dell'assegnazione Ruoli
Progetto di importazione dati
Progetto dati
Livello delle norme relative ai dati Lettore mascherato (roles/bigquerydatapolicy.maskedReader)

Gruppo di visualizzatori di 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 di lettori in chiaro dispone dell'autorizzazione necessaria per chiamare la decrittografia funzione definita dall'utente per visualizzare dati di testo non crittografato e l'autorizzazione aggiuntiva per leggere dati non mascherati. Questo gruppo richiede ruoli nel progetto dati, come descritto nella tabella seguente.

Questo gruppo richiede i seguenti ruoli nel progetto 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 pipeline di dati e data warehouse. Questo gruppo richiede ruoli in progetti diversi, come descritto nella tabella seguente.

Ambito dell'assegnazione 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)
  • Visualizzatore Cloud KMS (roles/cloudkms.viewer)
  • Utente di rete Compute (roles/compute.networkuser)
  • Amministratore Dataflow (roles/dataflow.admin)
  • Amministratore DLP (roles/dlp.admin)
  • Visualizzatore log (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 di Cloud DLP.

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 sezione soluzione di data warehouse aziendale.

Flusso di accesso per il gruppo Visualizzatore di dati criptati

Il seguente diagramma mostra cosa succede quando un utente Gruppo di visualizzatori dei 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 dati criptati esegue la query seguente 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 VPC Service Controls.
    • IAM verifica che l'utente disponga dei ruoli appropriati e che con l'autorizzazione ad accedere alle colonne criptate selezionate in 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 succede quando un utente Gruppo di 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 non crittografato 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 funzione definita dall'utente recupera la chiave di crittografia dei dati con wrapping (DEK) che era utilizzati per proteggere le colonne di dati sensibili.

    La funzione definita dall'utente per la decrittografia chiama la chiave di crittografia della chiave (KEK) in Cloud HSM a decodifica 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 di testo non crittografato nei dati sensibili colonne.

Comprensione dei controlli di sicurezza necessari

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

  • Proteggi 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.
  • Classificare e proteggere i dati in base al loro livello di rischio.
  • Comprendere i requisiti di sicurezza per l'ambiente che ospita e il data warehouse.
  • Configura un monitoraggio e un logging sufficienti per il rilevamento l'indagine e la risposta.

Controlli di sicurezza per l'importazione dei 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 i dati da Google Cloud in un data warehouse BigQuery protetto.

Puoi utilizzare una delle seguenti opzioni per trasferire i tuoi dati nei dati warehouse su BigQuery:

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

Per proteggere i dati durante l'importazione, puoi usare la crittografia lato client, regole firewall e criteri relativi al livello di accesso. A volte il processo di importazione noto come processo ETL (Extract, Transform, Load).

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 firewall e di rete

Regole firewall Virtual Private Cloud (VPC) per controllare 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 file restricted.googleapis.com presenta i seguenti vantaggi:

  • Aiuta a ridurre la superficie di attacco di rete utilizzando 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, vedi Configurazione dell'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 in diagramma dell'architettura, posizioni 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:

  • Collegano il progetto di importazione dati al progetto dati in modo che i dati possono essere importati in BigQuery.
  • Collegano il progetto di dati al progetto di governance dei dati in modo che Cloud DLP può analizzare BigQuery per individuare elementi non protetti e la riservatezza dei dati.
  • Collegano il progetto di importazione dati al progetto di governance dei dati per accedere alle chiavi di logging, monitoraggio e crittografia.

Oltre ai bridge perimetrali, vengono utilizzati regole in uscita per consentire alle risorse protette dai perimetri di accedere alle risorse fuori dal perimetro. In questa soluzione, configuri le regole in uscita per ottenere i job esterni del modello flessibile Dataflow che si trovano in Cloud Storage in un progetto esterno. Per ulteriori informazioni, vedi Accedi a una risorsa Google Cloud all'esterno del perimetro.

Criterio di accesso

Garantire che solo identità specifiche (utente o servizio) possano accedere le risorse e i dati, abilita 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 ulteriori informazioni, vedi 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 in locale o da Cloud HSM. Per aggregare o proteggere la DEK, puoi utilizzare una KEK generata in per la risoluzione dei problemi di Google Cloud HSM. La KEK è un CMEK simmetrica set di chiavi di crittografia archiviato in modo sicuro in Cloud HSM e gestito utilizzando ruoli e autorizzazioni IAM.

Durante l'importazione, sia il DEK con wrapping sia i dati vengono archiviati in BigQuery. BigQuery include due tabelle: una i dati e l'altro per la DEK con wrapping. Quando gli analisti devono visualizzare i 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 mediante Tink protegge ulteriormente i tuoi dati criptando colonne di dati sensibili in BigQuery. Il progetto utilizza seguenti chiavi di crittografia Cloud HSM:

  • Una chiave CMEK per il processo di importazione, utilizzata anche Pub/Sub, pipeline Dataflow per i flussi di dati, caricamento in batch di Cloud Storage e artefatti delle funzioni di Cloud Run per caricamenti in blocco 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.

Devi specificare la località CMEK, che determina la posizione geografica 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, inclusa rotazione della chiave.

Account di servizio e controlli dell'accesso

Gli account di servizio sono identità che Google Cloud può utilizzare per eseguire le API richieste per tuo conto. Gli account di servizio assicurano che le identità utente hanno 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 i dati batch automatizzati di caricamento nel bucket di archiviazione di importazione.
  • L'account di servizio Pub/Sub consente di trasmettere flussi di dati e il servizio Pub/Sub.
  • L'account di servizio del controller Dataflow è utilizzato Pipeline Dataflow per trasformare e scrivere dati da Pub/Sub a BigQuery.
  • L'account di servizio funzioni Cloud Run scrive i dati batch successivi da Cloud Storage a BigQuery.
  • L'account di servizio Caricamento in archiviazione consente alla pipeline ETL di creare oggetti.
  • L'account di servizio di scrittura Pub/Sub consente alla pipeline ETL di scrivere in Pub/Sub.

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

Nome Ruoli Ambito dell'assegnazione
Service account del controller Dataflow Progetto di importazione dati
Progetto dati
Governance dei dati
Account di servizio Cloud Run Functions Progetto di importazione dati
  • Editor dati BigQuery (roles/bigquery.dataEditor)
  • Visualizzatore metadati BigQuery (roles/bigquery.metadataViewer)
 Progetto di dati
Service account di caricamento in Storage Progetto di importazione dati
Account di servizio di scrittura Pub/Sub 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
  • Account di servizio con ruoli limitati
  • Mascheramento dinamico dei dati dei campi sensibili
  • Criteri dell'organizzazione
  • Scansione automatica e profiler dei dati di Cloud DLP
  • Perimetri Controlli di servizio VPC tra il progetto di importazione dati e il progetto Data, con le opportune ponti perimetrali
  • 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 dinamico dei dati

Per facilitare la condivisione e l'applicazione dei criteri di accesso ai dati su larga scala, puoi configura mascheramento dinamico 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 criterio 1_Sensitive per le colonne che includono dati che non possono essere resi pubblici, come il limite 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 ai dati 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é crittografare un'intera tabella, seleziona le colonne che contengono di dati sensibili in BigQuery e solo queste colonne criptato. BigQuery utilizza Crittografia e decriptazione AEAD che creano 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 il controllo del doppio accesso sui dati criptati in BigQuery, l'utente deve disporre delle autorizzazioni sia per la tabella che per la chiave di crittografia per leggere i dati in chiaro.

Profiler dei dati per BigQuery con Cloud DLP

Profilo dei dati consente di identificare le posizioni dei dati sensibili e ad alto rischio e tabelle BigQuery. Data profiler scansiona e analizza automaticamente tutte le tabelle e le colonne BigQuery nell'intera organizzazione, incluse tutte le cartelle e i progetti. Il profiler dei dati genera quindi metriche come il valore previsto infoTypes, i livelli di rischio e sensibilità dei dati valutati e i metadati delle tabelle. Basandoti su queste informazioni, puoi prendere decisioni consapevoli su come proteggere, condividere e utilizzare i tuoi dati.

Account di servizio con ruoli limitati

Devi limitare l'accesso al progetto Dati in modo che solo gli utenti autorizzati possano visualizza 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 progetto include i vincoli dei criteri dell'organizzazione che l'azienda che utilizza e aggiunge vincoli aggiuntivi. Per ulteriori informazioni sui vincoli utilizzati dal progetto della piattaforma di base dell'azienda, consulta Vincoli dei criteri dell'organizzazione.

La tabella seguente descrive i criteri aggiuntivi dell'organizzazione vincoli definiti criteri-organizzazione in maggior dettaglio più avanti in questo modulo.

Norme Nome vincolo Valore consigliato
Limita i deployment delle risorse a specifiche fisiche sedi gcp.resourceLocations Uno dei seguenti:
in:us-locations
in:eu-locations
in:asia-locations
Richiedere la protezione CMEK gcp.restrictNonCmekServices bigquery.googleapis.com
Disabilita account di servizio creazione 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 forwarding a solo uso interno, in base all'IP indirizzo compute.restrictProtocolForwardingCreationForTypes INTERNAL
Disabilitare il logging degli output delle porte seriali 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 di la subnet privata che deve essere utilizzata dal progetto.

Controlli operativi

Puoi abilitare il logging e 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 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

Trasparenza degli accessi ti fornisce una notifica in tempo reale Personale dell'Assistenza Google richiedono l'accesso ai dati. I log di Access Transparency vengono generati ogni volta che un essere umano accede ai contenuti e solo il personale Google con giustificazioni aziendali valide (ad esempio, una richiesta di assistenza) può ottenere l'accesso. Ti consigliamo di abilita 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. La modulo harness-logging configura le seguenti best practice:

Per tutti i servizi all'interno dei progetti, i log devono includere informazioni letture e scritture di dati e informazioni su ciò che leggono gli amministratori. Per altre best practice sul logging, consulta Controlli di rilevamento nel blueprint Enterprise Foundations.

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. Per Ad esempio, puoi utilizzare gli avvisi per comunicare al tuo analista della sicurezza quando è 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, esaminare e gestire la sicurezza e i rischi nelle aree chiave che si sovrappongono e interagiscono all'uso di questa soluzione. Queste considerazioni sulla sicurezza includono seguenti:

  • La sicurezza del codice che utilizzi per configurare, eseguire il deployment e Job Dataflow e funzioni Cloud Run.
  • La tassonomia di classificazione dei dati utilizzata con questa soluzione.
  • Generazione e gestione delle chiavi di crittografia.
  • Il contenuto, la qualità e la sicurezza dei set di dati archiviati per l'analisi 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 connettersi 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 eseguirai il deployment del progetto con l'azienda progetti di base o da soli. Se scegli di non eseguire il deployment del modello di base aziendale, assicurati che il tuo ambiente abbia un modello una base di riferimento per la sicurezza.
  2. Imposta un Connessione Dedicated Interconnect con la tua rete.
  3. Esamina il file README per il progetto e assicurati di soddisfare tutte le e i prerequisiti necessari.
  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 che devi attivare, consulta il file README.
  7. Crea l'account di servizio per Terraform e assegna l'appropriata ruoli 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. Installare 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. Generare set 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 questa funzione di decrittografia per creare:

    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 per la 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 selezionata dalla vista:

    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