Importa dati da Google Cloud in un data warehouse BigQuery protetto

Last reviewed 2021-12-16 UTC

Molte organizzazioni eseguono il deployment di data warehouse che archiviano informazioni riservate, in modo da poter analizzare i dati per vari scopi aziendali. Questo documento è rivolto ai data engineer e agli amministratori della sicurezza che il deployment e la protezione dei data warehouse usando BigQuery. Fa parte di un progetto di sicurezza composto da quanto segue:

  • Un repository GitHub contiene un set di configurazioni e script Terraform. Il comando configura un ambiente Google Cloud che supporta una in un data warehouse in cui vengono archiviati dati riservati.

  • Una guida all'architettura, alla progettazione i controlli di sicurezza utilizzati da questo progetto per implementare (questo documento).

  • Una procedura dettagliata che esegue il deployment di un ambiente di esempio.

In questo documento vengono trattati i seguenti argomenti:

  • L'architettura e i servizi Google Cloud che puoi utilizzare proteggere un data warehouse in un ambiente di produzione.

  • Best practice per la governance dei dati quando creando, eseguendo il deployment e gestendo un data warehouse Google Cloud, inclusi l'anonimizzazione, il differenziale dei dati gestione dei dati riservati e controlli dell'accesso a livello di colonna.

Questo documento presuppone che tu abbia già configurato un set di base controlli di sicurezza come descritto nel progetto di base aziendale di Google Cloud. Consente di aggiungere controlli aggiuntivi alle impostazioni di sicurezza per proteggere i dati riservati in un data warehouse.

Casi d'uso di data warehouse

Il progetto supporta i seguenti casi d'uso:

Panoramica

I data warehouse come BigQuery consentono le aziende analizzano i propri dati per ottenere insight. Gli analisti accedono ai dati aziendali archiviati nei data warehouse per creare insight. Se il tuo data warehouse include dati riservati, devi adottare misure per preservare sicurezza, riservatezza, integrità e disponibilità dei dati aziendali mentre è archiviato, mentre è in transito o mentre è in fase di analisi. In questo progetto, devi seguenti:

  • Configura i controlli che contribuiscono a proteggere l'accesso ai dati riservati.
  • Configura i controlli che contribuiscono a proteggere la pipeline di dati.
  • Configura una separazione appropriata dei compiti per diversi utenti tipo.
  • Configura i modelli per trovare e anonimizzare i dati riservati.
  • Configura controlli di sicurezza e logging adeguati per proteggere i dati riservati.
  • Usa la classificazione dei dati e i tag di criteri per limitare l'accesso a colonne specifiche nel data warehouse.

Architettura

Per creare un data warehouse riservato, devi classificare i dati come confidenziali e non riservate, quindi archiviano i dati in perimetri separati. La l'immagine seguente mostra come vengono classificati, anonimizzati e archiviati. Mostra inoltre come reidentificare i dati riservati on demand per e analisi.

L'architettura di un data warehouse riservato.

