Importa 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, per analizzarli per vari scopi aziendali. Questo documento è rivolto ai data engineer e agli amministratori della sicurezza che eseguono il deployment e proteggono i data warehouse utilizzando BigQuery. Fa parte di un progetto di sicurezza che include quanto segue:

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

Questo documento tratta i seguenti argomenti:

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

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

Casi d'uso di data warehouse

Il progetto supporta i seguenti casi d'uso:

Panoramica

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

  • Cripta i dati di origine che si trovano all'esterno 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 dei dati.
  • Configura una separazione appropriata dei compiti per i diversi utenti tipo.
  • Configurare log e controlli di sicurezza appropriati per proteggere i dati riservati.
  • Utilizza classificazione dei dati, tag di criteri, mascheramento dinamico dei dati e crittografia a livello di colonna per limitare l'accesso a colonne specifiche nel datawarehouse.

Architettura

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

L'architettura di data warehouse sicuro per le reti esterne.

L'architettura utilizza una combinazione dei seguenti servizi e funzionalità 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 per la 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 seguono il principio del privilegio minimo.

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

    • Un perimetro di importazione dati che accetta i dati in entrata (in modalità batch o flussi). Un perimetro separato aiuta 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 i dati riservati.

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

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

  • Cloud Functions viene attivato da Cloud Storage e scrive in BigQuery i dati caricati da Cloud Storage nel bucket di importazione.

  • Una pipeline Dataflow scrive i flussi di dati in BigQuery. Per proteggere i dati, Dataflow utilizza un account di servizio e controlli dell'accesso univoci. Per proteggere l'esecuzione della pipeline spostandola nel servizio di backend, Dataflow utilizza Streaming Engine. Per ulteriori informazioni, consulta Sicurezza e autorizzazioni di Dataflow.

  • Cloud Data Loss Prevention (Cloud DLP) esegue la scansione dei dati archiviati in BigQuery per individuare dati sensibili non protetti. Per maggiori informazioni, consulta Utilizzare Cloud DLP per eseguire la scansione dei dati di BigQuery.

  • Cloud HSM ospita la chiave di crittografia della chiave (KEK). Cloud HSM è un servizio HSM (Hardware Security Module) basato su cloud. Puoi utilizzare Cloud HSM per generare la chiave di crittografia da utilizzare per criptare i dati nella rete prima di inviarli a Google Cloud.

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

  • BigQuery archivia i dati 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 dell'accesso, crittografia a livello di colonna, sicurezza a livello di colonna e crittografia dei dati.

  • Security Command Center monitora ed esamina i risultati sulla sicurezza dell'intero ambiente Google Cloud da una posizione centralizzata.

  • 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 raccoglie e archivia informazioni e metriche sulle prestazioni dei servizi Google Cloud.

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

Struttura organizzativa

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.

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

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

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

Cartelle

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

Cartella Descrizione
Bootstrap Contiene le risorse necessarie per il deployment del progetto di base aziendale.
Comune Contiene servizi centralizzati per l'organizzazione, ad esempio il progetto di governance dei dati.
Produzione Contiene progetti con risorse cloud testate e pronte per l'uso. La cartella Produzione in questo progetto contiene il progetto di importazione dati e il progetto dati.
Non di produzione Contiene progetti con risorse cloud attualmente in fase di test e implementazione graduale. In questo progetto, la cartella Non di produzione contiene il progetto di importazione dati e il progetto Dati.
Sviluppo Contiene progetti con risorse cloud in fase di sviluppo. La cartella Sviluppo in questo progetto contiene il progetto di importazione dati e il progetto dati.

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

Progetti

Puoi isolare parti del tuo ambiente utilizzando i progetti. La seguente tabella descrive i progetti necessari all'interno dell'organizzazione. Puoi creare 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 offrono funzionalità di gestione delle chiavi, logging e catalogazione dei dati.
Dati Contiene i servizi necessari per archiviare i dati.

Oltre a questi progetti, il tuo ambiente deve includere anche un progetto che ospita un job Dataflow Modello flessibile. Il job del modello flessibile è obbligatorio per la pipeline dei dati in modalità flusso.

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 riservato. Le seguenti sezioni descrivono i suggerimenti per il progetto per i gruppi di utenti e le assegnazioni dei 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 simile dei compiti e dell'assegnazione dei ruoli.

Gruppo di analisti di dati

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

Ambito dell'assegnazione Ruoli
Progetto di importazione dati
Progetto dati
Livello dei criteri relativi ai dati Lettore mascherato (roles/bigquerydatapolicy.maskedReader)

Gruppo di visualizzatori dei dati criptati

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

