Come Applicare il Dynamic Masking in MariaDB

Con la crescita delle implementazioni di MariaDB, lo stesso database serve sempre più spesso contemporaneamente differenti utenti, inclusi servizi applicativi, sviluppatori, analisti, team di supporto e pipeline di automazione. Di conseguenza, le organizzazioni ottengono una maggiore efficienza operativa. Tuttavia, questo modello di accesso condiviso introduce anche un rischio persistente: l’esposizione di dati sensibili tramite i risultati delle query. La documentazione ufficiale di MariaDB descrive questa sfida nei modelli reali di accesso ai database.

Il dynamic data masking affronta questo problema trasformando i valori sensibili al momento dell’esecuzione della query anziché modificare i dati memorizzati o gli schemi del database. Invece di bloccare completamente l’accesso, si applica una visibilità controllata. Di conseguenza, gli utenti vedono solo i dati per cui sono autorizzati. Questo approccio integra pratiche più ampie come la sicurezza dei dati e la sicurezza del database, dove i team proteggono i dati durante l’accesso e non solo a riposo.

In questo articolo spieghiamo come i team possano implementare il dynamic masking in MariaDB usando tecniche native. Mostriamo inoltre come piattaforme centralizzate come DataSunrise estendano il masking in un livello di controllo basato su policy, verificabile e conforme. Pertanto, la discussione è strettamente correlata a concetti come il dynamic data masking e la visibilità unificata delle attività.

Che Cos’è il Dynamic Data Masking?

Il dynamic data masking è una tecnica di protezione a runtime che modifica i risultati delle query al volo in base a regole quali identità utente, ruolo, origine della connessione o contesto di accesso. A differenza della crittografia o del masking statico, questa tecnica non cambia il modo in cui il database immagazzina i dati. Piuttosto protegge i valori sensibili precisamente al momento dell’accesso, rendendolo un componente fondamentale delle strategie moderne di dynamic data masking.

Con il dynamic masking, la stessa query SQL può restituire risultati differenti a seconda di chi la esegue. Per esempio, gli utenti autorizzati ricevono i valori completi, mentre gli utenti con restrizioni vedono rappresentazioni mascherate degli stessi campi. Di conseguenza, i team abilitano un accesso sicuro ai dati senza duplicare i set di dati o modificare la logica applicativa.

Nella pratica, le organizzazioni usano comunemente il dynamic masking per proteggere:

• Informazioni personali identificabili (PII)
• Dati di contatto come email e numeri di telefono
• Dati finanziari, inclusi numeri di carta e saldi
• Identificatori interni e attributi operativi

Approcci Nativi al Masking in MariaDB

MariaDB non include controlli nativi di dynamic masking. Tuttavia, gli amministratori spesso tentano di approssimare il comportamento del masking usando costrutti SQL.

View con Colonne Trasformate

L’approccio più comune è esporre i dati sensibili tramite view che restituiscono valori trasformati invece di quelli reali.

Questo metodo si basa interamente sull’enforcement dell’accesso tramite la view. Se gli utenti possono interrogare la tabella di base direttamente, il masking viene aggirato.

Funzioni Memorizzate con Logica Condizionale

Un’altra tecnica è incapsulare la logica di masking all’interno di funzioni memorizzate che valutano attributi di sessione.

 /*CREATE FUNCTION mask_email(email VARCHAR(255))
RETURNS VARCHAR(255)
RETURN
  IF(USER() = 'admin@%', email, CONCAT(SUBSTRING(email,1,3),'***@***'));*/

Le funzioni consentono un masking condizionale ma devono essere usate esplicitamente in ogni query o definizione di view.

Copie Mascherate Separate dei Dati

Alcuni ambienti mantengono copie permanentemente mascherate di tabelle o schemi per accessi non di produzione.

Questo approccio duplica i dati e non fornisce protezione in tempo reale. Il masking è applicato una sola volta e rimane statico fino all’aggiornamento dei dati.

 /*-- Crea una copia mascherata della tabella originale
CREATE TABLE customers_masked AS
SELECT
    id,
    CONCAT(SUBSTRING(email, 1, 3), '***@***') AS email,
    '****-****-****' AS card_number,
    created_at
FROM customers;

-- Concedi accesso solo alla tabella mascherata
GRANT SELECT ON customers_masked TO analyst_user;*/

In questo modello, il masking viene eseguito durante la copia dei dati. Qualsiasi aggiornamento alla tabella originale richiede la rigenerazione manuale o programmata della copia mascherata, rendendo questo metodo inadatto ad ambienti che richiedono visibilità dati aggiornata o controllo di accesso adattivo.

Approcci al Masking in DataSunrise

DataSunrise applica il masking come controllo a livello di accesso piuttosto che come trasformazione lato database. Invece di incorporare la logica di masking in oggetti SQL, valuta le query in tempo reale e applica regole di masking in modo trasparente prima che i risultati siano restituiti al client. Questo disaccoppia la protezione dei dati dagli schemi del database e dalla logica applicativa.

