Esegui il deployment di una piattaforma di analisi e gestione dei dati aziendali

Last reviewed 2025-04-04 UTC

Una piattaforma aziendale di gestione dei dati e analisi fornisce un enclave in cui puoi archiviare, analizzare e manipolare informazioni sensibili mantenendo i controlli di sicurezza. Puoi utilizzare l'architettura a mesh di dati aziendali per implementare una piattaforma su Google Cloud per la gestione e l'analisi dei dati. L'architettura è progettata per funzionare in un ambiente ibrido, in cui i componenti interagiscono con i componenti on-premise e i processi operativi esistenti. Google Cloud

L'architettura mesh di dati aziendali include quanto segue:

• Un repository GitHub che contiene un insieme di configurazioni, script e codice Terraform per creare quanto segue:
  • Un progetto di governance che ti consente di utilizzare l'implementazione di Google del framework di controlli delle chiavi delle funzionalità di gestione dei dati cloud (CDMS).
  • Un esempio di piattaforma dati che supporta flussi di lavoro interattivi e di produzione.
  • Un ambiente di produzione all'interno della piattaforma di dati che supporta più domini di dati. I domini di dati sono raggruppamenti logici di elementi di dati.
  • Un ambiente di consumo all'interno della piattaforma di dati che supporta più progetti di consumo.
  • Un servizio di trasferimento dei dati che utilizza la federazione delle identità per i workload e la libreria di crittografia Tink per aiutarti a trasferire i dati in Google Cloud in modo sicuro.
  • Esempio di un dominio di dati che contiene progetti di importazione, non riservati e riservati.
  • Un esempio di sistema di accesso ai dati che consente ai consumer di dati di richiedere l'accesso a set di dati e ai proprietari dei dati di concedere l'accesso a questi set di dati. L'esempio include anche un gestore del flusso di lavoro che modifica le autorizzazioni IAM di questi set di dati di conseguenza.
• Una guida all'architettura, alla progettazione, ai controlli di sicurezza e ai processi operativi che utilizzi questa architettura per implementare (questo documento).

L'architettura di mesh di dati aziendali è progettata per essere compatibile con il blueprint delle fondamenta aziendali. Il blueprint delle fondamenta aziendali fornisce una serie di servizi di base su cui si basa questa architettura, come le reti VPC e la registrazione. Puoi eseguire il deployment di questa architettura senza eseguire il deployment del blueprint delle fondamenta aziendali se il tuo ambienteGoogle Cloud fornisce la funzionalità necessaria.

Questo documento è rivolto ad architetti cloud, data scientist, data engineer e architetti della sicurezza che possono utilizzare l'architettura per creare e implementare servizi di dati completi su Google Cloud. Questo documento presuppone che tu abbia familiarità con i concetti di data mesh, Google Cloudservizi di dati e l'implementazione del framework CDMC. Google Cloud

Architettura

L'architettura di data mesh aziendale adotta un approccio a più livelli per fornire le funzionalità che consentono l'importazione, l'elaborazione e la governance dei dati. L'architettura è pensata per essere implementata e controllata tramite un workflow CI/CD. Il seguente diagramma mostra la relazione tra il livello di dati implementato da questa architettura e gli altri livelli del tuo ambiente.

Questo diagramma include quanto segue:

• L'infrastruttura Google Cloud fornisce funzionalità di sicurezza come la crittografia at-rest e la crittografia in transito, nonché blocchi di base come computing e archiviazione.
• La base aziendale fornisce una linea di base di risorse come sistemi di identità, networking, logging, monitoraggio e deployment che ti consentono di adottare Google Cloud per i tuoi carichi di lavoro di dati.
• Il livello dati fornisce varie funzionalità come l'importazione dati, l'archiviazione dei dati, il controllo dell'accesso ai dati, la governance dei dati, il monitoraggio dei dati e la condivisione dei dati.
• Il livello applicazione rappresenta varie applicazioni diverse che utilizzano gli asset del livello dati.
• CI/CD fornisce gli strumenti per automatizzare il provisioning, la configurazione, la gestione e il deployment di infrastrutture, flussi di lavoro e componenti software. Questi componenti ti aiutano a garantire deployment coerenti, affidabili e verificabili, a ridurre al minimo gli errori manuali e ad accelerare il ciclo di sviluppo complessivo.

Per mostrare come viene utilizzato l'ambiente di dati, l'architettura include un flusso di lavoro di dati di esempio. Il flusso di lavoro dei dati di esempio ti guida attraverso i seguenti processi: governance dei dati, importazione dati, trattamento dei dati, condivisione dei dati e utilizzo dei dati.

Decisioni architettoniche chiave

La tabella seguente riepiloga le decisioni di alto livello dell'architettura.