L'architettura utilizza una combinazione dei seguenti servizi Google Cloud e caratteristiche:

  • Identity and Access Management (IAM) e Resource Manager limitano l'accesso e la segmentazione delle risorse. I controlli dell'accesso e la gerarchia delle risorse seguono il principio del privilegio minimo.

  • Controlli di servizio VPC crea perimetri di sicurezza che isolano servizi e risorse grazie all'impostazione autorizzazioni, controlli dell'accesso e scambio sicuro di dati. I perimetri sono i seguenti:

    • Un perimetro di importazione dati che accetta i dati in entrata (in batch o in flusso) e li anonimizza. Una zona di destinazione separata aiuta a proteggere il resto carichi di lavoro dai dati in entrata.

    • un perimetro dei dati riservati in grado di reidentificare dati riservati e archiviarli in un'area riservata.

    • Un perimetro di governance che archivia le chiavi di crittografia e definisce quali dati sono considerati riservati.

    Questi perimetri sono progettati per proteggere i contenuti in entrata, isolare le informazioni i dati configurando ulteriori controlli e monitoraggio dell'accesso e la governance dai dati effettivi nel data warehouse. La tua governance include gestione delle chiavi, gestione del catalogo dati e logging.

  • Cloud Storage e Pub/Sub riceve i dati nel seguente modo:

    • Cloud Storage: riceve e archivia i dati in batch prima dell'anonimizzazione. Cloud Storage utilizza TLS per criptare i dati in transito e cripta i dati nello spazio di archiviazione per impostazione predefinita. La chiave di crittografia è una chiave di crittografia gestita dal cliente (CMEK). Puoi contribuire a proteggere l'accesso a Cloud Storage bucket utilizzando controlli di sicurezza come Identity and Access Management, elenchi di controllo dell'accesso (ACL) e documenti relativi ai criteri. Per ulteriori informazioni sui controlli di accesso supportati, consulta la Panoramica di il controllo dell'accesso.

    • Pub/Sub: riceve e archivia i flussi di dati prima anonimizzazione. Pub/Sub utilizza authentication, accesso controlli e crittografia a livello di messaggio con una CMEK per proteggere i tuoi dati.

  • Due pipeline Dataflow anonimizzano e reidentificano i dati riservati nel modo seguente:

    • La prima pipeline anonimizza i dati riservati mediante la assegnazione di pseudonimi.
    • La seconda pipeline reidentifica i dati riservati quando gli utenti autorizzati richiedono l'accesso.

    Per proteggere i dati, Dataflow utilizza un account di servizio univoco e una chiave di crittografia per ogni pipeline, oltre all'accesso i controlli di sicurezza. Per contribuire a proteggere l'esecuzione della pipeline spostandola nel servizio di backend, Dataflow utilizza Streaming Engine. Per ulteriori informazioni, consulta Dataflow sicurezza e autorizzazioni.

  • Sensitive Data Protection anonimizza i dati riservati durante per l'importazione.

    Sensitive Data Protection anonimizza i dati strutturati e non strutturati in base agli infoType o ai record rilevati.

  • Cloud HSM ospita la chiave di crittografia della chiave (KEK). Cloud HSM è un servizio per modulo di sicurezza hardware (HSM) basato su cloud.

  • Data Catalog classifica automaticamente i dati riservati con metadati, noti anche come tag di criterio, durante l'importazione. Data Catalog utilizza anche i metadati per gestire l'accesso ai dati riservati. Per ulteriori informazioni, consulta Data Catalog Panoramica. Per controllare l'accesso ai dati all'interno del data warehouse, puoi applicare tag di criteri alle colonne che includono dati riservati.

  • BigQuery archivia i dati riservati nel perimetro dei dati riservati.

    BigQuery utilizza vari controlli di sicurezza per proteggere i contenuti, tra cui l'accesso controlli, a livello di colonna di sicurezza per contenuti e la crittografia dei dati.

  • Security Command Center monitora e esamina i risultati sulla sicurezza in tutto l'ambiente Google Cloud da una posizione centrale.

Struttura organizzativa

Puoi raggruppare le risorse dell'organizzazione in modo da poterle gestire e separare gli ambienti di test dall'ambiente di produzione. Resource Manager ti consente di raggruppare logicamente e le risorse per progetto, cartella e organizzazione.

Il seguente diagramma mostra una gerarchia di risorse con cartelle che rappresentano ambienti diversi, bootstrap, Common, di produzione, non di produzione (o gestione temporanea) e di sviluppo. Esegui il deployment della maggior parte dei progetti del progetto nella cartella di produzione e del progetto di governance dei dati nella cartella comune utilizzata per la governance.

Gerarchia delle risorse per un data warehouse riservato.

Cartelle

Puoi utilizzare le cartelle per isolare l'ambiente di produzione e i servizi di governance dagli ambienti non di produzione e di test. La tabella seguente descrive le cartelle del progetto delle basi aziendali utilizzate da questo progetto.

Cartella Descrizione
Produzione Contiene progetti con risorse cloud che sono state testate e sono pronto per l'uso.
Comune Contiene servizi centralizzati per l'organizzazione, ad esempio il progetto di governance.

Puoi modificare i nomi di queste cartelle per allinearli alla struttura delle cartelle della tua organizzazione, ma ti consigliamo di mantenere una struttura simile. Per saperne di più, consulta il progetto delle basi aziendali di Google Cloud.

Progetti

Puoi isolare le parti dell'ambiente utilizzando i progetti. La tabella seguente descrive i progetti necessari all'interno dell'organizzazione. Questi progetti vengono creati quando esegui il codice Terraform. Puoi modificare i nomi di questi progetti, ma ti consigliamo di mantenere una struttura dei progetti simile.

