Implementazione del framework dei controlli chiave CDMC in un data warehouse BigQuery

Badge CDMC

Molte organizzazioni eseguono il deployment di data warehouse su cloud per archiviare informazioni sensibili in modo da analizzarli per vari scopi aziendali. Questo documento descrive come implementare il Cloud Data Management Capabilities (CDMC) Key Controls Framework, gestito dall'Enterprise Data Management Council, in un data warehouse BigQuery.

Il framework CDMC Key Controls è stato pubblicato principalmente per fornitori di servizi cloud e fornitori di tecnologia. Il framework descrive 14 controlli chiave che i provider possono implementare per consentire ai propri clienti di gestire e governare in modo efficace i dati sensibili nel cloud. I controlli sono stati redatti dal CDMC Working Group, con più di 300 professionisti di oltre 100 aziende. Durante la stesura del framework, il CDMC Working Group ha preso in considerazione molti dei requisiti legali e normativi esistenti.

Questa architettura di riferimento di BigQuery e Data Catalog è stata valutata e certificata in base al CDMC Key Controls Framework come soluzione cloud certificata CDMC. L'architettura di riferimento utilizza vari servizi e funzionalità di Google Cloud, nonché librerie pubbliche, per implementare i controlli chiave CDMC e l'automazione consigliata. Questo documento spiega come implementare i controlli chiave per proteggere i dati sensibili in un data warehouse BigQuery.

Architettura

La seguente architettura di riferimento di Google Cloud è in linea con le specifiche di test del framework CDMC Key Controls v1.1.1. I numeri nel diagramma rappresentano i controlli chiave che vengono gestiti con i servizi Google Cloud.

I componenti dell'architettura CDMC.

L'architettura di riferimento si basa sul progetto di data warehouse sicuro, che fornisce un'architettura che consente di proteggere un data warehouse BigQuery che include informazioni sensibili. Nel diagramma precedente, i progetti nella parte superiore del diagramma (in grigio) fanno parte del progetto di data warehouse sicuro, mentre il progetto di governance dei dati (in blu) include i servizi aggiunti per soddisfare i requisiti del framework dei controlli chiave di CDMC. Per implementare il framework CDMC Key Controls, l'architettura estende il progetto di governance dei dati. Il progetto di governance dei dati fornisce controlli come classificazione, gestione del ciclo di vita e gestione della qualità dei dati. Il progetto fornisce anche un modo per verificare l'architettura e creare report sui risultati.

Per ulteriori informazioni su come implementare questa architettura di riferimento, consulta l'architettura di riferimento CDMC di Google Cloud su GitHub.

Panoramica del framework CDMC Key Controls

La seguente tabella riassume il framework CDMC Key Controls.

# Controllo chiavi CDMC Requisito di controllo CDMC
1 Conformità al controllo dei dati I business case nella gestione dei dati cloud sono definiti e regolati. Tutti gli asset di dati che contengono dati sensibili devono essere monitorati per verificare che siano conformi ai controlli chiave CDMC tramite metriche e notifiche automatiche.
2 La proprietà dei dati è confermata sia per i dati migrati che generati nel cloud Il campo Proprietà in un catalogo di dati deve essere compilato per tutti i dati sensibili o altrimenti segnalato a un flusso di lavoro definito.
3 L'approvvigionamento e l'utilizzo dei dati sono regolati e supportati dall'automazione Per tutti gli asset di dati che contengono dati sensibili è necessario compilare un registro di origini dati e punti di provisioning autorevoli oppure, in caso contrario, deve essere segnalato a un flusso di lavoro definito.
4 Vengono gestiti la sovranità dei dati e lo spostamento transfrontaliero dei dati La sovranità dei dati e il trasferimento transfrontaliero di dati sensibili devono essere registrati, controllati e controllati in base a criteri definiti.
5 I cataloghi di dati sono implementati, utilizzati e interoperabili La catalogazione deve essere automatizzata per tutti i dati al momento della creazione o dell'importazione, in modo coerente in tutti gli ambienti.
6 Le classificazioni dei dati vengono definite e utilizzate La classificazione deve essere automatizzata per tutti i dati al momento della creazione o dell'importazione e deve essere sempre attiva. La classificazione è automatica per quanto segue:
  • Informazioni di identificazione personale (PII)
  • Classificazione della sensibilità alle informazioni
  • Informazioni non pubbliche (MNPI)
  • Informazioni che consentono l'identificazione del cliente
  • Classificazione definita dall'organizzazione
7 I diritti dei dati vengono gestiti, applicati e tracciati Per questo controllo è necessario:
  • I diritti e l'accesso per i dati sensibili devono essere concessi al proprietario e all'autore per impostazione predefinita finché non vengono concessi esplicitamente e autorevole.
  • L'accesso deve essere monitorato per tutti i dati sensibili.
8 L'accesso, l'uso e i risultati etici dei dati sono gestiti Lo scopo di consumo dei dati deve essere specificato per tutti gli accordi sulla condivisione dei dati che prevedono dati sensibili. Lo scopo deve specificare il tipo di dati richiesti e, per le organizzazioni globali, l'ambito a livello di paese o persona giuridica.
9 I dati sono protetti e i controlli vengono messi in evidenza Per questo controllo è necessario:
  • È necessario abilitare controlli di sicurezza appropriati per i dati sensibili.
  • Le prove dei controlli di sicurezza devono essere registrate nel catalogo dati per tutti i dati sensibili.
10 Un framework per la privacy dei dati è definito e operativo Le valutazioni di impatto sulla protezione dei dati (DPIA) devono essere attivate automaticamente per tutti i dati personali in base alla giurisdizione.
11 Il ciclo di vita dei dati è pianificato e gestito La conservazione, l'archiviazione e l'eliminazione definitiva dei dati devono essere gestite in base a un piano di conservazione definito.
12 La qualità dei dati viene gestita La misurazione della qualità dei dati deve essere abilitata per i dati sensibili con metriche distribuite, se disponibili.
13 I principi di gestione dei costi vengono stabiliti e applicati I principi di progettazione tecnica vengono stabiliti e applicati. Le metriche dei costi direttamente associate all'utilizzo, all'archiviazione e allo spostamento dei dati devono essere disponibili nel catalogo.
14 La provenienza e la derivazione dei dati vengono comprese Per tutti i dati sensibili devono essere disponibili informazioni sulla derivazione dei dati. Queste informazioni devono includere almeno l'origine da cui i dati sono stati importati o da cui sono stati creati in un ambiente cloud.

