Proteggere, conservare e dimostrare

🌐 Disponibile anche in 28 lingue

English · Español · 日本語 · Português (Brasil) · Français · Deutsch · 한국어 · 简体中文 · Português (Portugal) · 繁體中文 · Bahasa Indonesia · Türkçe · Polski · Tiếng Việt · ไทย · Nederlands · العربية · עברית · Українська · हिन्दी · Русский · Svenska · Dansk · Norsk bokmål · Suomi · Español (México) · Français (Canada) · Deutsch (Schweiz)

Immagine generata con l'IA

Tradotto con l'IA. Non ancora rivisto dalla comunità. Leggi in inglese

Modulo 6 di 6 del capitolo Qualità e governance dei dati, capitolo 5 del corso Data Architect. Ogni modulo si regge da solo. Precedente: Il consenso e il diritto all’oblio · Successivo: il prossimo capitolo, Dati master e identità

La domanda a cui risponde questo modulo: Come proteggi i dati, li conservi per il tempo richiesto, e lo dimostri?

Abbiamo stabilito responsabili e politiche, tenuto fuori i dati cattivi, scritto il dizionario, tracciato la lineage, classificato ciò che conta, imparato le leggi e modellato il consenso. Ora dobbiamo farlo funzionare. I dati arrivano, vengono usati, copiati e modificati, invecchiano, e alla fine una parte deve sparire. E un giorno qualcuno chiederà: dimostrate cosa è successo.

La governance segue i dati

Non penso alla governance come a una sola funzionalità. Penso a cosa succede ai dati dal momento in cui entrano finché non abbiamo finito con loro:

Acquisizione → Classificazione → Protezione → Uso → Conservazione → Cancellazione → Audit

Non sette processi tecnici: sette domande a cui l’architettura deve rispondere. Acquisizione e classificazione le abbiamo trattate: tenere fuori gli errori costosi (modulo 2), e sapere quali dati sono sensibili (modulo 3). La classificazione decide cosa succede in ogni fase successiva, quindi questo modulo riparte da lì.

Click to enlarge

Sette domande lungo la vita dei dati. Gli strumenti sostengono la politica; non la definiscono.

Proteggere: adatta il controllo ai dati

Chi può vederli, modificarli, riceverli? Dovrebbero essere crittografati, mascherati fuori dalla produzione, esportabili, raggiungibili da un agente? È qui che la sicurezza di Salesforce diventa parte della governance dei dati: condivisione, autorizzazioni su oggetti e campi, crittografia, mascheramento, accesso delle integrazioni. Sono argomenti che riempiono interi corsi, quindi non li rispiego. Il punto di governance: la protezione segue la classificazione e la politica. Non ogni campo ha bisogno della stessa protezione, non ogni utente dello stesso accesso, non ogni sistema a valle di ogni campo.

La crittografia è un controllo, non la conformità

Per i dati regolamentati, la crittografia a riposo può essere obbligatoria, e la mia posizione è che Shield è la risposta per i requisiti normativi chiave come questo. Shield Platform Encryption crittografa campi e file a riposo. Ma “l’abbiamo crittografato, quindi siamo conformi” è sbagliato due volte. La crittografia è un controllo tra tanti: accesso, conservazione, audit, consenso, monitoraggio, minimizzazione e cancellazione. E ha trade-off funzionali per cui si progetta fin dall’inizio. Con lo schema probabilistico predefinito, un campo crittografato non si può usare nelle clausole SOQL WHERE, GROUP BY o ORDER BY né nei filtri di gestione dei dati; la crittografia deterministica rinuncia a un po’ di robustezza perché tu possa filtrare sul campo. I campi crittografati non possono guidare regole di condivisione basate sui criteri, e non puoi ordinare le viste elenco in base a essi (General Shield Platform Encryption Considerations (opens in a new tab); Filter Encrypted Data with Deterministic Encryption (opens in a new tab)). Quindi la crittografia non è una casella da spuntare alla fine. È una decisione di architettura. Il capitolo sulla sicurezza dei dati va più a fondo.

Non copiare il rischio della produzione nella sandbox

La produzione è blindata. Poi qualcuno aggiorna una sandbox completa, e sviluppatori, tester, consulenti esterni e integrazioni di test ora hanno copie di dati personali reali di cui non hanno mai avuto bisogno. L’ambiente è cambiato; la sensibilità dei dati no. Gli strumenti di mascheramento di Salesforce esistono proprio per questo. Nota un cambiamento: il pacchetto gestito Data Mask arriva a fine servizio il 31 dicembre 2026, e il suo successore è Data Mask & Seed (Data Mask (Legacy) (opens in a new tab)). Ma lo strumento sostiene la politica, e la domanda viene prima: questo ambiente ha davvero bisogno di dati sensibili reali? Se dati realistici e non sensibili bastano per i test, è la risposta migliore.

Usare: il permesso non riguarda solo le persone

