Importare i dati da Google Cloud in un data warehouse BigQuery protetto

Last reviewed 2021-12-16 UTC

Molte organizzazioni implementano data warehouse che archiviano informazioni confidenziali in modo da poter analizzare i dati per una serie di scopi commerciali. 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:

  • Un repository GitHub che contiene un insieme di configurazioni e script Terraform. La configurazione Terraform imposta un ambiente in Google Cloud che supporta un data warehouse che archivia 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.

Questo documento illustra quanto segue:

  • L'architettura e i servizi Google Cloud che puoi utilizzare per contribuire a 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. Ti aiuta ad applicare controlli aggiuntivi a quelli di sicurezza esistenti per contribuire a proteggere i dati riservati in un data warehouse.

Casi d'uso dei data warehouse

Il progetto supporta i seguenti casi d'uso:

Panoramica

I data warehouse come BigQuery consentono alle attività di analizzare i dati aziendali per ottenere informazioni. Gli analisti accedono ai dati aziendali archiviati nei data warehouse per creare approfondimenti. 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 i controlli di sicurezza e la registrazione appropriati per proteggere i dati riservati.
  • Utilizza 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 riservati e non riservati, quindi archiviarli 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 del 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 segmentano le 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 impostando autorizzazioni, controlli di accesso e scambio di dati protetti. 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 identificare nuovamente dati riservati e archiviarli in un'area riservata.

    • Un perimetro di governance che archivia le chiavi di crittografia e definisce cosa è considerato dato riservato.

    Questi perimetri sono progettati per proteggere i contenuti in entrata, isolare i dati riservati impostando controlli e monitoraggio dell'accesso aggiuntivi e separare 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 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 ai bucket Cloud Storage utilizzando controlli di sicurezza come Identity and Access Management, elenchi di controllo dell'accesso (ACL) e documenti di criteri. Per ulteriori informazioni sui controlli di accesso supportati, consulta la Panoramica di il controllo dell'accesso.

    • Pub/Sub: riceve e archivia i dati in streaming prima della 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 identificano nuovamente i dati riservati come segue:

    • La prima pipeline anonimizza i dati riservati utilizzando la pseudonimizzazione.
    • La seconda pipeline identifica di nuovo i dati riservati quando gli utenti autorizzati necessitano di accedere.

    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 trasferendola al servizio di backend, Dataflow utilizza Streaming Engine. Per ulteriori informazioni, vedi Autorizzazioni e sicurezza di Dataflow.

  • 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 i metadati anche per gestire l'accesso ai dati riservati. Per ulteriori informazioni, consulta la panoramica di Data Catalog. Per controllare l'accesso ai dati all'interno del data warehouse, applica i tag criterio 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 dell'organizzazione

Raggruppa le risorse della tua 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, come bootstrap, common, produzione, non di produzione (o gestione temporanea) e 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.

La 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 ulteriori informazioni, consulta il progetto di base per le aziende con Google Cloud.

Progetti

Isolerai parti del tuo 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 funzionalità di gestione delle chiavi, di registrazione e di catalogazione dei dati.
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 modello flessibile è necessario per la pipeline di dati in streaming.

Mappatura di ruoli e gruppi ai progetti

Devi concedere a diversi gruppi di utenti della tua organizzazione l'accesso ai progetti che compongono il 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 base 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 dei 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 la pipeline e il data warehouse. Questo gruppo richiede ruoli in progetti diversi, come descritto nella tabella seguente.

Mappatura dei 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, fanno parte del team di networking.

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, tra cui accesso, chiavi, regole del 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:

  • Garantisci 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 ciascun servizio.

  • Classifica e proteggi i dati in base al loro livello di rischio.

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

  • Configurare un monitoraggio e un logging sufficienti per il rilevamento, l'indagine e la 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 una delle 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 contribuire a proteggere i dati durante l'importazione, puoi utilizzare regole firewall, criteri di accesso e crittografia.

Regole di rete e firewall

Le regole firewall Virtual Private Cloud (VPC) controllano il flusso di dati nei perimetri. Crea regole firewall che negano tutto il traffico in uscita, ad eccezione di determinate connessioni alla porta TCP 443 provenienti dai nomi di dominio speciali restricted.googleapis.com. Il dominio restricted.googleapis.com presenta 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, come definito nel file dataflow_firewall.tf nel repository del modulo dwh-networking. Per ulteriori informazioni, consulta la pagina Configurazione dell'accesso a internet e delle regole firewall.

Per negare alle risorse la possibilità di utilizzare indirizzi IP esterni, il criterio dell'organizzazione compute.vmExternalIpAccess è impostato su Rifiuta tutto.

Controlli del perimetro

Come mostrato nel diagramma dell'architettura, le risorse vengono posizionate per il data warehouse riservato in perimetri separati. Per consentire ai servizi in perimetri diversi di condividere dati, crei ponti di perimetro. I bridge per i perimetri consentono ai servizi protetti di effettuare richieste di risorse al di fuori del loro perimetro. Questi ponti effettuano le seguenti connessioni:

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

  • Collega il progetto di dati non riservati al progetto di dati riservati in modo che i dati riservati possano essere nuovamente identificati quando un data analyst lo richiede.

  • Collega il progetto riservato al progetto di governance dei dati in modo che la reidentificazione possa avvenire quando un analista dei dati lo richiede.

