Molte organizzazioni eseguono il deployment di data warehouse su cloud per archiviare informazioni sensibili in modo da poter analizzare i dati per vari scopi aziendali. Questo documento descrive come puoi implementare il framework di controlli delle chiavi Cloud Data Management Capivity (CDMC) gestito dall'Enterprise Data Management Council, in un data warehouse BigQuery.
Il CDMC Key Controls Framework è stato pubblicato principalmente per provider 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 gestire in modo efficace i dati sensibili nel cloud. I controlli sono stati scritti dal Gruppo di lavoro CDMC, con oltre 300 professionisti che hanno partecipato da più di 100 aziende. Nella redazione del framework, il CDMC Working Group ha preso in considerazione molti dei requisiti legali e normativi che esistono.
Questa architettura di riferimento di BigQuery e Data Catalog è stata valutata e certificata in base al CDMC Key Controls Framework come CDMC Certified Cloud Solution. L'architettura di riferimento utilizza vari servizi e funzionalità di Google Cloud, oltre a librerie pubbliche per implementare i controlli delle chiavi 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 è conforme alle specifiche di test del quadro di controllo delle chiavi CDMC v1.1.1. I numeri nel diagramma rappresentano i controlli chiave gestiti con i servizi Google Cloud.
L'architettura di riferimento si basa sul progetto base per il data warehouse protetto, che offre un'architettura che ti aiuta a 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 base del data warehouse sicuro e il progetto di governance dei dati (in blu) include i servizi aggiunti per soddisfare i requisiti del framework di CDMC Key Controls. Per implementare il framework di controlli delle chiavi CDMC, l'architettura estende il progetto di governance dei dati. Il progetto di governance dei dati offre controlli come la classificazione, la gestione del ciclo di vita e la qualità dei dati. Il progetto fornisce anche un modo per controllare l'architettura e creare report sui risultati.
Per ulteriori informazioni su come implementare questa architettura di riferimento, consulta l'architettura di riferimento per CDMC di Google Cloud su GitHub.
Panoramica del framework di CDMC Key Controls
La seguente tabella riepiloga il framework dei controlli delle chiavi CDMC.
| # | Controllo delle chiavi CDMC | Requisiti per il controllo del CDMC |
|---|---|---|
| 1 | Conformità dei controlli dei dati | I business case per la gestione dei dati cloud sono definiti e regolati. Tutti gli asset di dati che contengono dati sensibili devono essere monitorati per verificarne la conformità ai controlli delle chiavi CDMC, utilizzando metriche e notifiche automatiche. |
| 2 | La proprietà dei dati viene stabilita sia per i dati migrati che per quelli generati nel cloud | Il campo Proprietà in un catalogo dati deve essere compilato per tutti i dati sensibili o altrimenti riportati in un flusso di lavoro definito. |
| 3 | L'origine dati e il consumo sono regolati e supportati dall'automazione | Un registro delle origini dati autorevoli e dei punti di provisioning deve essere compilato per tutti gli asset di dati che contengono dati sensibili, oppure devono essere segnalati in un flusso di lavoro definito. |
| 4 | La sovranità dei dati e lo spostamento di dati transfrontalieri sono gestiti | La sovranità dei dati e il trasferimento transfrontaliero di dati sensibili devono essere registrati, controllati e controllati secondo i 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, con coerenza 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 è automatizzata per:
|
| 7 | I diritti dei dati sono gestiti, applicati e monitorati | Questo controllo richiede quanto segue:
|
| 8 | Accesso etico, utilizzo e risultati dei dati sono gestiti | Lo scopo del consumo di dati deve essere fornito per tutti i contratti di condivisione dei dati che riguardano dati sensibili. Lo scopo deve specificare il tipo di dati richiesti e, per le organizzazioni globali, il paese o l'ambito della persona giuridica. |
| 9 | I dati sono protetti e i controlli sono comprovati | Questo controllo richiede quanto segue:
|
| 10 | Un framework per la privacy dei dati è definito e operativo | Le valutazioni dell'impatto della protezione dei dati (DPIA) devono essere attivate automaticamente per tutti i dati personali in base alla relativa 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 una pianificazione di conservazione definita. |
| 12 | La qualità dei dati è gestita | La misurazione della qualità dei dati deve essere attivata per i dati sensibili con metriche distribuite quando disponibili. |
| 13 | I principi di gestione dei costi vengono stabiliti e applicati | I principi di progettazione tecnica sono stabiliti e applicati. Le metriche dei costi associate direttamente all'utilizzo dei dati, allo spazio di archiviazione e allo spostamento devono essere disponibili nel catalogo. |
| 14 | La provenienza dei dati e la derivazione sono comprensibili | Le informazioni sulla derivazione dei dati devono essere disponibili per tutti i dati sensibili. Queste informazioni devono includere almeno l'origine da cui i dati sono stati importati o in cui sono stati creati in un ambiente cloud. |
1. Conformità dei controlli dei dati
Questo controllo richiede che tu possa verificare che tutti i dati sensibili siano monitorati per la conformità a questo framework utilizzando le metriche.
L'architettura utilizza metriche che mostrano fino a che punto di controllo sono operativi tutti i controlli chiave. L'architettura include anche dashboard che indicano quando le metriche non soddisfano le soglie definite.
L'architettura include rilevatori che pubblicano risultati e consigli per la 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 agli abbonati. Puoi integrare i tuoi strumenti di gestione dei servizi interni o di gestione dei servizi con l'argomento Pub/Sub in modo che gli incidenti vengano creati automaticamente nel tuo sistema di gestione delle richieste di assistenza.
L'architettura utilizza Dataflow per creare un sottoscrittore di esempio per gli eventi risultati, che vengono poi archiviati in un'istanza BigQuery eseguita nel progetto Governance dei dati. Utilizzando una serie di viste fornite, puoi eseguire query sui dati utilizzando l'area di lavoro SQL nella console Google Cloud. Puoi anche creare report utilizzando Looker Studio o altri strumenti di business intelligence compatibili con BigQuery. Ecco alcuni report che puoi visualizzare:
- Riepilogo dei risultati dell'ultima esecuzione
- Dettagli dei risultati dell'ultima esecuzione
- Metadati dell'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.
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 viste di riepilogo.
- Looker Studio offre dashboard e report.
Il seguente screenshot mostra un esempio di dashboard di riepilogo di Looker Studio.
Il seguente screenshot mostra una vista di esempio dei risultati per asset di dati.
2. La proprietà dei dati viene stabilita sia per i dati migrati che per quelli 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 sono 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 completa i metadati tecnici. La sincronizzazione tra gli asset di catalogo e 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:
is_sensitive: indica se l'asset di dati contiene dati sensibili (consulta il Controllo 6 per la classificazione dei dati)owner_name: il proprietario dei datiowner_email: l'indirizzo email del proprietario
I tag vengono completati utilizzando i valori predefiniti memorizzati in una tabella BigQuery di riferimento nel progetto di governance dei dati.
Per impostazione predefinita, l'architettura imposta i metadati di proprietà a livello di tabella, ma puoi modificarla in modo che i metadati siano impostati a livello di colonna. Per ulteriori informazioni, consulta Tag catalogo dati e modelli di tag.
Il seguente diagramma mostra i servizi applicabili a questo controllo.
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 valori predefiniti per la proprietà degli asset di dati.
- Data Catalog archivia i metadati di proprietà tramite modelli e tag.
- Due istanze Cloud Run, come segue:
- Un'istanza esegue Report Engine, che verifica se i tag vengono applicati e pubblica i risultati.
- Un'altra istanza esegue Tag Engine, che tagga i dati nel data warehouse sicuro.
- Pub/Sub pubblica i risultati.
Per rilevare problemi relativi a questo controllo, l'architettura controlla se ai dati sensibili viene assegnato un tag del nome del proprietario.
3. L'origine dati e il consumo sono regolati e supportati dall'automazione
Questo controllo richiede la classificazione degli asset 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 viste BigQuery con metadati tecnici e metadati aziendali. I metadati tecnici vengono
compilati automaticamente e includono l'URL della risorsa, che corrisponde alla posizione
del punto di provisioning. I metadati aziendali sono definiti nel file di configurazione di Tag Engine e includono il tag is_authoritative.
Durante la successiva esecuzione pianificata, Tag Engine inserisce il tag is_authoritative nel modello di tag CDMC controls dai valori predefiniti memorizzati in una tabella di riferimento in BigQuery.
Il seguente diagramma mostra i servizi applicabili a questo controllo.
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 valori predefiniti per l'origine autorevole dell'asset di dati.
- Data Catalog archivia i metadati di origine autorevoli tramite i tag.
- Due istanze Cloud Run, come segue:
- Un'istanza esegue Report Engine, che verifica se i tag vengono applicati e pubblica i risultati.
- Un'altra istanza esegue Tag Engine, che codifica i dati nel data warehouse protetto.
- Pub/Sub pubblica i risultati.
Per rilevare problemi relativi a questo controllo, l'architettura verifica se ai dati sensibili viene assegnato il tag di origine autorevole.
4. La sovranità dei dati e lo spostamento di dati transfrontalieri sono gestiti
Questo controllo richiede all'architettura di ispezionare il registro di dati per individuare requisiti di archiviazione specifici per la 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 è possibile archiviare l'asset di dati.
La posizione effettiva dei dati viene archiviata come metadati tecnici nei dettagli della tabella BigQuery. BigQuery non consente agli amministratori di modificare la posizione di un set di dati o di una tabella. Se, invece, gli amministratori vogliono cambiare la posizione dei dati, devono copiare il set di dati.
Il
vincolo di servizio dei criteri dell'organizzazione per le località delle risorse
definisce le regioni di Google Cloud in cui è possibile archiviare i dati. Per impostazione predefinita, l'architettura imposta il vincolo sul progetto di dati riservati, ma se preferisci puoi impostare il vincolo a livello di organizzazione o cartella. Tag Engine replica le località consentite nel modello di tag Data Catalog e memorizza le località nel tag approved_storage_location. Se attivi
il livello Premium di Security Command Center e qualcuno aggiorna le località delle risorse
vincolo di servizio del criterio dell'organizzazione, 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 devono trovarsi gli utenti prima di poter accedere agli asset di dati. Utilizzando i livelli di accesso, puoi specificare da quali regioni possono provenire le richieste. Quindi, dovrai aggiungere il criterio di accesso al perimetro dei Controlli di servizio VPC per il progetto di dati riservati.
Per monitorare lo spostamento dei dati, BigQuery mantiene un audit trail completo per ogni job e query in base a ogni set di dati. L'audit trail è archiviato nella visualizzazione Job schema schema informativo di BigQuery.
Il seguente diagramma mostra i servizi applicabili a questo controllo.
Per soddisfare i requisiti di questo controllo, l'architettura utilizza i seguenti servizi:
- Il servizio Criteri dell'organizzazione definisce e applica il vincolo delle 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 che viene utilizzata per ispezionare il criterio di località.
- Data Catalog archivia le posizioni di archiviazione approvate come tag.
- Due istanze Cloud Run, come segue:
- Un'istanza esegue Report Engine, che verifica se i tag vengono applicati e pubblica i risultati.
- Un'altra istanza esegue Tag Engine, che codifica i 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 problemi relativi a questo controllo, l'architettura include un risultato che indica se il tag delle località approvate include la posizione dei dati sensibili.
5. I cataloghi di dati sono implementati, utilizzati e interoperabili
Questo controllo richiede l'esistenza di un catalogo dati e la possibilità di eseguire la scansione degli asset nuovi e aggiornati nell'architettura per aggiungere i metadati in base alle esigenze.
Per soddisfare i requisiti di questo controllo, l'architettura utilizza Data Catalog. Data Catalog registra automaticamente gli asset di Google Cloud, inclusi i set di dati, le tabelle e le viste BigQuery. Quando crei una nuova tabella in BigQuery, Data Catalog registra automaticamente i metadati e lo schema tecnici della nuova tabella. Quando aggiorni una tabella in BigQuery, Data Catalog aggiorna le relative voci quasi istantaneamente.
Il seguente diagramma mostra i servizi applicabili a questo controllo.
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 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 sono PII, identificano i clienti o soddisfano altri standard definiti dalla tua organizzazione. Per soddisfare i requisiti di questo controllo, l'architettura crea un report sugli asset di dati e sulla loro sensibilità. Puoi utilizzare questo report per verificare se le impostazioni di sensibilità sono corrette. Inoltre, ogni nuova risorsa di dati o la modifica a un asset di dati esistente comporta un aggiornamento al catalogo dei dati.
Le classificazioni sono memorizzate nel tag sensitive_category del modello di tag Data Catalog a livello di tabella e di colonna. Una
tabella di riferimento di classificazione ti consente di classificare i tipi di informazioni
Protezione dei dati sensibili disponibili (infoType), con ranking più elevati per i contenuti più sensibili.
Per soddisfare i requisiti di questo controllo, l'architettura utilizza Protezione dei dati sensibili, 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 sensibilisensitive_category: categoria dei dati; una delle seguenti opzioni:- 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 per soddisfare i tuoi requisiti. Ad esempio, puoi aggiungere la classificazione delle informazioni non pubbliche (MNPI).
Dopo che la protezione dei dati sensibili
controlla 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ù notevole e sia le colonne sensibili sia l'intera tabella vengono taggate come categoria con il ranking più alto. Tag Engine assegna anche un tag di criteri corrispondente alla colonna e assegna il tag booleano is_sensitive alla tabella.
Puoi utilizzare Cloud Scheduler per automatizzare l'ispezione per la protezione dei dati sensibili.
Il seguente diagramma mostra i servizi applicabili a questo controllo.
Per soddisfare i requisiti di questo controllo, l'architettura utilizza i seguenti servizi:
- Quattro data warehouse BigQuery archiviano le seguenti informazioni:
- Dati riservati
- Informazioni sui risultati relativi alla protezione dei dati sensibili
- Dati di riferimento per la classificazione dei dati
- Informazioni sull'esportazione di tag
- Data Catalog archivia i tag di classificazione.
- La protezione dei dati sensibili controlla gli asset alla ricerca di infoType sensibili.
- Compute Engine esegue lo script Ispeziona set di dati, che attiva un job di protezione dei dati sensibili per ogni set di dati BigQuery.
- Due istanze Cloud Run, come segue:
- Un'istanza esegue Report Engine, che verifica se i tag vengono applicati e pubblica i risultati.
- Un'altra istanza esegue Tag Engine, che codifica i dati nel data warehouse protetto.
- Pub/Sub pubblica i risultati.
Per rilevare i 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 sono gestiti, applicati e monitorati
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 completamente l'accesso 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 alle classificazioni di sensibilità derivate dagli infoType di protezione dei dati sensibili. Ad esempio, il tag di criteri 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 in base ai tag di criteri consente un accesso granulare agli asset di dati sensibili. Per impostazione predefinita, gli utenti non hanno accesso alle colonne che hanno 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 verifichi regolarmente la presenza di asset di dati senza diritti definiti. Il rilevatore, gestito da Cloud Scheduler, controlla 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.
In questi casi, il rilevatore genera risultati che vengono pubblicati da Pub/Sub e poi scritti nella tabella events in BigQuery da Dataflow. Puoi quindi distribuire i risultati allo strumento di correzione, come descritto nella sezione 1. Conformità dei controlli dei dati.
Il seguente diagramma mostra i servizi applicabili a questo controllo.
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 controlli dell'accesso granulari.
- IAM gestisce l'accesso.
- Data Catalog archivia i tag a livello di tabella e colonna per la categoria sensibile.
- Due istanze Cloud Run, come segue:
- Un'istanza esegue Report Engine, che verifica se i tag vengono applicati e pubblica i risultati.
- Un'altra istanza esegue Tag Engine, che codifica i dati nel data warehouse protetto.
Per rilevare problemi relativi a questo controllo, l'architettura verifica se ai dati sensibili è associato un tag di criteri.
8. Accesso etico, utilizzo e risultati dei dati sono gestiti
Questo controllo richiede all'architettura di archiviare i contratti di condivisione dei dati sia del fornitore di dati sia dei consumatori dei dati, incluso un elenco di scopi di consumo approvati. Lo scopo di consumo dei dati sensibili viene quindi mappato ai diritti archiviati in BigQuery utilizzando le etichette di 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 l'accordo di condivisione dei dati con il fornitore di dati:
approved_use: l'uso approvato o gli utenti dell'asset di datisharing_scope_geography: elenco di posizioni geografiche in cui può essere condiviso l'asset di datisharing_scope_legal_entity: l'elenco delle 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: accordo di condivisione dei dati con il fornitore di dati, che include la persona giuridica concordata e l'ambito geografico. Questi sono i valori predefiniti per i tagshared_scope_geographyesharing_scope_legal_entity.consumer_agreement: accordo di condivisione dei dati con il consumatore di dati, tra cui la persona giuridica concordata e l'ambito geografico. Ogni contratto è associato a un'associazione IAM per l'asset di dati.use_purpose: lo scopo del consumo, come la descrizione dell'utilizzo e le operazioni consentite per l'asset di dati.data_asset: informazioni sull'asset di dati, come il nome dell'asset e dettagli sul proprietario dei dati.
Per controllare i contratti di condivisione dei dati, BigQuery mantiene un audit trail completo per ogni job e query su ogni set di dati. L'audit trail è archiviato nella visualizzazione Job di schemi informativi di BigQuery. Dopo aver associato un'etichetta di query a una sessione ed eseguito query al suo interno, puoi raccogliere i log di controllo per le query con quell'etichetta. Per ulteriori informazioni, consulta il riferimento per i log di controllo per BigQuery.
Il seguente diagramma mostra i servizi applicabili a questo controllo.
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 sui diritti, tra cui i contratti di condivisione dei dati tra fornitori e consumatori e lo scopo di utilizzo approvato.
- Data Catalog archivia i dati del contratto di condivisione dei dati del provider come tag.
- Due istanze Cloud Run, come segue:
- Un'istanza esegue Report Engine, che verifica se i tag vengono applicati e pubblica i risultati.
- Un'altra istanza esegue Tag Engine, che codifica i dati nel data warehouse protetto.
- Pub/Sub pubblica i risultati.
Per rilevare i problemi relativi a questo controllo, l'architettura include i seguenti risultati:
- Indica se è presente una voce per un asset di dati nel set di dati
entitlement_management. - Indica se un'operazione viene eseguita su una tabella sensibile con un caso d'uso scaduto (ad esempio, il
valid_until_datenelconsumer_agreement tableè stato superato). - Indica se un'operazione viene eseguita su una tabella sensibile con una chiave di etichetta errata.
- Indica se un'operazione viene eseguita su una tabella sensibile con un valore di etichetta per il caso d'uso vuoto o non approvato.
- Indica se per una tabella sensibile viene eseguita una query con un metodo dell'operazione non approvato (ad esempio,
SELECToINSERT). - Indica se lo scopo registrato specificato dal consumatore quando esegue query sui dati sensibili corrisponde al contratto di condivisione dei dati.
9. I dati sono protetti e i controlli sono comprovati
Questo controllo richiede l'implementazione della crittografia dei dati e dell'anonimizzazione per contribuire a 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 ti consente di gestire le tue chiavi utilizzando chiavi di crittografia gestite dal cliente (CMEK). Cloud KMS consente di criptare i tuoi dati con chiavi di crittografia supportate da software o moduli di sicurezza hardware (HSM) convalidati FIPS 140-2 di livello 3.
L'architettura utilizza il mascheramento dinamico dei dati a livello di colonna configurato tramite i tag di criteri e archivia i dati riservati all'interno di un perimetro Controlli di servizio VPC separati. Puoi anche aggiungere l'anonimizzazione a livello di applicazione, che puoi implementare on-premise o come parte della pipeline di importazione dati.
Per impostazione predefinita, l'architettura implementa la crittografia CMEK con HSM, ma supporta anche Cloud External Key Manager (Cloud EKM).
La tabella seguente descrive il criterio di sicurezza di esempio implementato dall'architettura per l'area geografica us-central1. Puoi adattare i criteri per soddisfare i tuoi requisiti, ad esempio aggiungendo criteri diversi per aree geografiche 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 | Nullify o valore di mascheramento predefinito |
| Informazioni personali sensibili | CMEK con HSM | EKM | Valore di mascheramento predefinito | SHA-256 Hash o nullify |
| Informazioni personali | CMEK con HSM | EKM | Valore di mascheramento predefinito | SHA-256 Hash 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 il platform_deid_method, che viene applicato usando il mascheramento dei dati dinamici. Puoi aggiungere app_deid_method e completarlo utilizzando le pipeline di importazione dati di Dataflow e Sensitive Data Protection incluse nel progetto base del data warehouse sicuro.
Il seguente diagramma mostra i servizi applicabili a questo controllo.
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 esegue la reidentificazione.
- Tre data warehouse BigQuery: uno archivia i dati riservati, uno archivia i dati non riservati e il terzo 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 verifica se i tag vengono applicati e pubblica i risultati.
- Un'altra istanza esegue Tag Engine, che codifica i dati nel data warehouse protetto.
- Risultati pubblicati da Pub/Sub.
Per rilevare i 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 località e la sensibilità specificate.
- La tabella contiene colonne sensibili, ma il tag Modello di criterio di sicurezza contiene un metodo di anonimizzazione non valido a livello di piattaforma.
- La tabella contiene colonne sensibili, ma manca il tag Modello di criterio di sicurezza.
10. Un framework per la privacy dei dati è definito e operativo
Questo controllo richiede che l'architettura esamini il catalogo dati e le classificazioni per determinare se è necessario creare un report di valutazione dell'impatto della protezione dei dati (DPIA) o un report di valutazione dell'impatto della privacy. Le valutazioni della privacy variano notevolmente in base all'area geografica e alle autorità di regolamentazione. Per determinare se è 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 questo asset.is_dpia: se è stata completata una valutazione dell'impatto sulla privacy dei dati (DPIA) per questa risorsa.is_pia: indica se è stata completata una valutazione dell'impatto della privacy per questo asset.impact_assessment_reports: link esterno al punto 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 ciascun 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, località del soggetto, sensibilità dei dati (ad esempio, se si tratta di PII) e quale tipo di valutazione dell'impatto (PIA o DPIA) è richiesto.
Il seguente diagramma mostra i servizi applicabili a questo controllo.
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
- Norme 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 verifica se i tag vengono applicati e pubblica i risultati.
- Un'altra istanza esegue Tag Engine, che codifica i dati nel data warehouse protetto.
- Pub/Sub pubblica i risultati.
Per rilevare i problemi relativi a questo controllo, l'architettura include i seguenti risultati:
- Esistono dati sensibili senza un modello di valutazione dell'impatto.
- Esistono dati sensibili privi di 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 del contratto 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 se esiste un criterio del ciclo di vita dei dati e se è conforme.
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 tabellaexpiration_action: archiviazione o eliminazione definitiva della tabella al termine del periodo di conservazione
Per impostazione predefinita, l'architettura utilizza i seguenti periodo di conservazione e azione di scadenza:
| Categoria di dati | Periodo di conservazione, in giorni | Azione di scadenza |
|---|---|---|
| Informazioni sensibili che consentono l'identificazione personale | 60 | Elimina definitivamente |
| Informazioni che consentono l'identificazione personale | 90 | Archive |
| Informazioni personali sensibili | 180 | Archive |
| Informazioni personali | 180 | Archive |
Record Manager, un asset open source per BigQuery, automatizza l'eliminazione definitiva e l'archiviazione delle tabelle BigQuery in base ai valori tag sopra riportati 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 a upgrade a una tabella BigLake che consente di taggare il file esterno con i metadati in Data Catalog.
Il seguente diagramma mostra i servizi applicabili a questo controllo.
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 il criterio di conservazione dei dati.
- Due istanze Cloud Storage, una fornisce archiviazione 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 di record e l'altra esegue il deployment dei rilevatori.
- Tre istanze Cloud Run, come segue:
- Un'istanza esegue Report Engine, che verifica se i tag vengono applicati e pubblica i risultati.
- Un'altra istanza esegue Tag Engine, che codifica i 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 i problemi relativi a questo controllo, l'architettura include i seguenti risultati:
- Per le risorse sensibili, assicurati che il metodo di conservazione sia allineato alle norme relative alla località dell'asset.
- Per le risorse sensibili, assicurati che il periodo di conservazione sia conforme alle norme relative alla località dell'asset.
12. La qualità dei dati è gestita
Questo controllo richiede la possibilità di misurare la qualità dei dati in base alla profilazione dei dati o alle metriche definite dall'utente.
L'architettura include la possibilità di definire le regole sulla qualità dei dati per un singolo valore o aggregato e di assegnare le soglie a una specifica colonna della tabella. Include modelli di tag per la correttezza e la completezza. Data Catalog aggiunge i seguenti tag a ciascun modello di tag:
column_name: il nome della colonna a cui si applica la metricametric: il nome della metrica o della regola di qualitàrows_validated: numero di righe convalidatesuccess_percentage: la percentuale di valori che soddisfano questa metricaacceptable_threshold: la soglia accettabile per questa metricameets_threshold: indica se il punteggio di qualità (il valoresuccess_percentage) soddisfa la soglia accettabilemost_recent_run: l'ora più recente in cui è stata eseguita la metrica o la regola di qualità
Il seguente diagramma mostra i servizi applicabili a questo controllo.
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 le metriche delle regole di qualità.
- Data Catalog archivia i risultati della qualità dei dati in modelli e tag.
- Cloud Scheduler definisce l'esecuzione di Cloud Data Quality Engine.
- Tre istanze Cloud Run, come segue:
- Un'istanza esegue Report Engine, che verifica se i tag vengono applicati e pubblica i risultati.
- Un'altra istanza esegue Tag Engine, che codifica i dati nel data warehouse protetto.
- La terza istanza esegue Cloud Data Quality Engine.
- Cloud Data Quality Engine definisce regole per la qualità dei dati e pianifica controlli della 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 per i livelli tabella sia per i livelli colonna.
Per rilevare i problemi relativi a questo controllo, l'architettura include i seguenti risultati:
- I dati sono sensibili, ma non vengono applicati modelli di tag qualità dei dati (correzione e completezza).
- I dati sono sensibili, ma il tag della qualità dei dati non viene applicato alla colonna sensibile.
- I dati sono sensibili, ma i risultati della qualità dei dati non rientrano nella soglia impostata nella regola.
- I dati non sono sensibili e i risultati sulla qualità dei dati non rientrano nella soglia impostata dalla regola.
In alternativa al Cloud Data Quality Engine, puoi configurare le attività relative alla qualità dei dati di 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 di costo devono essere complete e non solo limitate all'utilizzo 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 in una tabella BigQuery denominata cloud_pricing_export.
Il seguente diagramma mostra i servizi applicabili a questo controllo.
Per soddisfare i requisiti di questo controllo, l'architettura utilizza i seguenti servizi:
- Fatturazione Cloud fornisce dati di fatturazione.
- Data Catalog archivia le informazioni sui costi nei modelli e nei tag dei tag.
- BigQuery archivia le informazioni sui prezzi esportate e le informazioni sui job storici delle query tramite la visualizzazione INFORMATION_SCHEMA integrata.
- Due istanze Cloud Run, come segue:
- Un'istanza esegue Report Engine, che verifica se i tag vengono applicati e pubblica i risultati.
- Un'altra istanza esegue Tag Engine, che codifica i dati nel data warehouse protetto.
- Pub/Sub pubblica i risultati.
Per rilevare i problemi relativi a questo controllo, l'architettura verifica se sono presenti asset di dati sensibili senza metriche di costo associate.
14. La provenienza dei dati e la derivazione sono comprensibili
Questo controllo richiede la possibilità di ispezionare la tracciabilità dell'asset di dati dall'origine ed eventuali modifiche alla derivazione degli asset di dati.
Per mantenere le informazioni sulla provenienza e sulla derivazione dei dati, l'architettura utilizza le funzionalità integrate di derivazione dei dati in Data Catalog. Inoltre, gli script di importazione dati definiscono l'origine definitiva e aggiungono l'origine come nodo aggiuntivo al grafico sulla 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.
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 di origine per eccellenza.
- Data Catalog archivia l'origine massima nei modelli e nei tag.
- Gli script di importazione dati caricano i dati da Cloud Storage, definiscono l'origine definitiva e aggiungono l'origine al grafico sulla derivazione dei dati.
- Due istanze Cloud Run, come segue:
- Un'istanza esegue Report Engine, che verifica se i tag vengono applicati e pubblica i risultati.
- Un'altra istanza esegue Tag Engine, che codifica i dati nel data warehouse protetto.
- Pub/Sub pubblica i risultati.
Per rilevare i problemi relativi a questo controllo, l'architettura include i seguenti controlli:
- I dati sensibili sono identificati senza tag di origine finali.
- Il grafico sulla derivazione non viene completato per gli asset di dati sensibili.
Riferimento tag
Questa sezione descrive i modelli e i tag di tag utilizzati da questa architettura per soddisfare i requisiti dei controlli delle chiavi CDMC.
Modelli di tag di controllo CDMC a livello di tabella
La seguente tabella elenca i tag che fanno parte del modello di tag di controllo CDMC e che vengono applicati alle tabelle.
| Tag | ID tag | Controllo delle chiavi applicabile |
|---|---|---|
| Località di archiviazione approvata | approved_storage_location |
4 |
| Uso approvato | approved_use |
8 |
| Email proprietario dati | data_owner_email |
2 |
| Nome del 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 |
| Regione ambito condivisione | sharing_scope_geography |
8 |
| Persona giuridica ambito di condivisione | sharing_scope_legal_entity |
8 |
| Periodo di conservazione | retention_period |
11 |
| Fonte di origine | ultimate_source |
14 |
Modello di tag per la valutazione dell'impatto
La seguente tabella elenca i tag che fanno parte del modello di tag di valutazione dell'impatto e che vengono applicati alle tabelle.
| Tag | ID tag | Controllo delle chiavi applicabile |
|---|---|---|
| Posizioni degli oggetti | subject_locations |
10 |
| Valutazione dell'impatto DPIA | is_dpia |
10 |
| Valutazione dell'impatto del 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
La seguente tabella elenca i tag che fanno parte del modello di tag delle metriche dei costi e che vengono applicati alle tabelle.
| Tag | Scheda ID | Controllo delle chiavi applicabile |
|---|---|---|
| Costo stimato delle 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 per la sensibilità dei dati
La seguente tabella elenca i tag che fanno parte del modello di tag Sensibilità dei dati e che vengono applicati ai campi.
| Tag | ID tag | Controllo delle chiavi applicabile |
|---|---|---|
| Campo sensibile | sensitive_field |
6 |
| Tipo sensibile | sensitive_category |
6 |
Modello di tag Criterio di sicurezza
La seguente tabella elenca i tag che fanno parte del modello di tag di criteri di sicurezza e che vengono applicati ai campi.
| Tag | ID tag | Controllo delle chiavi applicabile |
|---|---|---|
| Metodo di anonimizzazione dell'applicazione | app_deid_method |
9 |
| Metodo di anonimizzazione della piattaforma | platform_deid_method |
9 |
Modelli di tag relativi alla qualità dei dati
La seguente tabella elenca i tag che fanno parte dei modelli di tag Qualità dei dati di completezza e correttezza e che vengono applicati ai campi.
| Tag | ID tag | Controllo delle 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
La seguente tabella elenca i tag di criteri che fanno parte della tassonomia dei tag di criteri 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 delle 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 delle chiavi applicabile |
|---|---|
| Tipo di risorsa | — |
| Ora creazione | — |
| Data di scadenza | 11 |
| Località | 4 |
| URL risorsa | 3 |
Passaggi successivi
- Scopri di più sulla CDMC.
- Scopri di più sui controlli di sicurezza utilizzati dal progetto base per il data warehouse protetto.
- Scopri Data Catalog.
- Scopri di più su Dataplex.
- Scopri di più su Tag Engine.
- Implementa questa soluzione utilizzando l'architettura di riferimento CDMC di Google Cloud in GitHub.