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

Last reviewed 2025-04-04 UTC

Una piattaforma di gestione e analisi dei dati aziendali 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 aziendale per eseguire il deployment di una piattaforma 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 e i processi operativi on-premise esistenti. Google Cloud

L'architettura del data mesh aziendale 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 Quadro di riferimento per i controlli chiave 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ù ambiti di dati. I domini di dati sono raggruppamenti logici di elementi di dati.
  • Un ambiente consumer all'interno della piattaforma di dati che supporta più progetti consumer.
  • Un servizio di trasferimento dati che utilizza la federazione delle identità dei carichi di lavoro e la libreria di crittografia Tink per aiutarti a trasferire i dati in Google Cloud in modo sicuro.
  • Un esempio di dominio dati contenente progetti di importazione, non riservati e riservati.
  • Un esempio di sistema di accesso ai dati che consente ai consumatori di dati di richiedere l'accesso ai set di dati e ai proprietari di dati di concedere l'accesso a questi set di dati. L'esempio include anche un gestore del flusso di lavoro che modifica di conseguenza le autorizzazioni IAM di questi set di dati.
• Una guida all'architettura, al design, ai controlli di sicurezza e ai processi operativi che utilizzi per implementare questa architettura (questo documento).

L'architettura del mesh di dati aziendale è progettata per essere compatibile con il blueprint delle basi aziendali. Il blueprint Nuclei dell'azienda fornisce una serie di servizi di base su cui si basa questa architettura, come le reti VPC e il logging. Puoi eseguire il deployment di questa architettura senza eseguire il deployment del blueprint Enterprise Foundations se il tuoGoogle Cloud ambiente fornisce le funzionalità necessarie.

Questo documento è rivolto a cloud architect, data scientist, data engineer e security architect 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 mesh di dati, Google Cloud servizi di dati e Google Cloud implementazione del framework CDMC.

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 è progettata per essere implementata e controllata tramite un flusso di lavoro CI/CD. Il seguente diagramma mostra la relazione tra il livello di dati di cui è stato eseguito il deployment da questa architettura e gli altri livelli del tuo ambiente.

Questo diagramma include quanto segue:

• L'Google Cloud infrastruttura fornisce funzionalità di sicurezza come la crittografia at-rest e la crittografia in transito, nonché elementi di base come il calcolo e lo spazio di archiviazione.
• La base di dati aziendale fornisce una linea di base di risorse come sistemi di identità, di rete, di registrazione, di monitoraggio e di implementazione che ti consentono di adottare Google Cloud per i tuoi carichi di lavoro di dati.
• Il livello dati fornisce varie funzionalità, come importazione dati, archiviazione dei dati, controllo dell'accesso ai dati, governance dei dati, monitoraggio dei dati e condivisione dei dati.
• Il livello di applicazione rappresenta varie applicazioni diverse che utilizzano gli asset del livello di 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 illustra le seguenti operazioni: governance dei dati, importazione dati, elaborazione dei dati, condivisione dei dati e utilizzo dei dati.

Decisioni di architettura chiave

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

Area decisionale	Decisione
Google Cloud architecture
Gerarchia delle risorse	L'architettura utilizza la gerarchia delle risorse del progetto della piattaforma aziendale.
Networking	L'architettura include un esempio di servizio di trasferimento dati che utilizza la Federazione delle identità per i carichi di lavoro e una libreria Tink.
Ruoli e autorizzazioni IAM	L'architettura include ruoli di produttori di dati segmentati, ruoli di consumatori di dati, ruoli di governance dei dati e ruoli della piattaforma di dati.
Servizi dati comuni
Metadati	L'architettura utilizza Data Catalog per gestire i metadati dei dati.
Gestione centralizzata delle norme	Per gestire i criteri, 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 alle risorse dati al proprietario dei dati.
Qualità dei dati	L'architettura utilizza Cloud Data Quality Engine per definire ed eseguire regole di qualità dei dati su colonne di tabelle specifiche, 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 (di 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 di infrastruttura Pipeline di elementi Pipeline del catalogo dei servizi
Repository	Ogni pipeline utilizza un repository separato per consentire la separazione delle responsabilità.
Flusso di lavoro	La procedura richiede che le modifiche all'ambiente di produzione includano un utente che invia la richiesta e un approvatore.
Operazioni cloud
Schede di controllo dei prodotti di dati	Report Engine genera prospetti dei prodotti di dati.
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 basi dell'azienda.