Le decisioni di masking sono prese dinamicamente per ogni query utilizzando il contesto di esecuzione, garantendo una protezione coerente attraverso applicazioni, strumenti BI, sessioni amministrative e processi automatizzati. Sono disponibili diversi approcci di masking in base a esigenze di sicurezza, operative e di conformità.

Regole di Masking

Il masking in DataSunrise è applicato attraverso regole centralizzate che definiscono quando e come i dati sensibili sono mascherati. Queste regole operano indipendentemente dagli schemi del database e dalla logica applicativa e sono valutate in tempo reale per ogni query, considerando il contesto di esecuzione. Quando le condizioni della regola sono soddisfatte, il masking è applicato prima che i risultati siano restituiti al client. Questo approccio è allineato con pratiche più ampie di sicurezza dei dati e sicurezza del database, dove la protezione si applica al momento dell’accesso.

Possono coesistere molteplici regole di masking prioritarie. Questo abilita modelli di protezione stratificati, dove restrizioni di default si applicano in modo ampio mentre regole più specifiche alleggeriscono selettivamente il masking per utenti, ruoli o servizi fidati. Le regole di masking si integrano naturalmente con dynamic data masking centralizzato e con controlli di accesso basati su policy (access controls).

• Gestione centralizzata delle regole su tutti i database protetti
• Valutazione in tempo reale per ogni query senza riscrittura SQL
• Esecuzione delle regole basata su priorità per un controllo di accesso stratificato

Dynamic Masking a Livello di Colonna

Il masking a livello di colonna applica regole di trasformazione direttamente alle colonne selezionate quando le condizioni di accesso sono soddisfatte. Questo approccio è indicato per campi sensibili ben definiti ed è comunemente usato insieme a processi strutturati di data discovery.

I casi d’uso comuni includono masking parziale delle email, masking completo dei numeri di carta e oscuramento degli identificatori. Le regole possono essere definite a livello di singole tabelle, schemi o interi database, fornendo un controllo preciso e prevedibile sull’esposizione dei dati.

• Controllo preciso sulle singole colonne sensibili
• Comportamento coerente del masking attraverso query e strumenti
• Supporto per formati di masking multipli per colonna

Masking Consapevole di Ruolo e Contesto

Il masking consapevole di ruolo e contesto estende il masking a livello di colonna valutando il contesto di esecuzione invece di affidarsi solo a permessi statici. Questo modello integra il controllo accessi basato su ruolo (RBAC) aggiungendo controlli di visibilità a runtime.

Le condizioni possono includere utente o ruolo del database, indirizzo IP del client, nome dell’applicazione o origine dell’autenticazione. Di conseguenza, la stessa colonna può essere mascherata o meno per utenti diversi che eseguono identiche query.

• Visibilità adattiva dei dati basata su utente e contesto di connessione
• Nessuna necessità di duplicare ruoli o oggetti database
• Supporto per ambienti con accesso misto e schemi condivisi

Masking Basato su Policy per Tipo di Dato

Il masking basato su policy si concentra su categorie di dati sensibili piuttosto che su singole colonne. Una volta classificati i dati, le policy di masking sono applicate automaticamente a tutti i campi corrispondenti tra schemi e tabelle, riducendo lo sforzo manuale e supportando flussi di lavoro guidati dalla conformità quali la data compliance.

• Protezione automatica delle nuove colonne sensibili aggiunte
• Riduzione del carico operativo per schemi di grandi dimensioni
• Masking coerente allineato ai risultati di classificazione

Applicazione in Tempo Reale Senza Modifiche alle Query

Tutti gli approcci al masking operano senza modificare query SQL, view, stored procedure o logica applicativa. Le applicazioni continuano a emettere query standard mentre il masking è applicato in modo trasparente a runtime, integrandosi perfettamente con il monitoraggio unificato delle attività di database.

Essendo il masking applicato al di fuori del motore del database, le policy possono essere aggiornate senza ridistribuire applicazioni o alterare oggetti database.

• Nessuna modifica al codice applicativo o alla logica SQL
• Aggiornamenti immediati delle policy senza interruzione del servizio
• Enforcement uniforme su applicazioni, strumenti BI e accesso amministrativo

Principali Vantaggi del Masking con DataSunrise

Conclusione

Gli ambienti MariaDB spesso richiedono un accesso flessibile a dati condivisi proteggendo comunque i valori sensibili. Sebbene le tecniche basate su SQL possano simulare il comportamento del masking, esse dipendono da enforcement manuale e da una rigorosa disciplina operativa.

Al contrario, DataSunrise applica il masking a livello di accesso e garantisce la protezione in tempo reale. Di conseguenza, i team mettono in sicurezza i dati sensibili in MariaDB attraverso controlli basati su policy che restano trasparenti, verificabili e allineati a requisiti di sicurezza, conformità e usabilità.