Utenti, integrazioni, analisi, partner, automazioni e agenti usano tutti i dati. Consenso (modulo 5), responsabilità (modulo 1) e classificazione (modulo 3) si incontrano qui, in fase di esecuzione. Questo utente dovrebbe vedere il numero di telefono del Destinatario? Questa integrazione dovrebbe riceverlo, o Snowflake, o questo agente come grounding? La risposta non può essere “beh, tecnicamente può”. È la differenza tra capacità e governance: l’architettura decide se dovrebbe.

Conservare: tenere tutto per sempre non è neutro

Molte organizzazioni hanno una politica di conservazione accidentale: per sempre. Nessuno l’ha decisa; lo spazio c’era, quindi i dati sono rimasti. Ma conservare i dati costa spazio e prestazioni, amplia l’esposizione sul fronte della privacy e della sicurezza, aggiunge obblighi di esibizione in caso di contenzioso, e ti dà più posti in cui cercare quando qualcuno chiede di essere dimenticato. Per ogni categoria importante: perché conservarla, per quanto, cosa fa partire il conteggio, c’è un minimo legale o un massimo per la privacy, e cosa succede alla fine: archiviare, cancellare, de-identificare?

E archiviare non equivale a risolvere la conservazione. “L’abbiamo archiviato.” Il requisito di conservazione è sparito? Quello di privacy? La sicurezza? Hai cambiato dove risiedono i dati, non cosa sono. Un archivio ha bisogno di controlli di accesso, regole di conservazione e cancellazione, individuazione e audit. Sposta dati personali in un archivio che tutti dimenticano, e la governance è appena peggiorata.

Cancellare: il ciclo di vita ha bisogno di un’uscita

La cancellazione non serve solo per le richieste di privacy individuali. I dati arrivano alla fine del periodo di conservazione; record temporanei sopravvivono al loro uso; gli archivi scadono; un processo de-identifica dopo un tempo stabilito. Qualunque cosa dica la politica, l’architettura ha bisogno di un’uscita, non di acquisire → memorizzare → memorizzare di più → memorizzare per sempre. E come ha mostrato il modulo 5, eliminare il record Salesforce non basta quando le copie vivono altrove.

Anche lo storico è un dato

A volte il valore attuale non basta. La ragione sociale di un partner, la classificazione di un cliente, uno stato di consenso, un attributo finanziario: il business o un’autorità di controllo possono aver bisogno di sapere com’era prima, quando è cambiato e chi l’ha cambiato. Quello storico è un dato, e ha bisogno di una sua decisione di conservazione.

Il tracciamento della cronologia dei campi standard segue fino a 20 campi per oggetto e conserva le modifiche fino a 18 mesi, e fino a 24 mesi solo tramite l’API, con Data Loader o queryAll() (Field History Tracking Overview (opens in a new tab)). E per i campi di testo lungo registra solo che il campo è stato modificato, non cosa diceva: una lacuna, se quella è la tua prova. Field Audit Trail, parte di Shield o acquistabile da solo, segue fino a 200 campi per oggetto e conserva lo storico finché non lo elimini, in un archivio a cui accedi tramite l’API (Field Audit Trail (opens in a new tab)). La mia posizione: la cronologia standard dei campi è l’impostazione predefinita; usa Field Audit Trail quando una normativa o un obbligo di conformità richiede uno storico più lungo e dimostrabile. Non perché “audit suona bene”.

Audit e monitoraggio non sono la stessa cosa

La cronologia dei campi risponde a domande sulle modifiche a campi selezionati. Le domande più ampie (chi ha effettuato l’accesso, chi ha esportato dati, quali API sono state chiamate, chi ha visto cosa) sono monitoraggio, e quello è Event Monitoring. Nella mia esperienza serve tipicamente con i clienti più regolamentati, ed ecco la mia posizione più forte in questo capitolo: configuralo prima che ti serva, e convoglia gli eventi in un repository, come Splunk o un altro SIEM, in anticipo.

Ecco perché. I file di log degli eventi vengono conservati per 1 giorno senza il componente aggiuntivo, e solo per alcuni tipi di evento; 30 giorni per impostazione predefinita con Shield o il componente aggiuntivo Event Monitoring, e fino a 365 giorni se estendi la conservazione (Event Monitoring FAQ (opens in a new tab)). Tutto ciò che è più vecchio è perso, a meno che tu non l’abbia esportato. E i log a pagamento non si possono recuperare per nessun periodo precedente all’inizio del contratto (stessa FAQ): acquistare il componente aggiuntivo dopo l’incidente non riporta indietro il passato. Quindi una delle conversazioni peggiori che un architetto possa avere è questa: “Possiamo vedere cosa è successo sei mesi fa?” “No.” “Perché no?” “Non lo stavamo raccogliendo.” Non vuoi incontrare un problema e scoprire solo allora che non stavi raccogliendo e conservando quegli eventi. A quel punto la risposta è semplicemente sparita.

Click to enlarge

Configuralo prima che ti serva.