Identità: mappatura dei ruoli ai gruppi

Il data mesh sfrutta l'architettura esistente di gestione del ciclo di vita, autorizzazione e autenticazione delle identità del blueprint delle basi dell'azienda. Gli utenti non vengono assegnati direttamente ai ruoli, ma i gruppi sono 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 su domini, e consumatori basati su domini.

Gli ambiti di autorizzazione 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 hanno come ambito il loro dominio di dati.

Le tabelle seguenti mostrano i vari ruoli utilizzati in questa implementazione del mesh di dati 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 nel 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, i ruoli BigQuery e i ruoli Data Catalog
[e-mail]	Lettori di 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 autorizzazione per utilizzare i modelli di tag	roles/datacatalog.tagTemplateUser
[e-mail]	Gruppo con autorizzazione per utilizzare i modelli di tag e aggiungere tag	roles/datacatalog.tagTemplateUser e roles/datacatalog.tagEditor
[e-mail]	Gruppo di account di servizio 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 nel progetto del dominio di 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 ruoli roles/viewer, BigQuery e 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]	Data steward per il dominio di dati	Ruoli per gestire gli aspetti di governance dei dati e dei metadati

Utenti di dati basati sul dominio

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

Struttura dell'organizzazione

Per distinguere le operazioni di produzione dai 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 di cui hai bisogno per gestire la tua organizzazione. Tutti gli ambienti sono progettati per avere controlli di sicurezza che ti consentono di importare e gestire i 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 vengono gestiti tramite pipeline con architettura e configurazione codificate.

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

La tabella seguente 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 da catalogo dei servizi per eseguire il deployment delle risorse nell'ambiente interattivo.
	prj-c-datagovernance	Contiene tutte le risorse utilizzate dall'implementazione del framework CDMC da parte di Google Cloud.
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 di 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 di dati per il deployment in produzione.

Cartella della piattaforma dati

La cartella della piattaforma di dati contiene tutti i componenti del piano dati e alcune delle risorse CDMC. Inoltre, la cartella della piattaforma di dati e il progetto di governance dei dati contengono le risorse CDMC. Il seguente diagramma mostra le cartelle e i progetti di cui è stato eseguito il deployment nella cartella della piattaforma di 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 di dati.

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

Cartella Produttori

Ogni cartella dei produttori include uno o più domini di dati. Un dominio dati fa riferimento a un raggruppamento logico di elementi di dati che condividono un significato, uno scopo o un contesto aziendale comune. I domini dati ti 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 directory della piattaforma di dati per ogni ambiente.

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

Progetto	Descrizione
Importazione	Il progetto di importazione importa i dati nel dominio dati. L'architettura fornisce esempi di come puoi trasmettere i dati in BigQuery, Cloud Storage e Pub/Sub. Il progetto di importazione contiene anche esempi di Dataflow e Cloud Composer che puoi utilizzare per orchestrare la trasformazione e il trasferimento dei dati importati.
Non riservato	Il progetto non riservato contiene dati anonimizzati. Puoi mascherare, conteggiare, 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 in testo normale. Puoi controllare l'accesso tramite le autorizzazioni IAM.

Cartella del consumatore

La cartella consumer contiene i progetti consumer. I progetti per i consumatori forniscono un meccanismo per segmentare gli utenti dei dati in base al confine di attendibilità richiesto. Ogni progetto viene assegnato a un gruppo di utenti separato e al gruppo viene assegnato l'accesso alle risorse di dati richieste in base al progetto. Puoi utilizzare il progetto consumer per raccogliere, analizzare e integrare i dati del gruppo.

Cartella comune

La cartella common contiene i servizi utilizzati da diversi ambienti e progetti. Questa sezione descrive le funzionalità aggiunte alla cartella comune per abilitare il data mesh aziendale.

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 indirizzati con i servizi Google Cloud.

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

