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 Funzionalità di gestione dei dati cloud (CDMC) Key Controls Framework, gestito dall'Enterprise Data Management Council, in un data warehouse BigQuery.
Il framework CDMC Key Controls è stato pubblicato principalmente per fornitori di servizi cloud e fornitori di tecnologia. Il framework descrive 14 controlli chiave che i 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 in base al Key Controls Framework CDMC come soluzione cloud certificata CDMC. L'architettura di riferimento utilizza vari servizi e funzionalità di Google Cloud, nonché biblioteche pubbliche per implementare i controlli chiave 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 architettura di riferimento di Google Cloud è in linea con le specifiche di test del framework di controllo chiave CDMC v1.1.1. I numeri nel diagramma rappresentano i controlli chiave affrontati 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 dei controlli chiave CDMC, 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 architettura di riferimento CDMC di Google Cloud su GitHub.
Panoramica del framework dei controlli chiave CDMC
La seguente tabella riassume Framework dei controlli chiave CDMC.
| # | Controllo chiavi CDMC | Requisito di controllo CDMC |
|---|---|---|
| 1 | Conformità del controllo dei dati | I business case per la gestione dei dati nel cloud sono definiti e regolati. Devi monitorare tutti gli asset di dati che contengono dati sensibili la conformità ai controlli chiave CDMC, utilizzando metriche e strumenti notifiche. |
| 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 | Un registro delle origini dati autorevoli e dei punti di provisioning deve essere compilato per tutti gli asset di dati che contengono dati sensibili altrimenti devono essere segnalate a 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 nel punto creazione o 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 nel punto
creazione o 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'uso e i risultati etici dei dati vengono gestiti | Lo scopo del consumo dei dati deve essere fornito per tutti i dati sulla condivisione di contratti che riguardano dati sensibili. Lo scopo deve specificare il tipo di dati richiesti e, per le organizzazioni globali, il nell'ambito del paese o della persona giuridica. |
| 9 | I dati sono protetti e i controlli sono messi in evidenza | Questo controllo richiede quanto segue:
|
| 10 | Viene definito e operativo un framework sulla privacy dei dati | Le valutazioni d'impatto sulla protezione dei dati (DPIA) devono essere per tutti i dati personali in base alla giurisdizione dell'utente. |
| 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 in base a un piano di conservazione definito. |
| 12 | La qualità dei dati è gestita | La misurazione della qualità dei dati deve essere attivata per i dati sensibili con e le metriche distribuite se disponibili. |
| 13 | Vengono stabiliti e applicati i principi di gestione dei costi | Vengono stabiliti e applicati principi di progettazione tecnica. Nel catalogo devono essere disponibili le metriche di costo direttamente associate all'utilizzo, allo spazio di archiviazione e al movimento dei dati. |
| 14 | La provenienza e la derivazione dei dati sono comprese | Le informazioni sulla derivazione dei dati devono essere disponibili 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à del controllo dei dati
Questo controllo richiede che tu possa verificare che tutti i dati sensibili siano monitorati per la conformità a questo framework tramite 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 i risultati e le correzioni 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 sottoscrittore di esempio di risultati, che vengono poi archiviati in un'istanza di BigQuery eseguito nel progetto di governance dei dati. Utilizzando alcune delle viste fornite, può eseguire query sui dati usando BigQuery Studio nella console Google Cloud. Puoi anche creare report utilizzando Looker Studio o altri strumenti di business intelligence compatibili con BigQuery. Segnalazioni che puoi visualizzare includono:
- Riepilogo dei risultati dell'ultima esecuzione
- Dettagli dei risultati 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 che si applicano a questo controllo.
Per soddisfare i requisiti di questo controllo, l'architettura utilizza quanto segue Google Cloud:
- Pub/Sub pubblica i risultati.
- Dataflow carica i risultati in un'istanza BigQuery.
- BigQuery archivia i dati dei risultati e fornisce visualizzazioni di riepilogo.
- Looker Studio fornisce dashboard e report.
Il seguente screenshot mostra un riepilogo di Looker Studio di esempio Fitbit.com.
Il seguente screenshot 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, che è una funzionalità di Dataplex, gestisce due tipi di metadati: metadati tecnici e 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 il catalogo e gli asset di dati viene mantenuta su 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 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 valori predefiniti memorizzati in un riferimento Tabella BigQuery nel progetto di governance dei dati.
Per impostazione predefinita, l'architettura imposta i metadati di proprietà a livello di tabella, ma puoi modificare l'architettura in modo che i metadati siano 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 applicata 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 problemi relativi a questo controllo, l'architettura controlla se ai dati sensibili sia 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 in Tag Engine
di configurazione del deployment e include il tag is_authoritative.
Durante la successiva esecuzione pianificata, Tag Engine compila il tag is_authoritative
nel modello di tag CDMC controls dai valori predefiniti archiviati in un 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 quanto segue Google Cloud:
- 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 Tag Engine, che contrassegna i dati nella un 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 lo spostamento transfrontaliero dei dati vengono gestiti
Questo controllo richiede che l'architettura ispeziona il registro dati requisiti di archiviazione specifici per regione e applicare regole di utilizzo. Un report descrive la posizione geografica degli asset di dati.
L'architettura utilizza Data Catalog per aggiungere
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 Dettagli della tabella BigQuery. BigQuery non consente agli amministratori di modificare la posizione di un set di dati o di una tabella. Invece, se amministratori vogliano cambiare la posizione dei dati, copia il set di dati.
La
vincolo del servizio Criteri dell'organizzazione per le località delle risorse
definisce le regioni di Google Cloud in cui puoi archiviare i dati. Per impostazione predefinita,
l'architettura pone un vincolo al progetto Confidential Data, ma
puoi impostare il vincolo a livello di organizzazione o cartella, se preferisci. Etichetta
Engine replica le località consentite nel tag Data Catalog
modello e memorizza la posizione nel tag approved_storage_location. Se
attivi il livello Premium di Security Command Center e qualcuno aggiorna le località delle risorse
un vincolo del Servizio criteri dell'organizzazione, che Security Command Center genera.
risultati relativi alla vulnerabilità
per le risorse archiviate al di fuori del criterio aggiornato.
Gestore contesto accesso definisce la posizione geografica in cui gli utenti devono trovarsi prima di poter accedere asset di dati. Utilizzo livelli di accesso, puoi specificare quali regioni da cui 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. L'audit trail è archiviato BigQuery Job per schema di informazioni vista.
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 dei 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 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 Tag Engine, che contrassegna i dati nella un data warehouse protetto.
- Pub/Sub pubblica i risultati.
- Cloud Logging scrive gli audit log.
- Security Command Center genera report su eventuali risultati relativi alla località delle risorse l'accesso ai dati.
Per rilevare problemi relativi a questo controllo, l'architettura include un risultato per verificare se il tag delle località approvate include la posizione delle località sensibili e i dati di Google Cloud.
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 (Catalogo dati). Data Catalog registra automaticamente Gli asset Google Cloud, inclusi set di dati, tabelle, e viste. 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 sue 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 quanto segue Google Cloud:
- Due data warehouse BigQuery: uno memorizza i dati riservati e l'altro i dati non riservati.
- Data Catalog archivia i metadati tecnici per le tabelle 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 la modalità questo report per verificare se le impostazioni di sensibilità sono corrette. Inoltre, ogni nuovo asset di dati o modifica a un asset di dati esistente comporta un aggiornamento il catalogo dati.
Le classificazioni vengono archiviate 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; uno dei seguenti:- Informazioni che consentono l'identificazione personale sensibili
- Informazioni che consentono l'identificazione personale
- Informazioni personali sensibili
- Informazioni personali
- Informazioni pubbliche
Puoi modificare le categorie di dati in base ai tuoi requisiti. Ad esempio, puoi aggiungere la classificazione Informazioni Materiali Non Pubbliche (MNPI).
Dopo la protezione dei dati sensibili
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, il più
viene determinato il tipo di infoType e sia le colonne sensibili sia l'intera tabella
con tag con la categoria con il ranking più alto. Il motore dei tag assegna inoltre alla colonna un corrispondente tag delle norme e alla tabella il tag booleano is_sensitive.
Puoi utilizzare la modalità 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
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 Tag Engine, che contrassegna i dati nella un data warehouse protetto.
- Pub/Sub pubblica i risultati.
Per rilevare i problemi relativi a questo controllo, l'architettura include i seguenti risultati:
- Se ai dati sensibili è 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 di accesso ai dati vengono gestiti, applicati e monitorati
Per impostazione predefinita, solo ai creator e ai proprietari vengono assegnati i diritti e l'accesso a e i 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 criterio:
- Informazioni che consentono l'identificazione personale sensibili
- 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
classificazioni di sensibilità derivate da Sensitive Data Protection
e infoType. Ad esempio, il criterio sensitive_personal_identifiable_information
e la categoria sensibile mappa a infoType come AGE, DATE_OF_BIRTH,
PHONE_NUMBER e EMAIL_ADDRESS.
L'architettura utilizza Identity and Access Management (IAM) per gestire gruppi, utenti, e account di servizio che richiedono l'accesso ai dati. IAM vengono concesse autorizzazioni a un determinato asset 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 possono accedere 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 il tuo tramite i provider di identità esistenti per autenticare gli utenti.
Questo controllo richiede anche che l'architettura verifichi regolarmente la presenza di dati risorse a cui non sono stati definiti diritti. Il rilevatore, gestito da Cloud Scheduler, controlla i seguenti scenari:
- Un asset di dati include una categoria sensibile, ma non esiste una categoria .
- 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 dello 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 archivia i tag a livello di tabella e di colonna per la categoria sensibile.
- Due istanze Cloud Run, come segue:
- Un'istanza esegue Report Engine, che controlla se 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'uso e i risultati etici dei dati vengono gestiti
Questo controllo richiede che l'architettura archivi gli accordi di condivisione dei dati
sia il fornitore di dati che i consumatori dei dati, incluso un elenco di
agli scopi di consumo. Lo scopo del consumo dei dati sensibili è quindi
mappati ai diritti archiviati in BigQuery
etichette delle query.
Quando un consumatore interroga i dati sensibili in BigQuery, deve
specificare uno scopo valido che corrisponde al relativo diritto (ad esempio, SET @@query_label = “use:3”;).
L'architettura utilizza Data Catalog per aggiungere i seguenti tag a
il 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 dell'asset di datisharing_scope_geography: l'elenco di località geografiche in cui un asset di dati può essere condivisosharing_scope_legal_entity: l'elenco di entità concordate che possono condividere l'asset di dati
Un data warehouse BigQuery separato include
entitlement_management set di dati 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 pershared_scope_geographyesharing_scope_legal_entitytag.consumer_agreement: il contratto di condivisione dei dati con il consumatore dei dati, inclusi la persona giuridica e l'ambito geografico concordati. Ogni accordo è associati a un'associazione IAM per l'asset 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 sull'asset di dati, ad esempio il nome dell'asset e i dettagli sul proprietario dei dati.
Per verificare i contratti di condivisione dei dati, BigQuery mantiene una per ogni job ed eseguire query su ogni set di dati. La traccia di controllo viene memorizzata nella vista BigQuery Job dello schema delle informazioni. 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 ulteriori informazioni, consulta Informazioni sugli audit log per BigQuery.
Il seguente diagramma mostra i servizi che si applicano a questo controllo.
Per soddisfare i requisiti di questo controllo, l'architettura utilizza quanto segue Google Cloud:
- Due data warehouse BigQuery: uno archivia riservati e l'altra archivia i dati dei diritti, che includono i contratti di condivisione dei dati di fornitori e consumatori, nonché i che non ha uno scopo specifico.
- Data Catalog archivia il contratto di condivisione dei dati del provider le informazioni 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 Tag Engine, che contrassegna i dati nella un data warehouse protetto.
- Pub/Sub pubblica i risultati.
Per rilevare i problemi relativi a questo controllo, l'architettura include i seguenti risultati:
- Se è presente una voce per un asset di dati nella
entitlement_managementset di dati. - 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). - Se un'operazione viene eseguita su una tabella sensibile con un errore chiave di etichetta.
- Indica se un'operazione viene eseguita su una tabella sensibile con un vuoto o con un valore di etichetta per il caso d'uso non approvato.
- Se viene eseguita una query su una tabella sensibile con un metodo operativo non approvato
(ad es.
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 dei dati anonimizzazione per contribuire a proteggere i dati sensibili e fornire un record di questi i controlli di sicurezza.
Questa architettura si basa sulla sicurezza predefinita di Google, che include 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 livello di colonna mascheramento dinamico dei dati configurati tramite tag di criteri e archivia i dati riservati in un Perimetro Controlli di servizio VPC. Puoi anche aggiungere l'applicazione l'anonimizzazione, che puoi implementare on-premise o nell'ambito delle una pipeline di importazione 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 che l'architettura per la regione us-central1. Puoi adattare le norme in base alle tue e soddisfare requisiti diversi, 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 che consentono l'identificazione personale sensibili | 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 o annullamento SHA-256 |
| Informazioni personali | CMEK con HSM | EKM | Valore di mascheramento predefinito | Hash o annullamento SHA-256 |
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 completarlo utilizzando il
Pipeline di importazione dati di Dataflow e Sensitive Data Protection incluse in
il progetto di un 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 delle quali esegue l'anonimizzazione a livello di applicazione, mentre l'altra esegue 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 la crittografia e l'anonimizzazione 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 Tag Engine, che applica i tag ai dati nel data warehouse protetto.
- Risultati pubblicati da Pub/Sub.
Per rilevare problemi relativi a questo controllo, l'architettura include i seguenti risultati:
- Il valore del tag del metodo di crittografia non corrisponde al valore consentito metodi di crittografia per sensibilità e località specificate.
- Una tabella contiene colonne sensibili ma il tag Security Policy Template Template 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 di impatto sulla protezione dei dati (DPIA) o un report di valutazione di impatto sulla privacy (PIA). privacy le valutazioni variano significativamente tra le regioni e le autorità di regolamentazione. Per determinare se sia necessaria una valutazione d'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 si riferisce contenuti in questo asset.is_dpia: indica se è stata completata una valutazione di impatto sulla privacy dei dati (DPIA) per questa risorsa.is_pia: indica se è stata completata una valutazione di impatto sulla privacy (PIA) per questo asset.impact_assessment_reports: link esterno alla pagina dell'impatto viene archiviato il report di valutazione.most_recent_assessment: la data della più recente valutazione dell'impatto.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 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 tipo di valutazione dell'impatto (PIA o DPIA).
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
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 archivia i dettagli della valutazione dell'impatto nei tag all'interno dei modelli di tag.
- Due istanze Cloud Run, come segue:
- Un'istanza esegue Report Engine, che controlla se i tag sono applicati e pubblica i risultati.
- Un'altra istanza esegue Tag Engine, che contrassegna i dati nella un data warehouse protetto.
- Pub/Sub pubblica i risultati.
Per rilevare problemi relativi a questo controllo, l'architettura include i seguenti risultati:
- I dati sensibili esistono 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 della tabella dei criteri.
- 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 esaminare tutti gli asset di dati per determinare esiste un criterio del ciclo di vita dei dati e viene rispettato.
L'architettura utilizza Data Catalog per aggiungere i seguenti tag a
il modello di tag CDMC controls:
retention_period: il tempo, in giorni, per conservare la tabellaexpiration_action: indica se archiviare o eliminare definitivamente la tabella quando termine del periodo di conservazione
Per impostazione predefinita, l'architettura utilizza il seguente periodo di conservazione e scadenza azione:
| Categoria di dati | Periodo di conservazione, in giorni | Azione di scadenza |
|---|---|---|
| Informazioni che consentono l'identificazione personale sensibili | 60 | Elimina definitivamente |
| Informazioni che consentono l'identificazione personale | 90 | Archivia |
| Informazioni personali sensibili | 180 | Archivia |
| Informazioni personali | 180 | Archivia |
Gestione record un asset open source per BigQuery, automatizza l'eliminazione definitiva archiviazione delle tabelle BigQuery in base ai valori tag riportati sopra e a di configurazione del deployment. La procedura di eliminazione degli elementi non validi 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 scadenza è di 30 giorni. Durante il periodo di eliminazione soft, puoi recuperare la tabella. La procedura di archiviazione crea una tabella esterna per Tabella BigQuery che ha superato 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 contrassegna i dati nella un 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 la norma relativa alla posizione dell'asset.
- 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 a: profilazione dei dati o metriche definite dall'utente.
L'architettura include la possibilità di definire regole di qualità dei dati per un valore singolo o aggregato e 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à (il valoresuccess_percentage) soddisfi la soglia accettabilemost_recent_run: l'ora più recente in cui la metrica o la regola di qualità è stato eseguito
Il seguente diagramma mostra i servizi che si applicano a questo controllo.
Per soddisfare i requisiti di questo controllo, l'architettura utilizza quanto segue Google Cloud:
- Tre data warehouse BigQuery: uno per l'archiviazione dati, uno archivia i dati non sensibili e il terzo la qualità metriche delle regole.
- Data Catalog archivia i risultati sulla qualità dei dati nei modelli di tag e nei tag.
- Cloud Scheduler definisce quando viene eseguito Cloud Data Quality Engine.
- Tre istanze Cloud Run, come segue:
- Un'istanza esegue Report Engine, che controlla se 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 che a livello di colonna.
Per rilevare problemi relativi a questo controllo, l'architettura include i seguenti risultati:
- I dati sono sensibili, ma non viene applicato nessun modello di tag per la 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 sulla qualità dei dati non rientrano nelle 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 gli asset di dati per confermare l'utilizzo dei costi, in base ai requisiti delle norme e all'architettura dei dati. Le metriche relative ai costi devono essere e non solo all'uso e allo spostamento dello spazio di archiviazione.
L'architettura utilizza Data Catalog per aggiungere i seguenti tag
Modello di tag cost_metrics:
total_query_bytes_billed: numero totale di byte di query che sono stati fatturati per questo asset di dati dall'inizio del mese in corso.total_storage_bytes_billed: numero totale di byte di archiviazione precedenti fatturati per questo asset di dati dall'inizio del mese in corso.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 la di dati per il mese in corso.estimated_storage_cost: costo stimato dell'archiviazione, in dollari statunitensi, per la risorsa di dati del mese corrente.estimated_egress_cost: traffico in uscita stimato in dollari statunitensi per l'attuale mese 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 Tag Engine, che contrassegna i dati nella un 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 vengono comprese
Questo controllo richiede la possibilità di ispezionare la tracciabilità della risorsa dati dalla relativa origine e di eventuali modifiche alla relativa origine.
Per mantenere le informazioni sulla provenienza e sulla derivazione dei dati, l'architettura utilizza funzionalità di derivazione dei dati 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 archivia riservati, mentre l'altra archivia i dati di origine definitivi.
- Data Catalog archivia l'origine definitiva nei modelli di tag e nei tag.
- Gli script di importazione dati caricano i dati da Cloud Storage, l'origine definitiva e aggiungerla al grafico della derivazione 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 Tag Engine, che contrassegna i dati nella un 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 |
|---|---|---|
| Località di archiviazione approvata | approved_storage_location |
4 |
| Uso approvato | approved_use |
8 |
| Email 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 |
| Condivisione dell'area geografica dell'ambito | sharing_scope_geography |
8 |
| Persona giuridica ambito condivisione | sharing_scope_legal_entity |
8 |
| Periodo di conservazione | retention_period |
11 |
| Fonte definitiva | 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 chiave applicabile |
|---|---|---|
| Località degli argomenti | subject_locations |
10 |
| È una valutazione di impatto del DPIA | is_dpia |
10 |
| È una valutazione di impatto PIA | is_pia |
10 |
| Report di valutazione dell'impatto | impact_assessment_reports |
10 |
| Valutazione d'impatto più recente | most_recent_assessment |
10 |
| Valutazione dell'impatto meno recente | oldest_assessment |
10 |
Modello di tag per le metriche di costo
Nella tabella seguente sono elencati i tag che fanno parte del tag Metriche di costo e che vengono applicate 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 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 di 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 dei criteri di sicurezza
Nella tabella seguente sono elencati i tag che fanno parte del tag del criterio di sicurezza e che si applicano ai campi.
| Tag | ID tag | Controllo chiave 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
Nella tabella seguente sono elencati i tag che fanno parte della colonna Completezza e Modelli di tag di qualità dei dati di correttezza e applicati ai campi.
| Tag | ID tag | Controllo chiave applicabile |
|---|---|---|
| Soglia accettabile | acceptable_threshold |
12 |
| Nome colonna | column_name |
12 |
| Soddisfa la soglia | meets_threshold |
12 |
| Metrica | metric |
12 |
| Corsa più recente | most_recent_run |
12 |
| Righe convalidate | rows_validated |
12 |
| Percentuale di successo | success_percentage |
12 |
Tag dei criteri CDMC a livello di campo
La tabella seguente elenca i tag criterio che fanno parte della tassonomia dei tag criterio di classificazione dei dati sensibili del CDMC e che vengono applicati ai campi. Questi I tag di criteri limitano l'accesso a livello di campo e abilitano i dati a livello di piattaforma anonimizzazione.
| 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
Nella tabella seguente sono elencati i metadati tecnici sincronizzati da predefinita in Data Catalog per tutti i dati BigQuery asset.
| Metadati | Controllo chiave applicabile |
|---|---|
| Tipo di asset | — |
| Ora creazione | — |
| Data di scadenza | 11 |
| Località | 4 |
| URL risorsa | 3 |
Passaggi successivi
- Scopri di più su CDMC.
- Leggi le informazioni sui controlli di sicurezza utilizzati progetto di data warehouse protetto.
- Da scoprire 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 su GitHub.