DataSunrise Consegue la Certificazione AWS DevOps Competency per AWS DevSecOps e Monitoraggio, Logging e Performance

Mascheratura dei Dati in Vertica

La mascheratura dei dati in Vertica consiste nel permettere agli analisti di lavorare con vere strutture di dati nascondendo i valori che non dovrebbero mai essere esposti in chiaro. Vertica è un database analitico ad alte prestazioni utilizzato frequentemente per dashboard BI, analisi cliente, feature store ML ed esplorazioni ad-hoc su grandi dataset colonnari. Questa flessibilità è preziosa per il business, ma significa anche che campi regolamentati come numeri di carta, codici fiscali e attributi medici possono facilmente fuoriuscire in query, esportazioni o dataset di training se non viene applicato uno strato di protezione.

Cercare di risolvere questo problema affidandosi esclusivamente a permessi manuali, tabelle copiate o viste SQL scritte a mano diventa rapidamente frustrante. Gli schemi cambiano, appaiono nuove proiezioni, i processi ETL creano tabelle derivate e improvvisamente nessuno è più sicuro di quali colonne siano effettivamente sicure da esporre. Invece di inseguire ogni query, i team necessitano di uno strato di mascheratura che funzioni automaticamente per ogni carico di lavoro Vertica.

La mascheratura dei dati con DataSunrise fornisce agli utenti Vertica questo strato. DataSunrise si posiziona tra Vertica e gli strumenti client, rileva i campi sensibili e riscrive i risultati delle query al volo in modo che i valori riservati siano nascosti, tokenizzati o parzialmente rivelati secondo la policy. Vertica continua a fare ciò che sa fare meglio—analisi rapide—mentre la logica di mascheratura, i registri di controllo e le regole di conformità risiedono in un piano di controllo separato e dedicato.

Perché Vertica ha Bisogno di uno Strato di Mascheratura Dedicato

L’architettura di Vertica lo rende potente ma allo stesso tempo complicato. I dati sono memorizzati in contenitori ROS colonnari, le modifiche recenti vivono nel WOS e le proiezioni offrono molteplici layout fisici per la stessa tabella logica, come descritto nella documentazione sull’architettura di Vertica. Questo design è ideale per le prestazioni, ma complica domande come “Dove si trovano esattamente i numeri delle carte clienti?” o “Quali carichi di lavoro toccano oggi informazioni sanitarie protette (PHI)?”.

I punti critici comuni includono:

  • Ampie tabelle analitiche che raggruppano dozzine di attributi (inclusi PII e PHI) in un’unica struttura.
  • Molteplici proiezioni che replicano fisicamente colonne sensibili attraverso il cluster.
  • Cluster condivisi usati simultaneamente da BI, ETL, notebook e framework ML.
  • SQL ad-hoc da power user e data scientist, che bypassano i layer di reporting curati.
  • Log sparsi che rendono difficile ricostruire chi ha visto cosa, e quando.

Il controllo degli accessi basato su ruoli (RBAC) di Vertica gestisce chi può connettersi e quali oggetti può interrogare. Tuttavia, non comprende se una data query stia esportando numeri di carta, unendo dati HR e CRM in modi non sicuri oppure popolando un ambiente non di produzione con dettagli reali dei clienti. Per colmare queste lacune, le organizzazioni implementano un motore esterno di mascheratura e policy che comprende la sensibilità delle colonne e il contesto utente.

Come DataSunrise Fornisce la Mascheratura dei Dati in Vertica

DataSunrise agisce come proxy trasparente davanti a Vertica. Strumenti BI, client SQL, scheduler e piattaforme di data science si connettono a DataSunrise invece di parlare direttamente con Vertica. Per ogni query, DataSunrise analizza l’SQL, verifica quali colonne sono sensibili, valuta le policy di mascheratura e quindi passa la query senza modifiche oppure riscrive il set di risultati in modo che i valori riservati non lascino mai il database in forma leggibile.

Dietro le quinte, questo motore di mascheratura combina diverse capacità:

Gli screenshot qui sotto guidano attraverso una configurazione tipica di mascheratura in Vertica: definire una regola di mascheratura, scegliere quali colonne proteggere e verificare che le query siano mascherate e registrate correttamente.

Definire una Regola di Mascheratura in Vertica

Il primo passo è creare una regola di mascheratura e associarla all’istanza Vertica appropriata. Nell’esempio sotto, la regola chiamata Vertica_Masking punta a un database Vertica raggiungibile sulla porta 5433. La regola specifica anche cosa dovrebbe succedere quando si attiva la mascheratura: in questo caso, ogni evento di mascheratura viene scritto sia nell’archivio di audit di DataSunrise che nel syslog esterno, semplificando l’integrazione con piattaforme SIEM.

Cruscotto DataSunrise che mostra opzioni di menu per funzionalità di conformità dati, audit e mascheratura in Vertica.
Impostazioni generali per una regola di mascheratura dinamica Vertica con logging di audit abilitato.

A questo punto si definisce il comportamento ad alto livello:

  • A quali istanze Vertica si applica la regola.
  • Se gli eventi di mascheratura devono essere auditati, ignorati o inoltrati a sistemi esterni.
  • Eventuali filtri globali, come limitare la regola agli ambienti di produzione.

