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 commerciali. Questo documento è rivolto ai data engineer e agli amministratori della sicurezza che eseguono il deployment e la protezione dei data warehouse utilizzando BigQuery. Fa parte di un blueprint costituito da quanto segue:

• Due repository GitHub (terraform-google-secured-data-warehouse e terraform-google-secured-data-warehouse-onprem-ingest) che contengono configurazioni e script Terraform. La configurazione Terraform configura 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 di questo blueprint (questo documento).
• Un percorso guidato che esegue il deployment di un ambiente di esempio.

Questo documento illustra quanto segue:

• L'architettura e i Google Cloud servizi che puoi utilizzare per contribuire a proteggere un data warehouse in un ambiente di produzione.
• Best practice per l'importazione dei dati in BigQuery da una rete esterna, ad esempio un ambiente on-premise.

• Best practice per la governance dei dati durante la creazione, il deployment e il funzionamento di un data warehouse inGoogle Cloud, tra cui:

  • Anonimazzione dei dati

  • 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 controlli di sicurezza di base come descritto nel blueprint delle basi aziendali. Ti aiuta a applicare controlli aggiuntivi a quelli di sicurezza esistenti per contribuire a proteggere i dati riservati in un data warehouse.

Casi d'uso dei data warehouse

Il blueprint supporta i seguenti casi d'uso:

• Utilizza il repository terraform-google-secured-data-warehouse per importare i dati da Google Cloud in un data warehouse BigQuery
• Utilizza il repository terraform-google-secured-data-warehouse-onprem-ingest per importare i dati da un ambiente on-premise o da un altro cloud in un data warehouse BigQuery

Panoramica

I data warehouse come BigQuery consentono alle aziende di analizzarne i dati per ottenere informazioni. Gli analisti accedono ai dati aziendali memorizzati 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 mentre sono archiviati, in transito o durante l'analisi. In questo blueprint, esegui le seguenti operazioni:

• 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 delle responsabilità appropriata per diversi profili.
• Quando importi dati da altre origini situate in Google Cloud (chiamate anche origini dati interne), configura i modelli per trovare e anonimizzare i dati riservati.
• Configura controlli di sicurezza e log appropriati per proteggere i dati riservati.
• Utilizza la classificazione dei dati, i tag di criteri, la mascheratura dei dati dinamici 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.

Architettura durante l'importazione dei dati da Google Cloud

L'immagine seguente mostra come i dati importati vengono classificati, anonimizzati e memorizzati quando importi i dati di origine da Google Cloud utilizzando il repositoryterraform-google-secured-data-warehouse. Inoltre, mostra come puoi identificare nuovamente i dati riservati su richiesta per l'analisi.

Architettura per l'importazione di dati da origini esterne

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

Google Cloud servizi e funzionalità

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