1. Conformità al controllo dei dati

Questo controllo richiede che tu possa verificare che tutti i dati sensibili siano monitorati per verificare la conformità a questo framework utilizzando le metriche.

L'architettura utilizza metriche che mostrano la misura in cui ciascuno dei controlli chiave è operativo. L'architettura include anche dashboard che indicano quando le metriche non soddisfano le soglie definite.

L'architettura include rilevatori che pubblicano i risultati e consigli di correzione quando gli asset di dati non soddisfano un controllo chiave. Questi risultati e suggerimenti sono in formato JSON e pubblicati in un argomento Pub/Sub per la distribuzione ai sottoscrittori. Puoi integrare il tuo service desk interno o gli strumenti di gestione dei servizi con l'argomento Pub/Sub in modo che gli incidenti vengano creati automaticamente nel tuo sistema di gestione dei ticket.

L'architettura utilizza Dataflow per creare un sottoscrittore di esempio agli eventi dei risultati, che vengono quindi archiviati in un'istanza BigQuery in esecuzione nel progetto di governance dei dati. Utilizzando una serie di viste fornite, puoi eseguire query sui dati con BigQuery Studio nella console Google Cloud. Puoi anche creare report utilizzando Looker Studio o altri strumenti di business intelligence compatibili con BigQuery. I report che puoi visualizzare includono:

  • Riepilogo dei risultati dell'ultima esecuzione
  • Dettagli risultati ultima esecuzione
  • Metadati ultima esecuzione
  • Asset di dati dell'ultima esecuzione nell'ambito
  • Statistiche del set di dati dell'ultima esecuzione

Il seguente diagramma mostra i servizi applicabili a questo controllo.

I componenti dell'architettura Control 1.

Per soddisfare i requisiti di questo controllo, l'architettura utilizza i seguenti servizi:

  • Pub/Sub pubblica i risultati.
  • Dataflow carica i risultati in un'istanza BigQuery.
  • BigQuery archivia i dati dei risultati e fornisce visualizzazioni di riepilogo.
  • Looker Studio fornisce dashboard e report.

Il seguente screenshot mostra una dashboard di riepilogo di esempio di Looker Studio.

Dashboard di riepilogo di Looker Studio di esempio.

Il seguente screenshot mostra una visualizzazione di esempio dei risultati per asset di dati.

Visualizzazione di esempio dei risultati per asset di dati.

2. La proprietà dei dati viene stabilita sia per i dati migrati che generati nel cloud

Per soddisfare i requisiti di questo controllo, l'architettura esamina automaticamente i dati nel data warehouse BigQuery e aggiunge tag di classificazione dei dati che indicano che i proprietari vengono identificati per tutti i dati sensibili.

Data Catalog, una funzionalità di Dataplex, gestisce due tipi di metadati: metadati tecnici e metadati aziendali. Per un determinato progetto, Data Catalog cataloga automaticamente set di dati, tabelle e viste BigQuery e compila i metadati tecnici. La sincronizzazione tra il catalogo e gli asset di dati viene mantenuta quasi in tempo reale.

L'architettura utilizza Tag Engine per aggiungere i seguenti tag di metadati aziendali a un modello di tag CDMC controls in Data Catalog:

I tag vengono compilati utilizzando valori predefiniti archiviati in una tabella BigQuery di riferimento nel progetto di governance dei dati.

Per impostazione predefinita, i metadati di proprietà sono impostati a livello di tabella nell'architettura, ma puoi modificare l'architettura in modo che i metadati siano impostati a livello di colonna. Per ulteriori informazioni, consulta Tag e modelli di tag di Data Catalog.

Il seguente diagramma mostra i servizi applicabili a questo controllo.

I componenti dell'architettura Control 2.

Per soddisfare i requisiti di questo controllo, l'architettura utilizza i seguenti servizi:

  • Due data warehouse BigQuery: uno memorizza i dati riservati e l'altro archivia i valori predefiniti per la proprietà degli asset dati.
  • Data Catalog archivia i metadati di proprietà tramite tag e modelli di tag.
  • Due istanze Cloud Run, come segue:
    • Un'istanza esegue Report Engine, che controlla se vengono applicati i tag e pubblica i risultati.
    • Un'altra istanza esegue Tag Engine, che esegue il tagging dei dati nel data warehouse protetto.
  • Pub/Sub pubblica i risultati.

Per rilevare problemi relativi a questo controllo, l'architettura controlla se ai dati sensibili è stato assegnato un tag nome del proprietario.

3. L'approvvigionamento e l'utilizzo dei dati sono regolati e supportati dall'automazione

Questo controllo richiede la classificazione delle risorse di dati e un registro di dati di fonti autorevoli e distributori autorizzati. L'architettura utilizza Data Catalog per aggiungere il tag is_authoritative al modello di tag CDMC controls. Questo tag definisce se l'asset di dati è autorevole.

Data Catalog cataloga set di dati, tabelle e visualizzazioni BigQuery con metadati tecnici e metadati aziendali. I metadati tecnici vengono compilati automaticamente e includono l'URL della risorsa, ovvero la posizione del punto di provisioning. I metadati aziendali vengono definiti nel file di configurazione di Tag Engine e includono il tag is_authoritative.

Durante la successiva esecuzione pianificata, Tag Engine compila il tag is_authoritative nel modello di tag CDMC controls utilizzando i valori predefiniti archiviati in una tabella di riferimento in BigQuery.

Il seguente diagramma mostra i servizi applicabili a questo controllo.

i componenti dell'architettura di Control 3.

Per soddisfare i requisiti di questo controllo, l'architettura utilizza i seguenti servizi:

  • Due data warehouse BigQuery: uno memorizza i dati riservati e l'altro archivia i valori predefiniti per l'origine autorità degli asset di dati.
  • Data Catalog archivia i metadati di fonti autorevoli tramite i tag.
  • Due istanze Cloud Run, come segue:
    • Un'istanza esegue Report Engine, che controlla se vengono applicati i tag e pubblica i risultati.
    • Un'altra istanza esegue Tag Engine, che esegue il tagging dei dati nel data warehouse protetto.
  • Pub/Sub pubblica i risultati.