Progetto Descrizione
Importazione dati Contiene i servizi necessari per ricevere dati e anonimizzare i dati riservati.
Governance Contiene servizi che forniscono gestione delle chiavi, logging e catalogazione dei dati le funzionalità di machine learning.
Dati non riservati Contiene i servizi necessari per archiviare i dati anonimizzati.
Dati riservati Contiene i servizi necessari per archiviare e reidentificare le informazioni riservate e i dati di Google Cloud.

Oltre a questi progetti, l'ambiente deve includere anche un progetto che ospita un job di modello flessibile di Dataflow. Il job del modello flessibile è richiesto per la pipeline di dati in modalità flusso.

Mappatura di ruoli e gruppi ai progetti

Devi concedere a gruppi di utenti diversi della tua organizzazione l'accesso ai progetti che compongono la e un data warehouse riservato. Le seguenti sezioni descrivono i suggerimenti relativi ai progetti per i gruppi di utenti e le assegnazioni dei ruoli nei progetti creati. Puoi personalizzare i gruppi in modo che corrispondano alla struttura esistente della tua organizzazione, ma ti consigliamo di mantenere una separazione simile dei compiti e dell'assegnazione dei ruoli.

Gruppo di analisti di dati

Gli analisti di dati analizzano i dati nel data warehouse. Questo gruppo richiede ruoli in progetti diversi, come descritto nella tabella seguente.

Mappatura di progetti Ruoli
Importazione dati

Ruolo aggiuntivo per gli analisti di dati che richiedono l'accesso a dati riservati:

Dati riservati
  • roles/bigquery.dataViewer
  • roles/bigquery.jobUser
  • roles/bigquery.user
  • roles/dataflow.viewer
  • roles/dataflow.developer
  • roles/logging.viewer
Dati non riservati
  • roles/bigquery.dataViewer
  • roles/bigquery.jobUser
  • roles/bigquery.user
  • roles/logging.viewer

Gruppo di data engineer

I data engineer configurano e gestiscono pipeline di dati e data warehouse. Questo gruppo richiede ruoli in progetti diversi, come descritto nella tabella seguente.

Mappatura di progetti Ruoli
Importazione dati
Dati riservati
  • roles/bigquery.dataEditor
  • roles/bigquery.jobUser
  • roles/cloudbuild.builds.editor
  • roles/cloudkms.viewer
  • roles/compute.networkUser
  • roles/dataflow.admin
  • roles/logging.viewer
Dati non riservati
  • roles/bigquery.dataEditor
  • roles/bigquery.jobUser
  • roles/cloudkms.viewer
  • roles/logging.viewer

Gruppo di amministratori di rete

Gli amministratori di rete configurano la rete. In genere, sono membri del networking dell'IA.

Gli amministratori di rete richiedono i seguenti ruoli a livello di organizzazione:

Gruppo di amministratori della sicurezza

Gli amministratori della sicurezza gestiscono i controlli di sicurezza, ad esempio accesso, chiavi, regole firewall, Controlli di servizio VPC e Security Command Center.

Gli amministratori della sicurezza richiedono i seguenti ruoli a livello di organizzazione:

Gruppo di analisti della sicurezza

Gli analisti della sicurezza monitorano e rispondono agli incidenti di sicurezza e ai risultati del Sensitive Data Protection.

Gli analisti della sicurezza richiedono i seguenti ruoli a livello di organizzazione:

Comprensione dei controlli di sicurezza necessari

Questa sezione illustra i controlli di sicurezza all'interno di Google Cloud che per proteggere il tuo data warehouse. I principi di sicurezza chiave da considerare sono i seguenti:

  • Proteggi l'accesso adottando i principi del privilegio minimo.

  • Proteggi le connessioni di rete mediante la progettazione e le norme di segmentazione.

  • Proteggi la configurazione di ogni servizio.

  • Classificare e proteggere i dati in base al loro livello di rischio.

  • Comprendere i requisiti di sicurezza per l'ambiente che ospita il data warehouse.

  • Configura un monitoraggio e un logging sufficienti per rilevamento, indagine e risposta.

Controlli di sicurezza per l'importazione dati

Per creare il tuo data warehouse, devi trasferire i dati da un altro Origine Google Cloud (ad esempio un data lake). Puoi utilizzare uno dei seguenti seguenti opzioni per trasferire i dati nel data warehouse su BigQuery:

  • Un job batch che utilizza Cloud Storage.

  • un job di flussi di dati che utilizza Pub/Sub. Per proteggere i dati durante l'importazione, puoi utilizzare le regole del firewall, i criteri di accesso e la crittografia.