Questo gruppo richiede il ruolo Utente BigQuery (roles/bigquery.jobUser) nel progetto di dati. Questo gruppo richiede anche il lettore mascherato (roles/bigquerydatapolicy.maskedReader) a livello di criterio relativo ai dati.

Gruppo di lettori di testo in chiaro

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

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 la pipeline di dati e il warehouse. Questo gruppo richiede ruoli in diversi progetti, come descritto nella tabella seguente.

Ambito dell'assegnazione Ruoli
Progetto di importazione dati
Progetto dati
  • Editor 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. Di solito sono membri del team di networking.

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

  • Amministratore Compute (roles/compute.networkAdmin)
  • Visualizzatore log (roles/logging.viewer)

Gruppo di amministratori della sicurezza

Gli amministratori della sicurezza amministrano i controlli di sicurezza quali 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 Cloud DLP.

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

Esempi di flussi di accesso al gruppo

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

Flusso di accesso per il gruppo di visualizzatori dei dati criptati

Il seguente diagramma mostra cosa succede quando un utente del gruppo di visualizzatori dei dati criptati prova ad accedere ai dati criptati in BigQuery.

Il flusso per il gruppo di visualizzatori dei dati criptati.

Per accedere ai dati in BigQuery, segui questi passaggi:

  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 è stato autenticato utilizzando credenziali Google Cloud valide e non scadute.
    • L'identità utente e l'indirizzo IP da cui ha avuto origine la richiesta fanno parte della lista consentita della regola Livello di accesso/in entrata nel perimetro dei 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 lettori di testo normale

Il seguente diagramma mostra cosa succede quando un utente del gruppo di lettori plaintext prova ad accedere a dati criptati in BigQuery.

Il flusso per il gruppo di lettori di testo non crittografato.

Per accedere ai dati in BigQuery, segui questi passaggi:

  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 di decrittografia definita dall'utente (UDF) all'interno della query per accedere alle colonne protette.

  3. L'accesso viene verificato come segue:

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

    La funzione definita dall'utente di decriptazione chiama la chiave di crittografia della chiave (KEK) in Cloud HSM per annullare il wrapping della DEK. La funzione di decrittografia della funzione definita dall'utente 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 non crittografato nelle colonne di dati sensibili.

Comprendere i controlli di sicurezza necessari

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

  • Proteggi l'accesso adottando i principi del privilegio minimo.
  • Proteggere le connessioni di rete attraverso la progettazione e i criteri di segmentazione.
  • Proteggi la configurazione per ciascuno dei servizi.
  • Classifica e proteggi i dati in base al loro livello di rischio.
  • Comprendere i requisiti di sicurezza per l'ambiente che ospita il data warehouse.
  • Configura monitoraggio e 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, da un altro cloud o da un'altra origine Google Cloud. Questo documento è incentrato sul trasferimento dei dati dal tuo ambiente on-premise o da un altro cloud; se stai trasferendo i dati da un'altra origine Google Cloud, consulta Importare dati da Google Cloud in un data warehouse BigQuery.

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

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

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

Connessione criptata a Google Cloud

Puoi utilizzare Cloud VPN o Cloud Interconnect per proteggere tutti i dati in transito tra Google Cloud e il tuo ambiente. Questo progetto consiglia Dedicated Interconnect, perché fornisce una connessione diretta e una velocità effettiva elevata, un aspetto importante se trasmetti molti dati in modalità flusso.

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

Regole di rete e firewall

Le regole firewall virtual private cloud (VPC) controllano il flusso di dati nei perimetri. Puoi creare regole firewall che negano tutto il traffico in uscita, ad eccezione di connessioni specifiche sulla 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 di rete utilizzando l'accesso privato Google quando i carichi di lavoro comunicano con le API e i servizi Google.
  • Garantisce di utilizzare solo servizi che supportano i Controlli di servizio VPC.

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

La pipeline dei dati richiede l'apertura delle porte TCP nel firewall, come definito nel file dataflow_firewall.tf nel repository del modulo Harness-projects. Per maggiori informazioni, consulta Configurazione dell'accesso a internet e delle regole del 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 per negare tutti.

Controlli del perimetro

Come mostrato nel diagramma dell'architettura, le risorse per il data warehouse vengono disposte in perimetri separati. Per consentire ai servizi in perimetri diversi di condividere dati, devi creare bridge di perimetro.

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

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

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

Criterio di accesso

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

Per garantire che solo origini specifiche possano accedere ai progetti, abilita 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 provenienti dal tuo ambiente on-premise e consenta solo le richieste provenienti da utenti o account di servizio specifici. Per maggiori informazioni, consulta la sezione Attributi dei livelli di accesso.

Crittografia lato client