Per rilevare i problemi relativi a questo controllo, l'architettura verifica se ai dati sensibili è stato assegnato il tag di origine autorevole.

4. Vengono gestiti la sovranità dei dati e lo spostamento transfrontaliero dei dati

Questo controllo richiede che l'architettura esamini il registro dei dati per verificare i requisiti di archiviazione specifici per regione e applicare le regole di utilizzo. Un report descrive la posizione geografica degli asset di dati.

L'architettura utilizza Data Catalog per aggiungere il tag approved_storage_location al modello di tag CDMC controls. Questo tag definisce la posizione geografica in cui può essere archiviato l'asset di dati.

La località effettiva dei dati viene archiviata come metadati tecnici nei dettagli della tabella BigQuery. BigQuery non consente agli amministratori di modificare la località di un set di dati o di una tabella. Se invece gli amministratori vogliono modificare la località dei dati, devono copiare il set di dati.

Il vincolo del servizio dei criteri dell'organizzazione per le località delle risorse definisce le regioni di Google Cloud in cui puoi archiviare i dati. Per impostazione predefinita, l'architettura imposta il vincolo sul progetto di dati riservati, ma puoi impostare il vincolo a livello di organizzazione o cartella, se preferisci. Tag Engine replica le località consentite nel modello di tag Data Catalog e memorizza la località nel tag approved_storage_location. Se attivi il livello Premium di Security Command Center e qualcuno aggiorna il vincolo del servizio dei criteri dell'organizzazione per le località delle risorse, Security Command Center genera risultati di vulnerabilità per le risorse archiviate al di fuori del criterio aggiornato.

Gestore contesto accesso definisce la posizione geografica in cui gli utenti devono trovarsi prima di poter accedere agli asset di dati. Utilizzando i livelli di accesso, puoi specificare da quali regioni possono provenire le richieste. Quindi, aggiungi il criterio di accesso al perimetro dei Controlli di servizio VPC per il progetto di dati riservati.

Per tenere traccia dello spostamento dei dati, BigQuery gestisce un audit trail completo per ogni job e query su ciascun set di dati. L'audit trail viene archiviato nella visualizzazione Job schema di informazioni di BigQuery.

Il seguente diagramma mostra i servizi applicabili a questo controllo.

I componenti dell'architettura Control 4.

Per soddisfare i requisiti di questo controllo, l'architettura utilizza i seguenti servizi:

  • Il servizio criteri dell'organizzazione definisce e applica il vincolo per le località delle risorse.
  • Gestore contesto accesso definisce le località da cui gli utenti possono accedere ai dati.
  • Due data warehouse BigQuery: uno archivia i dati riservati e l'altro ospita una funzione remota utilizzata per ispezionare i criteri di geolocalizzazione.
  • Data Catalog archivia le località di archiviazione approvate come tag.
  • Due istanze Cloud Run, come segue:
    • Un'istanza esegue Report Engine, che controlla se vengono applicati i tag e pubblica i risultati.
    • Un'altra istanza esegue Tag Engine, che esegue il tagging dei dati nel data warehouse protetto.
  • Pub/Sub pubblica i risultati.
  • Cloud Logging scrive gli audit log.
  • Security Command Center genera report su qualsiasi risultato relativo alla località delle risorse o all'accesso ai dati.

Per rilevare i problemi relativi a questo controllo, l'architettura include un risultato che indica se il tag delle località approvato include la località dei dati sensibili.

5. I cataloghi di dati sono implementati, utilizzati e interoperabili

Questo controllo richiede l'esistenza di un catalogo dati e che l'architettura possa analizzare asset nuovi e aggiornati per aggiungere metadati in base alle esigenze.

Per soddisfare i requisiti di questo controllo, l'architettura utilizza Data Catalog. Data Catalog registra automaticamente gli asset Google Cloud, inclusi set di dati, tabelle e viste BigQuery. Quando crei una nuova tabella in BigQuery, Data Catalog registra automaticamente i metadati tecnici e lo schema della nuova tabella. Quando aggiorni una tabella in BigQuery, Data Catalog aggiorna le voci in modo quasi istantaneo.

Il seguente diagramma mostra i servizi applicabili a questo controllo.

I componenti dell'architettura Control 5.

Per soddisfare i requisiti di questo controllo, l'architettura utilizza i seguenti servizi:

  • Due data warehouse BigQuery: uno memorizza i dati riservati e l'altro archivia i dati non riservati.
  • Data Catalog archivia i metadati tecnici per tabelle e campi.

Per impostazione predefinita, in questa architettura Data Catalog archivia i metadati tecnici di BigQuery. Se necessario, puoi integrare Data Catalog con altre origini dati.

6. Le classificazioni dei dati vengono definite e utilizzate

Questa valutazione richiede che i dati possano essere classificati in base alla loro sensibilità, ad esempio se si tratta di PII, identifica i clienti o soddisfano qualche altro standard definito dalla tua organizzazione. Per soddisfare i requisiti di questo controllo, l'architettura crea un report sugli asset di dati e sulla relativa sensibilità. Puoi utilizzare questo report per verificare se le impostazioni di sensibilità sono corrette. Inoltre, ogni nuovo asset di dati o modifica a uno esistente comporta un aggiornamento del catalogo di dati.

Le classificazioni sono memorizzate nel tag sensitive_category nel modello di tag di Data Catalog a livello di tabella e a livello di colonna. Una tabella di riferimento della classificazione consente di classificare i tipi di informazioni (infoType) di Sensitive Data Protection (infoType) disponibili con ranking più elevati per i contenuti più sensibili.

Per soddisfare i requisiti di questo controllo, l'architettura utilizza Sensitive Data Protection, Data Catalog e Tag Engine per aggiungere i seguenti tag alle colonne sensibili delle tabelle BigQuery:

  • is_sensitive: indica se l'asset di dati contiene informazioni sensibili
  • sensitive_category: la categoria dei dati; uno dei seguenti valori:
    • Informazioni sensibili che consentono l'identificazione personale
    • Informazioni che consentono l'identificazione personale
    • Informazioni personali sensibili
    • Informazioni personali
    • Informazioni pubbliche

