Dataskyddsmönster


Lär dig mer om Well-Architected Trust → Dataskydd och sekretess

Mönster

Var man ska letaHur bra ser ut
Dataklassificeringsschema✅ Klassificeringsschema dokumenterat med nivåer (offentlig, intern, konfidentiell, begränsad)
✅ Affärsexempel för varje klassificeringsnivå
✅ Klassificeringsschema anpassat till lagstadgade skyldigheter (HIPAA, PCI DSS, GDPR)
✅ Datamodellerare utbildade för att tillämpa klassificering konsekvent under design
✅ Nya fält som klassificeras som en del av datamodelleringsprocessen, inte retroaktivt
Fältnivåklassificering✅ Klassificering tillämpad på fältnivå, inte bara objektnivå
✅ Fält inom ett enskilt objekt kan ha olika klassificeringar
✅ Fältnivåsäkerhet återspeglar klassificeringsskillnader
✅ Oklassificerade data blir som standard högsta lämpliga skyddsnivå
✅ Klassificering driver skyddskontroller (kryptering, åtkomst, lagring)
Egna objekt och fält✅ Alla egna objekt har dokumenterad dataklassificering
✅ Känsliga fält (lön, SSN, PHI, betalningsdata) klassificerade som konfidentiell eller begränsad
✅ Offentliga fält (företagsnamn, webbplats) dokumenterade som offentliga
✅ Klassificering metadata som samlats in i fältbeskrivningar
✅ Klassificering granskas under kodgranskningar och ARB
Standardobjekt✅ Standardobjektfält utvärderade mot klassificeringsschema
✅ Shield Platform Encryption aktiverat för begränsade standardfält
✅ Fältnivåsäkerhet tillämpad på konfidentiella standardfält
✅ Rapporter och listvyer filtrerade för att förhindra exponering av känsliga standardfält
Integreringsdata✅ Data som flödar genom integreringar klassificerade innan implementering
✅ Extern systemdatakänslighet utvärderad och dokumenterad
✅ Integreringsslutpunkter som hanterar begränsad dataanvändning certifikatbaserad autentisering
✅ Dataklassificering bevarad över systemgränser
Mappning av efterlevnad✅ HIPAA PHI fält identifierade och markerade Begränsad
✅ PCI-korthållardata undviks i Salesforce där så är möjligt—tokeniseras via betalningsgateway för omfattningsreduktion; där det måste lagras, använd krypterade egna fält under PCI DSS-kontroller
✅ GDPR personuppgifter identifierade och föremål för sekretesskontroller
✅ SOX finansiella data klassificerade och föremål för uppdelning av uppgifter

Antimönster

Var man ska letaHur dåligt ser ut
Enhetligt skydd⚠️ Samma skydd gäller för alla fält oavsett känslighet
⚠️ Data med lågt värde överskyddade (slösar resurser) medan data med högt värde är underskyddade
⚠️ Offentlig företagsinformation behandlas på samma sätt som PHI- eller betalkortsuppgifter
⚠️ Varje fält krypteras “bara för att vara säker” utan klassificeringsmotivering
Retroaktiv klassificering⚠️ Data klassificerade efter distribution till produktion
⚠️ Känsliga data som upptäcks genom efterlevnadsgranskningar istället för designgranskningar
⚠️ Data som endast är klassificerade efter säkerhetsincidenter
⚠️ “Vi räknar ut klassificering senare” är standard under utveckling
Endast klassificering på objektnivå⚠️ Hela objekt klassificeras enhetligt när fält har olika känslighet
⚠️ Objektnivååtkomst beviljad utan fältnivåsäkerhet för känsliga fält
⚠️ Alla fält i objekten Konto eller Kontakt antas ha samma klassificering
⚠️ Objektbehörigheter som används som den enda åtkomstkontrollen för objekt med blandad känslighet
Tribal Knowledge⚠️ Klassificering odokumenterad, finns endast i nyckelpersoners Knowledge
⚠️ Utvecklare förlitade sig på att “bara veta” vilka fält som är känsliga
⚠️ Inget skriftligt klassificeringsschema tillgängligt för alla datamodellerare
⚠️ Nya teammedlemmar har gått ombord utan klassificeringsutbildning

Mönster

