Molte organizzazioni implementano data warehouse su cloud per archiviare informazioni sensibili in modo da poter analizzare i dati per una serie di scopi commerciali. Questo documento descrive come implementare il Key Controls Framework di Cloud Data Management Capabilities (CDMC), 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 fornitori 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 gruppo di lavoro CDMC, con la partecipazione di oltre 300 professionisti di oltre 100 aziende. Durante la stesura del framework, il gruppo di lavoro CDMC 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 Google Cloud servizi e funzionalità, nonché librerie pubbliche, per implementare i controlli delle chiavi CDMC e l'automazione consigliata. Questo documento spiega come implementare i controlli chiave per contribuire a proteggere i dati sensibili in un data warehouse BigQuery.
Architettura
La seguente Google Cloud architettura di riferimento è in linea con le specifiche di test del framework CDMC Key Controls v1.1.1. I numeri nel diagramma rappresentano i controlli chiave indirizzati con i servizi Google Cloud .
L'architettura di riferimento si basa sul progetto di data warehouse protetto, che fornisce 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 blueprint del data warehouse protetto e il progetto di governance dei dati (in blu) include i servizi aggiunti per soddisfare i requisiti del CDMC Key Controls Framework. 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 eseguire la revisione dell'architettura e generare report sui risultati.
Per ulteriori informazioni su come implementare questa architettura di riferimento, consulta la Google Cloud architettura di riferimento CDMC su GitHub.
Panoramica del framework CDMC Key Controls
La seguente tabella riassume il CDMC Key Controls Framework.
| # | Controllo delle chiavi CDMC | Requisito di controllo CDMC |
|---|---|---|
| 1 | Conformità al controllo dei dati | I casi d'uso per la gestione dei dati nel cloud sono definiti e regolamentati. È necessario monitorare la conformità di tutte le risorse di dati che contengono dati sensibili ai controlli chiave del CDMC, utilizzando metriche e notifiche automatiche. |
| 2 | La proprietà dei dati viene stabilita sia per i dati sottoposti a migrazione sia per quelli generati in cloud | Il campo Proprietà in un catalogo di dati deve essere compilato per tutti i dati sensibili o segnalato a un flusso di lavoro definito. |
| 3 | L'origine e il consumo dei dati sono regolati e supportati dall'automazione | Deve essere compilato un registro di origini dati e punti di provisioning autorevoli per tutti gli asset di dati che contengono dati sensibili o che devono essere registrati in un flusso di lavoro definito. |
| 4 | La sovranità dei dati e il trasferimento di dati transfrontalieri sono gestiti | La sovranità dei dati e il trasferimento transfrontaliero di dati sensibili devono essere registrati, controllati e monitorati 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, 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 è automatica per quanto segue:
|
| 7 | I diritti di accesso ai dati vengono gestiti, applicati e monitorati | Questo controllo richiede quanto segue:
|
| 8 | L'accesso, l'utilizzo e i risultati etici dei dati sono gestiti | Lo scopo del consumo dei 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, l'ambito del paese o della persona giuridica. |
| 9 | I dati sono protetti e i controlli sono evidenti | Questo controllo richiede quanto segue:
|
| 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 ed il purging dei dati devono essere gestiti in base a un programma di conservazione definito. |
| 12 | La qualità dei dati è gestita | La misurazione della qualità dei dati deve essere attivata per i dati sensibili con le metriche distribuite, se disponibili. |
| 13 | Vengono stabiliti e applicati i principi di gestione dei costi | Vengono stabiliti e applicati i principi di progettazione tecnica. Nel catalogo devono essere disponibili le metriche relative ai costi associate direttamente all'utilizzo, allo spazio di archiviazione e al movimento dei dati. |
| 14 | La provenienza e la derivazione dei dati sono comprese | Le informazioni sulla provenienza dei dati devono essere disponibili per tutti i dati sensibili. Queste informazioni devono includere almeno l'origine da cui sono stati importati i dati o in 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 vengano monitorati per verificare la conformità a questo framework utilizzando le metriche.
L'architettura utilizza metriche che mostrano il grado di operatività di ciascun controllo 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 consigli sono in formato JSON e vengono pubblicati in un argomento Pub/Sub per la distribuzione agli abbonati. Puoi integrare il tuo help desk interno o gli strumenti di gestione dei servizi con l'argomento Pub/Sub in modo che gli incidenti vengano creati automaticamente nel sistema di ticketing.
L'architettura utilizza Dataflow per creare un abbonato di esempio agli eventi di risultati, che vengono poi archiviati in un'istanza BigQuery eseguita nel progetto di governance dei dati. Utilizzando una serie di visualizzazioni fornite, puoi eseguire query sui dati utilizzando 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 dei risultati dell'ultima esecuzione
- Metadati dell'ultima esecuzione
- Asset di dati dell'ultima esecuzione inclusi nell'ambito
- Statistiche del set di dati dell'ultima esecuzione
Il seguente diagramma mostra i servizi che si applicano 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 fornisce dashboard e report.
Lo screenshot seguente mostra un'esempio di dashboard di riepilogo di Looker Studio.
Lo screenshot seguente mostra una visualizzazione di esempio dei risultati per asset di dati.
2. La proprietà dei dati viene stabilita sia per i dati sottoposti a migrazione sia per quelli generati nel cloud
Per soddisfare i requisiti di questo controllo, l'architettura esamina automaticamente i dati nel data warehouse BigQuery e aggiunge i 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 i set di dati, le tabelle e le viste BigQuery e compila i metadati tecnici. La sincronizzazione tra le risorse di catalogo e dati viene mantenuta su una base quasi in tempo reale.
L'architettura utilizza il motore di tag per aggiungere i seguenti tag dei metadati aziendali a un
CDMC controls modello di tag in Data Catalog:
is_sensitive: indica se la risorsa di dati contiene dati sensibili (consulta Controllo 6 per la classificazione dei dati)owner_name: il proprietario dei datiowner_email: l'indirizzo email del proprietario
I tag vengono compilati 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 della proprietà a livello di tabella, ma puoi modificarla in modo che i metadati vengano impostati a livello di colonna. Per ulteriori informazioni, consulta Modelli di tag e tag di Data Catalog.
Il seguente diagramma mostra i servizi che si applicano a questo controllo.
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 memorizza i valori predefiniti per la proprietà delle risorse di dati.
- Data Catalog archivia i metadati della proprietà tramite modelli di tag e tag.
- Due istanze Cloud Run, come segue:
- Un'istanza esegue Report Engine, che controlla se i tag sono applicati e pubblica i risultati.
- Un'altra istanza esegue Tag Engine, che applica i tag ai 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 è assegnato un tag del nome del proprietario.
3. L'origine e il consumo dei dati sono regolati e supportati dall'automazione
Questo controllo richiede la classificazione degli asset di dati e un registro dei 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 aziendali. I metadati tecnici vengono compilati automaticamente e includono l'URL della risorsa, ovvero la posizione del punto di provisioning. I metadati aziendali sono definiti nel file di configurazione di Tag Engine e includono il tag is_authoritative.
Durante l'esecuzione pianificata successiva, Tag Engine compila il tag is_authoritative nel modello di tag CDMC controls a partire dai valori predefiniti memorizzati in una tabella di riferimento in BigQuery.
Il seguente diagramma mostra i servizi che si applicano a questo controllo.
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 memorizza i valori predefiniti per l'origine autorevole della risorsa dati.
- Data Catalog memorizza i metadati delle origini autorevoli tramite i tag.
- Due istanze Cloud Run, come segue:
- Un'istanza esegue Report Engine, che controlla se i tag sono applicati e pubblica i risultati.
- Un'altra istanza esegue il motore di tag, che applica i tag ai 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 è assegnato il tag dell'origine attendibile.
4. La sovranità dei dati e il trasferimento di dati transfrontalieri sono gestiti
Questo controllo richiede che l'architettura esamini il registry dei dati per verificare la presenza di requisiti di archiviazione specifici per regione e applichi le regole di utilizzo. Un report descrive la posizione geografica degli asset di dati.
L'architettura utilizza Data Catalog per aggiungere il
approved_storage_location al modello di tag CDMC controls. Questo tag
definisce la posizione geografica in cui è consentito archiviare la risorsa 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 modificare la posizione dei dati, devono copiare il set di dati.
Il
vincolo del servizio Organization Policy per le località delle risorse
definisce le Google Cloud regioni in cui puoi archiviare i dati. Per impostazione predefinita,
l'architettura imposta il vincolo sul progetto Dati riservati, ma se preferisci puoi impostarlo a livello di organizzazione o cartella. 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 Security Command Center Premium e qualcuno aggiorna le posizioni delle risorse del vincolo del servizio di criteri dell'organizzazione, Security Command Center genera risultati relativi alle vulnerabilità per le risorse archiviate al di fuori del criterio aggiornato.
Access Context Manager definisce la posizione geografica in cui devono trovarsi gli utenti prima di poter accedere alle risorse di dati. Con i livelli di accesso, puoi specificare da quali regioni possono provenire le richieste. Quindi, aggiungi il criterio di accesso al perimetro Controlli di servizio VPC per il progetto Dati riservati.
Per monitorare lo spostamento dei dati, BigQuery mantiene una traccia completa per ogni job e query eseguita su ogni set di dati. La traccia di controllo viene archiviata nella visualizzazione Job dello schema di informazioni di BigQuery.
Il seguente diagramma mostra i servizi che si applicano a questo controllo.
Per soddisfare i requisiti di questo controllo, l'architettura utilizza i seguenti servizi:
- Il servizio Organization Policy definisce e applica il vincolo delle località delle risorse.
- Access Context Manager definisce le posizioni da cui gli utenti possono accedere ai dati.
- Due data warehouse BigQuery: uno memorizza i dati riservati e l'altro ospita una funzione remota 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 controlla se i tag sono applicati e pubblica i risultati.
- Un'altra istanza esegue il motore di tag, che applica i tag ai dati nel data warehouse protetto.
- Pub/Sub pubblica i risultati.
- Cloud Logging scrive gli audit log.
- Security Command Center segnala eventuali risultati relativi alla posizione delle risorse o all'accesso ai dati.
Per rilevare i problemi relativi a questo controllo, l'architettura include un rilevamento per verificare 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 che esista un catalogo di dati e che l'architettura possa eseguire la scansione di asset nuovi e aggiornati per aggiungere i metadati in base alle esigenze.
Per soddisfare i requisiti di questo controllo, l'architettura utilizza Data Catalog. Data Catalog registra automaticamente gliGoogle Cloud asset, inclusi set di dati, tabelle e 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 voci quasi istantaneamente.
Il seguente diagramma mostra i servizi che si applicano a questo controllo.
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 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, se identificano i clienti o se soddisfano altri standard definiti dalla tua organizzazione. Per soddisfare i requisiti di questo controllo, l'architettura crea un report delle risorse di dati e della loro sensibilità. Puoi utilizzare questo report per verificare se le impostazioni di sensibilità sono corrette. Inoltre, ogni nuovo asset dati o modifica di un asset dati esistente comporta un aggiornamento del catalogo dei dati.
Le classificazioni vengono memorizzate nel tag sensitive_category nel
modello di tag Data Catalog a livello di tabella e di colonna. Una tabella di riferimento per la classificazione consente di classificare i tipi di informazioni (infoType) di Sensitive Data Protection disponibili, con classificazioni più alte 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 nelle tabelle BigQuery:
is_sensitive: indica se l'asset di dati contiene informazioni sensibilisensitive_category: la categoria dei dati; una delle seguenti:- 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 alle tue esigenze. Ad esempio, puoi aggiungere la classificazione Informazioni Materiali Non Pubbliche (MNPI).
Dopo che Sensitive Data Protection
esamina 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ù importante e sia le colonne sensibili sia l'intera tabella vengono contrassegnate come appartenenti alla categoria con il ranking più elevato. Il motore dei tag assegna inoltre un
tag delle norme corrispondente alla colonna e il tag booleano is_sensitive alla tabella.
Puoi utilizzare Cloud Scheduler per automatizzare l'ispezione di Sensitive Data Protection.
Il seguente diagramma mostra i servizi che si applicano 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 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 controlla gli asset per rilevare infoType sensibili.
- Compute Engine esegue lo script Inspect Datasets, che attiva un job Sensitive Data Protection per ogni set di dati BigQuery.
- Due istanze Cloud Run, come segue:
- Un'istanza esegue Report Engine, che controlla se i tag sono applicati e pubblica i risultati.
- Un'altra istanza esegue il motore di tag, che applica i tag ai 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 è stato assegnato un tag di categoria sensibile.
- Indica se ai dati sensibili è assegnato un tag del tipo di sensibilità a livello di colonna.
7. I diritti di accesso ai dati vengono gestiti, applicati e monitorati
Per impostazione predefinita, solo i creator e i proprietari ricevono i diritti e l'accesso ai dati sensibili. Inoltre, questo controllo richiede che l'architettura monitori tutto 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 contenenti dati riservati nelle tabelle BigQuery. La tassonomia include i seguenti tag criteri:
- Informazioni sensibili che consentono l'identificazione personale
- Informazioni che consentono l'identificazione personale
- Informazioni personali sensibili
- Informazioni personali
I tag di criteri ti consentono di controllare chi può visualizzare le colonne sensibili nelle
tabelle BigQuery. L'architettura mappa questi tag di criteri alle classificazioni di sensibilità ricavate dagli infoType di Sensitive Data Protection. Ad esempio, il tag delle norme 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 una determinata risorsa per l'accesso a livello di tabella. Inoltre, l'accesso a livello di colonna in base ai tag criterio consente un accesso granulare alle risorse 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 esegua regolarmente dei controlli per rilevare gli asset di dati per i quali non sono stati definiti i diritti. Il rilevatore, gestito da Cloud Scheduler, controlla i seguenti scenari:
- Una risorsa di dati include una categoria sensibile, ma non è presente un tag delle norme correlato.
- Una categoria non corrisponde al tag delle norme.
Quando si verificano questi scenari, 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 in 1. Conformità ai controlli dei dati.
Il seguente diagramma mostra i servizi che si applicano 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 dei tag di criteri per i controlli dell'accesso granulare.
- IAM gestisce l'accesso.
- Data Catalog memorizza i tag a livello di tabella e colonna per la categoria sensibile.
- Due istanze Cloud Run, come segue:
- Un'istanza esegue Report Engine, che controlla se i tag sono applicati e pubblica i risultati.
- Un'altra istanza esegue Tag Engine, che applica i tag ai dati nel data warehouse protetto.
Per rilevare i problemi relativi a questo controllo, l'architettura verifica se i dati sensibili hanno un tag delle norme corrispondente.
8. L'accesso, l'utilizzo e i risultati etici dei dati sono gestiti
Questo controllo richiede che l'architettura memorizzi i contratti di condivisione dei dati sia del fornitore di dati sia dei relativi consumatori, incluso un elenco di finalità di utilizzo approvate. Lo scopo di utilizzo per i dati sensibili viene poi 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 il contratto di condivisione dei dati con il fornitore di dati:
approved_use: l'utilizzo o gli utenti approvati della risorsa di datisharing_scope_geography: l'elenco delle località geografiche in cui la risorsa di dati può essere condivisasharing_scope_legal_entity: l'elenco delle entità concordate che possono condividere la risorsa 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 di dati, incluso l'ambito geografico e la persona giuridica concordati. Questi dati sono i valori predefiniti per i tagshared_scope_geographyesharing_scope_legal_entity.consumer_agreement: il contratto di condivisione dei dati con il consumatore di dati, incluso l'ambito geografico e la persona giuridica concordati. Ogni contratto è associato a un'associazione IAM per la risorsa di dati.use_purpose: lo scopo del consumo, ad esempio la descrizione dell'utilizzo e le operazioni consentite per l'asset di datidata_asset: informazioni sulla risorsa di dati, ad esempio il nome della risorsa e i dettagli sul proprietario dei dati.
Per eseguire la revisione dei contratti di condivisione dei dati, BigQuery mantiene un audit trail completo per ogni job e query eseguita su ogni set di dati. La traccia di controllo viene memorizzata nella vista Job dello schema delle informazioni di BigQuery. Dopo aver associato un'etichetta di query a una sessione ed eseguito query all'interno della sessione, puoi raccogliere i log di controllo per le query con quell'etichetta. Per maggiori informazioni, consulta il riferimento per i log di controllo di BigQuery.
Il seguente diagramma mostra i servizi che si applicano a questo controllo.
Per soddisfare i requisiti di questo controllo, l'architettura utilizza i seguenti servizi:
- Due data warehouse BigQuery: uno memorizza i dati confidenziali e l'altro i dati dei diritti, che includono i contratti di condivisione dei dati di fornitori e consumatori e lo scopo di utilizzo approvato.
- Data Catalog archivia le informazioni del contratto di condivisione dei dati del fornitore come tag.
- Due istanze Cloud Run, come segue:
- Un'istanza esegue Report Engine, che controlla se i tag sono applicati e pubblica i risultati.
- Un'altra istanza esegue il motore di tag, che applica i tag ai 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 esiste una voce per una risorsa 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, è trascorso il periodo di
valid_until_dateinconsumer_agreement table). - Indica se un'operazione viene eseguita su una tabella sensibile con una chiave dell'etichetta errata.
- Indica se un'operazione viene eseguita su una tabella sensibile con un valore vuoto o un valore dell'etichetta del caso d'uso non approvato.
- Indica se viene eseguita una query su una tabella sensibile con un metodo di operazione non approvato
(ad esempio
SELECToINSERT). - Se lo scopo registrato specificato dal consumatore durante la query sui dati sensibili corrisponde al contratto di condivisione dei dati.
9. I dati sono protetti e i controlli sono evidenti
Questo controllo richiede l'implementazione della crittografia e della anonimizzazione dei dati 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 le chiavi di crittografia gestite dal cliente (CMEK). Cloud KMS ti consente di criptare i dati con chiavi di crittografia con supporto 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 dei criteri e archivia i dati riservati in un perimetro distinto dei Controlli di servizio VPC. Puoi anche aggiungere la anonimizzazione a livello di applicazione, che puoi implementare on-premise o all'interno della pipeline di importazione dei dati.
Per impostazione predefinita, l'architettura implementa la crittografia CMEK con gli HSM, ma supporta anche Cloud External Key Manager (Cloud EKM).
La tabella seguente descrive il criterio di sicurezza di esempio implementato dall'architettura per la regione us-central1. Puoi adattare il criterio in base ai 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 | Valore di mascheramento nullo o predefinito |
| Informazioni personali sensibili | CMEK con HSM | EKM | Valore di mascheramento predefinito | Hash SHA-256 o Annulla |
| Informazioni personali | CMEK con HSM | EKM | Valore di mascheramento predefinito | Hash SHA-256 o Annulla |
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 dinamico dei dati. Puoi aggiungere app_deid_method e compilarlo utilizzando le pipeline di importazione dei dati di Dataflow e Sensitive Data Protection incluse nel blueprint del data warehouse protetto.
Il seguente diagramma mostra i servizi che si applicano 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 la reidentificazione.
- Tre data warehouse BigQuery: uno memorizza i dati riservati, uno memorizza i dati non riservati e il terzo memorizza 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 i tag sono applicati e pubblica i risultati.
- Un'altra istanza esegue il motore di tag, che applica i tag ai 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 sensibilità e la posizione specificate.
- Una tabella contiene colonne sensibili, ma il tag Modello di criteri di sicurezza contiene un metodo di anonimizzazione a livello di piattaforma non valido.
- Una tabella contiene colonne sensibili, ma manca il tag Modello di norme sulla sicurezza.
10. È definito e operativo un framework per la privacy dei dati
Questo controllo richiede che l'architettura esamini il catalogo e le classificazioni dei dati per determinare se devi creare un report di valutazione dell'impatto sulla protezione dei dati (DPIA) o un report di valutazione dell'impatto sulla privacy (PIA). Le valutazioni della privacy variano notevolmente in base alle aree geografiche e ai regolatori. Per determinare se è necessaria una valutazione di impatto, l'architettura deve prendere in considerazione la residenza dei dati e la residenza della persona interessata.
L'architettura utilizza Data Catalog per aggiungere i seguenti tag al
modello di tag Impact assessment:
subject_locations: la posizione dei soggetti a cui fanno riferimento i dati in questa risorsa.is_dpia: indica se è stata completata una valutazione di impatto sulla privacy dei dati (DPIA) per questa risorsa.is_pia: indica se è stata completata un'analisi dell'impatto sulla privacy (PIA) per questa risorsa.impact_assessment_reports: link esterno alla posizione in cui è archiviato il report di valutazione dell'impatto.most_recent_assessment: la data della valutazione dell'impatto più recente.oldest_assessment: la data della prima valutazione dell'impatto.
Il motore dei tag aggiunge questi tag a ogni asset di dati sensibili, come definito dal controllo 6. Il rilevatore convalida questi tag in base a una tabella delle norme in BigQuery, che include combinazioni valide di residenza dei dati, posizione 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 che si applicano 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
- Timestamp dei criteri di valutazione dell'impatto e dei diritti
- Esportazioni di tag utilizzate per la dashboard
- Data Catalog memorizza 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 i tag sono applicati e pubblica i risultati.
- Un'altra istanza esegue il motore di tag, che applica i tag ai 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 senza un link a un report DPIA o PIA.
- I tag non soddisfano i requisiti indicati nella tabella delle norme.
- La valutazione dell'impatto è precedente al diritto approvato più di recente per la risorsa 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 stabilire se esiste un criterio relativo al ciclo di vita dei dati e se viene rispettato.
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: indica se archiviare o eliminare definitivamente la tabella al termine del periodo di conservazione
Per impostazione predefinita, l'architettura utilizza il seguente periodo di conservazione e l'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 | Archivia |
| Informazioni personali sensibili | 180 | Archivia |
| Informazioni personali | 180 | Archivia |
Record Manager, un asset open source per BigQuery, automatizza l'eliminazione e l'archiviazione delle tabelle BigQuery in base ai valori dei tag sopra indicati e a un file di configurazione. La procedura di eliminazione degli elementi non più necessari imposta una data di scadenza su una tabella e crea una tabella istantanea con un data e ora di scadenza definita nella configurazione di Record Manager. Per impostazione predefinita, la data di scadenza è di 30 giorni. Durante il periodo di eliminazione soft, 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 viene eseguito l'upgrade a una tabella BigLake che consente di taggare il file esterno con i metadati in Data Catalog.
Il seguente diagramma mostra i servizi che si applicano a questo controllo.
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 le norme di conservazione dei dati.
- Due istanze Cloud Storage, una che fornisce spazio di archiviazione per l'archivio e l'altra che 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 Record Manager e l'altra esegue il deployment dei rilevatori.
- Tre istanze Cloud Run, come segue:
- Un'istanza esegue Report Engine, che controlla se i tag sono applicati e pubblica i risultati.
- Un'altra istanza esegue Tag Engine, che applica i tag ai dati nel data warehouse protetto.
- Un'altra istanza esegue Record Manager, che automatizza la pulizia 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 gli asset sensibili, assicurati che il metodo di conservazione sia in linea con le norme relative alla posizione della risorsa.
- Per le risorse sensibili, assicurati che il periodo di conservazione sia in linea con le norme relative alla località della risorsa.
12. La qualità dei dati è gestita
Questo controllo richiede la possibilità di misurare la qualità dei dati in base alla definizione del profilo dei dati o a metriche definite dall'utente.
L'architettura include la possibilità di definire regole di qualità dei dati per un valore singolo o aggregato e di assegnare soglie a una colonna della tabella specifica. Sono inclusi i modelli di tag per verificarne 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 metricametric: il nome della metrica o della regola di qualitàrows_validated: il 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à (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 che si applicano a questo controllo.
Per soddisfare i requisiti di questo controllo, l'architettura utilizza i seguenti servizi:
- Tre data warehouse BigQuery: uno memorizza i dati sensibili, uno memorizza i dati non sensibili e il terzo memorizza le metriche delle regole di qualità.
- Data Catalog archivia i risultati relativi alla 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 i tag sono applicati e pubblica i risultati.
- Un'altra istanza esegue Tag Engine, che applica i tag ai dati nel data warehouse protetto.
- La terza istanza esegue Cloud Data Quality Engine.
- Cloud Data Quality Engine definisce le regole di 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 sia a livello di 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 di qualità dei dati (correttezza e completezza).
- I dati sono sensibili, ma il tag di qualità dei dati non viene applicato alla colonna sensibili.
- 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 a Cloud Data Quality Engine, puoi configurare le attività di qualità dei dati di Dataplex.
13. Vengono stabiliti e applicati i principi di gestione dei costi
Questo controllo richiede la possibilità di ispezionare le risorse dati per confermare l'utilizzo dei costi, in base ai requisiti delle norme e all'architettura dei dati. Le metriche sui costi devono essere complete e non limitarsi all'utilizzo e al trasferimento dello spazio di archiviazione.
L'architettura utilizza Data Catalog per aggiungere i seguenti tag al
cost_metrics modello di tag:
total_query_bytes_billed: numero totale di byte delle query fatturati per questa risorsa dati dall'inizio del mese corrente.total_storage_bytes_billed: numero totale di byte di spazio di archiviazione fatturati per questa risorsa di dati dall'inizio del mese corrente.total_bytes_transferred: somma dei byte trasferiti tra regioni in questo asset dati.estimated_query_cost: costo stimato delle query, in dollari statunitensi, per l'asset di dati del mese corrente.estimated_storage_cost: costo stimato dell'archiviazione, in dollari statunitensi, per la risorsa di dati del mese corrente.estimated_egress_cost: uscita stimata 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 da Fatturazione Cloud in una tabella BigQuery denominata cloud_pricing_export.
Il seguente diagramma mostra i servizi che si applicano a questo controllo.
Per soddisfare i requisiti di questo controllo, l'architettura utilizza i seguenti servizi:
- La fatturazione Cloud fornisce informazioni di fatturazione.
- Data Catalog archivia le informazioni sui costi nei modelli di tag e nei tag.
- BigQuery memorizza le informazioni sui prezzi esportate e le informazioni sui job storici delle query tramite la vista INFORMATION_SCHEMA integrata.
- Due istanze Cloud Run, come segue:
- Un'istanza esegue Report Engine, che controlla se i tag sono applicati e pubblica i risultati.
- Un'altra istanza esegue il motore di tag, che applica i tag ai dati nel data warehouse protetto.
- Pub/Sub pubblica i risultati.
Per rilevare i problemi relativi a questo controllo, l'architettura verifica se esistono asset di dati sensibili senza metriche sui costi associate.
14. La provenienza e la derivazione dei dati sono comprese
Questo controllo richiede la possibilità di ispezionare la tracciabilità della risorsa dati dalla relativa origine e di eventuali modifiche alla relativa eredità.
Per mantenere le informazioni sull'origine e sulla derivazione dei dati, l'architettura utilizza le funzionalità di Data Lineage integrate in Data Catalog. Inoltre, gli script di importazione dei dati definiscono la sorgente finale e la aggiungono come nodo aggiuntivo al grafico della filiera 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 questa risorsa di dati.
Il seguente diagramma mostra i servizi che si applicano a questo controllo.
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 i dati dell'origine finale.
- Data Catalog archivia l'origine finale nei modelli di tag e nei tag.
- Gli script di importazione dei dati caricano i dati da Cloud Storage, definiscono la fonte finale e la aggiungono al grafico della struttura dei dati.
- Due istanze Cloud Run, come segue:
- Un'istanza esegue Report Engine, che controlla se i tag sono applicati e pubblica i risultati.
- Un'altra istanza esegue il motore di tag, che applica i tag ai 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 vengono identificati senza un tag dell'origine finale.
- Il grafico della struttura non è compilato per gli asset di dati sensibili.
Riferimento tag
Questa sezione descrive i modelli di tag e i tag utilizzati da questa architettura per soddisfare i requisiti dei controlli delle chiavi di CDMC.
Modelli di tag di controllo CDMC a livello di tabella
La tabella seguente 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 |
|---|---|---|
| Posizione di archiviazione approvata | approved_storage_location |
4 |
| Uso approvato | approved_use |
8 |
| Email del proprietario dei 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 |
| Geografia dell'ambito di condivisione | sharing_scope_geography |
8 |
| Persona giuridica ambito condivisione | sharing_scope_legal_entity |
8 |
| Periodo di conservazione | retention_period |
11 |
| Ultimate Source | ultimate_source |
14 |
Modello di tag di valutazione dell'impatto
La tabella seguente 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 |
|---|---|---|
| Località soggetto | subject_locations |
10 |
| La valutazione dell'impatto della DPIA | is_dpia |
10 |
| La valutazione dell'impatto della PIA | is_pia |
10 |
| Report di 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 Metriche sui costi
La tabella seguente elenca i tag che fanno parte del modello di tag Metriche sui 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 stimato del traffico in uscita | estimated_egress_cost |
13 |
| Byte totali delle query fatturati | total_query_bytes_billed |
13 |
| Byte di spazio di archiviazione totale fatturati | total_storage_bytes_billed |
13 |
| Byte trasferiti totali | total_bytes_transferred |
13 |
Modello di tag Sensibilità dei dati
La tabella seguente 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 per i criteri di sicurezza
La tabella seguente elenca i tag che fanno parte del modello di tag dei 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 di qualità dei dati
La tabella seguente elenca i tag che fanno parte dei modelli di tag di qualità dei dati 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 tabella seguente elenca i tag di criteri che fanno parte della tassonomia dei tag di criterio di classificazione dei dati sensibili del CDMC e che vengono applicati ai campi. Questi tag delle norme limitano l'accesso a livello di campo e attivano la 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 tabella seguente elenca i metadati tecnici sincronizzati per impostazione predefinita in Data Catalog per tutti gli asset di dati BigQuery.
| Metadati | Controllo delle chiavi applicabile |
|---|---|
| Tipo di asset | — |
| Ora creazione | — |
| Data di scadenza | 11 |
| Località | 4 |
| URL risorsa | 3 |
Passaggi successivi
- Scopri di più su 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ù sul motore di tag.
- Implementa questa soluzione utilizzando l'Google Cloud architettura di riferimento CDMC su GitHub.