Regole firewall e di rete

Regole firewall Virtual Private Cloud (VPC) che controllano il flusso di dati nei perimetri. Puoi creare regole firewall che negano tutto il traffico in uscita, ad eccezione di connessioni TCP 443 specifiche dalla porta restricted.googleapis.com nomi di dominio. Il dominio restricted.googleapis.com offre i seguenti vantaggi:

  • Aiuta a ridurre la superficie di attacco della rete utilizzando l'accesso privato Google quando i carichi di lavoro comunicano con le API e i servizi Google.
  • Garantisce di utilizzare solo i servizi che supportano i Controlli di servizio VPC.

Per ulteriori informazioni, consulta Configurazione Accesso privato Google.

Devi configurare subnet separate per ogni job Dataflow. Subnet separate assicurano che i dati anonimizzati siano correttamente separati dai dati che vengono reidentificati.

La pipeline di dati richiede l'apertura delle porte TCP nel firewall, definita nel File dataflow_firewall.tf nel modulo dwh-networking repository Git. Per ulteriori informazioni, consulta Configurazione dell'accesso a internet e del firewall .

Per impedire alle risorse di utilizzare indirizzi IP esterni, il criterio dell'organizzazione compute.vmExternalIpAccess è impostato in modo da rifiutare tutto.

Controlli del perimetro

Come mostrato nel diagramma dell'architettura, le risorse vengono posizionate per il data warehouse riservato in perimetri separati. Per abilitare i servizi in perimetri diversi per condividere i dati, si creano bridge perimetri. Perimetro i bridge consentono ai servizi protetti di effettuare richieste per risorse al di fuori del proprio perimetrale. Questi bridge creano le seguenti connessioni:

  • Collegano il progetto di importazione dati al progetto di governance in modo che l'anonimizzazione possa avvenire durante l'importazione.

  • Collegano il progetto relativo ai dati non riservati e il progetto relativo ai dati riservati. in modo che i dati riservati possano essere identificati nuovamente quando un analista di dati che lo richieda.

  • Collegano il progetto riservato al progetto di governance dei dati in modo che la reidentificazione possa avvenire su richiesta di un analista di dati.

Oltre ai bridge perimetrali, puoi utilizzare le regole di traffico in uscita per consentire alle risorse protette da perimetri di servizio accedono alle risorse che si trovano all'esterno perimetrale. In questa soluzione, configurerai le regole in uscita per ottenere il traffico Job del modello flessibile Dataflow che si trovano in Cloud Storage in una progetto. Per saperne di più, consulta Accedere a una risorsa Google Cloud fuori dal perimetro.

Criterio di accesso

Per garantire che solo identità specifiche (utente o servizio) possano accedere a risorse e dati, abilita i gruppi e i ruoli IAM.

Per assicurarti che solo origini specifiche possano accedere ai progetti, attiva una norme di accesso per il tuo account dell'organizzazione. Ti consigliamo di creare un criterio di accesso che specifichi di indirizzi IP consentiti per le richieste e consente solo le richieste provenienti da specifiche o account di servizio. Per ulteriori informazioni, vedi Livello di accesso attributi.

Gestione delle chiavi e crittografia per l'importazione

Entrambe le opzioni di importazione utilizzano Cloud HSM per gestire CMEK. Puoi usare le chiavi CMEK per proteggere i tuoi dati durante l'importazione. Sensitive Data Protection protegge ulteriormente i tuoi dati criptando i dati riservati tramite i rilevatori che configuri.

Per importare i dati, utilizzi le seguenti chiavi di crittografia:

  • Una chiave CMEK per il processo di importazione, utilizzata anche la pipeline Dataflow e il servizio Pub/Sub. Il processo di importazione è a volte indicato come processo ETL (Extract, Transform, Load).

  • La chiave di crittografia sottoposta a wrapping da Cloud HSM per il processo di anonimizzazione dei dati mediante Sensitive Data Protection.

  • Due chiavi CMEK: una per il warehouse BigQuery nel progetto relativo ai dati non riservati e l'altra per il warehouse nel progetto relativo ai dati riservati. Per ulteriori informazioni, consulta le sezioni Chiave dei modelli.