Var man ska letaHur bra ser ut
Kryptering vid vila✅ Alla data krypterade på infrastrukturnivå genom Hyperforce
✅ Shield Platform Encryption aktiverat för begränsade data
✅ Krypteringsschema (probabilistisk, deterministisk, skiftlägeskänslig deterministisk) valt baserat på sökfråga och unika krav
✅ Kryptering kompromisser utvärderas under datamodelldesign
Strategi för Shield Platform Encryption✅ Probabilistisk kryptering som används för de flesta begränsade fält (stöder alla sökfrågeoperationer)
✅ Deterministisk kryptering som används för fält som kräver exakt matchning WHERE klausuler eller unikhet
✅ Skiftlägeskänslig deterministisk används där kundcase åtskillnad spelar roll för affärslogik
✅ Krypterat fältbeteende testat innan produktionsdistribuering
✅ Formelfältreferenser till krypterade fält hanteras korrekt (flyttas till Apex om det behövs)
Nyckelhantering✅ Nyckel rotationsprocesser dokumenterade och automatiserade
✅ Nyckel förstörelsescenarier testade under katastrofåterställningsövningar
✅ Kundhanterade nycklar (BYOK) utvärderas för efterlevnad som kräver uttrycklig nyckelkontroll
✅ Nyckel återkallandeförfaranden dokumenterade
✅ Krypteringsnyckel livscykel hanteras enligt efterlevnadskrav
Kryptering under överföring✅ TLS 1.2 eller högre krävs för alla integreringar
✅ Certifikatbaserad ömsesidig autentisering för integreringar som hanterar begränsade data
✅ HSTS-sidhuvuden konfigurerade för Experience Cloud-webbplatser för att förhindra protokollnedgradering
✅ TLS-certifikatutgång bevakad och automatiserad förnyelse konfigurerad
✅ Svaga chiffer och protokoll inaktiverade
Kod och konfiguration✅ Inloggningsuppgifter aldrig inbäddade i kod, konfigurationsfiler eller versionskontroll
✅ autentiseringsuppgifter och externa inloggningsuppgifter som används för att hantera autentisering centralt
✅ Inloggningsrotation kapacitet inbyggd i arkitektur
✅ abstrakt autentisering från kod, aktivera uppdateringar utan kodändringar
AppExchange paket✅ Paketsäkerhetskrav utvärderade innan installation
✅ Krypterade fält endast tillgängliga för paket när det är affärsmotiverat
✅ Paketera dataåtkomstmönster övervakas genom händelseövervakning
✅ Paket som kräver åtkomst till Begränsad registrerad föremål för utökad granskning

Antimönster

Var man ska letaHur dåligt ser ut
Kryptering utan utvärdering⚠️ Probabilistisk kryptering aktiverad för alla fält utan test
⚠️ Kritiska rapporter som upptäcks i produktion misslyckas eftersom krypterade fält inte kan aggregeras
⚠️ Kryptering aktiverad för formelfältkällor utan förståelsepåverkan
⚠️ Fält som används i SOQL LIKE-frågor krypterade utan att växla till deterministisk kryptering
Inbäddade inloggningsuppgifter⚠️ Inloggningsuppgifter inbäddade i kod, egna inställningar eller versionshantering
⚠️ API-nycklar, lösenord och certifikat hårdkodade i Apex klasser
⚠️ Inloggningsuppgifter för källkontrollarkiv
⚠️ Inloggningsuppgifter som lagras i egna metadata eller inställningar utan kryptering
Svaga eller äldre protokoll️ TLS 1.0 eller 1.1 accepterat (föråldrat och sårbart)
⚠️ Användarnamn-lösenord OAuth-flöde tillåtet när JWT-bärare är tillgänglig
⚠️ Självsignerade certifikat accepterade i produktionsintegreringar
⚠️ Certifikatvalidering inaktiverad “för att få integrering att fungera”
Ingen nyckelhantering⚠️ Shield Platform Encryption aktiverat utan nyckelrotationsprocesser
⚠️ Inga dokumenterade nyckelförstöringsscenarion
⚠️ Standardnycklar som används utan att utvärdera kundhanterade nycklar för efterlevnad
⚠️ Nyckelrotation och återkallande har aldrig testats
Överkryptering⚠️ Offentliga eller interna klassificeringsdata krypterade, vilket lägger till kostnad utan fördel
⚠️ Shield Platform Encryption aktiverat för varje fält, vilket skapar onödig komplexitet
⚠️ BYOK används när efterlevnad inte kräver det (lägger till operativ overhead)
⚠️ Kryptering obligatorisk där dataklassificering inte motiverar det

Mönster

