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.

Architettura di mesh di dati.

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

data-mesh-ops@example.com

Amministratori generali del data mesh

roles/owner (piattaforma di dati)

Governance dei dati

Gruppo Descrizione Ruoli

gcp-dm-governance-admins@example.com

Amministratori del progetto di governance dei dati

roles/owner nel progetto di governance dei dati

gcp-dm-governance-developers@example.com

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

gcp-dm-governance-data-readers@example.com

Lettori di informazioni sulla governance dei dati

roles/viewer

gcp-dm-governance-security-administrator@example.com

Amministratori della sicurezza del progetto di governance

roles/orgpolicy.policyAdmin e roles/iam.securityReviewer

gcp-dm-governance-tag-template-users@example.com

Gruppo con autorizzazione per utilizzare i modelli di tag

roles/datacatalog.tagTemplateUser

gcp-dm-governance-tag-users@example.com

Gruppo con autorizzazione per utilizzare i modelli di tag e aggiungere tag

roles/datacatalog.tagTemplateUser e roles/datacatalog.tagEditor

gcp-dm-governance-scc-notifications@example.com

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}-admins@example.com

Amministratori di un dominio di dati specifico

roles/owner nel progetto del dominio di dati

gcp-dm-{data_domain_name}-developers@example.com

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}-data-readers@example.com

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}-data-stewards@example.com

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}-admins@example.com

Amministratori di un progetto per consumatori specifico

roles/owner nel progetto consumer

gcp-dm-consumer-{project_name}-developers@example.com

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}-data-readers@example.com

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.

Struttura dell'organizzazione del mesh di dati.

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.

La 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 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 cartella dei produttori.

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.

L'architettura CDMC.

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.

Gestione dell'accesso ai dati

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.

Relazioni tra 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.

Ambiente interattivo con il catalogo dei servizi.

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.

Controlli di sicurezza nell'architettura del data mesh.

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.

Flusso di lavoro del produttore di dati

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