Ma non passare all’eccesso opposto di “registra tutto”. Cosa stai cercando di dimostrare? Quali eventi contano, chi ne ha bisogno, per quanto tempo, chi può leggere i log, e i log stessi potrebbero contenere dati sensibili? Registrare crea dati, e anche quei dati hanno bisogno di governance. E le prove hanno bisogno di un responsabile: chi possiede il repository, esamina gli avvisi, verifica che la conservazione funzioni, si accorge che il flusso si è interrotto in silenzio tre mesi fa? Tecnologia senza responsabilità non è governance; torniamo a responsabile, steward e custode del modulo 1.

Dimostra il controllo, non solo la configurazione

“I dati del Destinatario sono disponibili solo alle squadre assegnate alla tappa.” Come lo sappiamo? La configurazione della sicurezza mostra cosa dovrebbe succedere. Le prove operative (chi vi ha davvero avuto accesso, esportazioni insolite, un’integrazione che li preleva, controlli di accesso modificati) mostrano cosa è successo. Una buona governance spesso ha bisogno di entrambe.

Oltre l’esame: cosa cambia l’IA. Man mano che gli agenti passano dal rispondere all’agire, la governance ha bisogno di prove di cosa l’agente ha visto, cosa ha deciso o generato, e cosa ha fatto, e di chi o cosa l’ha avviato, in base a quale politica. I meccanismi di registrazione cambieranno; il requisito no: se un’azione autonoma conta, progetta adesso come la ricostruirai in seguito.

Steve Trucking: il ciclo di vita su un solo campo

Prendi il numero di telefono del Destinatario. Acquisizione: arriva con il manifesto di carico del partner; verifica che sia utilizzabile dove il processo ne ha bisogno. Classificazione: dato personale. Protezione: lo ricevono solo persone e sistemi con un’esigenza operativa, e le squadre lo vedono solo per le proprie tappe, quel giorno. Uso: la squadra coordina la consegna; la messaggistica lo usa per una finalità approvata; un agente lo usa solo se la politica lo consente. Conservazione: per il tempo indicato dalla politica di business e di privacy approvata. Cancellazione o de-identificazione: quando quel periodo finisce o arriva una richiesta valida, su ogni copia del panorama. Audit: conserva le prove che i controlli e le azioni ci sono stati.

Ora prendi il codice di un centro di distribuzione. Acquisiscilo con precisione, classificalo come dato di riferimento non sensibile, proteggilo con il normale accesso operativo, usalo ampiamente, conservalo per quanto serve al business, e sottoponi ad audit le modifiche se contano. Stesso ciclo di vita, controlli diversi. È a questo che serve la classificazione.

La governance non è mai finita

Compare una nuova normativa. Un nuovo sistema o una nuova integrazione crea un’altra copia. Un team inventa un altro campo. Una nuova piattaforma va in produzione. Un agente ottiene l’accesso. Una regola di conservazione cambia. Arriva un nuovo Partner retail. L’architettura si muove, e la governance si muove con essa. L’obiettivo non sono dati perfetti, controlli infiniti o un documento di governance che nessuno legge. Sono decisioni deliberate sui dati, costruite dentro l’architettura.

Cosa decide qui un architetto

• Quali controlli di protezione riceve ogni categoria di dati, in base a classificazione, politica e uso reale, compresi i trade-off della crittografia.
• Per quanto tempo si conservano i dati e il loro storico, cosa fa partire il conteggio, e cosa succede alla fine.
• Quando basta la cronologia standard dei campi e quando una normativa richiede Field Audit Trail.
• Quali eventi vengono raccolti, dove vengono conservate le prove oltre il periodo di conservazione della piattaforma, e chi ne è responsabile.
• Come l’architettura dimostra a posteriori le azioni importanti di persone, integrazioni e agenti.

Questo capitolo è partito da un’idea: la governance si progetta dentro la org, non si scrive accanto. I responsabili fissano le politiche e gli architetti le fanno rispettare. Tieni fuori i dati cattivi dove conta. Sappi cosa significano i tuoi dati, da dove vengono e quanto sono sensibili. Rispetta le leggi, modella il consenso, controlla dove vanno i dati personali. Proteggi, conserva e cancella secondo le politiche. E raccogli le prove prima che qualcuno le chieda, perché sei mesi dopo un incidente è un momento terribile per scoprire che le prove esistevano solo per trenta giorni.

Per approfondire

• Guida di Salesforce, General Shield Platform Encryption Considerations (opens in a new tab) e Filter Encrypted Data with Deterministic Encryption (opens in a new tab) (in inglese), consultato il 2026-10-14.
• Guida di Salesforce, Field History Tracking Overview (opens in a new tab) (in inglese), consultato il 2026-10-14.
• Guida di Salesforce, Field Audit Trail (opens in a new tab) (in inglese), consultato il 2026-10-14.
• Guida di Salesforce, Salesforce Event Monitoring Frequently Asked Questions (opens in a new tab) (in inglese), consultato il 2026-10-14.
• Guida di Salesforce, Secure Your Sandbox Data with Salesforce Data Mask (Legacy) (opens in a new tab) (in inglese), consultato il 2026-10-14.