Prima di spostare i tuoi dati sensibili in Google Cloud, criptali in locale per proteggerli quando sono inattivi e in transito. Puoi usare la libreria di crittografia Tink o altre librerie di crittografia. La libreria di crittografia Tink è compatibile con la crittografia AEAD di BigQuery, utilizzata dal progetto base per decriptare i dati criptati a livello di colonna dopo l'importazione dei dati.

La libreria di crittografia Tink utilizza le DEK che puoi generare in locale 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 simmetrica CMEK archiviato in modo sicuro in Cloud HSM e gestito utilizzando ruoli e autorizzazioni IAM.

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

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

  • Una chiave CMEK per il processo di importazione utilizzata anche da Pub/Sub, pipeline Dataflow per i flussi, caricamento batch di Cloud Storage e artefatti di Cloud Functions per i caricamenti batch successivi.
  • La chiave di crittografia sottoposta a wrapping da Cloud HSM per i dati criptati sulla rete tramite Tink.
  • Chiave CMEK per il warehouse BigQuery nel progetto dati.

Devi specificare la località CMEK, che determina la posizione geografica in cui viene archiviata la chiave e viene resa disponibile per l'accesso. Devi assicurarti che la tua 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 la gestione delle tue chiavi esternamente da Google Cloud, puoi abilitare Cloud External Key Manager. Se utilizzi chiavi esterne, sei responsabile delle attività di gestione delle chiavi, inclusa rotazione della chiave.

Account di servizio e controlli dell'accesso

Gli account di servizio sono identità che Google Cloud può utilizzare per eseguire richieste API per tuo conto. Gli account di servizio assicurano che le identità utente non abbiano accesso diretto ai servizi. Per separare i compiti, crei account di servizio con ruoli diversi per scopi specifici. Questi account di 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 automatizzato di caricamento dei dati in batch nel bucket di archiviazione per l'importazione.
  • L'account di servizio Pub/Sub consente il flusso di dati nel 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 Cloud Functions scrive i dati batch successivi caricati da Cloud Storage in BigQuery.
  • L'account di servizio Storage Upload consente alla pipeline ETL di creare oggetti.
  • L'account di servizio di scrittura Pub/Sub consente alla pipeline ETL di scrivere dati in Pub/Sub.

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

Nome Ruoli Ambito dell'assegnazione
Account di servizio del controller Dataflow Progetto di importazione dati
Progetto dati
Governance dei dati
Account di servizio Cloud Functions Progetto di importazione dati
  • Editor dati BigQuery (roles/bigquery.dataEditor)
  • Visualizzatore metadati BigQuery (roles/bigquery.metadataViewer)
 Progetto dati
Account di servizio Storage Upload Progetto di importazione dati
Account di servizio in scrittura Pub/Sub Progetto di importazione dati

Controlli di sicurezza per l'archiviazione dei dati

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

  • Controlli dell'accesso a livello di colonna
  • Account di servizio con ruoli limitati
  • Mascheramento dinamico dei dati dei campi sensibili
  • Criteri dell'organizzazione
  • Analisi automatica e profiler dati di Cloud DLP
  • Perimetri di Controlli di servizio VPC tra il progetto di importazione dati e il progetto dati, con i bridge perimetri appropriati
  • Crittografia e gestione delle chiavi, come segue:
    • Crittografia at-rest con chiavi CMEK archiviate in Cloud HSM
    • Crittografia a livello di colonna con Tink e BigQuery AEAD Encryption

Mascheramento dei dati dinamici

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

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

Per definire l'accesso per le 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, come il massimale di credito. A queste colonne viene applicata la regola predefinita di mascheramento dei dati per nascondere il valore della colonna.

Tutti i contenuti senza tag sono disponibili per tutti gli utenti che hanno accesso al data warehouse. Questi controlli di accesso assicurano che, anche dopo aver scritto i dati in BigQuery, i dati nei campi sensibili non possano essere letti finché non viene concesso esplicitamente l'accesso all'utente.

Crittografia e decrittografia a livello di colonna

La crittografia a livello di colonna consente di criptare i dati in BigQuery a un livello più granulare. Anziché criptare un'intera tabella, selezioni le colonne che contengono dati sensibili all'interno di BigQuery e solo quelle colonne sono criptate. BigQuery utilizza funzioni di crittografia e decriptazione AEAD che creano i set di chiavi contenenti le chiavi per la crittografia e la decriptazione. Queste chiavi vengono quindi utilizzate per criptare e decriptare i singoli valori in una tabella e ruotare le chiavi all'interno di un set di chiavi. La crittografia a livello di colonna offre il controllo a doppio accesso ai dati criptati in BigQuery, in quanto l'utente deve disporre delle autorizzazioni sia per la tabella sia per la chiave di crittografia per poter leggere i dati in testo in chiaro.

