Importa 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 riservate per poter analizzare i dati per vari scopi aziendali. Questo documento è destinato ai data engineer e agli amministratori della sicurezza che eseguono il deployment e la protezione dei data warehouse utilizzando BigQuery. Fa parte di un progetto di sicurezza composto dai seguenti elementi:

  • Un repository GitHub che contiene un set di configurazioni e script Terraform. La configurazione Terraform imposta un ambiente in Google Cloud che supporta un data warehouse che archivia i dati riservati.

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

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

Questo documento tratta i seguenti argomenti:

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

  • Best practice per la governance dei dati durante la creazione, il deployment e la gestione di un data warehouse in Google Cloud, tra cui l'anonimizzazione dei dati, la gestione differenziale dei dati riservati e i controlli dell'accesso a livello di colonna.

Questo documento presuppone che tu abbia già configurato un set di controlli di sicurezza di base come descritto nel progetto di base per gli elementi di base di Google Cloud. Consente di integrare ulteriori controlli sui controlli di sicurezza esistenti 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 alle aziende di analizzare i dati aziendali per ricavarne 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 la sicurezza, la riservatezza, l'integrità e la disponibilità dei dati aziendali mentre sono archiviati, mentre sono in transito o durante l'analisi. In questo progetto, esegui le seguenti operazioni:

  • Configura i controlli che contribuiscono a proteggere l'accesso ai dati riservati.
  • Configura i controlli che contribuiscono a proteggere la pipeline dei dati.
  • Configura una separazione appropriata dei compiti per i diversi utenti tipo.
  • Configura i modelli per trovare e anonimizzare i dati riservati.
  • Configura controlli di sicurezza e logging appropriati per proteggere i dati riservati.
  • Utilizza i tag di classificazione e criteri dei dati 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 e quindi archiviarli in perimetri separati. La seguente immagine mostra in che modo i dati importati vengono classificati, anonimizzati e archiviati. Mostra inoltre come reidentificare i dati riservati on demand per poterli analizzare.

Architettura del data warehouse riservato.

L'architettura utilizza una combinazione dei seguenti servizi e funzionalità di Google Cloud:

  • 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 configurando autorizzazioni, controlli di accesso e scambio di dati sicuro. I perimetri sono i seguenti:

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

    • Un perimetro di dati riservati che può reidentificare i dati riservati e archiviarli in un'area ad accesso limitato.

    • Un perimetro di governance che archivia le chiavi di crittografia e definisce i dati riservati.

    Questi perimetri sono progettati per proteggere i contenuti in entrata, isolare i dati riservati configurando controlli di accesso e monitoraggio aggiuntivi e separare la tua governance dai dati effettivi nel warehouse. La governance include gestione delle chiavi, gestione del catalogo dati e logging.

  • Cloud Storage e Pub/Sub ricevono i dati come segue:

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

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

  • Due pipeline Dataflow anonimizzano e reidentificano i dati riservati come segue:

    • La prima pipeline anonimizza i dati riservati utilizzando l'assegnazione di pseudonimi.
    • La seconda pipeline identifica nuovamente i dati riservati quando gli utenti autorizzati richiedono l'accesso.

    Per proteggere i dati, Dataflow utilizza un account di servizio e una chiave di crittografia univoci per ogni pipeline e controlli dell'accesso. Per proteggere l'esecuzione della pipeline spostandola nel servizio di backend, Dataflow utilizza Streaming Engine. Per ulteriori informazioni, consulta Sicurezza e autorizzazioni di Dataflow.

  • Sensitive Data Protection anonimizza i dati riservati durante 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 HSM (Hardware Security Module) basato su cloud.

  • Data Catalog classifica automaticamente i dati riservati con metadati, noti anche come tag di criteri, 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, 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 controlli dell'accesso, sicurezza a livello di colonna per i dati riservati e crittografia dei dati.

  • Security Command Center monitora ed esamina i risultati sulla sicurezza dell'intero ambiente Google Cloud da una posizione centralizzata.

Struttura organizzativa

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

Il seguente diagramma mostra una gerarchia di risorse con cartelle che rappresentano ambienti diversi, come bootstrap, comune, 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 seguente tabella descrive le cartelle del progetto di base aziendali utilizzate da questo progetto base.

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

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

Progetti

Puoi isolare parti del tuo ambiente utilizzando i progetti. La seguente tabella descrive i progetti necessari all'interno dell'organizzazione. Puoi creare questi progetti quando esegui il codice Terraform. Puoi cambiare i nomi dei progetti, ma ti consigliamo di mantenere una struttura simile.

Progetto Descrizione
Importazione dati Contiene i servizi necessari per ricevere dati e anonimizzare i dati riservati.
Governance Contiene servizi che offrono funzionalità di gestione delle chiavi, logging e 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 i dati riservati.

Oltre a questi progetti, il tuo ambiente deve includere anche un progetto che ospita un job Modello flessibile di Dataflow. Il job del modello flessibile è obbligatorio per la pipeline dei dati in modalità flusso.

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 per i progetti per i gruppi di utenti e le assegnazioni dei ruoli nei progetti che crei. 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 warehouse. Questo gruppo richiede ruoli in diversi progetti, come descritto nella tabella seguente.