Questa separazione permette di mantenere una singola policy logica “Vertica_Masking” anche se in seguito si aggiungono ulteriori nodi o cluster. La logica di mascheratura risiede in DataSunrise, non negli schemi Vertica.

Selezionare Colonne e Condizioni per la Mascheratura

Una volta creata la regola, si sceglie quali colonne Vertica mascherare e in quali condizioni. DataSunrise può importare direttamente le liste di colonne dai risultati della scoperta, così gli amministratori non devono mantenerle manualmente.

Configurazione regole di mascheratura dinamica per Vertica che mostra colonne sensibili selezionate.
Impostazioni di mascheratura per colonne sensibili Vertica.

Le funzioni di mascheratura possono essere personalizzate per ogni colonna. I numeri di carta potrebbero mostrare solo le ultime quattro cifre, i numeri di telefono potrebbero perdere il prefisso internazionale, e i nomi possono essere completamente sostituiti oppure ridotti alle iniziali. Il comportamento esatto dipende dalle policy di sicurezza interne e dai profili di mascheratura definiti in DataSunrise.

Una query tipica emessa da un client SQL o notebook potrebbe apparire così:

SELECT
    id,
    full_name,
    SUBSTR(email, 1, 5) AS email_prefix,
    credit_card,
    phone
FROM customers_sensitive;

Sen­za mascheratura, questa query restituirebbe nomi reali dei clienti, numeri di carta e dettagli telefonici. Con la regola abilitata, gli utenti non privilegiati vedono valori pseudonimizzati mentre il resto del set di risultati rimane intatto.

Client SQL che mostra risultati di query Vertica mascherati.
Vista client SQL di dati Vertica mascherati.

Audit delle Query Mascherate in Vertica

La sola mascheratura non è sufficiente per la conformità normativa. Le organizzazioni devono anche dimostrare che la mascheratura è stata applicata in modo coerente. DataSunrise registra ogni query che ha attivato la mascheratura, con informazioni su utente, applicazione, nome della regola e tempo di esecuzione. Questi record supportano audit secondo regolamenti come GDPR, HIPAA e SOX.

Dalla console di audit è possibile:

  • Filtrare per regola Vertica, utente o applicazione per investigare incidenti.
  • Esportare i log verso piattaforme SIEM o GRC.
  • Correlare eventi di mascheratura con alert da Database Activity Monitoring.

Poiché tutte le query passano dallo stesso gateway, i team di conformità ottengono un unico registro di audit normalizzato invece di dover collegare tabelle di sistema multiple di Vertica.

Scenari Comuni di Mascheratura in Vertica

La mascheratura dei dati in Vertica si applica a molteplici scenari operativi e analitici. La tabella sottostante riassume i casi d’uso comuni e come le organizzazioni tipicamente applicano i controlli di mascheratura DataSunrise.

Scenario Rischio Approccio di Mascheratura
Dashboard BI e analisi ad-hoc Esposizione di PII in report ed esportazioni Mascheratura dinamica basata su ruoli utente e account servizi BI
Data science e notebook Uso di dati reali dei clienti durante l’esplorazione Mascheratura parziale o totale per ambienti non di produzione e ruoli analisti
ETL e pipeline dati Propagazione di dati sensibili nei sistemi a valle Mascheratura applicata in fase di query prima che i dati lascino Vertica
Feature store ML e training modelli Perdita di identificatori nei dataset di addestramento Pseudonimizzazione e tokenizzazione tramite regole di mascheratura dinamica
Audit normativi e investigazioni Incapacità di dimostrare l’applicazione delle protezioni dati Risultati di query mascherati combinati con registri di audit centralizzati

Conclusione

Se fatta correttamente, la mascheratura dei dati in Vertica permette alle organizzazioni di continuare a usare la piattaforma come motore analitico ad alta velocità riducendo drasticamente il rischio di esposizione di informazioni sensibili. Esternalizzando la logica di mascheratura, la scoperta e l’audit a DataSunrise, i team sostituiscono soluzioni manuali fragili con una protezione coerente e automatizzata.

Sia che si supporti il self-service BI, si alimentino carichi di lavoro ML o ci si prepari per audit normativi, un gateway dedicato alla mascheratura fornisce a Vertica le protezioni necessarie—senza rallentare l’accesso ai dati.

Proteggi i tuoi dati con DataSunrise

Metti in sicurezza i tuoi dati su ogni livello con DataSunrise. Rileva le minacce in tempo reale con il Monitoraggio delle Attività, il Mascheramento dei Dati e il Firewall per Database. Applica la conformità dei dati, individua le informazioni sensibili e proteggi i carichi di lavoro attraverso oltre 50 integrazioni supportate per fonti dati cloud, on-premises e sistemi AI.

Inizia a proteggere oggi i tuoi dati critici

Richiedi una demo Scarica ora

Ha bisogno del nostro team di supporto?

I nostri esperti saranno lieti di rispondere alle Sue domande.

Informazioni generali:
[email protected]
Servizio clienti e supporto tecnico:
support.datasunrise.com
Richieste di collaborazione e alleanza:
[email protected]