Componente CDMC	Google Cloud servizio	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.
Gestore record	Cloud Run	Un'applicazione che gestisce log e record completi delle attività di elaborazione dei dati, garantendo alle organizzazioni di monitorare e controllare l'utilizzo dei dati.
Norme sull'archiviazione	BigQuery	Una tabella BigQuery che contiene il criterio di archiviazione per i dati.
Diritti	BigQuery	Una tabella BigQuery che memorizza le 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 di dati.
Policy	BigQuery	Una tabella BigQuery contenente pratiche di governance dei dati coerenti (ad esempio tipi di accesso ai dati).
Esportazione della fatturazione	BigQuery	Una tabella che memorizza le informazioni sui costi esportate da Fatturazione Cloud per consentire l'analisi delle metriche sui costi associate alle risorse di dati.
Cloud Data Quality Engine	Cloud Run	Un'applicazione che esegue controlli sulla qualità dei dati per tabelle e colonne.
Risultati relativi alla 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 avviene l'ispezione della protezione dei dati sensibili.
Report Engine	Cloud Run	Un'applicazione che genera report utili per monitorare e misurare la conformità ai controlli del framework CDMC.
Risultati e asset	BigQuery e Pub/Sub	Un report BigQuery di discrepanze o 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 contenente le informazioni sui tag estratte da Data Catalog.
Altri componenti
Gestione dei criteri	Servizio Criteri dell'organizzazione	Un servizio che definisce e applica limitazioni su dove possono essere memorizzati i dati a livello geografico.
Criteri di accesso basati 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 da località e dispositivi consentiti possano accedere alle informazioni sensibili.
Metadati	Data Catalog	Un servizio che memorizza informazioni sui metadati delle tabelle in uso nel data mesh.
Motore di tag	Cloud Run	Un'applicazione che aggiunge tag ai dati nelle tabelle BigQuery.
Report CDMC	Looker Studio	Dashboard che consentono agli analisti di visualizzare i report generati dagli engine dell'architettura CDMC.

Implementazione di CDMC

La tabella seguente descrive in che modo l'architettura implementa i controlli principali nel framework CDMC.