Mappatura 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 di dati e il warehouse. Questo gruppo richiede ruoli in diversi progetti, come descritto nella tabella seguente.

Mappatura 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 team di networking.

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

Gruppo di amministratori della sicurezza

Gli amministratori della sicurezza amministrano i controlli di sicurezza quali 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 della protezione dei dati sensibili.

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

Comprendere i controlli di sicurezza necessari

Questa sezione illustra i controlli di sicurezza all'interno di Google Cloud che utilizzi per proteggere il data warehouse. I principi fondamentali per la sicurezza da prendere in considerazione sono i seguenti:

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

  • Proteggere le connessioni di rete attraverso la progettazione e i criteri di segmentazione.

  • Proteggi la configurazione per ciascuno dei servizi.

  • 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.

  • Configura monitoraggio e 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'altra origine Google Cloud (ad esempio un data lake). Puoi utilizzare una delle seguenti opzioni per trasferire i tuoi dati nel data warehouse su BigQuery:

  • Un job batch che utilizza Cloud Storage.

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

Regole di rete e firewall

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

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

Per ulteriori informazioni, consulta Configurazione dell'accesso privato Google.

Devi configurare subnet separate per ogni job Dataflow. La presenza di subnet separate assicura che i dati anonimizzati vengano separati correttamente dai dati che vengono reidentificati.

La pipeline di dati richiede l'apertura di porte TCP nel firewall, come definito nel file dataflow_firewall.tf nel repository del modulo dwh-networking. Per ulteriori informazioni, consulta 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 in modo da rifiutare tutti.

Controlli del perimetro

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

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

  • Collegano il progetto di dati non riservati e il progetto di dati riservati in modo che i dati riservati possano essere reidentificati quando un analista di dati li richiede.

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

Oltre ai bridge perimetrali, utilizzi le regole di uscita per consentire alle risorse protette dai perimetri di servizio di accedere a risorse che si trovano al di fuori del perimetro. In questa soluzione, configurerai le regole in uscita per ottenere i job esterni del modello flessibile di Dataflow che si trovano in Cloud Storage in un progetto esterno. Per maggiori informazioni, vedi Accedere a una risorsa Google Cloud all'esterno del perimetro.

Criterio di accesso

Per garantire che solo identità specifiche (utente o servizio) possano accedere alle risorse e ai dati, devi abilitare i gruppi e i ruoli IAM.

Per garantire che solo origini specifiche possano accedere ai progetti, abilita un criterio di accesso per la tua organizzazione Google. Ti consigliamo di creare un criterio di accesso che specifichi l'intervallo di indirizzi IP consentito per le richieste e consenta solo le richieste provenienti da utenti o account di servizio specifici. Per ulteriori informazioni, consulta la sezione Attributi dei livelli di accesso.

Gestione delle chiavi e crittografia per l'importazione

Entrambe le opzioni di importazione utilizzano Cloud HSM per gestire la CMEK. Utilizza 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 hai configurato.

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 di estrazione, trasformazione e caricamento (ETL).

  • La chiave di crittografia è stata 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 di dati non riservati e l'altra per il warehouse nel progetto di dati riservati. Per ulteriori informazioni, consulta Gestione delle chiavi.

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

Se gli obblighi di conformità della tua organizzazione richiedono la gestione delle chiavi esternamente da Google Cloud, puoi abilitare Cloud External Key Manager. Se utilizzi chiavi esterne, sei responsabile delle 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 le 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, puoi creare 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 la pipeline Dataflow che anonimizza i dati riservati.

  • Un account di servizio controller Dataflow per la pipeline Dataflow che identifica nuovamente 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 inserimento di flussi.

  • 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, consulta Ruoli IAM per 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

Utilizza Sensitive Data Protection per anonimizzare i dati strutturati e non strutturati durante la fase di importazione. Per i dati strutturati, per anonimizzare i dati utilizzi le trasformazioni dei record in base ai campi. Per un esempio di questo approccio, consulta la cartella /examples/de_identification_template/. Questo esempio verifica nei dati strutturati la presenza di numeri di carte di credito e PIN. Per i dati non strutturati, utilizzi tipi di informazioni per anonimizzare i dati.

Per anonimizzare i dati etichettati come riservati, utilizza la protezione dei dati sensibili e una pipeline Dataflow per tokenizzarli. Questa pipeline acquisisce i dati da Cloud Storage, li elabora e quindi li invia al data warehouse BigQuery.

Per ulteriori informazioni sul processo di anonimizzazione dei dati, consulta la pagina relativa alla governance dei dati.

Controlli di sicurezza per l'archiviazione dei dati

Puoi configurare i seguenti controlli di sicurezza per contribuire a proteggere i dati nel warehouse BigQuery:

  • Controlli dell'accesso a livello di colonna

  • Account di servizio con ruoli limitati

  • Criteri dell'organizzazione

  • Perimetri di Controlli di servizio VPC tra il progetto riservato e il progetto non riservato, con bridge di perimetro appropriati

  • Crittografia e gestione delle chiavi

