--- schema_version: "1" id: a262fb6130349ad8cd328bd1b849c8ea98d8147bb84c15a22604ef3c4d0c1b41 title: Schemi di protezione dei dati collection: architect version: current locale: it-it portal_url: https://docs.salesforce.com/architect/current/it-it/well-architected/guides/trust-data-protection-patterns.md canonical_url: https://architect.salesforce.com/docs/architect/it-it/well-architected/guide/trust-data-protection-patterns.html source_site: architect.salesforce.com content_type: documentation content_hash: 966a9e6a28d6123fc972b50e6eb9e79ca81d0d935a7e9584699e10a0e5f17065 products: - Framework ben progettato - Architect Site Content Repo --- # Schemi di protezione dei dati
Ulteriori informazioni su Well-Architected [Trust](/docs/architect/it-it/well-architected/guide/trust.html) → [Data Protection and Privacy](/docs/architect/it-it/well-architected/guide/trust.html#data-protection-and-privacy) ## Classificazione dei dati **Schemi** | Dove cercare | Che bell'aspetto | | --- | --- | | Schema di classificazione dei dati | ✅ Schema di classificazione documentato con livelli (Pubblico, Interno, Riservato, Ristretto)
✅ esempi di business forniti per ogni livello di classificazione
✅ Schema di classificazione allineato agli obblighi normativi (HIPAA, PCI DSS, GDPR)
✅ Modellatori di dati addestrati ad applicare la classificazione in modo coerente durante la progettazione
✅ Nuovi campi classificati come parte del processo di modellazione dei dati, non retroattivamente | | Classificazione a livello di campo | ✅ Classificazione applicata a livello di campo, non solo a livello di oggetto
✅ I campi all'interno di un singolo oggetto possono avere classificazioni diverse
✅ La protezione a livello di campo riflette le distinzioni di classificazione
✅ Dati non classificati per impostazione predefinita al livello di protezione appropriato più alto
✅ La classificazione determina i controlli di protezione (crittografia, accesso, conservazione) | | Oggetti e campi personalizzati | ✅ Tutti gli oggetti personalizzati hanno una classificazione dei dati documentata
✅ Campi sensibili (stipendio, SSN, PHI, dati di pagamento) classificati come Riservato o Limitato
✅ Campi pubblici (nome società, sito Web) documentati come Pubblico
✅ metadati di classificazione acquisiti nelle descrizioni dei campi
✅ Classificazione rivista durante le revisioni del codice e ARB | | Oggetti standard | ✅ Campi oggetto standard valutati in base allo schema di classificazione
✅ Shield Platform Encryption abilitato per i campi standard con restrizioni
✅ Protezione a livello di campo applicata ai campi standard riservati
✅ Rapporti e visualizzazioni elenco filtrati per impedire l'esposizione di campi standard sensibili | | Dati di integrazione | ✅ Dati che fluiscono attraverso integrazioni classificate prima dell'implementazione
✅ Sensibilità dei dati del sistema esterno valutata e documentata
✅ Gestione degli endpoint di integrazione Autenticazione basata su certificato con uso limitato dei dati
✅ Classificazione dei dati conservata oltre i confini del sistema | | Mappatura della conformità | ✅ campi HIPAA PHI identificati e contrassegnati come Limitati
✅ Dati del titolare della carta PCI evitati in Salesforce ove possibile: tokenizzati tramite gateway di pagamento per ridurre l'ambito; dove devono essere memorizzati, utilizzare Campi personalizzati crittografati sotto i controlli PCI DSS
✅ Dati personali GDPR identificati e soggetti a controlli privacy
✅ Dati finanziari SOX classificati e soggetti a separazione delle mansioni | **Anti-schemi** | Dove cercare | Che brutto aspetto | | --- | --- | | Protezione uniforme | ⚠️ Stessa protezione applicata a tutti i campi indipendentemente dalla sensibilità
⚠️ Dati di basso valore iperprotetti (spreco di risorse) mentre dati di alto valore sono sottoprotetti
⚠️ Informazioni sulla società pubblica trattate come informazioni personali o dati delle carte di pagamento
⚠️ Ogni campo crittografato "solo per essere sicuri" senza giustificazione di classificazione | | Classificazione retroattiva | ⚠️ Dati classificati dopo la distribuzione in produzione
⚠️ Dati sensibili rilevati attraverso controlli di conformità anziché revisioni della progettazione
⚠️ Dati classificati solo dopo incidenti di sicurezza
⚠️ "Capiremo la classificazione in seguito" è l'impostazione predefinita durante lo sviluppo | | Classificazione solo a livello di oggetto | ⚠️ Interi oggetti classificati in modo uniforme quando i campi hanno sensibilità diverse
⚠️ Accesso a livello di oggetto concesso senza protezione a livello di campo per i campi sensibili
⚠️ Tutti i campi degli oggetti Account o Referente che si presume abbiano la stessa classificazione
⚠️ Autorizzazioni oggetto utilizzate come unico controllo dell'accesso per gli oggetti con sensibilità mista | | Knowledge tribale | ⚠️ Classificazione non documentata, esistente solo nella Knowledge delle persone chiave
⚠️ Gli sviluppatori si affidavano a "sapere" quali campi sono sensibili
⚠️ Nessuno schema di classificazione scritto accessibile a tutti i modellatori di dati
⚠️ Nuovi membri del team inseriti senza formazione in classificazione | ## Crittografia **Schemi** | Dove cercare | Che bell'aspetto | | --- | --- | | Crittografia a riposo | ✅ Tutti i dati crittografati a livello di infrastruttura tramite Hyperforce
✅ Shield Platform Encryption abilitato per Dati con restrizioni
✅ Schema di crittografia (probabilistica, deterministica, deterministica con distinzione tra maiuscole e minuscole) selezionato in base ai requisiti di query e univocità
✅ compromessi di crittografia valutati durante la progettazione del modello di dati | | Strategia Shield Platform Encryption | ✅ Crittografia probabilistica utilizzata per la maggior parte dei campi con restrizione (supporta tutte le operazioni di query)
✅ Crittografia deterministica utilizzata per i campi che richiedono clausole WHERE di corrispondenza esatta o univocità
✅ deterministica con distinzione tra maiuscole e minuscole utilizzata dove la distinzione dei casi è importante per la logica aziendale
✅ Comportamento dei campi crittografati testato prima della distribuzione in produzione
✅ Riferimenti di campi formula a campi crittografati gestiti in modo appropriato (spostati in Apex se necessario) | | Gestione delle chiavi | ✅ Procedure di rotazione delle chiavi documentate e automatizzate
✅ Scenari di distruzione chiave testati durante le esercitazioni di ripristino di emergenza
✅ Chiavi gestite dal cliente (BYOK) valutate per la conformità che richiedono un controllo esplicito delle chiavi
✅ Procedure di revoca chiave documentate
✅ Ciclo di vita della chiave di crittografia gestito in base ai requisiti di conformità | | Crittografia in transito | ✅ TLS 1.2 o superiore richiesto per tutte le integrazioni
✅ Autenticazione reciproca basata su certificato per le integrazioni che gestiscono dati con restrizioni
✅ Intestazioni HSTS configurate per i siti Experience Cloud per impedire il downgrade del protocollo
✅ scadenza certificato TLS monitorata e rinnovo automatico configurato
✅ Cifre deboli e protocolli disabilitati | | Codice e configurazione | ✅ Credenziali mai incorporate in codice, file di configurazione o controllo di versione
✅ credenziali denominate e credenziali esterne utilizzate per gestire l'autenticazione centralmente
✅ Funzionalità di rotazione delle credenziali integrate nell'architettura
✅ Le credenziali denominate astraggono l'autenticazione dal codice, abilitando gli aggiornamenti senza modifiche del codice | | Pacchetti AppExchange | ✅ Requisiti di sicurezza del pacchetto valutati prima dell'installazione
✅ Campi crittografati accessibili ai pacchetti solo se giustificati dall'azienda
✅ Pacchetti di schemi di accesso ai dati monitorati tramite Monitoraggio evento
✅ Pacchetti che richiedono l'accesso a Dati limitati soggetti a revisione avanzata | **Anti-schemi** | Dove cercare | Che brutto aspetto | | --- | --- | | Crittografia senza valutazione | ⚠️ Crittografia probabilistica abilitata su tutti i campi senza test
⚠️ Rapporti critici rilevati in produzione come non riusciti perché i campi crittografati non possono essere aggregati
⚠️ Crittografia abilitata nelle origini dei campi formula senza impatto sulla comprensione
⚠️ Campi utilizzati nelle query SOQL LIKE crittografati senza passare alla crittografia deterministica | | Credenziali incorporate | ⚠️ Credenziali incorporate nel codice, nelle impostazioni personalizzate o nel controllo delle versioni
⚠️ Chiavi API, password e certificati codificati nelle classi Apex
⚠️ Credenziali confermate negli archivi di controllo sorgente
⚠️ Credenziali memorizzate in metadati personalizzati o impostazioni personalizzate senza crittografia | | Protocolli deboli o legacy | ⚠️ TLS 1.0 o 1.1 accettato (obsoleto e vulnerabile)
⚠️ Flusso OAuth nome utente-password consentito quando è disponibile il bearer JWT
⚠️ Certificati autofirmati accettati nelle integrazioni di produzione
⚠️ Convalida del certificato disabilitata "per far funzionare l'integrazione" | | Nessuna gestione delle chiavi | ⚠️ Shield Platform Encryption abilitato senza procedure di rotazione delle chiavi
⚠️ Nessun scenario di distruzione delle chiavi documentato
⚠️ Chiavi predefinite utilizzate senza valutare la conformità delle chiavi gestite dal cliente
⚠️ Procedure di rotazione e revoca delle chiavi mai testate | | Sovracrittografia | ⚠️ Dati di classificazione pubblici o interni crittografati, con costi aggiuntivi senza vantaggi
⚠️ Shield Platform Encryption abilitato in ogni campo, creando complessità inutili
⚠️ BYOK utilizzato quando la conformità non lo richiede (aggiunge sovraccarico operativo)
⚠️ Crittografia obbligatoria dove la classificazione dei dati non lo giustifica | ## Mascheramento dei dati **Schemi** | Dove cercare | Che bell'aspetto | | --- | --- | | Strategia Sandbox | ✅ I dati limitati non entrano mai negli ambienti di sviluppo o test
✅ Copia Sandbox parziale esclude oggetti e campi con restrizione
✅ I modelli Sandbox definiscono gli oggetti e i campi da includere per tipo di ambiente
✅ Data Mask configurato per i Sandbox che richiedono dati simili a quelli di produzione | | Regole Data Mask | ✅ Le regole Data Mask nascondono i campi sensibili preservando le caratteristiche dei dati
✅ Gli schemi mantengono l'integrità referenziale (lo stesso input produce lo stesso output mascherato)
✅ indirizzi email mascherati ma rimangono in formato valido per il test
✅ Numeri di telefono mascherati ma rimangono in formato valido
✅ Le date sono cambiate in modo coerente mantenendo le relazioni relative
✅ Campi numerici randomizzati entro intervalli realistici | | Dati sintetici | ✅ Gli ambienti di sviluppo utilizzano la generazione di dati sintetici
✅ I dati sintetici hanno caratteristiche realistiche che consentono test efficaci
✅ Nessun dato di produzione mai richiesto per lo sviluppo
✅ Testare la generazione di dati automatizzata nelle pipeline di sviluppo | | Ambienti non di produzione | ✅ Dati di produzione mai copiati nelle organizzazioni sviluppatore personali
✅ Le catture schermata e le demo utilizzano dati mascherati o sintetici
✅ Gli ambienti di formazione utilizzano dati sintetici o dati di produzione fortemente mascherati
✅ Accesso di appaltatori e fornitori ai dati non di produzione limitato alla classificazione Business Use Only | **Anti-schemi** | Dove cercare | Che brutto aspetto | | --- | --- | | Dati di produzione nei Sandbox | ⚠️ Sandbox completi aggiornati con dati di produzione non mascherati per lo sviluppo
⚠️ Dati limitati copiati nei Sandbox per sviluppatori per comodità
⚠️ Sviluppatori con ampio accesso ai Sandbox dati di produzione
⚠️ Sandbox aggiornati con dati sensibili "perché i test sono più facili con dati reali" | | Nessun dato sintetico | ⚠️ Dati di produzione utilizzati esclusivamente per tutti i test
⚠️ Nessuna generazione di dati sintetici per gli ambienti di sviluppo
⚠️ "Abbiamo bisogno di dati reali" ipotizzati senza valutare alternative sintetiche
⚠️ Dati di test manuali creati quando la generazione può essere automatizzata | ## Privacy by Design **Schemi** | Dove cercare | Che bell'aspetto | | --- | --- | | Minimizzazione dei dati | ✅ Solo i dati necessari per scopi aziendali dichiarati raccolti
✅ Ogni aggiunta di campo contestato con "quale decisione architettonica richiede questi dati?"
✅ Dati che non servono più allo scopo di raccolta rimossi
✅ Campi facoltativi chiaramente contrassegnati e non obbligatori senza giustificazione aziendale
✅ Conservazione dei dati storici allineata alla base giuridica, non "mantenere tutto per sempre" | | Limitazione dello scopo | ✅ Gli insiemi di autorizzazioni limitano l'accesso ai dati in base allo scopo della funzione lavorativa
✅ Gli utenti marketing non possono accedere ai dettagli dei casi di assistenza senza una giustificazione documentata
✅ Gli utenti di vendita non possono accedere alle cronologie del servizio clienti a meno che il processo non lo richieda
✅ L'accesso ai dati multifunzionale richiede l'approvazione e il monitoraggio espliciti
✅ Scopo di accesso ai dati documentato nelle descrizioni degli insiemi di autorizzazioni | | Gestione del consenso | ✅ Consenso acquisito a livello individuale per marketing, analisi, elaborazione facoltativa
✅ Il consenso è granulare (specifico dello scopo), non consenso binario
✅ i flussi di lavoro di revoca del consenso si propagano tra i sistemi integrati
✅ decisioni di consenso tracciate con indicazione oraria, versione e meccanismo
✅ L'interfaccia utente del consenso spiega chiaramente a cosa l'utente acconsente | | Diritti degli interessati | ✅ I flussi di lavoro delle richieste di accesso forniscono copie dei dati entro il termine stabilito dal regolamento vigente per la distribuzione
✅ I flussi di lavoro di rettifica correggono le imprecisioni con l'itinerario di controllo
✅ Cancellare i flussi di lavoro per eliminare i dati laddove consentito dalla legge (considerando gli obblighi di conservazione)
✅ I flussi di lavoro di portabilità esportano i dati in formato leggibile dal computer
✅ flussi di lavoro per i diritti degli interessati testati regolarmente per convalidare le tempistiche
✅ L'automazione del flusso di lavoro garantisce che le tempistiche normative vengano rispettate in modo coerente | | Controlli della privacy | ✅ Controlli della privacy imposti tecnicamente, non solo attraverso la policy
✅ Le regole di condivisione implementano la limitazione dello scopo
✅ La protezione a livello di campo protegge gli attributi sensibili
✅ Itinerari di controllo acquisiscono eventi rilevanti per la privacy
✅ Controlli della privacy convalidati nelle pipeline CI/CD | **Anti-schemi** | Dove cercare | Che brutto aspetto | | --- | --- | | Raccogli tutto | ⚠️ Approccio "Raccogli tutti i dati possibili, potremmo averne bisogno un giorno"
⚠️ Campi aggiunti senza scopo aziendale documentato
⚠️ Dati conservati a tempo indeterminato senza giustificazione di conservazione
⚠️ Dati facoltativi raccolti rendendo obbligatori i campi | | Consenso generale | ⚠️ Singolo consenso "acconsento ai termini" per tutti gli scopi
⚠️ Consenso al marketing combinato con l'erogazione del servizio in un'unica casella di controllo
⚠️ Consenso fatto tutto o niente quando gli scopi sono separabili
⚠️ Consenso sepolto in termini e condizioni di 20 pagine | | Polizza senza applicazione | ⚠️ La policy sulla privacy descrive le pratiche ideali che non vengono applicate tecnicamente
⚠️ Formazione degli utenti utilizzata per impedire l'accesso inappropriato ai dati
⚠️ Principi di privacy documentati senza implementare controlli tecnici
⚠️ Conformità della policy assunta senza monitoraggio e convalida | | Richieste manuali degli interessati | ⚠️ Richieste GDPR/CCPA gestite tramite ticket IT manuali che richiedono mesi
⚠️ Nessuna procedura documentata di accesso, rettifica, cancellazione, portabilità
⚠️ La finestra di completamento della richiesta impostata dal regolamento vigente per la distribuzione non è visibile
⚠️ Richiedi che i flussi di lavoro rilevati durante i controlli non esistano | | Condivisione eccessiva dei dati | ⚠️ Ampio accesso ai dati concesso a tutti i reparti senza giustificazione dello scopo
⚠️ Accesso consentito per il marketing ai dettagli dei casi di assistenza
⚠️ Accesso consentito alle vendite alle cronologie del servizio clienti senza necessità documentata
⚠️ Lettura/Scrittura pubblica OWD utilizzato per gli oggetti contenenti dati personali | ## Residenza dati **Schemi** | Dove cercare | Che bell'aspetto | | --- | --- | | Distribuzione regionale Hyperforce | ✅ Organizzazione fornita nella regione Hyperforce che soddisfa i requisiti di residenza dei dati
✅ L'archiviazione e l'elaborazione dei dati avvengono entro i confini geografici richiesti
✅ Requisiti regionali documentati e convalidati prima del provisioning
✅ Requisiti multi-regione affrontati attraverso l'architettura multi-organizzazione dove necessario | | Mappatura del flusso di dati | ✅ Il flusso di dati mappa il documento da cui originano, transitano e risiedono i dati
✅ Trasferimenti di dati transfrontalieri identificati e valutati rispetto ai regolamenti
✅ clausole contrattuali standard o regole aziendali vincolanti per i trasferimenti internazionali
✅ Percorsi di transito dati valutati per la conformità della residenza, non solo la posizione di archiviazione | | Ambito residenza dati | ✅ Posizione di memoria dati (quale regione Hyperforce)
✅ Posizione di elaborazione dei dati (regioni di calcolo)
✅ Posizione di memoria di backup
✅ Log e posizione di archiviazione dell'itinerario di controllo
✅ Percorsi di transito integrazione valutati per la circolazione transfrontaliera dei dati | | Architettura multi-organizzazioni | ✅ Architettura multi-organizzazione utilizzata quando i requisiti normativi non possono essere soddisfatti all'interno di una singola organizzazione
✅ Ogni organizzazione fornita nella regione appropriata per i propri dati
✅ Gli schemi di integrazione rispettano i vincoli di residenza dei dati
✅ compromessi sulla complessità operativa documentati nelle ADR | | Convalida della conformità | ✅ Requisiti di residenza dei dati documentati per giurisdizione
✅ selezione della regione Hyperforce convalidata in base ai requisiti prima del provisioning
✅ Controlli periodici confermano che i dati rimangono entro i limiti richiesti
✅ Le modifiche ai regolamenti sulla residenza attivano la revisione dell'architettura | **Anti-schemi** | Dove cercare | Che brutto aspetto | | --- | --- | | Sorveglianza della residenza | ⚠️ Rilevate violazioni della residenza dei dati durante i controlli di conformità
⚠️ Fornitura di organizzazioni senza valutazione dei requisiti regionali
⚠️ "Cloud is cloud" assunto senza considerare le normative sulla posizione dei dati
⚠️ Giurisdizioni aggiunte senza revisione degli obblighi di residenza | | Transito ignorando la residenza | ⚠️ Considerata solo la posizione di stoccaggio mentre i percorsi di transito vengono ignorati
⚠️ Dati instradati attraverso regioni al di fuori dei confini di conformità
⚠️ Middleware di integrazione utilizzato nelle regioni non conformi
⚠️ Backup archiviati in regioni diverse dai dati principali | | Multi-organizzazione non necessaria | ⚠️ Architettura multi-organizzazione utilizzata quando è sufficiente una singola organizzazione con regioni Hyperforce
⚠️ Complessità operativa, costi di licenza e sovraccarico di integrazione moltiplicati senza necessità normative
⚠️ Implementazione multi-organizzazioni "solo per essere sicuri" senza un requisito di conformità specifico
⚠️ Multi-organizzazione utilizzata per impostazione predefinita quando i controlli di classificazione dei dati e accesso sono sufficienti |