Requisito di controllo CDMC	Implementazione
Conformità al controllo dei dati	Il Report Engine rileva gli asset di dati non conformi e pubblica i risultati in un argomento Pub/Sub. Questi risultati vengono caricati anche in BigQuery per i report utilizzando Looker Studio.
La proprietà dei dati viene stabilita sia per i dati sottoposti a migrazione sia per quelli generati sul cloud	Data Catalog acquisisce automaticamente i metadati tecnici da BigQuery. Il motore di tag applica i tag dei metadati aziendali come il nome del proprietario e il livello di sensibilità da una tabella di riferimento, il che contribuisce ad assicurare che tutti i dati sensibili siano contrassegnati con le informazioni del proprietario per garantire la conformità. Questa procedura di tagging automatico contribuisce a garantire la conformità e la governance dei dati identificando ed etichettando i dati sensibili con le informazioni appropriate sul proprietario.
L'approvvigionamento e il consumo dei dati sono regolati e supportati dall'automazione	Data Catalog classifica gli asset di dati applicando un tag con un indicatore is_authoritative quando sono una fonte autorevole. Data Catalog memorizza automaticamente le informazioni, insieme ai metadati tecnici, in un registro dati. Il Report Engine e il Tag Engine possono verificare e registrare 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 le risorse di dati e Access Context Manager limita l'accesso in base alla posizione dell'utente. Data Catalog archivia le località di archiviazione approvate come tag dei metadati. Report Engine confronta questi tag con la posizione effettiva delle risorse di dati in BigQuery e pubblica eventuali discrepanze come risultati utilizzando Pub/Sub. Security Command Center fornisce un ulteriore livello di monitoraggio generando risultati relativi alle vulnerabilità se i dati vengono archiviati o se vi si accede al di fuori dei criteri definiti.
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 in modo efficace un catalogo di dati sincronizzato continuamente. Data Catalog garantisce che tutte le tabelle e le visualizzazioni 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 di 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ù elevato viene assegnato come tag in Data Catalog a livello di colonna e tabella. Tag Engine gestisce questo processo aggiornando il Data Catalog con i tag di sensibilità ogni volta che vengono aggiunti nuovi asset di dati o vengono modificati quelli esistenti. Questa procedura garantisce una classificazione dei dati aggiornata costantemente in base alla sensibilità, che puoi monitorare e registrare utilizzando Pub/Sub e gli strumenti di generazione di report integrati.
I diritti di accesso ai dati vengono gestiti, applicati e monitorati	I tag di criteri BigQuery controllano l'accesso ai dati sensibili a livello di colonna, garantendo che solo gli utenti autorizzati possano accedere a dati specifici in base al tag di criteri assegnato. IAM gestisce l'accesso complessivo al data warehouse, mentre Data Catalog memorizza le classificazioni della sensibilità. Vengono eseguiti controlli periodici per garantire che tutti i dati sensibili abbiano i tag dei criteri corrispondenti e eventuali discrepanze vengano segnalate utilizzando Pub/Sub per la correzione.
L'accesso, l'utilizzo e i risultati dei dati vengono gestiti in modo etico	I contratti di condivisione dei dati sia per i fornitori che per i consumatori vengono archiviati in un data warehouse BigQuery dedicato per scopi di controllo del consumo. Data Catalog etichetta le risorse di dati con le informazioni del contratto del fornitore, mentre i contratti con i consumatori sono collegati alle associazioni IAM per controllo dell'accesso#39;accesso. Le etichette delle query applicano scopi di utilizzo, richiedendo ai consumatori di specificare uno scopo valido quando eseguono query sui dati sensibili, che vengono convalidati in base ai loro diritti in BigQuery. Una traccia di controllo in BigQuery monitora tutto l'accesso ai dati e garantisce la conformità ai contratti di condivisione dei dati.
I dati sono protetti e i controlli sono evidenti	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 la gestione avanzata delle chiavi. BigQuery implementa la mascheratura dinamica 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 anonimizzazione applicate alle risorse di dati. I controlli automatici assicurano che i metodi di crittografia e di anonimizzazione siano in linea con i criteri di sicurezza predefiniti, con eventuali discrepanze segnalate come risultati utilizzando Pub/Sub.
È definito e operativo un framework per la privacy dei dati	Data Catalog contrassegna gli asset di dati sensibili con informazioni pertinenti per la valutazione dell'impatto, ad esempio la località del soggetto e i link ai report di valutazione. Tag Engine applica questi tag in base alla sensibilità dei dati e a una tabella di criteri in BigQuery, che definisce i requisiti di valutazione in base ai dati e alla residenza del soggetto. Questo processo di tagging automatico consente il monitoraggio e la generazione di report continui sulla conformità ai requisiti di valutazione dell'impatto, garantendo che vengano eseguite valutazioni di impatto sulla protezione dei dati (DPIA) o valutazioni di impatto sulla privacy (PIA) ove necessario.
Il ciclo di vita dei dati è pianificato e gestito	Data Catalog etichetta le risorse di dati con i 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 l'adesione ai criteri del ciclo di vita dei dati e mantiene la conformità ai requisiti di conservazione dei dati, con eventuali discrepanze rilevate e segnalate utilizzando Pub/Sub.
La qualità degli annunci è gestita	Il motore Cloud Data Quality definisce ed esegue regole di qualità dei dati su colonne di tabelle specifiche, misurando la qualità dei dati in base a metriche come correttezza e completezza. I risultati di questi controlli, tra cui le percentuali di successo e le soglie, vengono archiviati come tag in Data Catalog. La memorizzazione di questi risultati consente il monitoraggio e la generazione di report continui sulla qualità dei dati, con eventuali problemi o deviazioni dalle soglie accettabili pubblicate come risultati utilizzando Pub/Sub.
I principi di gestione dei costi vengono 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 esportazione dei dati, che vengono calcolati utilizzando le informazioni di fatturazione esportate da Fatturazione Cloud in BigQuery. La memorizzazione delle metriche relative ai costi consente un monitoraggio e un'analisi dei costi completi, garantendo l'adesione alle norme sui costi e un utilizzo efficiente delle risorse, con eventuali anomalie segnalate utilizzando Pub/Sub.
La provenienza e la derivazione dei dati sono chiare	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 dell'architettura ai dati è controllato tramite un processo indipendente che separa il controllo operativo (ad esempio l'esecuzione di job Dataflow) dal controllo dell'accesso ai dati. L'accesso di un utente a un Google Cloud servizio è definito da un problema ambientale o operativo e viene eseguito il provisioning e l'approvazione da parte di un gruppo di ingegneria cloud. L'accesso di un utente alle Google Cloud risorse di dati (ad esempio una tabella BigQuery) è un problema di privacy, regolamentazione o governance ed è soggetto a un contratto di accesso tra le parti produttrici e di consumo e controllato tramite le seguenti procedure. Il diagramma seguente 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 è gestito dalle seguenti procedure:

• 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, il gestore del flusso di lavoro passa il gruppo, la risorsa e il tag associato al mappatore IAM.
5. Il mapper IAM traduce i tag del gestore del flusso di lavoro in autorizzazioni IAM e concede al gruppo specificato le autorizzazioni IAM per la risorsa dati.
6. Quando un utente vuole accedere all'asset di dati, IAM valuta l'accesso all' Google Cloud asset in base alle autorizzazioni del gruppo.
7. Se consentito, l'utente accede alla risorsa dati.