Area decisionale	Decisione
Google Cloud architettura
Gerarchia delle risorse	L'architettura utilizza la gerarchia delle risorse del progetto della piattaforma aziendale.
Networking	L'architettura include un servizio di trasferimento dei dati di esempio che utilizza la federazione delle identità per i workload e una libreria Tink.
Ruoli e autorizzazioni IAM	L'architettura include ruoli di produttore di dati segmentati, ruoli di consumatore di dati, ruoli di governance dei dati e ruoli di piattaforma di dati.
Servizi di dati comuni
Metadati	L'architettura utilizza Data Catalog per gestire i metadati dei dati.
Gestione centralizzata dei criteri	Per gestire le policy, l'architettura utilizza l'implementazione del framework CDMC di Google Cloud.
Gestione dell'accesso ai dati	Per controllare l'accesso ai dati, l'architettura include un processo indipendente che richiede ai consumatori di dati di richiedere l'accesso agli asset di dati al proprietario dei dati.
Qualità dei dati	L'architettura utilizza il motore di qualità dei dati di Cloud per definire ed eseguire regole di qualità dei dati su colonne di tabelle specificate, misurando la qualità dei dati in base a metriche come correttezza e completezza.
Sicurezza dei dati	L'architettura utilizza tagging, crittografia, mascheramento, tokenizzazione e controlli IAM per garantire la sicurezza dei dati.
Dominio di dati
Ambienti di dati	L'architettura include tre ambienti. Due ambienti (non di produzione e di produzione) sono ambienti operativi basati su pipeline. Un ambiente (sviluppo) è un ambiente interattivo.
Proprietari dei dati	I proprietari dei dati importano, elaborano, espongono e concedono l'accesso agli asset di dati.
Consumatori di dati	I consumatori di dati richiedono l'accesso agli asset di dati.
Onboarding e operazioni
Pipeline	L'architettura utilizza le seguenti pipeline per il deployment delle risorse: Pipeline di base Pipeline dell'infrastruttura Pipeline di artefatti Pipeline del catalogo dei servizi
Repository	Ogni pipeline utilizza un repository separato per consentire la separazione delle responsabilità.
Flusso del processo	La procedura richiede che le modifiche all'ambiente di produzione includano un autore dell'invio e un approvatore.
Cloud Operations
Schede punteggio dei prodotti di dati	Il motore di generazione dei report genera prospetti dei dati di prodotto.
Cloud Logging	L'architettura utilizza l'infrastruttura di logging del progetto di fondazione di un'azienda.
Cloud Monitoring	L'architettura utilizza l'infrastruttura di monitoraggio del blueprint delle fondamenta dell'impresa.

Identità: mappatura dei ruoli ai gruppi

Il data mesh sfrutta l'architettura esistente di gestione del ciclo di vita dell'identità, autorizzazione e autenticazione del blueprint delle fondamenta dell'impresa. Agli utenti non vengono assegnati ruoli direttamente. I gruppi sono invece il metodo principale per assegnare ruoli e autorizzazioni in IAM. I ruoli e le autorizzazioni IAM vengono assegnati durante la creazione del progetto tramite la pipeline di base.

Il data mesh associa i gruppi a una delle quattro aree chiave: infrastruttura, governance dei dati, produttori di dati basati sul dominio e consumatori basati sul dominio.

Gli ambiti delle autorizzazioni per questi gruppi sono i seguenti:

• L'ambito delle autorizzazioni del gruppo di infrastruttura è il data mesh nel suo complesso.
• L'ambito delle autorizzazioni dei gruppi di governance dei dati è il progetto di governance dei dati.
• Le autorizzazioni di producer e consumer basate sul dominio sono limitate al dominio dei dati.

Le tabelle seguenti mostrano i vari ruoli utilizzati in questa implementazione di data mesh e le relative autorizzazioni.

Infrastruttura

Gruppo	Descrizione	Ruoli
[e-mail]	Amministratori generali del data mesh	roles/owner (piattaforma di dati)

Governance dei dati

Gruppo	Descrizione	Ruoli
[e-mail]	Amministratori del progetto di governance dei dati	roles/owner sul progetto di governance dei dati
[e-mail]	Sviluppatori che creano e gestiscono i componenti di governance dei dati	Più ruoli nel progetto di governance dei dati, tra cui roles/viewer, ruoli BigQuery e ruoli Data Catalog
[e-mail]	Lettori delle informazioni sulla governance dei dati	roles/viewer
[e-mail]	Amministratori della sicurezza del progetto di governance	roles/orgpolicy.policyAdmin e roles/iam.securityReviewer
[e-mail]	Gruppo con l'autorizzazione per utilizzare i modelli di tag	roles/datacatalog.tagTemplateUser
[e-mail]	Gruppo con l'autorizzazione per utilizzare i modelli di tag e aggiungere tag	roles/datacatalog.tagTemplateUser e roles/datacatalog.tagEditor
[e-mail]	Gruppo di service account per le notifiche di Security Command Center	Nessuno. Si tratta di un gruppo per l'appartenenza e viene creato un account di servizio con questo nome, che dispone delle autorizzazioni necessarie.

Produttori di dati basati sul dominio

Gruppo	Descrizione	Ruoli
gcp-dm-{data_domain_name}[e-mail]	Amministratori di un dominio di dati specifico	roles/owner sul progetto del dominio dati
gcp-dm-{data_domain_name}[e-mail]	Sviluppatori che creano e gestiscono prodotti di dati all'interno di un dominio di dati	Più ruoli nel progetto del dominio dati, tra cui roles/viewer, ruoli BigQuery e ruoli Cloud Storage
gcp-dm-{data_domain_name}[e-mail]	Lettori delle informazioni sul dominio di dati	roles/viewer
gcp-dm-{data_domain_name}-metadata-editors@{var.domain}	Editor delle voci di Data Catalog	Ruoli per modificare le voci di Data Catalog
gcp-dm-{data_domain_name}[e-mail]	Responsabili dei dati per il dominio di dati	Ruoli per gestire i metadati e gli aspetti di governance dei dati

Consumer di dati basati sul dominio