Puoi modificare le categorie di dati in base ai tuoi requisiti. Ad esempio, puoi aggiungere la classificazione MNPI (Material Non-Public Information).

Dopo che Sensitive Data Protection ha ispezionato i dati, Tag Engine legge le tabelle DLP results per asset per compilare i risultati. Se una tabella contiene colonne con uno o più infoType sensibili, viene determinato l'infoType più rilevante e sia le colonne sensibili che l'intera tabella sono taggate come la categoria con il ranking più alto. Tag Engine assegna inoltre un tag di criterio corrispondente alla colonna e il tag booleano is_sensitive alla tabella.

Puoi utilizzare Cloud Scheduler per automatizzare l'ispezione della protezione dei dati sensibili.

Il seguente diagramma mostra i servizi applicabili a questo controllo.

I componenti dell'architettura Control 6.

Per soddisfare i requisiti di questo controllo, l'architettura utilizza i seguenti servizi:

  • Quattro data warehouse BigQuery archiviano le seguenti informazioni:
    • Dati riservati
    • Informazioni dei risultati di Sensitive Data Protection
    • Dati di riferimento per la classificazione dei dati
    • Informazioni sull'esportazione dei tag
  • Data Catalog memorizza i tag di classificazione.
  • Sensitive Data Protection ispeziona gli asset per individuare infoType sensibili.
  • Compute Engine esegue lo script Ispeziona set di dati, che attiva un job di Sensitive Data Protection per ogni set di dati BigQuery.
  • Due istanze Cloud Run, come segue:
    • Un'istanza esegue Report Engine, che controlla se vengono applicati i tag e pubblica i risultati.
    • Un'altra istanza esegue Tag Engine, che esegue il tagging dei dati nel data warehouse protetto.
  • Pub/Sub pubblica i risultati.

Per rilevare problemi relativi a questo controllo, l'architettura include i seguenti risultati:

  • Indica se ai dati sensibili viene assegnato un tag di categoria sensibile.
  • Indica se ai dati sensibili viene assegnato un tag di tipo di sensibilità a livello di colonna.

7. I diritti dei dati vengono gestiti, applicati e tracciati

Per impostazione predefinita, solo ai creator e ai proprietari vengono assegnati diritti e accesso ai dati sensibili. Inoltre, questo controllo richiede che l'architettura monitori tutti gli accessi ai dati sensibili.

Per soddisfare i requisiti di questo controllo, l'architettura utilizza la tassonomia dei tag di criteri cdmc sensitive data classification in BigQuery per controllare l'accesso alle colonne che contengono dati riservati nelle tabelle BigQuery. La tassonomia include i seguenti tag di criteri:

  • Informazioni sensibili che consentono l'identificazione personale
  • Informazioni che consentono l'identificazione personale
  • Informazioni personali sensibili
  • Informazioni personali

I tag di criteri consentono di controllare chi può visualizzare le colonne sensibili nelle tabelle BigQuery. L'architettura mappa questi tag di criteri a classificazioni di sensibilità derivate dagli infoType di Sensitive Data Protection. Ad esempio, il tag criterio sensitive_personal_identifiable_information e la categoria sensibile vengono mappati a infoType come AGE, DATE_OF_BIRTH, PHONE_NUMBER e EMAIL_ADDRESS.

L'architettura utilizza Identity and Access Management (IAM) per gestire i gruppi, gli utenti e gli account di servizio che richiedono l'accesso ai dati. Le autorizzazioni IAM vengono concesse a un determinato asset per l'accesso a livello di tabella. Inoltre, l'accesso a livello di colonna basato sui tag di criteri consente un accesso granulare agli asset di dati sensibili. Per impostazione predefinita, gli utenti non hanno accesso alle colonne con tag di criteri definiti.

Per garantire che solo gli utenti autenticati possano accedere ai dati, Google Cloud utilizza Cloud Identity, che puoi federare con i tuoi provider di identità esistenti per autenticare gli utenti.

Questo controllo richiede inoltre che l'architettura controlli regolarmente gli asset di dati per i quali non sono stati definiti diritti. Il rilevatore, gestito da Cloud Scheduler, verifica se sono presenti i seguenti scenari:

  • Un asset di dati include una categoria sensibile, ma non è presente un tag di criteri correlato.
  • Una categoria non corrisponde al tag di criteri.

Quando si verificano questi scenari, il rilevatore genera risultati pubblicati da Pub/Sub e quindi scritti nella tabella events in BigQuery da Dataflow. Puoi quindi distribuire i risultati allo strumento di correzione, come descritto nella sezione 1. Conformità al controllo dei dati.

Il seguente diagramma mostra i servizi applicabili a questo controllo.

I componenti dell'architettura Control 7.

Per soddisfare i requisiti di questo controllo, l'architettura utilizza i seguenti servizi:

  • Un data warehouse BigQuery archivia i dati riservati e le associazioni di tag di criteri per avere un controllo dell'accesso granulare.
  • IAM gestisce l'accesso.
  • Data Catalog memorizza i tag a livello di tabella e di colonna per la categoria sensibile.
  • Due istanze Cloud Run, come segue:
    • Un'istanza esegue Report Engine, che controlla se vengono applicati i tag e pubblica i risultati.
    • Un'altra istanza esegue Tag Engine, che esegue il tagging dei dati nel data warehouse protetto.

Per rilevare problemi relativi a questo controllo, l'architettura verifica se i dati sensibili hanno un tag di criteri corrispondente.

8. L'accesso, l'uso e i risultati etici dei dati sono gestiti

Questo controllo richiede che l'architettura memorizzi i contratti di condivisione dei dati sia dal fornitore che dai consumatori dei dati, compreso un elenco di finalità di consumo approvate. Lo scopo di utilizzo dei dati sensibili viene quindi mappato ai diritti archiviati in BigQuery utilizzando le etichette delle query. Quando un consumatore esegue query su dati sensibili in BigQuery, deve specificare uno scopo valido che corrisponda al suo diritto (ad esempio, SET @@query_label = “use:3”;).