Oltre ai bridge di perimetro, puoi utilizzare le regole di uscita per consentire alle risorse protette dai perimetri di servizio di accedere alle risorse esterne al perimetro. In questa soluzione, configuri le regole di uscita per ottenere i job di modello flessibile di Dataflow esterni che si trovano in Cloud Storage in un progetto esterno. 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, attiva 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 Google dell'organizzazione. Ti consigliamo di creare un criterio di accesso che specifichi l'intervallo di indirizzi IP consentiti per le richieste e consenta solo richieste da utenti o account di servizio specifici. Per ulteriori informazioni, consulta Attributi del livello di accesso.

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 utilizzando i rilevatori che configuri.

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

  • Una chiave CMEK per il processo di importazione utilizzata anche dalla pipeline Dataflow e dal servizio Pub/Sub. Il processo di importazione è talvolta definito processo ETL (estrazione, trasformazione e caricamento).

  • La chiave di crittografia incapsulata da Cloud HSM per il processo di anonimizzazione dei dati utilizzando la Protezione dei dati sensibili.

  • 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 saperne di più, consulta Gestione delle chiavi.

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

Se le obbligazioni di conformità della tua organizzazione richiedono di gestire le tue chiavi esternamente da Google Cloud, puoi attivare 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à utente non abbiano accesso diretto ai servizi. Per consentire la separazione dei compiti, crei account di servizio con ruoli diversi per scopi specifici. 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 del controller Dataflow per la pipeline 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 servizio di streaming.

  • 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

Dataflow controller

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 le descrizioni di questi ruoli, consulta Ruoli IAM per Pub/Sub.
Cloud Scheduler sa-scheduler-controller Importazione dati
  • roles/compute.viewer
  • roles/dataflow.developer

Anonimizzazione dei dati

Utilizzi Sensitive Data Protection per anonimizzare i 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 contrassegnati come riservati, utilizza Sensitive Data Protection e una pipeline Dataflow per tokenizzarli. Questa pipeline prende i dati da Cloud Storage, li elabora e poi la invia al data warehouse BigQuery.

Per ulteriori informazioni sulla procedura di anonimizzazione dei dati, consulta la governance dei dati.

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

  • Service account con ruoli limitati

  • Criteri dell'organizzazione

  • Perimetri dei Controlli di servizio VPC tra il progetto riservato e il progetto non riservato, con bridge di perimetro 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 alle colonne in BigQuery, crea tag di criteri. 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 con il tag criterio 1_Sensitive. Gli utenti non hanno accesso alle colonne contrassegnate con il tag di criterio 3_Confidential.

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

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

Questi controlli di accesso garantiscono che, anche dopo la reidentificazione, i 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 di dati riservati in modo che solo gli utenti autorizzati possano visualizzarli. Per farlo, crea un account di servizio con il ruolo roles/iam.serviceAccountUser che deve essere rappresentato dagli utenti autorizzati. La sostituzione dell'identità dell'account di servizio consente agli utenti di utilizzare gli account di servizio senza scaricare le chiavi degli account di servizio, migliorando 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 della piattaforma aziendale e aggiunge vincoli aggiuntivi. Per ulteriori informazioni sui vincoli utilizzati dal progetto della piattaforma di 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
Limitare i deployment delle risorse a località fisiche specifiche. Per ulteriori valori, consulta la sezione Valore gruppi di lavoro. gcp.resourceLocations
Uno dei seguenti:
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 Gestire OS Login 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 possono essere utilizzate dalle risorse 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. Utilizzi Cloud HSM per proteggere le tue chiavi. 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 della chiave 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 aiutano a eseguire le seguenti:

  • Monitora chi accede ai tuoi dati.

  • Assicurati di implementare un controllo adeguato.

  • Supporta la capacità dei team di gestione degli incidenti e delle operazioni di rispondere ai problemi che potrebbero verificarsi.

Access Transparency

Access Transparency ti invia una notifica in tempo reale nel caso in cui il personale dell'Assistenza Google debba accedere ai tuoi dati. I log di Access Transparency vengono generati ogni volta che una persona accede ai contenuti e solo il personale Google con motivazioni 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 sulle scritture dei dati e sulle informazioni lette dagli amministratori. Per ulteriori best practice di logging, vedi Controlli di rilevamento.

Avvisi e monitoraggio

Dopo aver eseguito il deployment del progetto base, puoi configurare avvisi per comunicare al tuo centro operativo di sicurezza (SOC) che un potrebbe verificarsi un incidente di sicurezza. Ad esempio, puoi utilizzare gli avvisi per comunicare all'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 non pubblicati da Security Command Center, puoi configurare gli avvisi con Cloud Monitoring.

Ulteriori considerazioni sulla sicurezza

I controlli di sicurezza in questo progetto sono stati rivisti sia dal Il team di Google Cybersecurity Action e un team per la sicurezza di terze parti. Per richiedere l'accesso ai sensi di un NDA sia a un modello di minacce STRIDE che al report di valutazione di riepilogo, invia un'email all'indirizzo secured-dw-blueprint-support@google.com.

Oltre ai controlli di sicurezza descritti in questa soluzione, devi esaminare e gestire la sicurezza e il rischio nelle aree chiave che si sovrappongono e interagiscono con il tuo utilizzo 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 utilizzata 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 di questa soluzione e che hanno accesso ai dati archiviati e gestiti in quell'infrastruttura.

Riepilogo

Per implementare l'architettura descritta in questo documento:

  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 del progetto e assicurati di soddisfare tutti i prerequisiti.

  3. Nell'ambiente di test, esegui il deployment della procedura dettagliata per vedere la soluzione in azione. Nell'ambito della procedura di test, tieni presente quanto segue:

    1. Usa Security Command Center per eseguire la scansione dei progetti appena creati in base requisiti di conformità.

    2. Aggiungi i tuoi dati di esempio nel data 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 a BigQuery nel modo previsto.

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

Passaggi successivi