Devi specificare la località CMEK, determina la posizione geografica in cui viene archiviata la chiave disponibili per l'accesso. Devi assicurarti che la CMEK si trovi nella stessa località delle risorse. Per impostazione predefinita, CMEK viene ruotata ogni 30 giorni.

Se gli obblighi di conformità della tua organizzazione richiedono di gestire le tue chiavi esternamente da Google Cloud, puoi abilitare Cloud External Key Manager. Se utilizzi chiavi esterne, sei responsabile attività di gestione delle chiavi, inclusa rotazione della chiave.

Account di servizio e controlli dell'accesso

Gli account di servizio sono identità che Google Cloud può utilizzare per eseguire richieste API per tuo conto. Gli account di servizio assicurano che le identità degli utenti non abbiano accesso diretto ai servizi. Per consentire la separazione dei compiti, crea account di servizio con ruoli diversi per specifici scopi. Questi account di servizio sono definiti nel modulo data-ingestion e nel modulo confidential-data. Gli account di servizio sono i seguenti:

  • Un account di servizio controller Dataflow per Dataflow che anonimizza i dati riservati.

  • Un account di servizio controller Dataflow per Dataflow che reidentifica i dati riservati.

  • Un account di servizio Cloud Storage per importare i dati da un file batch.

  • Un account di servizio Pub/Sub per importare i dati da un flusso di dati completamente gestito di Google Cloud.

  • Un account di servizio Cloud Scheduler per eseguire il job batch Dataflow che crea la pipeline Dataflow.

Nella tabella seguente sono elencati i ruoli assegnati a ciascun account di servizio:

Account di servizio Nome Progetto Ruoli

Controller Dataflow

Questo account viene utilizzato per l'anonimizzazione.

sa-dataflow-controller Importazione dati

Controller Dataflow

Questo account viene utilizzato per la reidentificazione.

sa-dataflow-controller-reid Dati riservati
Cloud Storage sa-storage-writer Importazione dati
  • roles/storage.objectViewer
  • roles/storage.objectCreator
Per le descrizioni di questi ruoli, vedi Ruoli IAM per in Cloud Storage.
Pub/Sub sa-pubsub-writer Importazione dati
  • roles/pubsub.publisher
  • roles/pubsub.subscriber
Per la descrizione di questi ruoli, vedi Ruoli IAM per Pub/Sub.
Cloud Scheduler sa-scheduler-controller Importazione dati
  • roles/compute.viewer
  • roles/dataflow.developer

Anonimizzazione dei dati

Puoi utilizzare Sensitive Data Protection per anonimizzare i tuoi dati strutturati e non strutturati durante la fase di importazione. Per i dati strutturati, utilizzi record trasformazioni in base ai campi per anonimizzare i dati. Per un esempio consulta la sezione Cartella /examples/de_identification_template/. Questo esempio controlla i dati strutturati per verificare la presenza di eventuali crediti numeri di carte e PIN delle carte di credito. Per i dati non strutturati, vengono utilizzate informazioni per anonimizzare i dati.

Per anonimizzare i dati taggati come riservati, utilizzare Sensitive Data Protection e una pipeline Dataflow per tokenizzarlo. Questa pipeline prende i dati da Cloud Storage, li elabora e poi la invia al data warehouse BigQuery.

Per ulteriori informazioni sul processo di anonimizzazione dei dati, consulta Informazioni governance.

Controlli di sicurezza per l'archiviazione dei dati

Configuri i seguenti controlli di sicurezza per proteggere i dati nel Warehouse BigQuery:

  • Controlli di accesso a livello di colonna

  • Account di servizio con ruoli limitati

  • Criteri dell'organizzazione

  • I perimetri Controlli di servizio VPC tra il progetto riservato e il progetto non riservato, con ponti perimetri appropriati

  • Crittografia e gestione delle chiavi

Controlli di accesso a livello di colonna

Per proteggere i dati riservati, puoi utilizzare i controlli di accesso per nelle colonne warehouse BigQuery. Per accedere ai dati in queste colonne, un analista di dati deve avere il ruolo Lettore granulare.