Gruppo	Descrizione	Ruoli
gcp-dm-consumer-{project_name}[e-mail]	Amministratori di un progetto consumer specifico	roles/owner sul progetto consumer
gcp-dm-consumer-{project_name}[e-mail]	Sviluppatori che lavorano all'interno di un progetto consumer	Più ruoli nel progetto consumer, inclusi roles/viewer e ruoli BigQuery
gcp-dm-consumer-{project_name}[e-mail]	Lettori delle informazioni sul progetto consumer	roles/viewer

Struttura dell'organizzazione

Per distinguere tra operazioni di produzione e dati di produzione, l'architettura utilizza ambienti diversi per sviluppare e rilasciare i flussi di lavoro. Le operazioni di produzione includono la governance, la tracciabilità e la ripetibilità di un flusso di lavoro e la verificabilità dei risultati del flusso di lavoro. I dati di produzione si riferiscono a dati potenzialmente sensibili necessari per gestire la tua organizzazione. Tutti gli ambienti sono progettati per disporre di controlli di sicurezza che ti consentono di importare e gestire i tuoi dati.

Per aiutare data scientist e ingegneri, l'architettura include un ambiente interattivo, in cui gli sviluppatori possono lavorare direttamente con l'ambiente e aggiungere servizi tramite un catalogo selezionato di soluzioni. Gli ambienti operativi sono gestiti tramite pipeline che hanno architettura e configurazione codificate.

Questa architettura utilizza la struttura organizzativa del blueprint delle fondamenta dell'impresa come base per il deployment dei carichi di lavoro dei dati. Il seguente diagramma mostra le cartelle e i progetti di primo livello utilizzati nell'architettura di mesh di dati aziendali.

La seguente tabella descrive le cartelle e i progetti di primo livello che fanno parte dell'architettura.

Cartella	Componente	Descrizione
common	prj-c-artifact-pipeline	Contiene la pipeline di deployment utilizzata per creare gli artefatti di codice dell'architettura.
	prj-c-service-catalog	Contiene l'infrastruttura utilizzata dal catalogo dei servizi per eseguire il deployment delle risorse nell'ambiente interattivo.
	prj-c-datagovernance	Contiene tutte le risorse utilizzate dall'implementazione di Google Clouddel framework CDMC.
development	fldr-d-dataplatform	Contiene i progetti e le risorse della piattaforma dati per lo sviluppo di casi d'uso in modalità interattiva.
non-production	fldr-n-dataplatform	Contiene i progetti e le risorse della piattaforma dati per i casi d'uso di test che vuoi implementare in un ambiente operativo.
production	fldr-p-dataplatform	Contiene i progetti e le risorse della piattaforma dati per il deployment in produzione.

Cartella della piattaforma dati

La cartella della piattaforma dati contiene tutti i componenti del piano dati e alcune delle risorse CDMC. Inoltre, la cartella della piattaforma dati e il progetto di governance dei dati contengono le risorse CDMC. Il seguente diagramma mostra le cartelle e i progetti di cui viene eseguito il deployment nella cartella della piattaforma dati.

Ogni cartella della piattaforma di dati include una cartella dell'ambiente (produzione, non produzione e sviluppo). La tabella seguente descrive le cartelle all'interno di ogni cartella della piattaforma dati.

Cartelle	Descrizione
Producer	Contiene i domini di dati.
Consumatori	Contiene i progetti consumer.
Dominio dei dati	Contiene i progetti associati a un determinato dominio.

Cartella dei produttori

Ogni cartella dei produttori include uno o più domini di dati. Un dominio di dati si riferisce a un raggruppamento logico di elementi di dati che condividono un significato, uno scopo o un contesto aziendale comuni. I domini di dati consentono di classificare e organizzare gli asset di dati all'interno di un'organizzazione. Il seguente diagramma mostra la struttura di un dominio di dati. L'architettura esegue il deployment dei progetti nella cartella della piattaforma dati per ogni ambiente.

La tabella seguente descrive i progetti di cui viene eseguito il deployment nella cartella della piattaforma dati per ogni ambiente.

Progetto	Descrizione
Importazione	Il progetto di importazione inserisce i dati nel dominio dati. L'architettura fornisce esempi di come trasmettere i flussi di dati in BigQuery, Cloud Storage e Pub/Sub. Il progetto di importazione contiene anche esempi di Dataflow e Managed Service for Apache Airflow che puoi utilizzare per orchestrare la trasformazione e lo spostamento dei dati importati.
Non riservato	Il progetto non riservato contiene dati a cui è stata rimossa l'identificazione. Puoi mascherare, inserire in un contenitore, criptare, tokenizzare o offuscare i dati. Utilizza i tag delle norme per controllare la modalità di presentazione dei dati.
Riservato	Il progetto riservato contiene dati non criptati. Puoi controllare l'accesso tramite le autorizzazioni IAM.

Cartella Consumatore

La cartella consumer contiene i progetti consumer. I progetti di consumo forniscono un meccanismo per segmentare gli utenti dei dati in base al limite di attendibilità richiesto. A ogni progetto viene assegnato un gruppo di utenti separato e al gruppo viene assegnato l'accesso agli asset di dati richiesti in base al singolo progetto. Puoi utilizzare il progetto consumer per raccogliere, analizzare e arricchire i dati del gruppo.

Cartella comune

La cartella common contiene i servizi utilizzati da ambienti e progetti diversi. Questa sezione descrive le funzionalità aggiunte alla cartella comune per abilitare la mesh di dati aziendali.

Architettura CDMC