Servizio o funzionalità	Descrizione
BigQuery	Applicabile sia alle origini dati interne che a quelle esterne. Tuttavia, esistono diverse opzioni di archiviazione, come segue: Quando importi i dati da Google Cloud, BigQuery archivia i dati riservati nel perimetro dei dati riservati. Quando importi i dati da un'origine esterna, 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, 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 origini interne che a quelle esterne. Tuttavia, esiste un altro caso d'uso per le origini dati esterne. Cloud HSM è un servizio per modulo di sicurezza hardware (HSM) basato su 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 origini interne che a quelle esterne. Cloud Logging raccoglie tutti i log dei Google Cloud servizi per l'archiviazione e il recupero da parte degli strumenti di analisi e indagine.
Cloud Monitoring	Applicabile sia alle fonti interne sia a quelle esterne. Cloud Monitoring raccoglie e archivia informazioni sul rendimento e metriche relative ai Google Cloud servizi.
Cloud Run Functions	Applicabile solo per le origini dati esterne. Le funzioni Cloud Run vengono attivate da Cloud Storage e scrivono in BigQuery i dati caricati da Cloud Storage nel bucket di importazione.
Cloud Storage e Pub/Sub	Applicabile sia alle fonti interne sia a quelle 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, consulta 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 di criteri. Per ulteriori informazioni sui controlli di accesso supportati, consulta Panoramica del controllo dell'accesso. Pub/Sub: riceve e archivia i dati in streaming prima della spersonalizzazione. Pub/Sub utilizza autenticazione, controlli di accesso e crittografia a livello di messaggio con una chiave CMEK per proteggere i tuoi dati.
Data Profiler per BigQuery	Applicabile sia alle origini interne che a quelle esterne. Data Profiler per BigQuery esegue automaticamente la ricerca di dati sensibili in tutte le tabelle e le colonne di BigQuery nell'intera organizzazione, incluse tutte le cartelle e tutti i progetti.
Pipeline Dataflow	Applicabile sia alle origini interne che a quelle esterne; tuttavia, esistono diverse pipeline. Le pipeline Dataflow importano i dati come segue: Quando importi i dati da Google Cloud, due pipeline Dataflow anonimizzano e identificano nuovamente i dati riservati. La prima pipeline rimuove l'identificazione dei dati riservati utilizzando la pseudonimizzazione. La seconda pipeline identifica di nuovo i dati riservati quando gli utenti autorizzati necessitano di accedere. Quando importi i dati da un'origine esterna, una pipeline Dataflow scrive i dati in streaming in BigQuery.
Catalogo universale Dataplex	Applicabile sia alle fonti interne sia a quelle esterne. Il Catalogo universale Dataplex classifica automaticamente i dati riservati con i metadati, noti anche come tag di criteri, 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 per le 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 Scegliere un prodotto per la connettività di rete.
IAM e Resource Manager	Applicabile sia alle fonti interne sia a quelle 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 rispettano il principio del privilegio minimo.
Security Command Center	Applicabile sia alle origini interne che a quelle esterne. Security Command Center monitora ed esamina i risultati di sicurezza di tutto il tuo Google Cloud ambiente in un'unica posizione.
Sensitive Data Protection	Applicabile sia alle origini interne che a quelle esterne, ma vengono eseguite scansioni diverse. Sensitive Data Protection analizza i dati come segue: Quando importi i 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 i dati da un'origine esterna, la funzionalità Protezione dei dati sensibili esegue la scansione dei dati archiviati in BigQuery per trovare eventuali dati sensibili non protetti. Per maggiori informazioni, consulta Utilizzare Sensitive Data Protection per eseguire la scansione dei dati di BigQuery.
Controlli di servizio VPC	Applicabile sia alle origini interne che a quelle esterne; tuttavia, esistono diversi perimetri. 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 sicuri. I perimetri sono i seguenti: Un perimetro di importazione dati accetta i dati in entrata (in batch o in flusso) e li anonimizza. Una landing zone separata aiuta a proteggere il resto dei carichi di lavoro dai dati in entrata. Quando importi i dati da Google Cloud, un perimetro dei 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 cosa viene considerato dato riservato. Questi perimetri sono progettati per proteggere i contenuti in entrata, isolare i dati riservati impostando controlli e monitoraggio dell'accesso aggiuntivi e separare la governance dai dati effettivi nel data warehouse. La governance include la gestione delle chiavi, la gestione del catalogo di dati e il logging.

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 le risorse in modo logico per progetto, cartella e organizzazione.

I seguenti diagrammi mostrano una gerarchia di risorse con cartelle che rappresentano diversi ambienti, come bootstrap, comuni, di produzione, non di produzione (o di staging) e di sviluppo. Esegui il deployment della maggior parte dei progetti nell'architettura nella cartella di produzione e 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 quando importi i dati da Google Cloud utilizzando il repository terraform-google-secured-data-warehouse.

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

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

Cartelle

Utilizzi le cartelle per isolare l'ambiente di produzione e i servizi di governance dagli ambienti di test e non di produzione. La tabella seguente descrive le cartelle del blueprint delle basi dell'azienda utilizzate da questa architettura.

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 questa architettura, la cartella Produzione contiene il progetto di importazione dei dati e i progetti relativi ai dati.
Non di produzione	Contiene progetti con risorse cloud in fase di test e di organizzazione per il rilascio. In questa architettura, la cartella Non di produzione contiene il progetto di importazione dei dati e i progetti relativi ai dati.
Sviluppo	Contiene progetti con risorse cloud in fase di sviluppo. In questa architettura, la cartella Sviluppo 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 blueprint della piattaforma di base per le aziende.

Progetti

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