Per definire l'accesso per le colonne in BigQuery, crea un criterio . Ad esempio, taxonomy.tf nel Il modulo di esempio bigquery-confidential-data crea i seguenti tag:

  • Un tag di criteri 3_Confidential per le colonne che includono informazioni molto sensibili, come numeri di carte di credito. Gli utenti che hanno accesso a questo tag hanno accesso anche alle colonne codificate con i tag di criterio 2_Private o 1_Sensitive.

  • Un tag di criteri 2_Private per le colonne che includono informazioni sensibili che consentono l'identificazione personale (PII), come il nome di una persona. Gli utenti che hanno accesso a questo tag hanno accesso anche alle colonne codificate con il tag di criteri 1_Sensitive. Gli utenti non hanno accesso alle colonne codificate con il tag di criteri 3_Confidential.

  • Un tag di criteri 1_Sensitive per le colonne che includono dati che non possono essere resi pubblici, come il massimale di credito. Gli utenti che hanno accesso a questo tag non hanno accesso alle colonne codificate con i tag di criterio 2_Private o 3_Confidential.

Tutto ciò che non è taggato è disponibile per tutti gli utenti che hanno accesso al data warehouse.

Questi controlli dell'accesso garantiscono che, anche dopo la nuova identificazione dei dati, non possano essere letti finché l'accesso non viene concesso esplicitamente all'utente.

Account di servizio con ruoli limitati

Devi limitare l'accesso al progetto relativo ai dati riservati in modo che gli utenti possono visualizzare i dati riservati. Per farlo, crea un account di servizio con il ruolo roles/iam.serviceAccountUser che deve essere rappresentato dagli utenti autorizzati. Servizio Il furto d'identità degli account consente agli utenti di utilizzare gli account di servizio senza scaricare il delle chiavi degli account di servizio, che migliorano la sicurezza complessiva del progetto. La rappresentazione Un token a breve termine che gli utenti autorizzati con il ruolo roles/iam.serviceAccountTokenCreator sono autorizzati a scaricare.

Criteri dell'organizzazione

Questo progetto include i vincoli dei criteri dell'organizzazione utilizzati dal progetto di base aziendale e aggiunge vincoli aggiuntivi. Per saperne di più sui vincoli utilizzati dal progetto base aziendale, consulta Vincoli dei criteri dell'organizzazione.

La tabella seguente descrive i vincoli aggiuntivi dei criteri dell'organizzazione definiti nel modulo org_policies:

Norme Nome vincolo Valore consigliato
Limita i deployment delle risorse a specifiche risorse fisiche luoghi. Per ulteriori valori, consulta la sezione Valore gruppi di lavoro. gcp.resourceLocations
Uno dei seguenti valori:
in:us-locations
in:eu-locations
in:asia-locations
Disabilita account di servizio creazione iam.disableServiceAccountCreation true
Abilita OS Login per le VM create nel progetto. Per ulteriori informazioni, consulta la sezione sulla gestione del sistema operativo in un organizzazione e OS Login. compute.requireOsLogin true
Limita le nuove regole di forwarding a solo per uso interno, in base a Indirizzo IP. compute.restrictProtocolForwardingCreationForTypes INTERNAL
Definisci l'insieme di subnet VPC condivise che le risorse di Compute Engine. compute.restrictSharedVpcSubnetworks projects/PROJECT_ID/regions/REGION/s ubnetworks/SUBNETWORK-NAME,

Sostituisci SUBNETWORK-NAME con l'ID risorsa della subnet privata che deve essere utilizzata dal progetto base.
Disabilita il logging dell'output della porta seriale in Cloud Logging. compute.disableSerialPortLogging true

Gestione delle chiavi e crittografia per l'archiviazione e la reidentificazione

Gestisci chiavi CMEK separate per i tuoi dati riservati in modo da poter re-identificare i dati. Per proteggere le chiavi, puoi utilizzare Cloud HSM. Per identificare nuovamente i tuoi dati, utilizza le seguenti chiavi:

  • Una chiave CMEK utilizzata dalla pipeline Dataflow per il processo di reidentificazione.

  • La chiave di crittografia originale utilizzata da Sensitive Data Protection per anonimizzare i tuoi dati.

  • Una chiave CMEK per il warehouse BigQuery nel progetto relativo ai dati riservati.

Come accennato in precedenza in Gestione delle chiavi e crittografia per l'importazione, puoi specificare la posizione e i periodi di rotazione CMEK. Puoi utilizzare Cloud EKM se richiesto dalla tua organizzazione.

Controlli operativi

