![](data:image/svg+xml, %3Csvg xmlns='http://www.w3.org/2000/svg' height='64' class='font-weight-bold' style='font: 600 30.11764705882353px "SegoeUI", Arial' width='64'%3E%3Ccircle fill='hsl(51.2, 78%, 14%)' cx='32' cy='32' r='32' /%3E%3Ctext x='50%25' y='55%25' dominant-baseline='middle' text-anchor='middle' fill='%23FFF' %3EYL%3C/text%3E%3C/svg%3E)
Ciao Yumee,
il problema nasce dal fatto che lo script di mascheramento si basa su uno schema ormai obsoleto: la colonna degli indirizzi email nella tabella sorgente è stata modificata (tipicamente rinominata, spostata o normalizzata in un’altra struttura). Di conseguenza, la logica di sostituzione non intercetta più i dati corretti e lascia passare valori reali in ambiente di sviluppo.
La prima azione è aggiornare lo script di mascheramento per puntare alle nuove colonne. Se ad esempio prima la tabella era dbo.Customer con campo EmailAddress, e ora lo schema prevede dbo.CustomerContact con campo Email, lo script deve essere rivisto per eseguire l’UPDATE o la funzione di mascheramento su CustomerContact.Email. È importante verificare anche eventuali vincoli di foreign key o join che lo script utilizza, perché una modifica di schema può rompere la catena di referenze.
Per garantire la conformità, ti consiglio di introdurre una fase di validazione obbligatoria subito dopo il refresh. Questo può essere implementato con query di controllo che verificano l’assenza di pattern tipici di email reali (ad esempio domini aziendali o pubblici come @gmail.com, @yahoo.com). Una pratica comune è inserire un job di post-processing che esegue un SELECT COUNT(*) su valori non mascherati e blocca la pipeline se il risultato è maggiore di zero. In ambienti SQL Server puoi integrare questa logica in un pacchetto SSIS o in uno script PowerShell che esegue il refresh e poi lancia la validazione.
Se vuoi un approccio più robusto, puoi usare funzioni di Data Masking native (Dynamic Data Masking in SQL Server) oppure librerie di data obfuscation esterne, ma la chiave rimane mantenere gli script allineati allo schema corrente e non lasciare che il refresh venga completato senza la validazione.
In sintesi: aggiorna gli script per riflettere il nuovo schema, aggiungi query di validazione obbligatorie che fermino l’esecuzione se vengono rilevati dati non mascherati, e integra questi controlli direttamente nella pipeline di refresh. In questo modo garantisci che nessun dato reale arrivi in ambiente dev.
Spero tu abbia trovato indicazioni utili. Se ti aiuta a chiarire meglio il problema, è gradito accettare la risposta. Per ulteriori dubbi lascia pure un messaggio. Buona giornata!HP.