Schemi di protezione dei dati | Schemi |

Schemi di protezione dei dati

Ulteriori informazioni su Well-Architected Trust → Data Protection and Privacy

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

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

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

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

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