Databeskyttelsesmønstre
Læs mere om Well-Architected Trust → Databeskyttelse og fortrolighed
Mønstre
| Hvor skal du se | Hvad der ser godt ud |
|---|---|
| Dataklassificeringsskema | ✅ Klassificeringsskema dokumenteret med niveauer (Offentlig, Intern, Fortrolig, Begrænset) ✅ Forretningseksempler angivet for hvert klassificeringsniveau ✅ Klassificeringsskema, der er i overensstemmelse med bestemmelsesforpligtelser (HIPAA, PCI DSS, GDPR) ✅ Datamodeller, der er trænet til at anvende klassificering ensartet under design ✅ Nye felter, der er klassificeret som en del af datamodelprocessen, ikke med tilbagevirkende kraft |
| Klassificering på feltniveau | ✅ Klassificering anvendt på feltniveau, ikke kun på objektniveau ✅ Felter i et enkelt objekt kan have forskellige klassificeringer ✅ Sikkerhed på feltniveau afspejler klassificeringsforskelle ✅ Ikke-klassificerede data sættes som standard til det højeste relevante beskyttelsesniveau ✅ Klassificering styrer beskyttelseskontroller (kryptering, adgang, bevarelse) |
| Tilpassede objekter og felter | ✅ Alle tilpassede objekter har dokumenteret dataklassificering ✅ Følsomme felter (løn, SSN, PHI, betalingsdata), der er klassificeret som Fortrolige eller Begrænsede ✅ Offentlige felter (firmanavn, website), der er dokumenteret som Offentlig ✅ Klassificeringsmetadata, der registreres i feltbeskrivelser ✅ Klassificering gennemset under kodegennemgange og ARB |
| Standardobjekter | ✅ Standardobjektfelter evalueret op mod klassificeringsskema ✅ Shield Platform Encryption aktiveret for begrænsede standardfelter ✅ Sikkerhed på feltniveau anvendt på fortrolige standardfelter ✅ Rapporter og listevisninger filtreres for at forhindre visning af følsomme standardfelter |
| Integrationsdata | ✅ Data, der flyder gennem integrationer, der er klassificeret før implementering ✅ Ekstern systemdatafølsomhed evalueret og dokumenteret ✅ Integrationsslutpunkter, der håndterer begrænset dataanvendelse - certifikatbaseret godkendelse ✅ Dataklassificering bevaret på tværs af systemgrænser |
| Overensstemmelsestilknytning | ✅ HIPAA PHI-felter identificeret og markeret som Begrænset ✅ PCI-kortholderdata undgås i Salesforce, hvor det er muligt – tokeniseres via betalingsgateway for at reducere omfanget. Hvor de skal lagres, skal du bruge krypterede tilpassede felter under PCI DSS-kontroller ✅ GDPR-personlige data identificeret og underlagt fortrolighedskontroller ✅ SOX-økonomiske data klassificeret og underlagt adskillelse af pligter |
Anti-mønstre
| Hvor skal du se | Hvad ser dårligt ud |
|---|---|
| Ensartet beskyttelse | ⚡️ Samme beskyttelse anvendes på alle felter, uanset følsomheden ⚡️ Data med lav værdi overbeskyttet (forbrugt ressourcer), mens data med høj værdi er underbeskyttet ⚡️ Offentlige firmaoplysninger behandles på samme måde som PHI- eller betalingskortdata ⚡️ Hvert felt er krypteret “kun for at være sikkert” uden klassificeringsjustering |
| Retroaktiv klassificering | ⚡️ Data, der er klassificeret efter implementering i produktion ⚡️ Følsomme data, der er fundet gennem overensstemmelsesrevisioner i stedet for designgennemgange ⚡️ Data, der kun er klassificeret efter sikkerhedshændelser ⚡️ “Vi finder på klassificering senere” er standarden under udvikling |
| Kun klassificering på objektniveau | ⚡️ Hele objekter klassificeret ens, når felter har forskellig følsomhed ⚡️ Adgang på objektniveau tildelt uden sikkerhed på feltniveau for følsomme felter ⚡️ Alle felter på konto- eller kontaktobjekter antages at have den samme klassificering ⚡️ Objekttilladelser, der bruges som den eneste adgangskontrol for objekter med blandet følsomhed |
| Tribal Knowledge | ⚡️ Klassificering udokumenteret, eksisterende kun i nøglepersoners Knowledge ⚡️ Udviklere har brug for “kun at vide”, hvilke felter der er følsomme ⚡️ Ingen skriftlig klassificeringsskema er tilgængelig for alle datamodelbrugere ⚡️ Nye teammedlemmer introduceret uden klassificeringsuddannelse |
Mønstre
| Hvor skal du se | Hvad der ser godt ud |
|---|---|
| Kryptering er inaktive | ✅ Alle data krypteret på infrastrukturniveau gennem Hyperforce ✅ Shield Platform Encryption aktiveret for begrænsede data ✅ Krypteringsskema (sandsynlighed, deterministisk, deterministisk, hvor der skelnes mellem store og små bogstaver) valgt baseret på forespørgsel og unikke krav ✅ Krypteringsudskiftninger evalueret under datamodeldesign |
| Shield Platform Encryption | ✅ Sandsynlighedskryptering, der bruges til de fleste begrænsede felter (understøtter alle forespørgselshandlinger) ✅ Deterministisk kryptering, der bruges til felter, der kræver exact-match WHERE-sætninger eller entydighed ✅ Deterministik, hvor der skelnes mellem store og små bogstaver, bruges, hvor sagssynlighed betyder noget for forretningslogik ✅ Krypteret feltadfærd testet før produktionsimplementering ✅ Formelfeltreferencer til krypterede felter, der håndteres korrekt (flyttes til Apex, hvis det er nødvendigt) |
| Nøglestyring | ✅ Nøglerotationsprocedurer dokumenteret og automatiseret ✅ Nøgledestyringsscenarier, der er testet under katastrofegenoprettelsesøvelser ✅ Kundeadministrerede nøgler evalueret for overensstemmelse, der kræver eksplicit nøglekontrol ✅ Nøgletilbagekaldelsesprocedurer dokumenteret ✅ Livscyklus for krypteringsnøgle administreret i henhold til overensstemmelseskrav |
| Kryptering under transit | ✅ TLS 1.2 eller højere påkrævet for alle integrationer ✅ Certifikatbaseret gensidig godkendelse for integrationer, der håndterer begrænsede data ✅ HSTS-sidehoveder, der er konfigureret for Experience Cloud-lokaliteter for at forhindre nedgradering af protokol ✅ TLS-certifikatudløb overvåget og automatisk fornyelse konfigureret ✅ Svage koder og protokoller inaktiveret |
| Kode og konfiguration | ✅ Legitimationsoplysninger, der aldrig er integreret i kode, konfigurationsfiler eller versionskontrol ✅ Navngivne legitimationsoplysninger og eksterne legitimationsoplysninger, der bruges til at administrere godkendelse centralt ✅ Roteringsfunktioner for legitimationsoplysninger, der er indbygget i arkitekturen ✅ Navngivne legitimationsoplysninger - abstrakt godkendelse fra kode, der aktiverer opdateringer uden kodeændringer |
| AppExchange | ✅ Pakkesikkerhedskrav evalueret før installation ✅ Krypterede felter er kun tilgængelige for pakker, når det er forretningsjusteret ✅ Mønstre for pakkedataadgang overvåget gennem Begivenhedsovervågning ✅ Pakker, der kræver adgang til Begrænsede data, der er underlagt forbedret gennemgang |
Anti-mønstre
| Hvor skal du se | Hvad ser dårligt ud |
|---|---|
| Kryptering uden evaluering | ⚡️ Sandsynlighedskryptering aktiveret på alle felter uden test ⚡️ Kritiske rapporter, der er fundet i produktion, mislykkes, fordi krypterede felter ikke kan aggregeres ⚡️ Kryptering aktiveret på formelfeltkilder uden forståelse af påvirkning ⚡️ Felter, der bruges i SOQL LIKE-forespørgsler, krypteret uden at skifte til deterministisk kryptering |
| Integrerede legitimationsoplysninger | ⚡️ Legitimationsoplysninger integreret i kode, tilpassede indstillinger eller versionskontrol ⚡️ API-nøgler, adgangskoder og certifikater hardcoded i Apex ⚡️ Legitimationsoplysninger, der er bekræftet til kildekontrollager ⚡️ Legitimationsoplysninger, der er lagret i tilpassede metadata eller tilpassede indstillinger uden kryptering |
| Svage eller forældede protokoller | ⚡️ TLS 1.0 eller 1.1 accepteret (udfaset og sårbar) ⚡️ Brugernavn-adgangskode OAuth-forløb tilladt, når JWT Bearer er tilgængelig ⚡️ Selvsignerede certifikater accepteres i produktionsintegrationer ⚡️ Certifikatvalidering inaktiveret “for at få integrationen til at fungere” |
| Ingen nøgleadministration | ⚡️ Shield Platform Encryption aktiveret uden nøglerotationsprocedurer ⚡️ Ingen dokumenterede nøgleødelæggelsesscenarier ⚡️ Standardnøgler, der bruges uden at evaluere kundeadministrerede nøgler for overensstemmelse ⚡️ Nøglerotations- og tilbagekaldelsesprocedurer aldrig testet |
| Overkryptering | ⚡️ Offentlige eller interne klassificeringsdata krypteret, hvilket tilføjer omkostninger uden fordel ⚡️ Shield Platform Encryption aktiveret på hvert felt, hvilket skaber unødvendig kompleksitet ⚡️ BYOK bruges, når overensstemmelse ikke kræver det (tilføjer driftsmæssig overhead) ⚡️ Kryptering er obligatorisk, hvor dataklassificering ikke justerer det |
Mønstre
| Hvor skal du se | Hvad der ser godt ud |
|---|---|
| Sandbox-strategi | ✅ Begrænsede data overføres aldrig til udviklings- eller testmiljøer ✅ Delvis sandbox-kopiering udelader begrænsede objekter og felter ✅ Sandbox-skabeloner definerer, hvilke objekter og felter der skal inkluderes efter miljøtype ✅ Data Mask konfigureret til sandboxes, der kræver produktionsagtige data |
| Data Mask regler | ✅ Data Mask regler skjule følsomme felter, mens data egenskaber bevares ✅ Mønstre bevarer referenceintegritet (samme input opretter det samme maskerede output) ✅ Mailadresser maskeres, men forbliver gyldigt format til test ✅ Telefonnumre maskeret, men forbliver gyldigt format ✅ Datoer vagt konsekvent vedligeholdelse af relative relationer ✅ Numeriske felter, der er randomiseret inden for realistiske områder |
| Syntetiske data | ✅ Udviklingsmiljøer bruger generering af syntetiske data ✅ Syntetiske data har realistiske egenskaber, der aktiverer effektiv test ✅ Ingen produktionsdata, der nogensinde er påkrævet til udvikling ✅ Test datagenerering automatiseret i udviklingspipelines |
| Ikke-produktionsmiljøer | ✅ Produktionsdata kopieres aldrig til personlige udviklerorganisationer ✅ Skærmbilleder og demoer bruger maskerede eller syntetiske data ✅ Uddannelsesmiljøer bruger syntetiske data eller hårdt maskerede produktionsdata ✅ Leverandør- og leverandøroadgang til ikke-produktionsdata, der er begrænset til Kun forretningsanvendelse-klassificering |
Anti-mønstre
| Hvor skal du se | Hvad ser dårligt ud |
|---|---|
| Produktionsdata i sandboxes | ⚡️ Fuld sandboxes opdateret med ikke-maskerede produktionsdata til udvikling ⚡️ Begrænsede data kopieret til udvikler-sandboxes for at gøre det nemmere ⚡️ Udviklere tildelte bred adgang til produktions-datasandboxes ⚡️ Sandboxes opdateret med følsomme data “fordi test er nemmere med virkelige data” |
| Ingen syntetiske data | ⚡️ Produktionsdata, der er baseret udelukkende på alle test ⚡️ Ingen syntese datagenerering for udviklingsmiljøer ”Vi har brug for virkelige data” antages uden at evaluere syntetiske alternativer ⚡️ Manuel testdata, der oprettes, når generering kan automatiseres |
Mønstre
| Hvor skal du se | Hvad der ser godt ud |
|---|---|
| Dataminimering | ✅ Kun data, der er nødvendige for angivne forretningsformål indsamles ✅ Hver felttilføjelse, der bliver stillet spørgsmålstegn ved “hvilken arkitektonisk beslutning kræver disse data?” ✅ Data, der ikke længere tjener til indsamlingsformål, fjernes ✅ Valgfri felter er tydeligt markeret og ikke påkrævet uden forretningsjustering ✅ Historisk databevarelse, der er i overensstemmelse med det juridiske grundlag, ikke “bevar alt permanent” |
| Begrænsning af formål | ✅ Tilladelsessæt begrænser dataadgang baseret på jobfunktionsformål ✅ Marketingbrugere kan ikke få adgang til supportsagsdetaljer uden dokumenteret begrundelse ✅ Salgsbrugere kan ikke få adgang til kundeservicehistorier, medmindre jobbet kræver det ✅ Tværgående dataadgang kræver eksplicit godkendelse og overvågning ✅ Dataadgangsformål dokumenteret i beskrivelser af tilladelsessæt |
| Samtykkestyring | ✅ Samtykke registreret på individuelt niveau til marketing, analyser, valgfri behandling ✅ Samtykke er detaljeret (formålspecifikt), ikke binært overordnet samtykke ✅ Arbejdsflows for samtykketilbagetrækning udbredes på tværs af integrerede systemer ✅ Samtykkebeslutninger spores med tidsstempel, version og mekanisme ✅ Samtykkebrugergrænseflade forklarer tydeligt, hvad brugeren samtykker til |
| Registrerets rettigheder | ✅ Adgangsanmodningsarbejdsflows leverer datakopier inden for tidsfristen, som de regulerende bestemmelser angiver for din implementering ✅ Retningsarbejdsflows retter unøjagtigheder med revisionsspor ✅ Slettearbejdsflows sletter data, hvor det er juridisk tilladt (under hensyntagen til bevarelsesforpligtelser) ✅ Portabilitetsarbejdsflows eksporterer data i maskinlæsbart format ✅ Arbejdsflows for registrerets rettigheder testes regelmæssigt for at validere tidslinjer ✅ Arbejdsflowautomatisering sikrer ensartede tidslinjer for bestemmelser |
| Fortrolighedskontroller | ✅ Fortrolighedskontroller håndhævet teknisk, ikke kun gennem politik ✅ Delingsregler implementerer begrænsning af formål ✅ Sikkerhed på feltniveau beskytter følsomme attributter ✅ Revisionsspor registrerer fortrolighedsrelevante begivenheder ✅ Fortrolighedskontroller valideret i CI/CD-pipelines |
Anti-mønstre
| Hvor skal du se | Hvad ser dårligt ud |
|---|---|
| Indsaml alt | ⚡️ “Saml alle mulige data, vi har brug for det en dag” -tilgang ⚡️ Felter tilføjet uden dokumenteret forretningsformål ⚡️ Data bevares uendeligt uden bevarelsesjustering ⚡️ Valgfri data, der indsamles ved at gøre felter påkrævede |
| Samtykke i dækning | ⚡️ Enkelt “sig med vilkårene” samtykke til alle formål ⚡️ Marketingsamtykke kombineret med servicelevering i et enkelt afkrydsningsfelt Samtykke foretaget alt-eller-ingen, når formål kan adskilles ⚡️ Samtykke ligger i 20-siders vilkår og betingelser |
| Politik uden håndhævelse | ⚡️ Fortrolighedspolitik beskriver ideelle fremgangsmåder, der ikke er teknisk håndhævet ⚡️ Brugeruddannelse, der er baseret på for at forhindre upassende dataadgang ⚡️ Fortrolighedsprincipper dokumenteret uden at implementere tekniske kontroller ⚡️ Antagelse om policeoverensstemmelse uden overvågning og validering |
| Manuel anmodning om registreret | ⚡️ GDPR/CCPA-anmodninger håndteres gennem manuelle it-billetter, der tager måneder ⚡️ Ingen dokumenterede procedurer for adgang, rettelse, sletning, portabilitet ⚡️ Anmodningsfuldførelsesvinduet, som den styrende bestemmelse angiver for din implementering, mangler ⚡️ Anmod om, at arbejdsflows, der blev fundet under revisioner, ikke findes |
| Overdreven datadeling | ⚡️ Bred dataadgang tildelt på tværs af afdelinger uden formålsjustering ⚡️ Marketing har tilladt adgang til supportsagsdetaljer ⚡️ Salg tilladt adgang til kundeservicehistorier uden dokumenteret behov ⚡️ Offentlig Læs/Skriv OWD, der bruges til objekter, der indeholder personlige data |
Mønstre
| Hvor skal du se | Hvad der ser godt ud |
|---|---|
| Hyperforce regionale implementering | ✅ Organisation klargjort i Hyperforce opfylder dataplaceringskrav ✅ Datalagring og -behandling forekommer inden for krævede geografiske grænser ✅ Regionale krav dokumenteret og valideret før klargøring ✅ Krav til flere områder håndteret gennem multi-organisationsarkitektur, hvor det er nødvendigt |
| Dataforløbstilknytning | ✅ Dataforløb tilknytter dokument, hvor data stammer, overføres og findes ✅ Grænseoverskridende dataoverførsler identificeret og evalueret i forhold til bestemmelser ✅ Standardkontraktklausuler eller bindende virksomhedsregler for internationale overførsler ✅ Datatransitstier evalueret for bopælsoverensstemmelse, ikke kun lagerplacering |
| Dataplaceringsomfang | ✅ Placering af datalagring (hvilket Hyperforce) ✅ Databehandlingsplacering (beregningsområder) ✅ Placering af sikkerhedskopilager ✅ Logfør og revisionssporlagringsplacering ✅ Integrationstransitstier evalueret for grænseoverskridende dataflytning |
| Arkitektur med flere organisationer | ✅ Flere organisationsarkitektur, der bruges, når bestemmelseskrav ikke kan opfyldes i en enkelt organisation ✅ Hver organisation klargjort i det rette område for dens data ✅ Integrationsmønstre respekterer begrænsninger for dataplacering ✅ Afvejninger i forbindelse med driftsmæssig kompleksitet, der er dokumenteret i ADR’er |
| Overensstemmelsesvalidering | ✅ Krav til dataplacering dokumenteret efter jurisdiktion ✅ Hyperforce valideret op mod krav før provisionering ✅ Periodiske revisioner bekræfter, at data forbliver inden for de krævede grænser ✅ Ændringer af bopælsbestemmelser udløser arkitekturgennemgang |
Anti-mønstre
| Hvor skal du se | Hvad ser dårligt ud |
|---|---|
| Opholdstilsyn | ⚡️ Dataopholdsovertrædelser fundet under overensstemmelsesrevisioner ⚡️ Organisationer klargjort uden at evaluere regionale krav ⚡️ “Cloud er cloud” antages uden at tage bestemmelser for dataplacering med i betragtning ⚡️ Jurisdiktioner tilføjet uden gennemgang af bopælsforpligtelser |
| Transit ignorerer bopæl | ⚡️ Kun lagerplacering tages med i betragtning, mens transitstier ignoreres Data distribueret gennem områder uden for overensstemmelsesgrænser ⚡️ Integrationsmidderware, der bruges i ikke-kompatible områder ⚡️ Sikkerhedskopier, der er lagret i andre områder end primære data |
| Unødvendig multi-organisation | ⚡️ Flere organisationsarkitektur, der bruges, når en enkelt organisation med Hyperforce er tilstrækkelig ⚡️ Driftskompleksitet, licensomkostninger og integrationsoverhead ganget uden regulerende nødvendighed ⚡️ Flere organisationer implementeret “kun for at være sikre” uden et specifikt overensstemmelseskrav ⚡️ Flerorganisationer bruges som standard, når dataklassificering og adgangskontroller er tilstrækkelige |