L'architettura utilizza l'architettura CDMC per la governance dei dati. Le funzioni di governance dei dati si trovano nel progetto di governance dei dati nella cartella comune. Il seguente diagramma mostra i componenti dell'architettura CDMC. I numeri nel diagramma rappresentano i controlli chiave che vengono gestiti con i servizi Google Cloud.

La seguente tabella descrive i componenti dell'architettura CDMC utilizzati dall'architettura enterprise data mesh.

Componente CDMC	ServizioGoogle Cloud	Descrizione
Componenti di accesso e ciclo di vita
Gestione delle chiavi	Cloud KMS	Un servizio che gestisce in modo sicuro le chiavi di crittografia che proteggono i dati sensibili.
Record Manager	Cloud Run	Un'applicazione che mantiene log e record completi delle attività di elaborazione dei dati, garantendo che le organizzazioni possano monitorare e controllare l'utilizzo dei dati.
Norme di archiviazione	BigQuery	Una tabella BigQuery che contiene le norme di archiviazione per i dati.
Diritti	BigQuery	Una tabella BigQuery che archivia informazioni su chi può accedere ai dati sensibili. Questa tabella garantisce che solo gli utenti autorizzati possano accedere a dati specifici in base ai loro ruoli e privilegi.
Componenti di scansione
Perdita dei dati	Sensitive Data Protection	Servizio utilizzato per ispezionare gli asset alla ricerca di dati sensibili.
Risultati DLP	BigQuery	Una tabella BigQuery che cataloga le classificazioni dei dati all'interno della piattaforma dati.
Norme	BigQuery	Una tabella BigQuery che contiene pratiche coerenti di governance dei dati (ad esempio, tipi di accesso ai dati).
Esportazione della fatturazione	BigQuery	Una tabella che archivia le informazioni sui costi esportate dalla fatturazione Cloud per consentire l'analisi delle metriche di costo associate agli asset di dati.
Motore Cloud Data Quality	Cloud Run	Un'applicazione che esegue controlli della qualità dei dati per tabelle e colonne.
Risultati della qualità dei dati	BigQuery	Una tabella BigQuery che registra le discrepanze identificate tra le regole di qualità dei dati definite e la qualità effettiva degli asset di dati.
Componenti dei report
Scheduler	Cloud Scheduler	Un servizio che controlla quando viene eseguito Cloud Data Quality Engine e quando viene eseguita l'ispezione di Sensitive Data Protection.
Report Engine	Cloud Run	Un'applicazione che genera report che aiutano a monitorare e misurare il rispetto dei controlli del framework CDMC.
Risultati e asset	BigQuery e Pub/Sub	Un report BigQuery sulle discrepanze o sulle incongruenze nei controlli di gestione dei dati, ad esempio tag mancanti, classificazioni errate o posizioni di archiviazione non conformi.
Esportazioni di tag	BigQuery	Una tabella BigQuery che contiene le informazioni sui tag estratte da Data Catalog.
Altri componenti
Gestione dei criteri	Servizio Policy dell'organizzazione	Un servizio che definisce e applica restrizioni sulla posizione geografica in cui possono essere archiviati i dati.
Policy di accesso basate sugli attributi	Gestore contesto accesso	Un servizio che definisce e applica criteri di accesso granulari basati sugli attributi, in modo che solo gli utenti autorizzati provenienti da località e dispositivi consentiti possano accedere alle informazioni sensibili.
Metadati	Data Catalog	Un servizio che archivia informazioni sui metadati delle tabelle in uso nel data mesh.
Tag Engine	Cloud Run	Un'applicazione che aggiunge tag ai dati nelle tabelle BigQuery.
Report CDMC	Data Studio	Dashboard che consentono agli analisti di visualizzare i report generati dai motori dell'architettura CDMC.

Implementazione di CDMC

La seguente tabella descrive come l'architettura implementa i controlli chiave nel framework CDMC.