L'architettura utilizza Data Catalog per aggiungere i seguenti tag al modello di tag CDMC controls. Questi tag rappresentano il contratto di condivisione dei dati con il fornitore di dati:

  • approved_use: l'uso approvato o gli utenti dell'asset di dati
  • sharing_scope_geography: l'elenco delle località geografiche in cui può essere condiviso l'asset di dati
  • sharing_scope_legal_entity: l'elenco di entità concordate che possono condividere l'asset di dati

Un data warehouse BigQuery separato include il set di dati entitlement_management con le seguenti tabelle:

  • provider_agreement: il contratto di condivisione dei dati con il fornitore dei dati, inclusi la persona giuridica e l'ambito geografico concordati. Questi dati sono i valori predefiniti per i tag shared_scope_geography e sharing_scope_legal_entity.
  • consumer_agreement: il contratto di condivisione dei dati con il consumatore dei dati, inclusi la persona giuridica e l'ambito geografico concordati. Ogni contratto è associato a un'associazione IAM per l'asset di dati.
  • use_purpose: la finalità di consumo, ad esempio la descrizione dell'utilizzo e le operazioni consentite per l'asset di dati
  • data_asset: informazioni sull'asset di dati, come il nome della risorsa e i dettagli sul proprietario dei dati.

Per verificare i contratti di condivisione dei dati, BigQuery gestisce un audit trail completo per ogni job e query su ciascun set di dati. L'audit trail viene archiviato nella visualizzazione Job schema di informazioni di BigQuery. Dopo aver associato un'etichetta di query a una sessione ed eseguito query all'interno della sessione, puoi raccogliere gli audit log per le query con quell'etichetta. Per ulteriori informazioni, consulta Riferimento agli audit log per BigQuery.

Il seguente diagramma mostra i servizi applicabili a questo controllo.

I componenti dell'architettura Control 8.

Per soddisfare i requisiti di questo controllo, l'architettura utilizza i seguenti servizi:

  • Due data warehouse BigQuery: uno archivia i dati riservati e l'altro archivia i dati relativi ai diritti, inclusi i contratti di condivisione dei dati per provider e consumatori e lo scopo di utilizzo approvato.
  • Data Catalog archivia le informazioni del contratto per la condivisione dei dati del provider come tag.
  • Due istanze Cloud Run, come segue:
    • Un'istanza esegue Report Engine, che controlla se vengono applicati i tag e pubblica i risultati.
    • Un'altra istanza esegue Tag Engine, che esegue il tagging dei dati nel data warehouse protetto.
  • Pub/Sub pubblica i risultati.

Per rilevare problemi relativi a questo controllo, l'architettura include i seguenti risultati:

  • Indica se esiste una voce per un asset di dati nel set di dati entitlement_management.
  • Indica se viene eseguita un'operazione su una tabella sensibile con un caso d'uso scaduto (ad esempio, valid_until_date in consumer_agreement table è trascorso).
  • Indica se viene eseguita un'operazione su una tabella sensibile con una chiave di etichetta non corretta.
  • Indica se viene eseguita un'operazione su una tabella sensibile con un valore di etichetta dei casi d'uso vuoto o non approvato.
  • Indica se viene eseguita una query su una tabella sensibile con un metodo operativo non approvato (ad esempio, SELECT o INSERT).
  • Indica se lo scopo registrato specificato dal consumatore durante l'esecuzione di query sui dati sensibili corrisponde al contratto di condivisione dei dati.

9. I dati sono protetti e i controlli evidenziano

Questo controllo richiede l'implementazione della crittografia e dell'anonimizzazione dei dati per proteggere i dati sensibili e fornire un record di questi controlli.

Questa architettura si basa sulla sicurezza predefinita di Google, che include la crittografia at-rest. Inoltre, l'architettura consente di gestire le chiavi utilizzando chiavi di crittografia gestite dal cliente (CMEK). Cloud KMS ti consente di criptare i dati con chiavi di crittografia supportate da software o con moduli di sicurezza hardware (HSM) convalidati di livello 3 e FIPS 140-2.

L'architettura utilizza il mascheramento dinamico dei dati a livello di colonna configurato tramite tag di criteri e archivia i dati riservati all'interno di un perimetro separato dei Controlli di servizio VPC. Puoi anche aggiungere l'anonimizzazione a livello di applicazione, che puoi implementare sia on-premise che come parte della pipeline di importazione dati.

Per impostazione predefinita, l'architettura implementa la crittografia CMEK con i moduli HSM, ma supporta anche Cloud External Key Manager (Cloud EKM).

La tabella seguente descrive il criterio di sicurezza di esempio che l'architettura implementa per la regione us-central1. Puoi adattare il criterio per soddisfare i tuoi requisiti, ad esempio aggiungendo criteri diversi per regioni diverse.

Sensibilità dei dati Metodo di crittografia predefinito Altri metodi di crittografia consentiti Metodo di anonimizzazione predefinito Altri metodi di anonimizzazione consentiti
Informazioni pubbliche Crittografia predefinita Qualsiasi Nessuno Qualsiasi
Informazioni sensibili che consentono l'identificazione personale CMEK con HSM EKM Annulla Hash SHA-256 o valore di mascheramento predefinito
Informazioni che consentono l'identificazione personale CMEK con HSM EKM Hash SHA-256 Annulla o valore di mascheramento predefinito
Informazioni personali sensibili CMEK con HSM EKM Valore di mascheramento predefinito Hash SHA-256 o nullify
Informazioni personali CMEK con HSM EKM Valore di mascheramento predefinito Hash SHA-256 o nullify

L'architettura utilizza Data Catalog per aggiungere il tag encryption_method al modello di tag CDMC controls a livello di tabella. encryption_method definisce il metodo di crittografia utilizzato dall'asset di dati.

Inoltre, l'architettura crea un tag security policy template per identificare il metodo di anonimizzazione applicato a un determinato campo. L'architettura utilizza platform_deid_method, che viene applicato utilizzando il mascheramento dei dati dinamici. Puoi aggiungere app_deid_method e compilarlo utilizzando le pipeline di importazione dati di Dataflow e Sensitive Data Protection incluse nel progetto di data warehouse sicuro.

Il seguente diagramma mostra i servizi applicabili a questo controllo.

I componenti dell'architettura Control 9.