Puoi abilitare il logging e le funzionalità del livello Premium di Security Command Center come come analisi dello stato della sicurezza e rilevamento delle minacce. Questi controlli ti consentono di seguenti:

  • Monitora chi accede ai tuoi dati.

  • Assicurati di eseguire controlli adeguati posto.

  • Supporta la capacità dei team operativi e di gestione degli incidenti per risolvere i problemi che potrebbero verificarsi.

Access Transparency

Access Transparency fornisce una notifica in tempo reale nel caso in cui il personale dell'Assistenza Google richieda l'accesso ai tuoi dati. I log di Access Transparency vengono generati ogni volta che una persona accede a contenuti, e solo il personale Google con giustificazioni aziendali valide (ad esempio, una richiesta di assistenza) può ottenere l'accesso. Ti consigliamo di abilitare Access Transparency.

Logging

Per aiutarti a soddisfare i requisiti di controllo e ottenere informazioni sui tuoi progetti, devi configurare Observability di Google Cloud con log di dati per i servizi che vuoi monitorare. Il modulo centralized-logging configura le seguenti best practice:

Per tutti i servizi all'interno dei progetti, i log devono includere informazioni sulle letture e scritture dei dati e su ciò che leggono gli amministratori. Per ulteriori best practice di logging, vedi Controlli di rilevamento.

Avvisi e monitoraggio

Dopo aver eseguito il deployment del progetto base, puoi configurare degli avvisi per comunicare al tuo centro operativo di sicurezza (SOC) che una potrebbe verificarsi un incidente di sicurezza. Ad esempio, puoi utilizzare gli avvisi per comunicare al tuo analista della sicurezza quando un'autorizzazione IAM è stata modificata. Per ulteriori informazioni sulla configurazione Per gli avvisi di Security Command Center, vedi Configurare le notifiche sui risultati. Per avvisi aggiuntivi che non sono pubblicati da Security Command Center, puoi configurare avvisi con e configurazione in Cloud Monitoring.

Ulteriori considerazioni sulla sicurezza

I controlli di sicurezza in questo progetto sono stati esaminati dal team Il team di Google Cybersecurity Action e un team per la sicurezza di terze parti. Per richiedere l'accesso in conformità a un NDA a entrambi Modello di minaccia STRIDE e il report di riepilogo di valutazione, invia un'email a secured-dw-blueprint-support@google.com.

Oltre ai controlli di sicurezza descritti in questa soluzione, devi rivedere e gestire la sicurezza e i rischi nelle aree chiave che si sovrappongono e interagire con l'uso che fai di questa soluzione. Questi includono seguenti:

  • Il codice che utilizzi per la configurazione, il deployment e l'esecuzione di job Dataflow.

  • La tassonomia di classificazione dei dati che utilizzi con questa soluzione.

  • Il contenuto, la qualità e la sicurezza dei set di dati archiviati per l'analisi nel data warehouse.

  • L'ambiente complessivo in cui esegui il deployment della soluzione, inclusi seguenti:

    • La progettazione, la segmentazione e la sicurezza delle reti che colleghi a questa soluzione.
    • La sicurezza e la governance dei controlli IAM della tua organizzazione.
    • Le impostazioni di autenticazione e autorizzazione per gli attori a cui concedi l'accesso all'infrastruttura che fa parte soluzione cloud e che hanno accesso ai dati archiviati e gestiti al suo interno.

Riepilogo

Per implementare l'architettura descritta in questo documento, segui questi passaggi:

  1. Determina se eseguirai il deployment del progetto con l'azienda progetti di base o da soli. Se scegli di non eseguire il deployment del progetto base aziendale, assicurati che il tuo ambiente abbia una base di sicurezza simile.

  2. Esamina il file Readme per il progetto e assicurati di soddisfare tutti i prerequisiti.

  3. Nell'ambiente di test, esegui il deployment della procedura dettagliata per visualizzare la soluzione in azione. Come parte del processo di test, considera quanto segue:

    1. Usa Security Command Center per analizzare i progetti appena creati in base requisiti di conformità.

    2. Aggiungi i tuoi dati di esempio al warehouse BigQuery.

    3. Collabora con un analista di dati della tua azienda per testare il suo accesso ai e sulla possibilità di interagire con i dati provenienti di BigQuery nel modo previsto.

  4. Esegui il deployment del progetto nell'ambiente di produzione.

Passaggi successivi