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 a data engineer e amministratori della sicurezza che implementano e proteggono i data warehouse utilizzando 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, al design e ai controlli di sicurezza che utilizzi questo blueprint 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 Google Cloud servizi che puoi utilizzare per contribuire a proteggere un data warehouse in un ambiente di produzione.
Best practice per la governance dei dati durante la creazione, il deployment e il funzionamento di un data warehouse inGoogle Cloud, tra cui l'anonimizzazione dei dati, il trattamento differenziale dei dati riservati e i controlli di accesso a livello di colonna.
Questo documento presuppone che tu abbia già configurato un insieme di controlli di sicurezza di base come descritto nel Google Cloud blueprint delle basi aziendali. Ti aiuta ad applicare controlli aggiuntivi a quelli di sicurezza esistenti per proteggere i dati riservati in un data warehouse.
Casi d'uso dei data warehouse
Il blueprint supporta i seguenti casi d'uso:
Importa i dati da Google Cloud in un data warehouse BigQuery protetto (questo documento)
Importare i dati da un ambiente on-premise o da un altro cloud in un data warehouse BigQuery
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 la sicurezza, la riservatezza, l'integrità e la disponibilità dei dati aziendali durante l'archiviazione, il transito o l'analisi. In questo blueprint, esegui quanto segue:
- 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 delle responsabilità appropriata per diversi profili.
- 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 distinti. L'immagine seguente mostra come i dati importati vengono classificati, anonimizzati e archiviati. Inoltre, mostra come puoi reidentificare i dati riservati su richiesta per analizzarli.
L'architettura utilizza una combinazione dei seguenti Google Cloud servizi e funzionalità:
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 landing zone 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 con limitazioni.
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 degli accessi aggiuntivi e separare la governance dai dati effettivi nel data warehouse. La governance include la gestione delle chiavi, la gestione del catalogo di dati e il 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 cripta i dati archiviati 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 del controllo dell'accesso.
Pub/Sub: riceve e archivia i dati in streaming prima della anonimizzazione. Pub/Sub utilizza autenticazione, controlli di accesso e crittografia a livello di messaggio con una chiave 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 e una chiave di crittografia univoci per ogni pipeline, nonché controlli di accesso. 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 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 sul cloud.
Data Catalog classifica automaticamente i dati riservati con metadati, noti anche come tag delle norme, 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 contribuire a proteggere i contenuti, tra cui controlli di accesso, sicurezza a livello di colonna per i dati riservati e la crittografia dei dati.
Security Command Center monitora ed esamina i risultati di sicurezza di tutto il tuo Google Cloud ambiente in un'unica posizione.
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 consente di raggruppare in modo logico 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 nel blueprint nella cartella di produzione e del progetto di governance dei dati nella cartella comune utilizzata per la governance.
Cartelle
Utilizzi le cartelle per isolare l'ambiente di produzione e i servizi di governance dagli ambienti di test e non di produzione. La tabella seguente descrive le cartelle del blueprint Enterprise Foundation utilizzate da questo blueprint.
Cartella | Descrizione |
---|---|
Produzione | Contiene progetti con risorse cloud che sono state testate e sono pronte per l'uso. |
Nome | Contiene servizi centralizzati per l'organizzazione, ad esempio il progetto di governance. |
Puoi modificare i nomi di queste cartelle in modo che corrispondano alla struttura delle cartelle della tua organizzazione, ma ti consigliamo di mantenere una struttura simile. Per ulteriori informazioni, consulta il Google Cloud blueprint della piattaforma di base per le aziende.
Progetti
Isolerai parti del tuo ambiente utilizzando i progetti. La tabella seguente descrive i progetti necessari all'interno dell'organizzazione. Creerai questi progetti quando esegui il codice Terraform. Puoi modificare i nomi di questi progetti, ma ti consigliamo di mantenere una struttura simile.
Progetto | Descrizione |
---|---|
Importazione dati | Contiene i servizi necessari per ricevere i 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 identificare nuovamente i dati riservati. |
Oltre a questi progetti, l'ambiente deve includere anche un progetto che ospita un job 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 sezioni seguenti descrivono i consigli per i blueprint per i gruppi di utenti e le assegnazioni dei ruoli nei progetti che crei. 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 dei dati che richiedono l'accesso a dati riservati: |
Dati riservati |
|
Dati non riservati |
|
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 |
|
Dati non riservati |
|
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:
roles/logging.viewer
Gruppo di amministratori della sicurezza
Gli amministratori della sicurezza gestiscono i controlli di sicurezza come accesso, chiavi, regole del firewall, Controlli di servizio VPC e il 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 della sicurezza richiedono i seguenti ruoli a livello di organizzazione:
roles/cloudkms.viewer
roles/logging.viewer
roles/securitycenter.findingsEditor
Uno dei seguenti ruoli di Security Command Center:
roles/securitycenter.findingsBulkMuteEditor
roles/securitycenter.findingsMuteSetter
roles/securitycenter.findingsStateSetter
Informazioni sui controlli di sicurezza di cui hai bisogno
Questa sezione illustra i controlli di sicurezza di Google Cloud che utilizzi per proteggere il tuo data warehouse. I principi di sicurezza principali da considerare sono i seguenti:
Garantisci l'accesso adottando i principi del privilegio minimo.
Proteggi le connessioni di rete tramite criteri e progettazione della segmentazione.
Proteggi la configurazione di ciascun servizio.
Classifica e proteggi i dati in base al loro livello di rischio.
Comprendi 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'altra Google Cloud origine (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 streaming 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:
- Contribuisce 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.
- Ti assicura di utilizzare solo servizi che supportano i Controlli di servizio VPC.
Per ulteriori informazioni, consulta la pagina Configurare Accesso privato Google.
Devi configurare sottoreti separate per ogni job Dataflow. Le sottoreti separate assicurano che i dati anonimizzati siano adeguatamente distinta dai dati sottoposti a reidentificazione.
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 per il data warehouse riservato vengono posizionate in perimetri separati. Per consentire ai servizi in perimetri diversi di condividere dati, crei ponti di perimetro. I ponti perimetrici consentono ai servizi protetti di effettuare richieste di risorse al di fuori del loro perimetro. Questi ponti effettuano le seguenti connessioni:
Collega 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 ulteriori informazioni, consulta Accedere a una risorsa Google Cloud al di fuori del perimetro.
Policy 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 garantire che solo determinate origini possano accedere ai progetti, devi attivare un criterio di accesso per la tua organizzazione Google. 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 la chiave CMEK. Utilizzi 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 data warehouse BigQuery nel progetto di dati non riservati e l'altra per il data warehouse nel progetto di dati riservati. Per saperne di più, consulta Gestione delle chiavi.
Specifica la località CMEK, che determina la posizione geografica in cui la chiave viene archiviata e resa disponibile per l'accesso. Devi assicurarti che il CMEK si trovi nella stessa posizione delle risorse. Per impostazione predefinita, il CMEK viene ruotato 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 delle attività di gestione delle chiavi, inclusa rotazione della chiave.
Account di servizio e controlli di accesso
Gli account di servizio sono identità che Google Cloud puoi 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, crea 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 del controller Dataflow per la pipeline 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 Dataflow batch che crea la pipeline Dataflow.
La tabella seguente elenca i ruoli assegnati a ciascun account di servizio:
Account di servizio | Nome | Progetto | Ruoli |
---|---|---|---|
Dataflow controller Questo account viene utilizzato per la spersonalizzazione. |
sa-dataflow-controller |
Importazione dati | |
Dataflow controller Questo account viene utilizzato per la reidentificazione. |
sa-dataflow-controller-reid |
Dati riservati | |
Cloud Storage | sa-storage-writer |
Importazione dati |
|
Pub/Sub | sa-pubsub-writer |
Importazione dati |
|
Cloud Scheduler | sa-scheduler-controller |
Importazione dati |
|
Anonimizzazione dei dati
Utilizzi Sensitive Data Protection per anonimizzare i dati strutturati e non strutturati durante la fase di importazione. Per i dati strutturati, utilizza le trasformazioni dei record in base ai campi per anonimizzare i dati. Per un esempio di questo approccio, consulta la cartella /examples/de_identification_template/
. Questo esempio controlla i dati strutturati per verificare la presenza di numeri di carte di credito e PIN delle carte. Per i dati non strutturati, utilizzi i tipi di informazioni per anonimizzarli.
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 li 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
Configura i seguenti controlli di sicurezza per contribuire a proteggere i dati nel data warehouse BigQuery:
Controlli di accesso a livello di colonna
Account di servizio 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 contribuire a proteggere i dati riservati, utilizza i controlli di accesso per colonne specifiche nel data warehouse BigQuery. Per accedere ai dati in queste colonne, un analista dei dati deve disporre del ruolo Lettore granulare.
Per definire l'accesso alle colonne in BigQuery, crea 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 con tag di criteri2_Private
o1_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 hanno accesso anche alle colonne con il tag di criteri1_Sensitive
. Gli utenti non hanno accesso alle colonne contrassegnate con il tag di criteri3_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 hanno accesso alle colonne contrassegnate con i tag di criteri2_Private
o3_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 gli utenti autorizzati devono rubare. 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. L'impersonazione crea un token a breve termine che gli utenti autorizzati con il ruolo roles/iam.serviceAccountTokenCreator
possono scaricare.
Criteri dell'organizzazione
Questo progetto include i vincoli delle norme 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 delle norme dell'organizzazione.
La tabella seguente descrive i vincoli aggiuntivi dei criteri dell'organizzazione definiti nel modulo org_policies
:
Policy | Nome vincolo | Valore consigliato |
---|---|---|
Limitare i deployment delle risorse a località fisiche specifiche. Per altri valori, consulta Gruppi di valori. |
gcp.resourceLocations
|
Uno dei seguenti:in:us-locations in:eu-locations in:asia-locations
|
Disattivare la creazione di 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 inoltro in modo che siano solo interne, 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 che venga utilizzata dal blueprint. |
Disattiva il logging dell'output della porta seriale in Cloud Logging. | compute.disableSerialPortLogging |
true |
Gestione delle chiavi e crittografia per archiviazione e reidentificazione
Gestisci chiavi CMEK separate per i tuoi dati riservati in modo da poterli reidentificare. Utilizzi Cloud HSM per proteggere le tue chiavi. Per identificare nuovamente i dati, utilizza le seguenti chiavi:
Una chiave CMEK utilizzata dalla pipeline Dataflow per la procedura di identificazione.
La chiave di crittografia originale utilizzata da Sensitive Data Protection per anonimizzare i tuoi dati.
Una chiave CMEK per il data warehouse BigQuery nel progetto di 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 attivare il logging e le funzionalità del livello Premium di Security Command Center, come la valutazione dello stato della sicurezza e il rilevamento delle minacce. Questi controlli ti consentono di:
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, configura Google Cloud Observability con i log dei dati per i servizi che vuoi monitorare. Il modulo centralized-logging
configura le seguenti best practice:
Creazione di un sink dei log aggregato in tutti i progetti.
Archiviazione dei log nella regione appropriata.
Aggiunta di chiavi CMEK all'apposita destinazione di logging.
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 altre best practice di registrazione, consulta Controlli di rilevamento.
Avvisi e monitoraggio
Dopo aver implementato il blueprint, puoi configurare avvisi per notificare al tuo Security Operations Center (SOC) che 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 degli avvisi di Security Command Center, consulta Configurare le notifiche dei risultati. Per avvisi aggiuntivi non pubblicati da Security Command Center, puoi configurare gli avvisi con Cloud Monitoring.
Considerazioni sulla sicurezza aggiuntive
I controlli di sicurezza in questo blueprint sono stati esaminati sia dal Google Cybersecurity Action Team sia da un team di 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. tra cui:
Il codice che utilizzi per configurare, eseguire il deployment ed eseguire i job Dataflow.
La tassonomia di classificazione dei dati che utilizzi con questa soluzione.
I contenuti, la qualità e la sicurezza dei set di dati archiviati e analizzati nel data warehouse.
L'ambiente complessivo in cui esegui il deployment della soluzione, inclusi quanto segue:
- 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:
Determina se implementare il blueprint con il blueprint delle basi dell'azienda o da solo. Se scegli di non implementare il blueprint Enterprise Foundations, assicurati che nel tuo ambiente sia implementata una base di riferimento per la sicurezza simile.
Esamina il file Readme del progetto e assicurati di soddisfare tutti i prerequisiti.
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:
Utilizza Security Command Center per eseguire la scansione dei progetti appena creati in base ai tuoi requisiti di conformità.
Aggiungi i tuoi dati di esempio nel data warehouse BigQuery.
Collabora con un analista di dati della tua azienda per verificare il suo accesso ai dati confidenziali e se può interagire con i dati di BigQuery nel modo previsto.
Esegui il deployment del blueprint nell'ambiente di produzione.
Passaggi successivi
Esamina il Google Cloud progetto della piattaforma di fondazione dell'azienda per un ambiente sicuro di riferimento.
Per visualizzare i dettagli del blueprint, leggi il file readme della configurazione Terraform.
Per altre best practice e modelli, visita il Centro best practice per la sicurezza.