Per soddisfare i requisiti di questo controllo, l'architettura utilizza i seguenti servizi:

  • Due istanze facoltative di Dataflow: una esegue l'anonimizzazione a livello di applicazione e l'altra la reidentificazione.
  • Tre data warehouse BigQuery: uno archivia i dati riservati, uno archivia i dati non riservati e il terzo archivia il criterio di sicurezza.
  • Data Catalog archivia i modelli di tag di crittografia e anonimizzazione.
  • Due istanze Cloud Run, come segue:
    • Un'istanza esegue Report Engine, che controlla se vengono applicati i tag e pubblica i risultati.
    • Un'altra istanza esegue Tag Engine, che esegue il tagging dei dati nel data warehouse protetto.
  • Risultati pubblicati da Pub/Sub.

Per rilevare problemi relativi a questo controllo, l'architettura include i seguenti risultati:

  • Il valore del tag del metodo di crittografia non corrisponde ai metodi di crittografia consentiti per la sensibilità e la località specificate.
  • Una tabella contiene colonne sensibili, ma il tag del modello dei criteri di sicurezza contiene un metodo di anonimizzazione a livello di piattaforma non valido.
  • Una tabella contiene colonne sensibili, ma manca il tag Modello dei criteri di sicurezza.

10. Un framework per la privacy dei dati è definito e operativo

Questo controllo richiede che l'architettura esamini il catalogo dei dati e le classificazioni per determinare se devi creare un report sulla valutazione dell'impatto sulla protezione dei dati (DPIA) o un report sulla valutazione di impatto sulla privacy (PIA). Le valutazioni della privacy variano in modo significativo tra le aree geografiche e gli enti regolatori. Per determinare se sia necessaria una valutazione dell'impatto, l'architettura deve considerare la residenza dei dati e la residenza dell'interessato.

L'architettura utilizza Data Catalog per aggiungere i seguenti tag al modello di tag Impact assessment:

  • subject_locations: la località dei soggetti a cui fanno riferimento i dati in questa risorsa.
  • is_dpia: se è stata completata una valutazione di impatto sulla privacy dei dati (DPIA) per questo asset.
  • is_pia: se è stata completata una valutazione di impatto sulla privacy (PIA) per questa risorsa.
  • impact_assessment_reports: link esterno alla posizione in cui è archiviato il report sulla valutazione dell'impatto.
  • most_recent_assessment: la data della valutazione dell'impatto più recente.
  • oldest_assessment: data della prima valutazione dell'impatto.

Tag Engine aggiunge questi tag a ogni asset di dati sensibili, come definito dal controllo 6. Il rilevatore convalida questi tag in base a una tabella dei criteri in BigQuery, che include combinazioni valide di residenza dei dati, posizione dell'oggetto, sensibilità dei dati (ad esempio, se si tratta di PII) e tipo di valutazione dell'impatto (PIA o DPIA) richiesto.

Il seguente diagramma mostra i servizi applicabili a questo controllo.

I componenti dell'architettura Control 10.

Per soddisfare i requisiti di questo controllo, l'architettura utilizza i seguenti servizi:

  • Quattro data warehouse BigQuery archiviano le seguenti informazioni:
    • Dati riservati
    • Dati non riservati
    • Criteri di valutazione dell'impatto e timestamp dei diritti
    • Esportazioni di tag utilizzate per la dashboard
  • Data Catalog archivia i dettagli della valutazione dell'impatto nei tag all'interno dei modelli di tag.
  • Due istanze Cloud Run, come segue:
    • Un'istanza esegue Report Engine, che controlla se vengono applicati i tag e pubblica i risultati.
    • Un'altra istanza esegue Tag Engine, che esegue il tagging dei dati nel data warehouse protetto.
  • Pub/Sub pubblica i risultati.

Per rilevare problemi relativi a questo controllo, l'architettura include i seguenti risultati:

  • Esistono dati sensibili senza un modello di valutazione dell'impatto.
  • I dati sensibili esistono senza un link a un report DPIA o PIA.
  • I tag non soddisfano i requisiti della tabella delle norme.
  • La valutazione dell'impatto è precedente all'ultimo diritto approvato per l'asset di dati nella tabella dei contratti con i consumatori.

11. Il ciclo di vita dei dati è pianificato e gestito

Questo controllo richiede la possibilità di ispezionare tutti gli asset di dati per determinare che esista e rispetta un criterio del ciclo di vita dei dati.

L'architettura utilizza Data Catalog per aggiungere i seguenti tag al modello di tag CDMC controls:

  • retention_period: il tempo, in giorni, per conservare la tabella
  • expiration_action: se archiviare o eliminare definitivamente la tabella al termine del periodo di conservazione

Per impostazione predefinita, l'architettura utilizza il periodo di conservazione e l'azione di scadenza seguenti:

Categoria di dati Periodo di conservazione, in giorni Azione per la scadenza
Informazioni sensibili che consentono l'identificazione personale 60 Elimina definitivamente
Informazioni che consentono l'identificazione personale 90 Archivia
Informazioni personali sensibili 180 Archivia
Informazioni personali 180 Archivia

Record Manager, un asset open source per BigQuery, automatizza l'eliminazione definitiva e l'archiviazione delle tabelle BigQuery in base ai valori dei tag sopra e a un file di configurazione. La procedura di eliminazione definitiva imposta una data di scadenza su una tabella e crea una tabella di snapshot con una data di scadenza definita nella configurazione di Record Manager. Per impostazione predefinita, la scadenza è di 30 giorni. Durante il periodo di eliminazione temporanea, puoi recuperare la tabella. La procedura di archiviazione crea una tabella esterna per ogni tabella BigQuery che supera il periodo di conservazione. La tabella viene archiviata in Cloud Storage in formato parquet e sottoposta ad upgrade a una tabella BigLake che consente di taggare il file esterno con metadati in Data Catalog.

Il seguente diagramma mostra i servizi applicabili a questo controllo.

I componenti dell'architettura Control 11.