Controlli dell'accesso a livello di colonna

Per proteggere i dati riservati, utilizza i controlli dell'accesso per colonne specifiche nel warehouse di BigQuery. Per accedere ai dati in queste colonne, un analista di dati deve disporre del ruolo Lettore granulare.

Per definire l'accesso per le colonne in BigQuery, devi creare tag di criteri. Ad esempio, il file taxonomy.tf nel modulo bigquery-confidential-data example crea i seguenti tag:

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

  • Un tag di criteri 2_Private per le colonne che includono informazioni sensibili che consentono l'identificazione personale (PII), ad esempio il nome di una persona. Gli utenti che hanno accesso a questo tag possono accedere 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, ad esempio il massimale di credito. Gli utenti che hanno accesso a questo tag non possono accedere alle colonne codificate con i tag di criteri 2_Private o 3_Confidential.

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

Questi controlli dell'accesso assicurano 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. Il impersonificazione degli account di servizio consente agli utenti di utilizzare gli account di servizio senza scaricare le chiavi degli account di servizio, migliorando la sicurezza generale del progetto. Il furto d'identità crea un token a breve termine che gli utenti autorizzati con ruolo roles/iam.serviceAccountTokenCreator possono scaricare.

Criteri dell'organizzazione

Questo progetto include i vincoli dei criteri dell'organizzazione utilizzati dal progetto di base della piattaforma aziendale e aggiunge ulteriori vincoli. Per saperne di più sui vincoli utilizzati dal progetto di base delle fondazioni aziendali, consulta l'articolo Vincoli dei criteri dell'organizzazione.

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

Norme Nome vincolo Valore consigliato
Limita i deployment delle risorse a località fisiche specifiche. Per valori aggiuntivi, consulta Gruppi di valori. gcp.resourceLocations
Uno dei seguenti valori:
in:us-locations
in:eu-locations
in:asia-locations
Disabilita la creazione dell'account di servizio 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 in modo che siano solo per uso interno, in base all'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 vuoi utilizzare per il 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 identificare nuovamente i dati. Puoi utilizzare Cloud HSM per proteggere le tue chiavi. Per reidentificare i tuoi dati, utilizza le seguenti chiavi:

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

  • La chiave di crittografia originale che Sensitive Data Protection utilizza per anonimizzare i tuoi dati.

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

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

Controlli operativi

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

  • Monitora chi accede ai tuoi dati.

  • Assicurati che vengano eseguiti controlli corretti.

  • Supporta la capacità dei tuoi team operativi e di gestione degli incidenti di rispondere a eventuali problemi.

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 ai contenuti e solo il personale Google con giustificazioni aziendali valide (ad esempio una richiesta di assistenza) può ottenere l'accesso. Ti consigliamo di attivare Access Transparency.

Logging

Per soddisfare i requisiti di controllo e ottenere insight sui tuoi progetti, devi configurare l'osservabilità di Google Cloud con i 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 operazioni di lettura e scrittura dei dati, nonché informazioni su ciò che gli amministratori leggono. Per ulteriori best practice relative al logging, consulta Controlli del rilevamento.

Avvisi e monitoraggio

Dopo aver eseguito il deployment del progetto base, puoi configurare avvisi per notificare al centro operativo di sicurezza (SOC) che potrebbe essersi verificato un incidente di sicurezza. Ad esempio, puoi utilizzare gli avvisi per comunicare all'analista della sicurezza quando un'autorizzazione IAM è cambiata. Per saperne di più sulla configurazione degli avvisi di Security Command Center, consulta Configurare le notifiche sui risultati. Per avvisi aggiuntivi che non vengono pubblicati da Security Command Center, puoi configurare degli avvisi con Cloud Monitoring.

Ulteriori considerazioni sulla sicurezza

I controlli di sicurezza in questo progetto sono stati esaminati dal team di Google Cybersecurity Action e da un team di sicurezza di terze parti. Per richiedere l'accesso ai sensi dell'NDA a un modello di minaccia STRIDE e 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 i rischi nelle aree chiave che si sovrappongono e che interagiscono con il tuo utilizzo di questa soluzione. Sono incluse le seguenti app:

  • Il codice che utilizzi per configurare, sottoporre a deployment ed eseguire job Dataflow.

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

  • Contenuti, qualità e sicurezza dei set di dati che archivi e analizzi nel data warehouse.

  • L'ambiente generale in cui esegui il deployment della soluzione, tra cui:

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

Riepilogo

Per implementare l'architettura descritta in questo documento:

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

  2. Esamina il Leggimi del progetto base 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. Utilizza Security Command Center per analizzare i progetti appena creati in base ai tuoi requisiti di conformità.

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

    3. Collabora con un analista di dati nella tua azienda per verificare il suo accesso ai dati riservati e se può interagire con i dati di BigQuery nel modo previsto.

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

Passaggi successivi