Requisito di controllo CDMC	Implementazione
Conformità del controllo dei dati	Il motore di generazione dei report rileva gli asset di dati non conformi e pubblica i risultati in un argomento Pub/Sub. Questi risultati vengono caricati anche in BigQuery per la generazione di report utilizzando Data Studio.
La proprietà dei dati viene stabilita sia per i dati migrati sia per quelli generati nel cloud	Data Catalog acquisisce automaticamente i metadati tecnici da BigQuery. Tag Engine applica i tag dei metadati aziendali, come il nome del proprietario e il livello di sensibilità, da una tabella di riferimento, il che contribuisce a garantire che tutti i dati sensibili siano taggati con le informazioni sul proprietario per la conformità. Questo processo di tagging automatizzato contribuisce a garantire la governance e la conformità dei dati identificando ed etichettando i dati sensibili con le informazioni del proprietario appropriate.
L'acquisizione e il consumo dei dati sono regolati e supportati dall'automazione	Data Catalog classifica gli asset di dati assegnando loro un flag is_authoritative quando sono un'origine autorevole. Data Catalog memorizza automaticamente le informazioni, insieme ai metadati tecnici, in un registro dei dati. Report Engine e Tag Engine possono convalidare e segnalare il registro dei dati delle fonti autorevoli utilizzando Pub/Sub.
La sovranità dei dati e il trasferimento transfrontaliero dei dati sono gestiti	Organization Policy Service definisce le regioni di archiviazione consentite per gli asset di dati e Gestore contesto accesso limita l'accesso in base alla posizione dell'utente. Data Catalog memorizza le posizioni di archiviazione approvate come tag di metadati. Report Engine confronta questi tag con la posizione effettiva degli asset di dati in BigQuery e pubblica eventuali discrepanze come risultati utilizzando Pub/Sub. Security Command Center fornisce un ulteriore livello di monitoraggio generando risultati di vulnerabilità se i dati vengono archiviati o acceduti al di fuori delle policy definite.
I cataloghi di dati sono implementati, utilizzati e interoperabili	Data Catalog archivia e aggiorna i metadati tecnici di tutti gli asset di dati BigQuery, creando di fatto un Data Catalog sincronizzato in modo continuo. Data Catalog garantisce che tutte le tabelle e le viste nuove o modificate vengano aggiunte immediatamente al catalogo, mantenendo un inventario aggiornato degli asset di dati.
Le classificazioni dei dati vengono definite e utilizzate	Sensitive Data Protection ispeziona i dati BigQuery e identifica i tipi di informazioni sensibili. Questi risultati vengono poi classificati in base a una tabella di riferimento per la classificazione e il livello di sensibilità più alto viene assegnato come tag in Data Catalog a livello di colonna e tabella. Tag Engine gestisce questo processo aggiornando Data Catalog con i tag di sensibilità ogni volta che vengono aggiunti nuovi asset di dati o vengono modificati quelli esistenti. Questo processo garantisce una classificazione dei dati costantemente aggiornata in base alla sensibilità, che puoi monitorare e su cui puoi generare report utilizzando Pub/Sub e strumenti di generazione di report integrati.
I diritti sui dati vengono gestiti, applicati e monitorati	I tag di policy di BigQuery controllano l'accesso ai dati sensibili a livello di colonna, garantendo che solo gli utenti autorizzati possano accedere a dati specifici in base atag di critericy assegnato. IAM gestisce l'accesso complessivo al data warehouse, mentre Data Catalog archivia le classificazioni della sensibilità. Vengono eseguiti controlli regolari per garantire che tutti i dati sensibili abbiano tag di policy corrispondenti e le eventuali discrepanze vengono segnalate utilizzando Pub/Sub per la correzione.
L'accesso, l'utilizzo e i risultati etici dei dati vengono gestiti	Gli accordi di condivisione dei dati per fornitori e consumatori vengono archiviati in un data warehouse BigQuery dedicato per controllare gli scopi di consumo. Data Catalog etichetta gli asset di dati con le informazioni dell'accordo con il fornitore, mentre gli accordi con i consumatori sono collegati ai binding IAM pecontrollo dell'accessolo dell'accesso. Le etichette delle query impongono scopi di consumo, richiedendo ai consumatori di specificare uno scopo valido quando eseguono query su dati sensibili, che viene convalidato in base ai loro diritti in BigQuery. Un audit trail in BigQuery monitora tutti gli accessi ai dati e garantisce la conformità agli accordi di condivisione dei dati.
I dati sono protetti e i controlli sono documentati	La crittografia at-rest predefinita di Google contribuisce a proteggere i dati archiviati su disco. Cloud KMS supporta le chiavi di crittografia gestite dal cliente (CMEK) per una gestione avanzata delle chiavi. BigQuery implementa il mascheramento dinamico dei dati a livello di colonna per l'anonimizzazione e supporta l'anonimizzazione a livello di applicazione durante l'importazione dati. Data Catalog archivia i tag dei metadati per le tecniche di crittografia e deidentificazione applicate agli asset di dati. I controlli automatizzati garantiscono che i metodi di crittografia e deidentificazione siano in linea con le norme di sicurezza predefinite e che eventuali discrepanze vengano segnalate come risultati utilizzando Pub/Sub.
È definito e operativo un framework per la privacy dei dati	Data Catalog tagga gli asset di dati sensibili con informazioni pertinenti per la valutazione dell'impatto, come la posizione del soggetto e i link ai report di valutazione. Tag Engine applica questi tag in base alla sensibilità dei dati e a una tabella dei criteri in BigQuery, che definisce i requisiti di valutazione in base alla residenza dei dati e dei soggetti. Questo processo di tagging automatico consente il monitoraggio e la generazione di report continui sulla conformità ai requisiti di valutazione dell'impatto, garantendo che le valutazioni di impatto sulla protezione dei dati (DPIA) o le valutazioni di impatto sulla protezione (PIA) vengano condotte quando necessario.
Il ciclo di vita dei dati è pianificato e gestito	Data Catalog etichetta gli asset di dati con criteri di conservazione, specificando i periodi di conservazione e le azioni di scadenza (ad esempio l'archiviazione o l'eliminazione). Record Manager automatizza l'applicazione di questi criteri eliminando o archiviando le tabelle BigQuery in base ai tag definiti. Questa applicazione garantisce il rispetto delle norme sul ciclo di vita dei dati e mantiene la conformità ai requisiti di conservazione dei dati, con eventuali discrepanze rilevate e segnalate tramite Pub/Sub.
La qualità dei dati è gestita	Cloud Data Quality Engine definisce ed esegue regole di qualità dei dati sulle colonne della tabella specificate, misurando la qualità dei dati in base a metriche come correttezza e completezza. I risultati di questi controlli, inclusi i tassi di successo e le soglie, vengono archiviati come tag in Data Catalog. L'archiviazione di questi risultati consente il monitoraggio e la generazione di report continui sulla qualità dei dati, con eventuali problemi o deviazioni dalle soglie accettabili pubblicati come risultati utilizzando Pub/Sub.
I principi di gestione dei costi sono stabiliti e applicati	Data Catalog archivia le metriche relative ai costi per gli asset di dati, come i costi delle query, i costi di archiviazione e i costi di uscita dei dati, che vengono calcolati utilizzando i dati di fatturazione esportati da Fatturazione Cloud a BigQuery. L'archiviazione delle metriche relative ai costi consente un monitoraggio e un'analisi completi dei costi, garantendo il rispetto delle norme sui costi e l'utilizzo efficiente delle risorse, con eventuali anomalie segnalate tramite Pub/Sub.
Provenienza e derivazione dei dati sono comprese	Le funzionalità di derivazione dei dati integrate di Data Catalog monitorano la provenienza e la derivazione degli asset di dati, rappresentando visivamente il flusso di dati. Inoltre, gli script di importazione dati identificano e taggano l'origine originale dei dati in Data Catalog, migliorando la tracciabilità dei dati fino alla loro origine.