Networking

Il processo di sicurezza dei dati viene avviato nell'applicazione di origine, che potrebbe essere on-premise o in un altro ambiente esterno al progettoGoogle Cloud di destinazione. Prima di qualsiasi trasferimento di rete, questa applicazione utilizza la federazione delle identità di carico di lavoro per autenticarsi in modo sicuro alle API Google Cloud. Utilizzando queste credenziali, interagisce con Cloud KMS per ottenere o sottoporre a wrapping le chiavi necessarie e poi utilizza la libreria Tink per eseguire la crittografia iniziale e la spersonalizzazione del payload dei dati sensibili in base a modelli predefiniti.

Una volta protetto, il payload dei dati deve essere trasferito in modo sicuro nel Google Cloud progetto di importazione. Per le applicazioni on-premise, puoi utilizzare Cloud Interconnect o potenzialmente Cloud VPN. All'interno della Google Cloud rete, utilizza Private Service Connect per instradare 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 originati dall'origine possano essere importati 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 eseguire 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 di Terraform nell'ambiente dell'architettura. Il seguente diagramma mostra la relazione tra le pipeline.

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

Pipeline	Con provisioning da	Risorse
Pipeline di base	Bootstrap	Cartella e sottocartelle della piattaforma di dati Progetti comuni Account di servizio della pipeline di infrastruttura Trigger Cloud Build per la pipeline di infrastruttura VPC condiviso Perimetro di Controllo di servizio VPC
Pipeline di infrastruttura	Pipeline di base	Progetti per i consumatori Service account del Catalogo dei servizi L'attivatore Cloud Build per la pipeline catalogo dei servizi Account di servizio della pipeline di elementi L'attivatore Cloud Build per la pipeline di elementi
Pipeline del catalogo dei servizi	Pipeline di infrastruttura	Risorse di cui è stato eseguito il deployment nel bucket del catalogo dei servizi
Pipeline di elementi	Pipeline di infrastruttura	Le pipeline di elementi generano i vari contenitori e altri componenti della base di codice utilizzata dal data mesh.

Ogni pipeline ha un proprio insieme di repository da cui estrae codice e file di configurazione. Ogni repository prevede una separazione dei compiti in cui i mittenti e le approvazioni dei deployment del codice operativo sono responsabilità di gruppi diversi.

Deployment interattivo tramite il 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 l'inizializzazione dei servizi Google. Questi modelli preconfigurati sono noti come modelli di servizio. I modelli di servizio ti aiutano a implementare la tua strategia di sicurezza, ad esempio rendendo obbligatoria la crittografia CMEK, e prevengono inoltre che gli utenti abbiano accesso diretto alle API di Google.

Il seguente diagramma mostra i componenti dell'ambiente interattivo e come 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 gli eventuali file di configurazione associati in Cloud Storage.
4. L'ingegnere MLOps configura manualmente le soluzioni 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 elementi

Il processo di importazione dati utilizza Cloud Composer e Dataflow per orchestrare il movimento e la trasformazione dei dati all'interno del dominio dati. La pipeline di elementi genera tutte le risorse necessarie per l'importazione dati e le sposta nella posizione appropriata per consentire ai servizi di accedervi. La pipeline degli elementi genera gli elementi del container utilizzati dall'orchestratore.

Controlli di sicurezza

L'architettura del data mesh aziendale utilizza un modello di sicurezza di difesa in profondità a più livelli che include funzionalità Google Cloud Google Cloudpredefinite, servizi e funzionalità di sicurezza configurati tramite il blueprint delle basi aziendali. Il 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	Google Cloud Implementazione del CDMC	Fornisce un framework di governance che aiuta a proteggere, gestire e controllare le risorse di dati. Per ulteriori informazioni, consulta il CDMC Key Controls Framework.
Deployment	Pipeline di infrastruttura	Fornisce una serie di pipeline che eseguono il deployment dell'infrastruttura, compilano i contenitori e creano pipeline di dati. L'utilizzo delle pipeline consente di verificare, tracciare e ripetere le operazioni.
	Pipeline di elementi	Esegue il deployment di vari componenti non implementati dalla pipeline di infrastruttura.
	Modelli Terraform	Sviluppa l'infrastruttura di sistema.
	Open Policy Agent	Contribuisce a garantire la conformità della piattaforma alle norme selezionate.
