Databeskyttelsesmønstre
Lær mer om Well-Architected Trust → Databeskyttelse og personvern
Mønstre
| Hvor du kan se | Hvordan det ser bra ut |
|---|---|
| Dataklassifiseringsskjema | ✅ Klassifiseringsskjema dokumentert med nivåer (Felles, Intern, Konfidensiell, Begrenset) ✅ Forretningseksempler oppgitt for hvert klassifiseringsnivå ✅ Klassifiseringsskjema tilpasset lovpålagte forpliktelser (HIPAA, PCI DSS, GDPR) ✅ Datamodellerere opplært til å bruke klassifisering konsekvent under utformingen ✅ Nye felt klassifisert som en del av datamodelleringsprosessen, ikke retroaktivt |
| Klassifisering på feltnivå | ✅ Klassifisering brukt på feltnivå, ikke bare på objektnivå ✅ Felt i ett objekt kan ha forskjellige klassifiseringer ✅ Feltnivåsikkerhet gjenspeiler klassifiseringsforskjeller ✅ Ikke-klassifiserte data er som standard det høyeste riktige beskyttelsesnivået ✅ Klassifisering driver beskyttelseskontroller (kryptering, tilgang, oppbevaring) |
| tilpassede objekter og felt | ✅ Alle tilpassede objekter har dokumentert dataklassifisering ✅ Sensitive felt (lønn, SSN, PHI, betalingsdata) klassifisert som konfidensiell eller begrenset ✅ Felles felt (firmanavn, nettsted) dokumentert som Felles ✅ Klassifiseringsmetadata fanget opp i feltbeskrivelser ✅ Klassifisering gjennomgått under kodegjennomganger og ARB |
| Standardobjekter | ✅ Standard objektfelt evaluert mot klassifiseringsskjema ✅ Shield Platform Encryption aktivert for begrensede standardfelt ✅ Feltnivåsikkerhet brukt på konfidensielle standardfelt ✅ Rapporter og listevisninger filtrert for å hindre eksponering av sensitive standardfelt |
| Integreringsdata | ✅ Data flyter gjennom integrasjoner klassifisert før implementering ✅ Ekstern datasensitivitet evalueres og dokumenteres ✅ Integrasjonsendepunkter som håndterer begrenset databruk, sertifikatbasert godkjenning ✅ Dataklassifisering beholdt på tvers av systemgrenser |
| Samsvarstilordning | ✅ HIPAA PHI-felt identifisert og merket Begrenset ✅ PCI-kortholderdata unngås i Salesforce der det er mulig – tokenisert via betalingsgateway for omfangsreduksjon, og der de må lagres, bruker du krypterte tilpassede felt under PCI DSS-kontroller ✅ Personlige GDPR-data identifisert og underlagt personvernkontroller ✅ SOX-økonomiske data klassifisert og underlagt oppgavesegregering |
Anti-Mønstre
| Hvor du kan se | Hvordan dårlig ser ut |
|---|---|
| Ensartet beskyttelse | ⚡️ Samme beskyttelse brukt på alle felt uavhengig av sensitivitet ⚡️ Data med lav verdi overbeskyttet (bruke ressurser) mens data med høy verdi er underbeskyttet ⚡️ Offentlig firmainformasjon behandles på samme måte som PHI- eller betalingskortdata ⚡️ Hvert felt er kryptert “bare for å være sikker” uten klassifiseringsbegrunnelse |
| Retroaktiv klassifisering | ⚡️ Data klassifisert etter distribusjon til produksjon ⚡️ Sensitive data oppdaget via samsvarsrevisjoner i stedet for utformingsgjennomganger ⚡️ Data klassifisert bare etter sikkerhetshendelser ⚡️ “Vi finner ut av klassifisering senere” er standardverdien under utvikling |
| Klassifisering bare på objektnivå | ⚡️ Hele objekter klassifisert jevnt når felt har forskjellig følsomhet ⚡️ Tilgang på objektnivå gitt uten feltnivåsikkerhet for sensitive felt ⚡️ Alle felt i Konto- eller Kontakt-objekter antas å ha samme klassifisering ⚡️ Objekttillatelser som brukes som eneste tilgangskontroll for objekter med blandet følsomhet |
| Tribal Knowledge | ⚡️ Klassifisering udokumentert, eksisterer bare i nøkkelpersons Knowledge ⚡️ Utviklere stolte på å “bare vite” hvilke felt som er sensitive ⚡️ Intet skriftlig klassifiseringsskjema tilgjengelig for alle datamodellerere ⚡️ Nye teammedlemmer i gang uten klassifiseringsopplæring |
Mønstre
| Hvor du kan se | Hvordan det ser bra ut |
|---|---|
| Kryptering under lagring | ✅ Alle data kryptert på infrastrukturnivå via Hyperforce ✅ Shield Platform Encryption aktivert for begrensede data ✅ Krypteringsskjema (sannsynlighets-, deterministisk-, deterministisk) valgt basert på spørrings- og unikhetskrav ✅ Krypteringsavveininger evaluert under datamodellutforming |
| Strategi for Shield Platform Encryption | ✅ Sannsynlighetskryptering brukt for de fleste Begrensede felt (støtter alle spørringsoperasjoner) ✅ Deterministisk kryptering brukt for felt som krever exact-match WHERE-setninger eller unikhet ✅ Deterministisk som skiller mellom små og store bokstaver, brukt der sakskilletegn er viktig for forretningslogikk ✅ Virkemåte for kryptert felt testet før produksjonsdistribusjon ✅ Formelfeltreferanser til krypterte felt som håndteres riktig (flyttet til Apex hvis det er nødvendig) |
| Nøkkeladministrasjon | ✅ Nøkkelrotasjonsprosedyrer dokumentert og automatisert ✅ Viktige ødeleggelsesscenarier som er testet under gjenopprettingsøvelser ved katastrofer ✅ Kundeadministrerte nøkler (BYOK) evaluert for samsvar som krever eksplisitt nøkkelkontroll ✅ Viktige opphevingsprosedyrer dokumentert ✅ Livssyklus for krypteringsnøkkel administrert i henhold til samsvarskrav |
| Kryptering underveis | ✅ TLS 1.2 eller høyere kreves for alle integrasjoner ✅ Sertifikatbasert gjensidig godkjenning for integrasjoner som håndterer begrensede data ✅ HSTS-hoder konfigurert for Experience Cloud-nettsteder for å hindre nedgradering av protokoller ✅ TLS-sertifikatutløp overvåket og automatisk fornyelse konfigurert ✅ Svake krypteringer og protokoller deaktivert |
| Kode og konfigurasjon | ✅ Legitimasjon som aldri er innebygd i kode, konfigurasjonsfiler eller versjonskontroll ✅ Navngivne legitimationsoplysninger og eksterne legitimationsoplysninger, der bruges til at administrere godkendelse centralt ✅ Legitimasjonsrotasjonsfunksjonalitet innebygd i arkitektur ✅ Abstrakt godkjenning av navngitt legitimasjon fra kode, aktivering av oppdateringer uten kodeendringer |
| AppExchange | ✅ Pakkesikkerhetskrav evaluert før installering ✅ Krypterte felt som er tilgjengelig for pakker bare når det er forretningsbegrunnet ✅ Pakkedatatilgangsmønstre overvåket via Hendelsesovervåking ✅ Pakker som krever tilgang til begrensede data som er underlagt forbedret gjennomgang |
Anti-Mønstre
| Hvor du kan se | Hvordan dårlig ser ut |
|---|---|
| Kryptering uten evaluering | ⚡️ Sannsynlighetskryptering aktivert for alle felt uten testing ⚡️ Kritiske rapporter som finnes i produksjonsorganisasjonen, mislykkes fordi krypterte felt ikke kan aggregeres ⚡️ Kryptering aktivert for formelfeltkilder uten innvirkning på forståelse ⚡️ Felt som brukes i SOQL LIKE-spørringer, kryptert uten å bytte til deterministisk kryptering |
| Innebygd legitimasjon | ⚡️ Legitimasjon innebygd i kode, tilpassede innstillinger eller versjonskontroll ⚡️ API-nøkler, passord og sertifikater hardkodet i Apex ⚡️legitimasjon som er bekreftet til kildekontrolloppbevaringssteder ⚡️Påloggingsinformasjon lagret i tilpassede metadata eller tilpassede innstillinger uten kryptering |
| Svake eller eldre protokoller | ⚡️ TLS 1.0 eller 1.1 godtatt (foreldet og sårbar) ⚡️ OAuth-flyt for brukernavn-passord tillatt når JWT-bæreren er tilgjengelig ⚡️ Egensignerte sertifikater godtatt i produksjonsintegrasjoner ⚡️ Sertifikatvalidering deaktivert “for å få integrasjonen til å fungere” |
| Ingen nøkkeladministrasjon | ⚡️ Shield Platform Encryption aktivert uten nøkkelrotasjonsprosedyrer ⚡️ Ingen dokumenterte nøkkelødeleggelsesscenarier ⚡️ Standardnøkler som brukes uten å evaluere kundestyrte nøkler for samsvar ⚡️ Nøkkelrotasjons- og opphevingsprosedyrer som aldri er testet |
| Overkryptering | ⚡️ Offentlige eller interne klassifiseringsdata kryptert, som legger til kostnad uten fordel ⚡️ Shield Platform Encryption aktivert på alle felt, noe som skaper unødvendig kompleksitet ⚡️ BYOK brukt når samsvar ikke krever det (legger til operasjonell overhead) ⚡️ Kryptering er obligatorisk der dataklassifisering ikke berettiger det |
Mønstre
| Hvor du kan se | Hvordan det ser bra ut |
|---|---|
| Sandbox-strategi | ✅ Begrensede data kommer aldri inn i utviklings- eller testmiljøer ✅ Delvis Sandbox-kopiering utelukker Begrensede objekter og felt ✅ Sandbox-maler definerer hvilke objekter og felt som skal inkluderes etter miljøtype ✅ Data Mask konfigurert for Sandbox-organisasjoner som krever produksjonsliknende data |
| Data Mask | ✅ Data Mask skjule sensitive felt samtidig som dataegenskaper beholdes ✅ Mønstre opprettholder referanseintegritet (samme inndata produserer samme maskerte utdata) ✅ E-postadresser maskeres, men forblir gyldig format for testing ✅ Telefonnumre maskeres, men beholdes i gyldig format ✅ Datoer skiftet konsistent ved å opprettholde relative relasjoner ✅ Tallfelt som er randomisert innenfor realistiske områder |
| Syntetiske data | ✅ Utviklingsmiljøer bruker generering av syntetiske data ✅ Syntetiske data har realistiske egenskaper som muliggjør effektiv testing ✅ Ingen produksjonsdata som er nødvendig for utvikling ✅ Teste datagenerering automatisert i utvikling under behandling |
| Ikke-produksjonsmiljøer | ✅ Produksjonsdata som aldri kopieres til personlige utviklerorganisasjoner ✅ Skjermbilder og demonstrasjoner med maskerte eller syntetiske data ✅ Opplæringsmiljøer bruker syntetiske data eller mye maskerte produksjonsdata ✅ Kontraktør- og leverandørtilgang til ikke-produksjonsdata begrenset til klassifisering bare for forretningsbruk |
Anti-Mønstre
| Hvor du kan se | Hvordan dårlig ser ut |
|---|---|
| Produksjonsdata i Sandbox-organisasjoner | ⚡️ Fullstendige Sandbox-organisasjoner oppdatert med maskerte produksjonsdata for utvikling ⚡️ Begrensede data kopiert til Developer-Sandbox-organisasjoner for å gjøre det enklere ⚡️ Utviklere gitt bred tilgang til Sandbox-organisasjoner for produksjonsdata ⚡️ Sandbox-organisasjoner oppdatert med sensitive data “fordi testing er enklere med ekte data” |
| Ingen syntetiske data | ⚡️ Produksjonsdata basert bare på alle tester ⚡️ Ingen generering av syntetiske data for utviklingsmiljøer ⚡️ “Vi trenger ekte data” antatt uten å evaluere syntetiske alternativer ⚡️ Manuelle testdata opprettet når generering kan automatiseres |
Mønstre
| Hvor du kan se | Hvordan det ser bra ut |
|---|---|
| Dataminimering | ✅ Bare data som er nødvendige for angitte forretningsformål, innhentet ✅ Hvert felttilføjelse udfordres med “hvilken arkitektonisk beslutning kræver disse data?” ✅ Data som ikke lenger betjener samlingsformålet, fjernet ✅ Valgfrie felt er tydelig merket og ikke nødvendig uten forretningsbegrunnelse ✅ Historisk dataoppbevaring justert etter juridisk grunnlag, ikke “behold alt for alltid” |
| Begrensning av formål | ✅ Tillatelsessett begrenser datatilgang basert på jobbfunksjonsformål ✅ Markedsføringsbrukere får ikke tilgang til kundestøttesaksdetaljer uten dokumentert begrunnelse ✅ Salgsbrukere får ikke tilgang til kundeservicehistorier med mindre jobb krever det ✅ Tilgang til data på tvers av funksjoner krever eksplisitt godkjenning og overvåking ✅ Formål med datatilgang dokumentert i tillatelsessettbeskrivelser |
| Samtykkebehandling | ✅ Samtykke innhentet på individuelt nivå for markedsføring, analyse, valgfri behandling ✅ Samtykke er detaljert (formespesifikt), ikke binært samtykke ✅ Arbeidsflyter for oppheving av samtykke overføres på tvers av integrerte systemer ✅ Samtykkebeslutninger sporet med tidsstempel, versjon og mekanisme ✅ Samtykke-grensesnittet forklarer tydelig hva brukeren samtykker til |
| registrertes rettigheter | ✅ Arbeidsflyter for tilgangsforespørsler sørger for datakopier innen tidsfristen som de aktuelle forskriftene angir for distribusjonen ✅ Rettelsesarbeidsflyter korrigerer unøyaktigheter med revisjonsspor ✅ Slettingsarbeidsflyter sletter data der det er juridisk tillatt (med tanke på oppbevaringsforpliktelser) ✅ Portability-arbeidsflyter eksporterer data i maskinlesbart format ✅ Arbeidsflyter for registrertes rettigheter som testes regelmessig for å validere tidslinjer ✅ Arbeidsflytautomatisering sikrer konsekvent oppfyllelse av lovpålagte tidslinjer |
| Personvernkontroller | ✅ Personvernkontroller håndheves teknisk, ikke bare via policy ✅ Begrensning av formål implementert for delingsregler ✅ Feltnivåsikkerhet beskytter sensitive attributter ✅ Revisjonsspor fanger opp personvernrelevante hendelser ✅ Personvernkontroller validert i CI/CD pipelines |
Anti-Mønstre
| Hvor du kan se | Hvordan dårlig ser ut |
|---|---|
| Innhent alt | ⚡️ Tilnærmingen “Samle alle mulige data, vi trenger dem kanskje en dag” ⚡️ Felt lagt til uten dokumentert forretningsformål ⚡️ Data beholdt på ubestemt tid uten oppbevaring ⚡️ Valgfrie data som samles inn ved å gjøre felt nødvendige |
| Totalsamtykke | ⚡️ Enkelt “godta vilkår” samtykke for alle formål ⚡️ Markedsføringssamtykke kombinert med levering av tjenester i en enkelt avmerkingsboks ⚡️ Samtykke gjort alt eller ingenting når formål kan skilles ⚡️ Samtykke begravet i 20-siders vilkår og betingelser |
| Policy without enforcement (policy uten håndheving) | ⚡️ Personvernpolicy beskriver ideelle fremgangsmåter som ikke håndheves teknisk ⚡️ Brukeropplæring som brukes til å hindre upassende datatilgang ⚡️ Personvernprinsipper dokumentert uten å implementere tekniske kontroller ⚡️ Policysamsvar antas uten overvåking og validering |
| Manuelle forespørsler fra datatilfeller | ⚡️ GDPR/CCPA-forespørsler som håndteres via manuelle IT-billetter som tar måneder ⚡️ Ingen dokumenterte prosedyrer for tilgang, rettelse, sletting og portabilitet ⚡️ Forespørselsfullføring-vinduet som de regulerende forskriftene angir for distribusjonen, mangler ⚡️ Be om at arbeidsflyter som ble funnet under revisjoner, ikke finnes |
| Overdreven datadeling | ⚡️ Bred datatilgang gitt på tvers av avdelinger uten begrunnelse for formål ⚡️ Markedsføring tillatt tilgang til kundestøttesaksdetaljer ⚡️ Salg tillatte tilgang til kundeservicehistorier uten dokumentert behov ⚡️ Felles lese/skrive OWD brukt for objekter som inneholder personlige data |
Mønstre
| Hvor du kan se | Hvordan det ser bra ut |
|---|---|
| Hyperforce regional distribusjon | ✅ Organisasjon klargjort i Hyperforce oppfyller kravene til dataoppbevaring ✅ Datalagring og behandling skjer innenfor nødvendige geografiske grenser ✅ Regionale krav dokumentert og validert før klargjøring ✅ Krav til flere områder, løst via flerorganisasjonsarkitektur der det er nødvendig |
| Dataflyttilordning | ✅ Dataflyttilordner dokumenter der data kommer fra, går over og befinner seg ✅ Grenseoverskridende dataoverføringer identifisert og evaluert i henhold til forskrifter ✅ Standardkontraktsvilkår eller bindende firmaregler for internasjonale overføringer ✅ Datatrafikkbaner evaluert for overholdelse av krav om opphold, ikke bare lagringssted |
| Omfang for dataoppbevaring | ✅ Datalagringssted (hvilket Hyperforce) ✅ Databehandlingssted (beregne områder) ✅ Sikkerhetslagringssted ✅ Lagringssted for logg- og revisjonsspor ✅ Integrasjonsbaner evaluert for grenseoverskridende dataflyt |
| Arkitektur for flere organisasjoner | ✅ Arkitektur for flere organisasjoner brukt når lovpålagte krav ikke kan oppfylles i én organisasjon ✅ Hver organisasjon klargjort i riktig område for sine data ✅ Integrasjonsmønstre tar hensyn til begrensninger for dataoppbevaring ✅ Avveining av operasjonell kompleksitet dokumentert i ADR-er |
| Samsvarvalidering | ✅ Krav til dataopphold dokumentert etter jurisdiksjon ✅ Hyperforce validert mot krav før klargjøring ✅ Periodiske revisjoner bekrefter at data forblir innenfor nødvendige grenser ✅ Endringer i oppholdsforskrifter utløser gjennomgang av arkitektur |
Anti-Mønstre
| Hvor du kan se | Hvordan dårlig ser ut |
|---|---|
| Residensovervåking | ⚡️ Dataoppholdsbrudd oppdaget under samsvarsrevisjoner ⚡️ Organisasjoner klargjort uten å evaluere regionale krav ⚡️ “Cloud er sky” antatt uten å vurdere datastedforskrifter ⚡️ Jurisdiksjoner lagt til uten å gå gjennom oppholdsforpliktelser |
| Transport ignorere opphold | ⚡️ Bare lagringsplassering vurderes når transportbaner ignoreres ⚡️ Data rutet gjennom områder utenfor samsvarsgrenser ⚡️ Integrasjonsmidlervare brukt i ikke-samsvarende områder ⚡️ Sikkerhetskopier lagret i andre områder enn primærdata |
| Unødvendig flerorganisasjon | ⚡️ Arkitektur for flere organisasjoner brukt når en enkelt organisasjon med Hyperforce er tilstrekkelig ⚡️ Driftskompleksitet, lisenskostnader og integrasjonsoverhead multiplisert uten regulatorisk nødvendighet ⚡️ Flere organisasjoner implementert “bare for å være trygge” uten et spesifikt samsvarskrav ⚡️ Flere organisasjoner som brukes som standard når dataklassifisering og tilgangskontroller er tilstrekkelige |