Profiler dei dati per BigQuery con Cloud DLP

Profilor dati consente di identificare le posizioni dei dati sensibili e ad alto rischio nelle tabelle BigQuery. La Profiler dati analizza e analizza automaticamente tutte le tabelle e le colonne BigQuery in tutta l'organizzazione, incluse tutte le cartelle e i progetti. Profiler dati restituisce quindi metriche come gli infoTypes previsti, i livelli di rischio e sensibilità dei dati valutati e i metadati delle tabelle. Utilizzando questi insight, 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 di dati in modo che solo gli utenti autorizzati possano visualizzare i campi dei dati sensibili. Per farlo, crea un account di servizio con il ruolo roles/iam.serviceAccountUser che deve essere rappresentato dagli utenti autorizzati. Il furto d'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. Il furto d'identità crea un token a breve termine che gli utenti autorizzati con il ruolo roles/iam.serviceAccountTokenCreator possono scaricare.

Criteri dell'organizzazione

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

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

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

Sostituisci SUBNETWORK-NAME con l'ID risorsa della subnet privata che vuoi utilizzare per il progetto base.

Controlli operativi

Puoi abilitare il logging e le funzionalità di 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 vengano eseguiti controlli corretti.
  • Genera risultati per risorse cloud configurate in modo errato.
  • Supporta la capacità dei tuoi team operativi e di gestione degli incidenti di rispondere a problemi che potrebbero verificarsi.

Access Transparency

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

Logging

Per soddisfare i requisiti di controllo e ottenere insight sui tuoi progetti, devi configurare l'osservabilità di Google Cloud con i log di 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 operazioni di lettura e scrittura dei dati, nonché informazioni su ciò che gli amministratori leggono. Per ulteriori best practice di logging, consulta Controlli di rilevamento nel progetto di base della piattaforma aziendale.

Avvisi e monitoraggio

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

Ulteriori considerazioni sulla sicurezza

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

  • La sicurezza del codice che utilizzi per configurare, sottoporre a deployment ed eseguire job Dataflow e Cloud Functions.
  • La tassonomia di classificazione dei dati che utilizzi con questa soluzione.
  • Generazione e gestione delle chiavi di crittografia.
  • Contenuti, qualità e sicurezza dei set di dati che archivi e analizzi nel data warehouse.
  • L'ambiente generale in cui esegui il deployment della soluzione, incluso quanto segue:
    • La progettazione, la segmentazione e la sicurezza delle reti che si connettono a questa soluzione.
    • Sicurezza e governance dei controlli IAM della tua organizzazione.
    • Le impostazioni di autenticazione e autorizzazione per gli autori a cui concedi l'accesso all'infrastruttura che fa parte di questa soluzione e che hanno accesso ai dati archiviati e gestiti in tale infrastruttura.

Riepilogo

Per implementare l'architettura descritta in questo documento:

  1. Determina se eseguirai il deployment del progetto base con il progetto di base dell'azienda o da solo. Se scegli di non eseguire il deployment del progetto di base per la piattaforma aziendale, assicurati che per il tuo ambiente sia attiva una base di sicurezza simile.
  2. Configura una connessione Dedicated Interconnect con la tua rete.
  3. Esamina il file README per il progetto base e assicurati di soddisfare tutti i prerequisiti.
  4. Verifica che l'identità utente disponga dei ruoli iam.serviceAccountUser e iam.serviceAccountTokenCreator per la cartella di sviluppo dell'organizzazione, come descritto in Struttura organizzativa. Se non disponi di una cartella che utilizzi per i test, crea una cartella e configura l'accesso.
  5. Registra l'ID account di fatturazione, il nome visualizzato dell'organizzazione, l'ID cartella per la cartella di test o demo e gli indirizzi email dei seguenti gruppi di utenti:
    • Analisti di dati
    • Visualizzatore dati criptati
    • Lettore di testo in chiaro
    • Data engineer
    • Amministratori rete
    • Amministratori sicurezza
    • Analisti sicurezza
  6. Crea i progetti per dati, governance dei dati, importazione dati e modello flessibile. Per un elenco delle API che devi attivare, vedi il file README.
  7. Creare l'account di servizio per Terraform e assegnare 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 set di chiavi criptati con Tink.

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

    7. Carica i dati criptati in BigQuery tramite caricamenti in modalità flusso o batch.

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

    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 visualizzazione:

    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 ulteriori query e casi d'uso, consulta Crittografia a livello di colonna con Cloud KMS.

  11. Utilizza Security Command Center per analizzare i progetti appena creati in base ai tuoi requisiti di conformità.

  12. Esegui il deployment del progetto base nell'ambiente di produzione.

Passaggi successivi