Progetto	Descrizione
Importazione dati	Progetto comune per origini sia interne che esterne. Contiene servizi necessari per ricevere dati e anonimizzare i dati confidentiali.
Governance dei dati	Progetto comune per origini sia interne che esterne. Contiene servizi che forniscono funzionalità di gestione delle chiavi, di registrazione e di catalogazione dei dati.
Dati non riservati	Progetto solo per fonti interne. Contiene i servizi obbligatori per archiviare i dati anonimizzati.
Dati riservati	Progetto solo per fonti interne. Contiene i servizi necessari per archiviare e identificare nuovamente i dati riservati.
Dati	Progetta solo per le sorgenti esterne. Contiene i servizi necessari per archiviare i dati.

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

Gruppo di analisti di dati

Gli analisti di dati analizzano i dati nel data warehouse. Nel repositoryterraform-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 di 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 dei progetti	Ruoli
Importazione dati	Sviluppatore Dataflow (roles/dataflow.developer) Visualizzatore di Dataflow (roles/dataflow.viewer) Log Visualizzatore (roles/logging.viewer) Ruolo aggiuntivo per gli analisti dei dati che richiedono l'accesso a dati riservati: Lettore dettagliato (roles/datacatalog.categoryFineGrainedReader)
Dati riservati	Visualizzatore dei dati BigQuery (roles/bigquery.dataViewer) Utente dell'attività BigQuery (roles/bigquery.jobUser) Utente BigQuery (roles/bigquery.user) Sviluppatore Dataflow (roles/dataflow.developer) Visualizzatore di Dataflow (roles/dataflow.viewer) Log Visualizzatore (roles/logging.viewer)
Dati non riservati	Visualizzatore dei dati BigQuery (roles/bigquery.dataViewer) Utente dell'attività BigQuery (roles/bigquery.jobUser) Utente BigQuery (roles/bigquery.user) Log Visualizzatore (roles/logging.viewer)

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 del compito	Ruoli
Progetto di importazione dati	Sviluppatore Dataflow (roles/dataflow.developer) Visualizzatore di Dataflow (roles/dataflow.viewer) Log Visualizzatore (roles/logging.viewer)
Progetto di dati	Visualizzatore dei dati BigQuery (roles/bigquery.dataViewer) Utente dell'attività BigQuery (roles/bigquery.jobUser) Utente BigQuery (roles/bigquery.user) Sviluppatore Dataflow (roles/dataflow.developer) Visualizzatore di Dataflow (roles/dataflow.viewer) Amministratore DLP (roles/dlp.admin) Log Visualizzatore (roles/logging.viewer)
Livello delle norme sui dati	Lettore con testo nascosto (roles/bigquerydatapolicy.maskedReader)

Gruppo di visualizzatori dei dati criptati (solo origini esterne)

Il gruppo Visualizzatore di dati criptati nel repository terraform-google-secured-data-warehouse-onprem-ingest può visualizzare i dati criptati delle tabelle di generazione di report di BigQuery tramite 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 norme relative ai dati.

Gruppo di lettori di testo non criptato (solo fonti esterne)

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

Questo gruppo richiede i seguenti ruoli nel progetto di dati:

• Utente BigQuery (roles/bigquery.user)
• Utente BigQuery (roles/bigquery.jobUser)
• Cloud KMS Viewer (roles/cloudkms.viewer)

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 e il data warehouse.

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

Punteggio del compito	Ruoli
Progetto di importazione dati	Editor Cloud Build (roles/cloudbuild.builds.editor) Cloud KMS Viewer (roles/cloudkms.viewer) Composer User (roles/composer.user) Utente della rete Compute (roles/compute.networkUser) Dataflow Admin (roles/dataflow.admin) Log Visualizzatore (roles/logging.viewer)
Progetto di dati riservati	Editor di dati BigQuery (roles/bigquery.dataEditor) Utente dell'attività BigQuery (roles/bigquery.jobUser) Editor Cloud Build (roles/cloudbuild.builds.editor) Cloud KMS Viewer (roles/cloudkms.viewer) Utente della rete Compute (roles/compute.networkUser) Dataflow Admin (roles/dataflow.admin) Log Visualizzatore (roles/logging.viewer)
Progetto di dati non riservati	Editor di dati BigQuery (roles/bigquery.dataEditor) Utente dell'attività BigQuery (roles/bigquery.jobUser) Cloud KMS Viewer (roles/cloudkms.viewer) Log Visualizzatore (roles/logging.viewer)

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