Per soddisfare i requisiti di questo controllo, l'architettura utilizza i seguenti servizi:

  • Due data warehouse BigQuery: uno memorizza i dati riservati e l'altro archivia il criterio di conservazione dei dati.
  • Due istanze Cloud Storage, una fornisce archiviazione in archivio e l'altra archivia i record.
  • Data Catalog archivia il periodo di conservazione e l'azione nei modelli di tag e nei tag.
  • Due istanze Cloud Run: una esegue il Gestore record e l'altra il deployment dei rilevatori.
  • Tre istanze Cloud Run, come segue:
    • Un'istanza esegue Report Engine, che controlla se vengono applicati i tag e pubblica i risultati.
    • Un'altra istanza esegue Tag Engine, che esegue il tagging dei dati nel data warehouse protetto.
    • Un'altra istanza esegue Record Manager, che automatizza l'eliminazione definitiva e l'archiviazione delle tabelle BigQuery.
  • Pub/Sub pubblica i risultati.

Per rilevare problemi relativi a questo controllo, l'architettura include i seguenti risultati:

  • Per gli asset sensibili, assicurati che il metodo di conservazione sia in linea con il criterio relativo alla posizione dell'asset.
  • Per gli asset sensibili, assicurati che il periodo di conservazione sia in linea con le norme relative alla posizione dell'asset.

12. La qualità dei dati viene gestita

Questo controllo richiede la possibilità di misurare la qualità dei dati in base alla profilazione dei dati o a metriche definite dall'utente.

L'architettura include la possibilità di definire regole sulla qualità dei dati per un valore singolo o aggregato e di assegnare soglie a una colonna specifica della tabella. Include modelli di tag per garantire la correttezza e la completezza. Data Catalog aggiunge i seguenti tag a ogni modello di tag:

  • column_name: il nome della colonna a cui si applica la metrica
  • metric: nome della metrica o della regola di qualità
  • rows_validated: il numero di righe convalidate
  • success_percentage: la percentuale di valori che soddisfano questa metrica
  • acceptable_threshold: la soglia accettabile per questa metrica
  • meets_threshold: se il punteggio di qualità (il valore success_percentage) soddisfa la soglia accettabile
  • most_recent_run: l'ultima volta in cui è stata eseguita la metrica o la regola di qualità

Il seguente diagramma mostra i servizi applicabili a questo controllo.

I componenti dell'architettura Control 12.

Per soddisfare i requisiti di questo controllo, l'architettura utilizza i seguenti servizi:

  • Tre data warehouse BigQuery: uno archivia i dati sensibili, uno archivia i dati non sensibili e il terzo archivia le metriche della regola di qualità.
  • Data Catalog memorizza i risultati sulla qualità dei dati nei modelli di tag e nei tag.
  • Cloud Scheduler definisce quando viene eseguito Cloud Data Quality Engine.
  • Tre istanze Cloud Run, come segue:
    • Un'istanza esegue Report Engine, che controlla se vengono applicati i tag e pubblica i risultati.
    • Un'altra istanza esegue Tag Engine, che esegue il tagging dei dati nel data warehouse protetto.
    • La terza istanza esegue il Cloud Data Quality Engine.
  • Cloud Data Quality Engine definisce le regole sulla qualità dei dati e pianifica i controlli di qualità dei dati per tabelle e colonne.
  • Pub/Sub pubblica i risultati.

Una dashboard di Looker Studio mostra i report sulla qualità dei dati sia a livello di tabella che a livello di colonna.

Per rilevare problemi relativi a questo controllo, l'architettura include i seguenti risultati:

  • I dati sono sensibili, ma non viene applicato alcun modello di tag per la qualità dei dati (corretta e completezza).
  • I dati sono sensibili, ma il tag relativo alla qualità dei dati non viene applicato alla colonna sensibile.
  • I dati sono sensibili, ma i risultati relativi alla qualità dei dati non rientrano nella soglia impostata nella regola.
  • I dati non sono sensibili e i risultati relativi alla qualità dei dati non rientrano nella soglia impostata dalla regola.

In alternativa al Cloud Data Quality Engine, puoi configurare attività relative alla qualità dei dati Dataplex.

13. I principi di gestione dei costi vengono stabiliti e applicati

Questo controllo richiede la possibilità di ispezionare gli asset di dati per confermare l'utilizzo dei costi, in base ai requisiti dei criteri e all'architettura dei dati. Le metriche relative ai costi devono essere complete e non solo limitate all'uso e allo spostamento dello spazio di archiviazione.

L'architettura utilizza Data Catalog per aggiungere i seguenti tag al modello di tag cost_metrics:

  • total_query_bytes_billed: numero totale di byte di query fatturati per questo asset di dati dall'inizio del mese corrente.
  • total_storage_bytes_billed: numero totale di byte di archiviazione fatturati per questo asset di dati dall'inizio del mese corrente.
  • total_bytes_transferred: somma dei byte trasferiti tra regioni in questo asset di dati.
  • estimated_query_cost: costo stimato delle query, in dollari statunitensi, per l'asset di dati per il mese corrente.
  • estimated_storage_cost: costo di archiviazione stimato, in dollari statunitensi, per l'asset di dati per il mese corrente.
  • estimated_egress_cost: traffico in uscita stimato in dollari statunitensi per il mese corrente in cui l'asset di dati è stato utilizzato come tabella di destinazione.

L'architettura esporta le informazioni sui prezzi dal fatturazione Cloud a una tabella BigQuery denominata cloud_pricing_export.

Il seguente diagramma mostra i servizi applicabili a questo controllo.

I componenti dell'architettura Control 13.

Per soddisfare i requisiti di questo controllo, l'architettura utilizza i seguenti servizi:

  • Fatturazione Cloud fornisce i dati di fatturazione.
  • Data Catalog memorizza le informazioni sui costi nei modelli di tag e nei tag.
  • BigQuery archivia le informazioni sui prezzi esportate e le informazioni cronologiche del job di query attraverso la vista INFORMATION_SCHEMA integrata.
  • Due istanze Cloud Run, come segue:
    • Un'istanza esegue Report Engine, che controlla se vengono applicati i tag e pubblica i risultati.
    • Un'altra istanza esegue Tag Engine, che esegue il tagging dei dati nel data warehouse protetto.
  • Pub/Sub pubblica i risultati.

Per rilevare problemi relativi a questo controllo, l'architettura verifica se esistono asset di dati sensibili senza che siano associate metriche dei costi.