Var man ska letaHur bra ser ut
Sandboxstrategi✅ Begränsade data kommer aldrig in i utvecklings- eller testmiljöer
✅ Delvis sandboxkopiering utesluter begränsade objekt och fält
✅ Sandboxmallar definierar vilka objekt och fält som ska inkluderas efter miljötyp
✅ Data Mask konfigurerad för sandboxar som kräver produktionsliknande data
Data Mask✅ Data Mask regler döljer känsliga fält samtidigt som dataegenskaper bevaras
✅ Mönster behåller referensens integritet (samma indata producerar samma maskerade utdata)
✅ E-postadresser maskerade men förblir giltigt format för tester
✅ Telefonnummer maskerad men förblir giltigt format
✅ Datum flyttade konsekvent upprätthålla relativa relationer
✅ numeriska fält slumpmässiga inom realistiska intervall
Syntetiska data✅ Utvecklingsmiljöer använder skapande av syntetiska data
✅ Syntetiska data har realistiska egenskaper som möjliggör effektiva tester
✅ Inga produktionsdata behövs någonsin för utveckling
✅ Testa dataskapande automatiserat i utvecklingspipeline
Icke-produktionsmiljöer✅ Produktionsdata kopieras aldrig till personliga utvecklarorganisationer
✅ Skärminsamling och demonstrationer använder maskerade eller syntetiska data
✅ Utbildningsmiljöer använder syntetiska data eller kraftigt maskerade produktionsdata
✅ Entreprenör och leverantör åtkomst till icke-produktionsdata begränsad till Endast företagsanvändning klassificering

Antimönster

Var man ska letaHur dåligt ser ut
Produktionsdata i sandboxar⚠️ Fulla sandboxar uppdaterade med omaskerade produktionsdata för utveckling
⚠️ Begränsade data kopierade till Developer Sandboxes för enkelhets skull
⚠️ Utvecklare beviljas bred åtkomst till produktionsdatasandboxar
⚠️ Sandboxar uppdaterade med känsliga data “eftersom tester är enklare med verkliga data”
Inga syntetiska data⚠️ Produktionsdata förlitar sig endast på alla tester
⚠️ Ingen skapande av syntetiska data för utvecklingsmiljöer
⚠️ “Vi behöver verkliga data” antas utan att utvärdera syntetiska alternativ
⚠️ Manuella testdata skapas när skapande kan automatiseras

Mönster

Var man ska letaHur bra ser ut
Dataminimering✅ Endast data som behövs för angivna affärssyften som samlats in
✅ Varje fälttillägg utmanas med “vilket arkitektoniskt beslut kräver dessa data?”
✅ Data som inte längre tjänar insamlingssyfte tas bort
✅ Valfria fält tydligt markerade och inte obligatoriska utan affärsmotivering
✅ Historisk datalagring i linje med rättslig grund, inte “håll allt för evigt”
Syftesbegränsning✅ Behörighetsuppsättningar begränsar dataåtkomst baserat på jobbfunktionssyfte
✅ Marknadsföringsanvändare kan inte komma åt supportkundcasedetaljer utan dokumenterad motivering
✅ Säljanvändare kan inte komma åt kundservicehistorik om inte jobbet kräver det
✅ tvärfunktionell dataåtkomst kräver uttryckligt godkännande och övervakning
✅ Dataåtkomstsyfte dokumenterat i behörighetsuppsättningsbeskrivningar
Samtyckeshantering✅ Samtycke som samlats in på individuell nivå för marknadsföring, analys, valfri bearbetning
✅ Samtycke är detaljerat (syftesspecifikt), inte binärt samtycke
✅ Arbetsflöden för samtyckesåterkallande propagerar över integrerade system
✅ Samtyckesbeslut spårade med tidsstämpel, version och mekanism
✅ Samtycke UI förklarar tydligt vad användaren samtycker till
Registrerades rättigheter✅ Arbetsflöden för åtkomstbegäran ger datakopior inom den tidsfrist som den styrande förordningen anger för din distribuering
✅ Rättelseflöden korrigerar felaktigheter med granskningslogg
✅ Radera arbetsflöden tar bort data där det är tillåtet enligt lag (med tanke på lagringsskyldigheter)
✅ Portabilitet arbetsflöden exportera data i maskinläsbart format
✅ Registrerade rättigheter arbetsflöden testas regelbundet för att validera tidslinjer
✅ Arbetsflödesautomatisering säkerställer att lagstadgade tidslinjer uppfylls enhetligt
Sekretesskontroller✅ Sekretesskontroller tillämpas tekniskt, inte bara genom policy
✅ Delningsregler implementerar syftesbegränsning
✅ Fältnivåsäkerhet skyddar känsliga attribut
✅ Granskningsspår samlar in sekretessrelevanta händelser
✅ Sekretesskontroller validerade i CI / CD-pipeline

Antimönster