Rete	Private Service Connect	Fornisce protezioni contro l'esfiltrazione di dati per le risorse dell'architettura a livello di API e IP. Ti consente di comunicare con le API di Google Cloud utilizzando indirizzi IP privati per evitare di esporre il traffico a internet.
	Rete VPC con indirizzi IP privati	Aiuta a ridurre l'esposizione alle minacce presenti su 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 aiuta a impedire l'uso non autorizzato delle risorse.
	Federazione delle identità per i workload	Non sono necessarie credenziali esterne per trasferire i dati sulla piattaforma da ambienti on-premise.
	Data Catalog	Fornisce un indice degli asset disponibili per gli utenti.
	IAM	Fornisce un accesso granulare.
Crittografia	Cloud KMS	Ti consente di gestire le chiavi di crittografia e i secret e di contribuire a proteggere i tuoi dati tramite la crittografia at-rest e la crittografia in transito.
	Secret Manager	Fornisce un archivio di 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 cripta i dati in transito.
Rilevamento	Security Command Center	Ti aiuta a rilevare errori di configurazione e attività dannose nella tua Google Cloud organizzazione.
	Architettura continua	Controlla continuamente la tua Google Cloud organizzazione rispetto a una serie di criteri OPA che hai definito.
	Motore per suggerimenti IAM	Analizza le autorizzazioni utente e fornisce suggerimenti per ridurle al fine di applicare il principio del privilegio minimo.
	Firewall Insights	Analizza le regole firewall, identifica quelle troppo permissive e suggerisce firewall più restrittivi per contribuire a rafforzare la tua security posture complessiva.
	Cloud Logging	Fornisce visibilità sull'attività di sistema e contribuisce a abilitare il rilevamento di anomalie e attività dannose.
	Cloud Monitoring	Monitora indicatori ed eventi chiave che possono aiutare a identificare attività مشکوکe.
Preventivo	Policy organizzazione	Ti consente di controllare e limitare le azioni all'interno della tua Google Cloud organizzazione.

Workflow

Le sezioni seguenti descrivono il flusso di lavoro dei produttori di dati e dei consumatori di dati, garantendo controlli di accesso 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 in BigQuery.

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

1. Un'applicazione integrata con la federazione delle identità per i carichi di lavoro 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 identificati di nuovo utilizzando un templato.
6. I dati decriptati vengono criptati o mascherati in base a un altro modello di anonimizzazione, quindi inseriti nel progetto non riservato. I tag vengono applicati dal motore di tagging in base alle esigenze.
7. I dati del progetto non riservato vengono trasferiti al progetto riservato e identificati di nuovo.

È consentito il seguente accesso ai dati:

• Gli utenti che hanno accesso al progetto riservato possono accedere a tutti i dati in testo non elaborato.
• Gli utenti che hanno accesso al progetto non riservato possono accedere ai dati mascherati, codificati o criptati in base ai tag associati ai dati e alle relative autorizzazioni.

Flusso di lavoro dei consumatori 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 cerca, 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 di soluzioni per creare un ambiente in cui analizzare e trasformare le risorse di dati.

Riepilogo

Il repository GitHub fornisce istruzioni dettagliate su come eseguire il deployment del data mesh suGoogle Cloud dopo aver eseguito il deployment della base di dati aziendale. Il processo di deployment dell'architettura prevede la modifica dei repository di infrastruttura esistenti e il deployment di nuovi componenti specifici di Data Mesh.

Completa quanto segue:

1. Completa tutti i prerequisiti, tra cui:
   1. Installa Google Cloud CLI, Terraform, Tink, Java e Go.
   2. Esegui il deployment del progetto di base per le aziende (v4.1).
   3. Gestisci i seguenti repository locali:
      • gcp-data-mesh-foundations
      • gcp-bootstrap
      • gcp-environments
      • gcp-networks
      • gcp-org
      • gcp-projects
2. Modifica il blueprint di base esistente e poi esegui il deployment delle applicazioni di data mesh. Per ogni articolo, completa quanto segue:
   1. Nel repository di destinazione, esegui il checkout del ramo Plan.
   2. Per aggiungere componenti di Data Mesh, copia i file e le directory pertinenti dagcp-data-mesh-foundations nella directory di base appropriata. Sostituisci i file, se necessario.
   3. Aggiorna le variabili, i ruoli e le impostazioni di 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 pull e unisci gli ambienti di sviluppo, non di produzione e di produzione.

Passaggi successivi

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