Gestione dell'accesso ai dati

L'accesso ai dati dell'architettura è controllato tramite un processo indipendente che separa il controllo operativo (ad esempio, l'esecuzione di job Dataflow) dal controllo dell'accesso dell'accesso ai dati. L'accesso di un utente a un servizio Google Cloud è definito da un problema ambientale o operativo ed è sottoposto a provisioning e approvato da un gruppo di ingegneria cloud. L'accesso di un utente agli asset di dati (ad esempio, una tabella BigQuery) è un problema di privacy, normativo o di governance ed è soggetto a un contratto di accesso tra le parti produttrici e consumatrici e controllato tramite le seguenti procedure. Google Cloud Il seguente diagramma mostra come viene eseguito il provisioning dell'accesso ai dati tramite l'interazione di diversi componenti software.

Come mostrato nel diagramma precedente, l'onboarding degli accessi ai dati viene gestito dai seguenti processi:

• Gli asset di dati cloud vengono raccolti e inventariati da Data Catalog.
• Il gestore del flusso di lavoro recupera gli asset di dati da Data Catalog.
• I proprietari dei dati vengono integrati in Workflow Manager.

Il funzionamento della gestione dell'accesso ai dati è il seguente:

1. Un consumatore di dati invia una richiesta per una risorsa specifica.
2. Il proprietario dei dati della risorsa viene avvisato della richiesta.
3. Il proprietario dei dati approva o rifiuta la richiesta.
4. Se la richiesta viene approvata, Workflow Manager passa il gruppo, l'asset e il tag associato al mapper IAM.
5. Il mapper IAM traduce i tag di Workflow Manager in autorizzazioni IAM e concede al gruppo specificato autorizzazioni IAM per l'asset di dati.
6. Quando un utente vuole accedere all'asset di dati, IAM valuta l'accesso all'asset Google Cloud in base alle autorizzazioni del gruppo.
7. Se consentito, l'utente accede all'asset di dati.

Networking

Il processo di sicurezza dei dati inizia nell'applicazione di origine, che potrebbe risiedere on-premise o in un altro ambiente esterno al progetto Google Cloud di destinazione. Prima di qualsiasi trasferimento di rete, questa applicazione utilizza la federazione delle identità per i workload per autenticarsi in modo sicuro nelle API Cloud di Google Cloud. Utilizzando queste credenziali, interagisce con Cloud KMS per ottenere o eseguire il wrapping delle chiavi necessarie e poi utilizza la libreria Tink per eseguire la crittografia e l'anonimizzazione iniziali del payload di dati sensibili in base a modelli predefiniti.

Una volta protetto, il payload di dati deve essere trasferito in modo sicuro nel progetto di importazione Google Cloud . Per le applicazioni on-premise, puoi utilizzare Cloud Interconnect o potenzialmente Cloud VPN. All'interno della reteGoogle Cloud , utilizza Private Service Connect per indirizzare i dati verso l'endpoint di importazione all'interno della rete VPC del progetto di destinazione. Private Service Connect consente all'applicazione di origine di connettersi alle API di Google utilizzando indirizzi IP privati, garantendo che il traffico non sia esposto a internet.

L'intero percorso di rete e i servizi di importazione di destinazione (Cloud Storage, BigQuery e Pub/Sub) all'interno del progetto di importazione sono protetti da un perimetro di Controlli di servizio VPC. Questo perimetro applica un confine di sicurezza, garantendo che i dati protetti provenienti dall'origine possano essere inseriti solo nei serviziGoogle Cloud autorizzati all'interno di quel progetto specifico.

Logging

Questa architettura utilizza le funzionalità di Cloud Logging fornite dal progetto base per la sicurezza.

Pipeline

L'architettura mesh di dati aziendale utilizza una serie di pipeline per il provisioning dell'infrastruttura, dell'orchestrazione, dei set di dati, delle pipeline di dati e dei componenti dell'applicazione. Le pipeline di deployment delle risorse dell'architettura utilizzano Terraform come strumento Infrastructure as Code (IaC) e Cloud Build come servizio CI/CD per eseguire il deployment delle configurazioni Terraform nell'ambiente dell'architettura. Il diagramma seguente mostra la relazione tra le pipeline.

La pipeline di base e la pipeline dell'infrastruttura fanno parte del progetto di fondazione di un'azienda. La tabella seguente descrive lo scopo delle pipeline e le risorse che eseguono il provisioning.

Pipeline	Provisioning effettuato da	Risorse
Pipeline di base	Bootstrap	Cartelle e sottocartelle della piattaforma dati Common Projects Account di servizio della pipeline dell'infrastruttura Trigger di Cloud Build per la pipeline dell'infrastruttura VPC condiviso Perimetro di controllo di servizio VPC
Pipeline dell'infrastruttura	Pipeline di base	Progetti consumer Service account di servizio del catalogo dei servizi Il trigger di Cloud Build per la pipeline del catalogo dei servizi Account di servizio della pipeline degli artefatti Il trigger di build di Cloud Build per la pipeline degli artefatti
Pipeline del catalogo dei servizi	Pipeline dell'infrastruttura	Risorse di cui è stato eseguito il deployment nel bucket del catalogo dei servizi
Pipeline di artefatti	Pipeline dell'infrastruttura	Le pipeline degli artefatti producono i vari contenitori e altri componenti del codebase utilizzato dal data mesh.

Ogni pipeline ha il proprio insieme di repository da cui estrae il codice e i file di configurazione. Ogni repository ha una separazione dei compiti in cui i responsabili dell'invio e delle approvazioni delle implementazioni del codice operativo sono responsabilità di gruppi diversi.

Deployment interattivo tramite catalogo dei servizi

Gli ambienti interattivi sono l'ambiente di sviluppo all'interno dell'architettura e si trovano nella cartella di sviluppo. L'interfaccia principale per l'ambiente interattivo è catalogo dei servizi, che consente agli sviluppatori di utilizzare modelli preconfigurati per creare istanze dei servizi Google. Questi modelli preconfigurati sono noti come modelli di servizio. I modelli di servizio ti aiutano a imporre la tua strategia di sicurezza, ad esempio rendendo obbligatoria la crittografia CMEK, e impediscono inoltre ai tuoi utenti di avere accesso diretto alle API di Google.

Il seguente diagramma mostra i componenti dell'ambiente interattivo e il modo in cui i data scientist eseguono il deployment delle risorse.

Per eseguire il deployment delle risorse utilizzando il catalogo dei servizi, vengono eseguiti i seguenti passaggi:

1. L'ingegnere MLOps inserisce un modello di risorsa Terraform per Google Cloud in un repository Git.
2. Il comando Git Commit attiva una pipeline Cloud Build.
3. Cloud Build copia il modello e tutti i file di configurazione associati in Cloud Storage.
4. L'ingegnere MLOps configura manualmente le soluzioni del catalogo dei servizi e il catalogo dei servizi. L'ingegnere condivide quindi il catalogo dei servizi con un progetto di servizio nell'ambiente interattivo.
5. Il data scientist seleziona una risorsa dal catalogo dei servizi.
6. Il catalogo dei servizi esegue il deployment del modello nell'ambiente interattivo.
7. La risorsa recupera gli script di configurazione necessari.
8. Il data scientist interagisce con le risorse.

Pipeline di artefatti

Il processo di importazione dati utilizza Managed Airflow e Dataflow per orchestrare lo spostamento e la trasformazione dei dati all'interno del dominio dei dati. La pipeline degli artefatti crea tutte le risorse necessarie per l&#39importazione datii e le sposta nella posizione appropriata per consentire ai servizi di accedervi. La pipeline degli artefatti crea gli artefatti container utilizzati dall'orchestratore.

Controlli di sicurezza

L'architettura di mesh di dati aziendali utilizza un modello di sicurezza a più livelli di difesa approfondita che include funzionalità, servizi e funzionalità di sicurezza predefiniti configurati tramite il blueprint delle fondamenta aziendali. Google Cloud Google CloudIl seguente diagramma mostra la stratificazione dei vari controlli di sicurezza per l'architettura.

La tabella seguente descrive i controlli di sicurezza associati alle risorse di ogni livello.

incorporato	Risorsa	Controllo di sicurezza
Framework CDMC	Implementazione diGoogle Cloud CDMC	Fornisce un framework di governance che aiuta a proteggere, gestire e controllare i tuoi asset di dati. Per saperne di più, consulta il framework dei controlli chiave di CDMC.
Deployment	Pipeline dell'infrastruttura	Fornisce una serie di pipeline che eseguono il deployment dell'infrastruttura, creano container e pipeline di dati. L'utilizzo delle pipeline consente auditabilità, tracciabilità e ripetibilità.
	Pipeline degli artefatti	Esegue il deployment di vari componenti non distribuiti dalla pipeline dell'infrastruttura.
	Modelli Terraform	Crea l'infrastruttura di sistema.
	Open Policy Agent	Consente di garantire che la piattaforma sia conforme alle norme selezionate.
Rete	Private Service Connect	Fornisce protezioni per l'esfiltrazione di dati intorno alle risorse dell'architettura a livello di API e IP. Consente di comunicare con le API Cloud di Google utilizzando indirizzi IP privati, in modo da evitare di esporre il traffico a internet.
	Rete VPC con indirizzi IP privati	Aiuta a eliminare l'esposizione alle minacce rivolte a internet.
	Controlli di servizio VPC	Contribuisce a proteggere le risorse sensibili dall'esfiltrazione di dati.
	Firewall	Contribuisce a proteggere la rete VPC da accessi non autorizzati.
Gestione degli accessi	Gestore contesto accesso	Controlla chi può accedere a quali risorse e contribuisce a prevenire l'utilizzo non autorizzato delle tue risorse.
	Federazione delle identità per i workload	Elimina la necessità di credenziali esterne per trasferire i dati sulla piattaforma dagli ambienti on-premise.
	Data Catalog	Fornisce un indice degli asset disponibili per gli utenti.
	IAM	Fornisce un accesso granulare.
Crittografia	Cloud KMS	Consente di gestire le chiavi di crittografia e i secret e di proteggere i dati tramite la crittografia at-rest e in transito.
	Secret Manager	Fornisce un archivio dei secret per le pipeline controllate da IAM.
	Crittografia dei dati inattivi	Per impostazione predefinita, Google Cloud cripta i dati at-rest.
	Crittografia dei dati in transito	Per impostazione predefinita, Google Cloud crittografa i dati in transito.
Rilevamento	Security Command Center	Ti aiuta a rilevare configurazioni errate e attività dannose nella tua organizzazione Google Cloud.
	Architettura continua	Controlla continuamente la tua Google Cloud organizzazione rispetto a una serie di policy OPA che hai definito.
	Motore per suggerimenti IAM	Analizza le autorizzazioni utente e fornisce suggerimenti su come ridurle per contribuire all'applicazione del principio del privilegio minimo.
	Firewall Insights	Analizza le regole firewall, identifica quelle eccessivamente permissive e suggerisce firewall più restrittivi per rafforzare la tua strategia di sicurezza complessiva.
	Cloud Logging	Fornisce visibilità sull'attività del sistema e contribuisce ad attivare il rilevamento di anomalie e attività dannose.
	Cloud Monitoring	Monitora segnali ed eventi chiave che possono contribuire a identificare attività sospette.
Preventivo	Policy organizzazione	Consente di controllare e limitare le azioni all'interno della tua Google Cloud organizzazione.

Workflow

Le sezioni seguenti descrivono il flusso di lavoro del produttore di dati e il flusso di lavoro del consumatore di dati, garantendo controlli degli accessi appropriati in base alla sensibilità dei dati e ai ruoli utente.

Flusso di lavoro del produttore di dati

Il seguente diagramma mostra come vengono protetti i dati durante il trasferimento a BigQuery.

Il flusso di lavoro per il trasferimento dei dati è il seguente:

1. Un'applicazione integrata con la federazione delle identità per i workload utilizza Cloud KMS per decriptare una chiave di crittografia con wrapping.
2. L'applicazione utilizza la libreria Tink per anonimizzare o criptare i dati utilizzando un modello.
3. L'applicazione trasferisce i dati al progetto di importazione in Google Cloud.
4. I dati arrivano in Cloud Storage, BigQuery o Pub/Sub.
5. Nel progetto di importazione, i dati vengono decriptati o reidentificati utilizzando un modello.
6. I dati decriptati vengono criptati o mascherati in base a un altro modello di anonimizzazione, quindi inseriti nel progetto non confidenziale. I tag vengono applicati dal motore di tagging in modo appropriato.
7. I dati del progetto non riservato vengono trasferiti al progetto riservato e vengono reidentificati.

È consentito il seguente accesso ai dati:

• Gli utenti che hanno accesso al progetto confidenziale possono accedere a tutti i dati non elaborati in formato non crittografato.
• Gli utenti che hanno accesso al progetto non riservato possono accedere ai dati mascherati, tokenizzati o criptati in base ai tag associati ai dati e alle loro autorizzazioni.

Flusso di lavoro del consumer di dati

I passaggi riportati di seguito descrivono come un consumatore può accedere ai dati archiviati in BigQuery.

1. Il consumatore di dati cerca gli asset di dati utilizzando Data Catalog.
2. Dopo aver trovato gli asset che sta cercando, il consumatore di dati richiede l'accesso agli asset di dati.
3. Il proprietario dei dati decide se fornire l'accesso agli asset.
4. Se il consumatore ottiene l'accesso, può utilizzare un notebook e il catalogo delle soluzioni per creare un ambiente in cui analizzare e trasformare gli asset di dati.

Riepilogo

Il repository GitHub fornisce istruzioni dettagliate per il deployment del data mesh su Google Cloud dopo aver eseguito il deployment della base aziendale. Il processo di deployment dell'architettura prevede la modifica dei repository dell'infrastruttura esistente e il deployment di nuovi componenti specifici del data mesh.

Completa i seguenti passaggi:

1. Completa tutti i prerequisiti, inclusi i seguenti:
   1. Installa Google Cloud CLI, Terraform, Tink, Java e Go.
   2. Esegui il deployment del progetto di base per le aziende (v4.1).
   3. Mantieni i seguenti repository locali:
      • gcp-data-mesh-foundations
      • gcp-bootstrap
      • gcp-environments
      • gcp-networks
      • gcp-org
      • gcp-projects
2. Modifica il progetto di base esistente e poi implementa le applicazioni del data mesh. Per ogni elemento, completa i seguenti passaggi:
   1. Nel repository di destinazione, estrai il ramo Plan.
   2. Per aggiungere componenti del data mesh, copia i file e le directory pertinenti da gcp-data-mesh-foundations nella directory di base appropriata. Sovrascrivi i file quando necessario.
   3. Aggiorna le variabili, i ruoli e le impostazioni del data mesh nei file Terraform (ad esempio *.tfvars e *.tf). Imposta i token GitHub come variabili di ambiente.
   4. Esegui le operazioni di inizializzazione, pianificazione e applicazione di Terraform su ogni repository.
   5. Esegui il commit delle modifiche, esegui il push del codice nel repository remoto, crea richieste di pull e uniscile agli ambienti di sviluppo, non di produzione e di produzione.

Passaggi successivi

• Scopri di più sull'architettura e sulle funzioni di una data mesh.
• Importa dati da Google Cloud in un data warehouse BigQuery protetto.
• Implementa il framework dei controlli chiave CDMC in un data warehouse BigQuery.
• Scopri di più sul blueprint delle fondamenta aziendali.