Var man ska letaHur dåligt ser ut
Samla allt⚠️ “Samla in alla möjliga data, vi kanske behöver dem en dag”-metoden
⚠️ Fält som lagts till utan dokumenterat verksamhetssyfte
️ Uppgifter som behålls tills vidare utan motivering för lagring
⚠️ Valfria data som samlats in genom att göra fält obligatoriska
Filtsamtycke⚠️ Enskilt samtycke “godkänn villkoren” för alla syften
⚠️ Marknadsföringssamtycke kombinerat med tjänsteleverans i en enda kryssruta
⚠️ Samtycke som gjorts allt eller inget när syften kan skiljas åt
⚠️ Samtycke begravt i villkor på 20 sidor
Policy utan tillämpning⚠️ Integritetspolicy beskriver idealiska metoder som inte tillämpas tekniskt
⚠️ Användarutbildning förlitar sig på för att förhindra olämplig dataåtkomst
️ Sekretessprinciper dokumenterade utan att genomföra tekniska kontroller
️ Policyefterlevnad antas utan övervakning och validering
Manuella begäranden från registrerade⚠️ GDPR/CCPA-begäranden som hanteras genom manuella IT-ärenden som tar månader
️ Inga dokumenterade förfaranden för åtkomst, rättelse, radering eller portabilitet
⚠️ Det fönster för begäran-ifyllning som den styrande förordningen anger för din distribuering missas
⚠️ Begär att arbetsflöden som hittas under granskningar inte ska finnas
Överdriven datadelning⚠️ Bred dataåtkomst beviljad mellan avdelningar utan motivering av syfte
⚠️ Marknadsföring tillåts åtkomst till supportkundcasedetaljer
⚠️ Försäljning tillåten åtkomst till kundservicehistorik utan dokumenterat behov
⚠️ Offentligt Läsa/Skriva OWD som används för objekt som innehåller personuppgifter

Mönster

Var man ska letaHur bra ser ut
Hyperforce regional distribuering✅ Organisation provisionerad i Hyperforce region som uppfyller kraven för datalagring
✅ Datalagring och bearbetning sker inom obligatoriska geografiska gränser
✅ Regionala krav dokumenterade och validerade innan provisionering
✅ Flerregionskrav hanteras genom flerorganisationsarkitektur vid behov
Dataflödesmappning✅ Dataflöde mappar dokument där data kommer från, transiteras och finns
✅ Gränsöverskridande dataöverföringar identifierade och utvärderade mot föreskrifter
✅ Standardavtalsklausuler eller bindande företagsregler för internationella överföringar
✅ Dataöverföringsvägar utvärderade för bosättningsefterlevnad, inte bara lagringsplats
Dataresidensomfattning✅ Datalagringsplats (vilken Hyperforce region)
✅ Databearbetningsplats (beräkna regioner)
✅ Backup lagringsplats
✅ Logga och granska spårlagringsplats
✅ Integrationstransitvägar utvärderade för gränsöverskridande dataflyttning
Flerorganisationsarkitektur✅ Flerorganisationsarkitektur som används när lagstadgade krav inte kan uppfyllas inom en enskild organisation
✅ Varje organisation provisionerad i lämplig region för sina data
✅ Integreringsmönster respekterar begränsningar för datalagring
✅ Operativ komplexitet kompromisser dokumenterade i ADR
Validering av efterlevnad✅ Data residency krav dokumenterade av jurisdiktion
✅ Hyperforce regionval validerade mot krav innan provisionering
✅ Regelbundna revisioner bekräftar att data förblir inom obligatoriska gränser
✅ Ändringar i bosättningsregler utlöser arkitekturgranskning

Antimönster

Var man ska letaHur dåligt ser ut
Tillsyn över bosättning⚠️ Datalagringsbrott upptäckta under efterlevnadsgranskningar
️ Organisationer provisionerade utan att utvärdera regionala krav
⚠️ “Moln är moln” antas utan att överväga dataplatsföreskrifter
⚠️ Jurisdiktioner läggs till utan att skyldigheten att vara bosatt omprövas
Transit ignorerar hemvist⚠️ Endast lagringsplats övervägs medan transitvägar ignoreras
⚠️ Data som dirigeras genom regioner utanför efterlevnadsgränser
⚠️ Mellanprogramvara för integration som används i regioner som inte uppfyller kraven
⚠️ Säkerhetskopior som lagras i andra regioner än primära data
Onödig multiorganisation⚠️ Flerorganisationsarkitektur som används när en enskild organisation med Hyperforce regioner är tillräcklig
⚠️ Operativ komplexitet, licenskostnader och integreringsoverhead multiplicerat utan lagstadgad nödvändighet
⚠️ Multiorganisation implementerad “bara för att vara säker” utan ett specifikt efterlevnadskrav
⚠️ Multiorganisation som används som standard när dataklassificering och åtkomstkontroller är tillräckliga