14. La provenienza e la derivazione dei dati vengono comprese

Questo controllo richiede la possibilità di ispezionare la tracciabilità dell'asset di dati dall'origine e qualsiasi modifica alla derivazione dell'asset di dati.

Per gestire le informazioni sulla provenienza e sulla derivazione dei dati, l'architettura utilizza le funzionalità integrate di Data Lineage in Data Catalog. Inoltre, gli script di importazione dati definiscono l'origine finale e la aggiungono come nodo aggiuntivo al grafico di derivazione dei dati.

Per soddisfare i requisiti di questo controllo, l'architettura utilizza Data Catalog per aggiungere il tag ultimate_source al modello di tag CDMC controls. Il tag ultimate_source definisce l'origine di questo asset di dati.

Il seguente diagramma mostra i servizi applicabili a questo controllo.

I componenti dell'architettura Control 14.

Per soddisfare i requisiti di questo controllo, l'architettura utilizza i seguenti servizi:

  • Due data warehouse BigQuery: uno archivia i dati riservati e l'altro i dati di origine definitivi.
  • Data Catalog archivia la sorgente definitiva nei modelli di tag e nei tag.
  • Gli script di importazione dati caricano i dati da Cloud Storage, definiscono l'origine finale e aggiungono l'origine al grafico della derivazione dei dati.
  • Due istanze Cloud Run, come segue:
    • Un'istanza esegue Report Engine, che controlla se vengono applicati i tag e pubblica i risultati.
    • Un'altra istanza esegue Tag Engine, che esegue il tagging dei dati nel data warehouse protetto.
  • Pub/Sub pubblica i risultati.

Per rilevare problemi relativi a questo controllo, l'architettura include i seguenti controlli:

  • I dati sensibili sono identificati senza un tag di origine definitivo.
  • Il grafico di derivazione non viene compilato per gli asset di dati sensibili.

Riferimento tag

In questa sezione vengono descritti i modelli di tag e i tag utilizzati da questa architettura per soddisfare i requisiti dei controlli chiave CDMC.

Modelli di tag di controllo CDMC a livello di tabella

Nella tabella seguente sono elencati i tag che fanno parte del modello di tag di controllo CDMC e che vengono applicati alle tabelle.

Tag ID tag Controllo chiavi applicabile
Località di archiviazione approvata approved_storage_location 4
Uso approvato approved_use 8
Email proprietario dati data_owner_email 2
Nome proprietario dei dati data_owner_name 2
Metodo di crittografia encryption_method 9
Azione di scadenza expiration_action 11
È autorevole is_authoritative 3
È sensibile is_sensitive 6
Categoria sensibile sensitive_category 6
Area geografica ambito di condivisione sharing_scope_geography 8
Persona giuridica che rientra nell'ambito della condivisione sharing_scope_legal_entity 8
Periodo di conservazione retention_period 11
Fonte definitiva ultimate_source 14

Modello di tag per la valutazione dell'impatto

Nella tabella seguente sono elencati i tag che fanno parte del modello di tag della valutazione dell'impatto e che vengono applicati alle tabelle.

Tag ID tag Controllo chiavi applicabile
Località oggetto subject_locations 10
È una valutazione d'impatto della DPIA? is_dpia 10
È una valutazione di impatto PIA is_pia 10
Report sulla valutazione dell'impatto impact_assessment_reports 10
Valutazione dell’impatto più recente most_recent_assessment 10
Valutazione dell'impatto meno recente oldest_assessment 10

Modello di tag delle metriche di costo

Nella tabella seguente sono elencati i tag che fanno parte del modello di tag delle metriche di costo e che vengono applicati alle tabelle.

Tag Scheda ID Controllo chiavi applicabile
Costo stimato della query estimated_query_cost 13
Costo di archiviazione stimato estimated_storage_cost 13
Costo in uscita stimato estimated_egress_cost 13
Byte di query totali fatturati total_query_bytes_billed 13
Byte di archiviazione totali fatturati total_storage_bytes_billed 13
Byte totali trasferiti total_bytes_transferred 13

Modello di tag Sensibilità dei dati

Nella tabella seguente sono elencati i tag che fanno parte del modello di tag Sensibilità dei dati e che vengono applicati ai campi.

Tag ID tag Controllo chiavi applicabile
Campo sensibile sensitive_field 6
Tipo sensibile sensitive_category 6

Modello di tag dei criteri di sicurezza

Nella tabella seguente sono elencati i tag che fanno parte del modello di tag dei criteri di sicurezza e che vengono applicati ai campi.

Tag ID tag Controllo chiavi applicabile
Metodo di anonimizzazione dell'applicazione app_deid_method 9
Metodo di anonimizzazione della piattaforma platform_deid_method 9

Modelli di tag della qualità dei dati

Nella tabella seguente sono elencati i tag che fanno parte dei modelli di tag Completezza e Correttezza Qualità dei dati e che vengono applicati ai campi.

Tag ID tag Controllo chiavi applicabile
Soglia accettabile acceptable_threshold 12
Nome colonna column_name 12
Soddisfa la soglia meets_threshold 12
Metrica metric 12
Esecuzione più recente most_recent_run 12
Righe convalidate rows_validated 12
Percentuale di successo success_percentage 12

Tag di criteri CDMC a livello di campo

Nella tabella seguente sono elencati i tag di criteri che fanno parte della tassonomia dei tag del criterio di classificazione dei dati sensibili CDMC e che vengono applicati ai campi. Questi tag di criteri limitano l'accesso a livello di campo e consentono l'anonimizzazione dei dati a livello di piattaforma.

Classificazione dati Nome tag Controllo chiavi applicabile
Informazioni che consentono l'identificazione personale personal_identifiable_information 7
Informazioni personali personal_information 7
Informazioni sensibili che consentono l'identificazione personale sensitive_personal_identifiable_information 7
Informazioni personali sensibili sensitive_personal_data 7

Metadati tecnici precompilati

La seguente tabella elenca i metadati tecnici che vengono sincronizzati per impostazione predefinita in Data Catalog per tutti gli asset di dati BigQuery.

Metadati Controllo chiavi applicabile
Tipo di risorsa
Ora creazione
Data di scadenza 11
Località 4
URL risorsa 3

Passaggi successivi