Ambito del compito	Ruoli
Progetto di importazione dati	Editor Cloud Build (roles/cloudbuild.builds.editor) Cloud KMS Viewer (roles/cloudkms.viewer) Composer User (roles/composer.user) Utente della rete Compute (roles/compute.networkUser) Dataflow Admin (roles/dataflow.admin) Log Visualizzatore (roles/logging.viewer)
Progetto di dati	Editor di dati BigQuery (roles/bigquery.dataEditor) Utente dell'attività BigQuery (roles/bigquery.jobUser) Editor Cloud Build (roles/cloudbuild.builds.editor) Cloud KMS Viewer (roles/cloudkms.viewer) Utente della rete Compute (roles/compute.networkUser) Dataflow Admin (roles/dataflow.admin) Amministratore DLP (roles/dlp.admin) Log Visualizzatore (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 di Compute (roles/compute.networkAdmin)
• Visualizzatore log (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 Security Command Center.

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

• Amministratore (roles/accesscontextmanager.policyAdmin) del Gestore contesto accesso
• Cloud Asset Viewer (roles/cloudasset.viewer)
• Amministratore Cloud KMS (roles/cloudkms.admin)
• Amministratore della sicurezza di Compute (roles/compute.securityAdmin)
• Amministratore del catalogo di dati (roles/datacatalog.admin)
• Amministratore DLP (roles/dlp.admin)
• Amministratore dei log (roles/logging.admin)
• Amministratore dell'organizzazione (roles/orgpolicy.policyAdmin)
• Amministratore della sicurezza (roles/iam.securityAdmin)

Gruppo di analisti della sicurezza

Gli analisti della sicurezza monitorano e rispondono agli incidenti di sicurezza e ai risultati relativi alla protezione dei dati sensibili.

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

• Lettore Gestore contesto accesso (roles/accesscontextmanager.policyReader)
• Visualizzatore della rete di calcolo (roles/compute.networkViewer)
• Visualizzatore del catalogo di dati (roles/datacatalog.viewer)
• Cloud KMS Viewer (roles/cloudkms.viewer)
• Visualizzatore log (roles/logging.viewer)
• Visualizzatore dei criteri dell'organizzazione (roles/orgpolicy.policyViewer)
• Visualizzatore amministratore di Security Center (roles/securitycenter.adminViewer)
• Editor dei risultati del Security Center(roles/securitycenter.findingsEditor)
• Uno dei seguenti ruoli di Security Command Center:
  • Security Center Findings Bulk Mute Editor (roles/securitycenter.findingsBulkMuteEditor)
  • Impostazione di disattivazione audio per i cercapersone del Centro per la sicurezza (roles/securitycenter.findingsMuteSetter)
  • Autore impostazione stato dei risultati Centro sicurezza (roles/securitycenter.findingsStateSetter)

Esempi di flussi di accesso ai gruppi per le origini esterne

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

Flusso di accesso per il gruppo Visualizzatore di dati criptati

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

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

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

   SELECT ssn, pan FROM cc_card_table
   

2. BigQuery verifica l'accesso nel seguente modo:

   • L'utente è 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 nel livello di accesso o nella regola di ingresso nel perimetro di Controlli di servizio VPC.
   • IAM verifica che l'utente abbia i ruoli appropriati e sia autorizzato ad accedere alle colonne criptate selezionate nella tabella BigQuery.

BigQuery restituisce i dati riservati in formato criptato.

Flusso di accesso per il gruppo di lettori di testo normale

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

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

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

   SELECT decrypt_ssn(ssn) FROM cc_card_table
   

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

3. L'accesso viene verificato nel seguente modo:

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

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

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

Controlli di sicurezza comuni

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

Controlli di importazione dei dati

Per creare il data warehouse, devi trasferire i dati da un'altraGoogle 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 contribuire a proteggere i dati durante l'importazione, puoi utilizzare la crittografia lato client, le regole del firewall e i criteri per i livelli di accesso. Il processo di importazione viene talvolta definito processo di estrazione, trasformazione e caricamento (ETL).

Regole di rete e firewall

Le regole del 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 determinate connessioni alla porta TCP 443 provenienti dai nomi di dominio speciali restricted.googleapis.com. Il dominio restricted.googleapis.com presenta i seguenti vantaggi:

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

Per ulteriori informazioni, consulta la pagina Configurare Accesso privato Google.

Quando utilizzi il repository terraform-google-secured-data-warehouse, devi configurare sottoreti separate per ogni job Dataflow. Le sottoreti separate assicurano che i dati anonimizzati siano separati correttamente da quelli che vengono nuovamente identificati.

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 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 Rifiuta tutto.

Controlli del perimetro

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

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 per il repository terraform-google-secured-data-warehouse:

• Collega il progetto di importazione dati al progetto di governance in modo che la spersonalizzazione possa avvenire durante l'importazione.
• Collega il progetto di dati non riservati al progetto di dati riservati in modo che i dati riservati possano essere nuovamente identificati quando un analista dei dati lo richiede.
• Collega 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 effettuano le seguenti connessioni per il repository terraform-google-secured-data-warehouse-onprem-ingest:

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

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

Policy di accesso

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

Per garantire che solo determinate origini possano accedere ai progetti, devi attivare un criterio di accesso per la tua organizzazione Google. Ti consigliamo di creare un criterio di accesso che specifichi l'intervallo di indirizzi IP consentiti per le richieste e consenta solo le richieste provenienti da utenti o account di servizio specifici. Per ulteriori informazioni, consulta Attributi del livello di accesso.

Account di servizio e controlli di accesso

Gli account di servizio sono identità che Google Cloud puoi utilizzare per eseguire richieste API per tuo conto. Gli account di servizio assicurano che le identità utente non abbiano accesso diretto ai servizi. Per consentire la separazione delle responsabilità, crei account di servizio con ruoli diversi per scopi specifici. Questi account di servizio sono definiti nel modulo data-ingestion e nel modulo confidential-data di ogni architettura.

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

• Un account di servizio del controller Dataflow per la pipeline Dataflow che anonimizza i dati riservati.
• Un account di servizio del controller Dataflow per la pipeline Dataflow che reidentifica i dati riservati.
• Un account di servizio Cloud Storage per importare i dati da un file batch.
• Un account di servizio Pub/Sub per importare i dati da un servizio di streaming.
• Un account di servizio Cloud Scheduler per eseguire il job Dataflow batch che crea la pipeline Dataflow.

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

Service account	Nome	Progetto	Ruoli
Dataflow controller Questo account viene utilizzato per la deidentificazione.	sa-dataflow-controller	Importazione dati	BigQuery Admin roles/bigquery.admin Amministratore Cloud KMS (roles/cloudkms.admin) Decriptatore della chiave CryptoCloud KMS (roles/cloudkms.cryptoKeyDecrypter) Compute Visualizzatore (roles/compute.viewer) Dataflow Worker (roles/dataflow.worker) Amministratore DLP (roles/dlp.admin) Abbonato Pub/Sub (roles/pubsub.subscriber) Amministratore dell'archiviazione (roles/storage.admin) Agente del servizio Dataflow (roles/dataflow.serviceAgent)
Dataflow controller Questo account viene utilizzato per la reidentificazione.	sa-dataflow-controller-reid	Dati riservati	BigQuery Admin roles/bigquery.admin Amministratore Cloud KMS (roles/cloudkms.admin) Cloud KMS CryptoKey Decrypter (roles/cloudkms.cryptoKeyDecrypter) Compute Visualizzatore (roles/compute.viewer) Dataflow Worker (roles/dataflow.worker) Amministratore DLP (roles/dlp.admin) Abbonato Pub/Sub (roles/pubsub.subscriber) Amministratore dell'archiviazione (roles/storage.admin) Agente del servizio Dataflow (roles/dataflow.serviceAgent)
Cloud Storage	sa-storage-writer	Importazione dati	Storage Object Creator (roles/storage.objectCreator) Visualizzatore di oggetti di archiviazione (roles/storage.ObjectViewer)
Pub/Sub	sa-pubsub-writer	Importazione dati	Publisher Pub/Sub (roles/pubsub.publisher) Abbonato Pub/Sub (roles/pubsub.subscriber)
Cloud Scheduler	sa-scheduler-controller	Importazione dati	Compute Visualizzatore (roles/compute.viewer) Sviluppatore Dataflow (roles/dataflow.developer)

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 automatico dei dati batch nel bucket di archiviazione di importazione.
• L'account di servizio Pub/Sub consente lo streaming dei dati al servizio Pub/Sub.
• L'account di servizio controller Dataflow viene utilizzato dalla pipeline Dataflow per trasformare e scrivere dati da Pub/Sub a BigQuery.
• L'account di servizio delle funzioni Cloud Run scrive i dati batch successivi caricati da Cloud Storage in BigQuery.
• L'account di servizio Caricamento in archiviazione consente alla pipeline ETL di creare oggetti.
• L'account di servizio Pub/Sub Write consente alla pipeline ETL di scrivere i dati su Pub/Sub.

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

Nome	Ruoli	Ambito del compito
Account di servizio del controller Dataflow	Editor di dati BigQuery (roles/bigquery.dataEditor) Utente dell'attività BigQuery (roles/bigquery.jobUser) Sviluppatore Dataflow (roles/dataflow.developer) Dataflow Worker (roles/dataflow.worker) Editor Pub/Sub (roles/pubsub.editor) Abbonato Pub/Sub (roles/pubsub.subscriber) Consumatore dell'utilizzo del servizio (roles/serviceusage.serviceUsageConsumer) Visualizzatore di oggetti di archiviazione (roles/storage.ObjectViewer)	Progetto di importazione dati
	Editor di dati BigQuery (roles/bigquery.dataEditor) Visualizzatore dei metadati di BigQuery (roles/bigquery.metadataViewer)	Progetto di dati
	Lettore di risultati dell'ispezione DLP (roles/dlp.deidentifyTemplatesReader) Editor di modelli di controllo DLP (roles/dlp.inspectTemplatesReader) Utente DLP (roles/dlp.user)	Governance dei dati
Account di servizio Cloud Run Functions	Editor di dati BigQuery (roles/bigquery.dataEditor) Utente dell'attività BigQuery (roles/bigquery.jobUser) Cloud Run Invoker (roles/run.invoker) Eventarc Event Receiver (roles/eventarc.eventReceiver)	Progetto di importazione dati
	Editor di dati BigQuery (roles/bigquery.dataEditor) Visualizzatore dei metadati di BigQuery (roles/bigquery.metadataViewer)	Progetto di dati
Account di servizio di caricamento in Storage	Storage Object Creator (roles/storage.objectCreator) Visualizzatore di oggetti di archiviazione (roles/storage.ObjectViewer)	Progetto di importazione dati
Account di servizio Pub/Sub Write	Publisher Pub/Sub (roles/pubsub.publisher) Abbonato Pub/Sub (roles/pubsub.subscriber)	Progetto di importazione dati

Criteri dell'organizzazione

Questa architettura include i vincoli delle norme dell'organizzazione utilizzati dal blueprint delle basi dell'azienda e aggiunge vincoli aggiuntivi. Per ulteriori informazioni sui vincoli utilizzati dal progetto della piattaforma di base aziendale, consulta Vincoli delle policy dell'organizzazione.

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

Norme	Nome vincolo	Valore consigliato
Limita i deployment delle risorse a località fisiche specifiche. Per altri valori, consulta Gruppi di valori.	gcp.resourceLocations	Uno dei seguenti elementi: in:us-locations in:eu-locations in:asia-locations
Disattiva la creazione di account di servizio	iam.disableServiceAccountCreation	true
Abilita 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 sottorete privata che vuoi che l'architettura utilizzi.
Disattiva la registrazione dell'output della porta seriale in Cloud Logging.	compute.disableSerialPortLogging	true
Richiedi protezione CMEK (soloterraform-google-secured-data-warehouse-onprem-ingest)	gcp.restrictNonCmekServices	bigquery.googleapis.com
Disattivare la creazione di chiavi dell'account di servizio (terraform-google-secured-data-warehouse-onprem-ingest only)	disableServiceAccountKeyCreation	true
Abilita OS Login per le VM create nel progetto (terraform-google-secured-data-warehouse-onprem-ingest only)	compute.requireOsLogin	true
Disattiva l'assegnazione automatica dei ruoli all'account di servizio predefinito (terraform-google-secured-data-warehouse-onprem-ingest only)	automaticIamGrantsForDefaultServiceAccounts	true
Impostazioni di traffico in entrata consentite (funzioni Cloud Run) (terraform-google-secured-data-warehouse-onprem-ingest only)	cloudfunctions.allowedIngressSettings	ALLOW_INTERNAL_AND_GCLB

Controlli di sicurezza per le origini dati esterne

Le seguenti sezioni descrivono i controlli che si applicano all'importazione dei 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 passano tra Google Cloud e il tuo ambiente. Per questa architettura aziendale è consigliato Dedicated Interconnect, in quanto fornisce una connessione diretta e un elevato throughput, che sono importanti se stai trasmettendo in streaming 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.

Crittografia lato client

Prima di spostare i tuoi dati sensibili in Google Cloud, criptali localmente per proteggerli in stato inattivo 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 che sono stati importati.

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

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

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

Se le obbligazioni di conformità della tua organizzazione richiedono di gestire le tue chiavi esternamente da Google Cloud, puoi attivare Cloud External Key Manager. Se utilizzi chiavi esterne, spetta a te svolgere le attività di gestione delle chiavi, inclusa rotazione della chiave.

Mascheramento dei dati dinamico

Per facilitare la condivisione e l'applicazione dei criteri di accesso ai dati su larga scala, puoi configurare il mascheramento dei dati dinamici. 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, 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. La regola di mascheramento dei dati predefinita viene applicata a queste colonne per nascondere il valore della colonna.

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

Crittografia e decriptazione a livello di colonna

La crittografia a livello di colonna ti consente di criptare i dati in BigQuery a un livello più granulare. Anziché criptare un'intera tabella, seleziona le colonne che contengono dati sensibili all'interno di BigQuery e solo queste colonne vengono criptate. BigQuery utilizza le funzioni di crittografia e decrittografia 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 controllo dell'accesso doppio sui dati criptati in BigQuery, perché l'utente deve disporre delle autorizzazioni sia per la tabella sia per la chiave di crittografia per leggere i dati in testo non cifrato.

Profiler dei dati per BigQuery con Sensitive Data Protection

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

Controlli di sicurezza per le origini dati interne

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

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. Sensitive Data Protection protegge ulteriormente i tuoi dati criptando i dati riservati utilizzando i rilevatori che hai configurato.

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 incapsulata da Cloud HSM per il processo di anonimizzazione dei dati utilizzando la Protezione dei dati sensibili.
• Due chiavi CMEK, una per il data warehouse BigQuery nel progetto di dati non riservati e l'altra per il data warehouse nel progetto di dati riservati. Per saperne di più, consulta Gestione delle chiavi.

Specifica la località CMEK, che determina la posizione geografica in cui la chiave viene archiviata e resa disponibile per l'accesso. Devi assicurarti che il CMEK si trovi nella stessa posizione delle tue 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 dall'esterno di 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, utilizza trasformazioni del record in base ai campi per anonimizzare i dati. Per un esempio di questo approccio, consulta la /examples/de_identification_template/ cartella. Questo esempio controlla i dati strutturati per verificare la presenza di numeri di carte di credito e PIN. Per i dati non strutturati, utilizzi i tipi di informazioni per anonimizzarli.

Per anonimizzare i dati contrassegnati come riservati, utilizza Sensitive Data Protection e una pipeline Dataflow per tokenizzarli. Questa pipeline prende 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 contribuire a proteggere i dati riservati, utilizza i controlli di 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, crei i tag di criteri. Ad esempio, il file taxonomy.tf nel modulo bigquery-confidential-data example 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 criteri 2_Private o 1_Sensitive.
• Un tag di criteri 2_Private per le colonne che includono informazioni 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 con tag con il tag di criteri 1_Sensitive. Gli utenti non hanno accesso alle colonne contrassegnate con il tag di criteri 3_Confidential.
• Un tag di criteri 1_Sensitive per le colonne che includono dati che non possono essere resi pubblici, ad esempio il massimale di credito. Gli utenti che hanno accesso a questo tag non hanno accesso alle colonne contrassegnate con i tag di criteri 2_Private o 3_Confidential.

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

Questi controlli di accesso garantiscono che, anche dopo la reidentificazione, i dati 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 le 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 visualizzarli. A tale scopo, crea un account di servizio con il ruolo Utente account di servizio (roles/iam.serviceAccountUser) che gli utenti autorizzati devono simulare. La sostituzione dell'identità dell'account di servizio consente agli utenti di utilizzare gli account di servizio senza scaricare le relative chiavi, migliorando la sicurezza complessiva del progetto. La simulazione dell'identità 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 archiviazione e reidentificazione

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

• Una chiave CMEK utilizzata dalla pipeline Dataflow per la procedura di nuova identificazione.
• La chiave crittografica originale utilizzata da Sensitive Data Protection per anonimizzare i tuoi dati.
• Una chiave CMEK per il data 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 il logging e le funzionalità del livello Premium o Enterprise 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 adeguati.
• Generare risultati per le risorse cloud configurate in modo errato
• Supporta la capacità dei team di gestione degli incidenti e delle operazioni di rispondere ai problemi che potrebbero verificarsi.

Access Transparency

Access Transparency ti invia una notifica in tempo reale quando il personale di Google richiede l'accesso ai tuoi 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.

Logging

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

• Creazione di un sink per log aggregato in tutti i progetti.
• Archiviazione dei log nella regione appropriata.
• Aggiunta di chiavi CMEK all'apposita destinazione di logging.

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

Avvisi e monitoraggio

Dopo aver implementato l'architettura, puoi configurare avvisi per notificare al tuo Centro operativo di sicurezza (SOC) la possibile presenza di un incidente di sicurezza. Ad esempio, puoi utilizzare gli avvisi per comunicare all'analista della sicurezza quando un'autorizzazione IAM è stata modificata. Per ulteriori informazioni sulla configurazione degli avvisi di Security Command Center, vedi 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 questo documento, devi esaminare e gestire la sicurezza e il rischio nelle aree chiave che si sovrappongono e interagiscono con l'utilizzo di questa soluzione. Di seguito sono elencati alcuni esempi:

• La sicurezza del codice utilizzato per configurare, eseguire il deployment ed eseguire i job Dataflow e le funzioni Cloud Run.
• La tassonomia di classificazione dei dati utilizzata con questa soluzione.
• Generazione e gestione delle chiavi di crittografia.
• I contenuti, la qualità e la sicurezza dei set di dati archiviati e analizzati nel data warehouse.
• L'ambiente complessivo in cui esegui il deployment della soluzione, inclusi quanto segue:
  • La progettazione, la segmentazione e la sicurezza delle reti che colleghi 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 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 esegui il deployment dell'architettura con il blueprint delle basi aziendali o autonomamente. Se scegli di non implementare il blueprint Nuclei dell'azienda, assicurati che nel tuo ambiente sia implementata una base di riferimento per la sicurezza simile.
2. Per importare dati da origini esterne, configura un collegamento con 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 account di servizio (roles/iam.serviceAccountUser) e Creatore token account di servizio Creatore token account di servizio (roles/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. Per un elenco delle API che devi abilitare, consulta il file README.

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

8. Configura il criterio di controllo dell'accesso.

9. Per le Google Cloud origini dati che utilizzano il terraform-google-secured-data-warehouse repository, esegui il deployment del percorso guidato nel tuo ambiente di test per vedere la soluzione in azione. Nell'ambito della procedura di test, tieni conto di quanto segue:

   1. Aggiungi i tuoi dati di esempio nel data warehouse BigQuery.
   2. Collabora con un analista dati della tua azienda per verificare il suo accesso ai dati confidenziali 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, esegui il deployment della soluzione nel tuo ambiente di test:

    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 per 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. Crittografa i dati con Tink utilizzando uno dei seguenti metodi:

       • Utilizzo della crittografia deterministica.
       • Utilizzo di uno script di supporto con dati di esempio.

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

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

    Esegui la query di creazione della vista:

    CREATE OR REPLACE VIEW `{project_id}.{bigquery_dataset}.decryption_view` AS
    
    SELECT
     Card_Type_Code,
     Issuing_Bank,
     Card_Number,
     `bigquery_dataset.decrypt`(Card_Number) AS Card_Number_Decrypted
    FROM `project_id.dataset.table_name`
    

    Esegui la query di selezione dalla 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.

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

• Esamina il progetto della piattaforma di sicurezza per le aziende per un ambiente sicuro di riferimento.
• Per visualizzare i dettagli dell'architettura, leggi il file README sulla configurazione di Terraform per le origini dati interne (terraform-google-secured-data-warehouse repository) o il file README sulla configurazione di Terraform per le origini dati esterne (terraform-google-secured-data-warehouse-onprem-ingest repository).