Beskytt, oppbevar og bevis
Finnes også på 28 språk
English · Español · 日本語 · Português (Brasil) · Français · Deutsch · Italiano · 한국어 · 简体中文 · Português (Portugal) · 繁體中文 · Bahasa Indonesia · Türkçe · Polski · Tiếng Việt · ไทย · Nederlands · العربية · עברית · Українська · हिन्दी · Русский · Svenska · Dansk · Suomi · Español (México) · Français (Canada) · Deutsch (Schweiz)
Modul 6 av 6 i kapitlet Datakvalitet og styring, kapittel 5 i kurset Data Architect. Hver modul står på egne ben. Forrige: Samtykke og retten til å bli glemt · Neste: neste kapittel, Masterdata og identitet
Spørsmålet denne modulen besvarer: Hvordan beskytter du data, oppbevarer dem så lenge det kreves, og beviser det?
Vi har satt eiere og policyer, holdt dårlige data ute, skrevet ordboken, sporet opphavet, klassifisert det som betyr noe, lært lovene og modellert samtykke. Nå må vi drifte det. Data kommer inn, blir brukt, kopiert og endret, blir eldre, og til slutt må noe av dem bort. Og en dag kommer noen til å spørre: bevis hva som skjedde.
Styringen følger dataene
Section titled “Styringen følger dataene ”Jeg tenker ikke på styring som én funksjon. Jeg tenker på hva som skjer med dataene fra de kommer inn til vi er ferdige med dem:
Fange inn → Klassifisere → Beskytte → Bruke → Oppbevare → Slette → Revidere
Ikke sju tekniske prosesser: sju spørsmål arkitekturen må svare på. Innfanging og klassifisering har vi dekket: hold de dyre feilene ute (modul 2), og vit hvilke data som er sensitive (modul 3). Klassifiseringen avgjør hva som skjer på hvert senere trinn, så denne modulen tar det derfra.
Sju spørsmål gjennom dataenes liv. Verktøyene støtter policyen; de definerer den ikke.
Beskytte: tilpass kontrollen til dataene
Section titled “Beskytte: tilpass kontrollen til dataene ”Hvem kan se dem, endre dem, motta dem? Bør de krypteres, maskeres utenfor produksjon, kunne eksporteres, kunne nås av en agent? Det er her sikkerheten i Salesforce blir en del av datastyringen: deling, objekt- og felttillatelser, kryptering, maskering, integrasjonstilgang. De temaene fyller hele kurs, så jeg lærer dem ikke bort på nytt her. Styringspoenget: beskyttelsen følger klassifiseringen og policyen. Ikke hvert felt trenger samme beskyttelse, ikke hver bruker samme tilgang, ikke hvert system lenger ned i kjeden hvert felt.
Kryptering er en kontroll, ikke etterlevelse
Section titled “Kryptering er en kontroll, ikke etterlevelse ”For regulerte data kan kryptering av lagrede data være påkrevd, og mitt standpunkt er at Shield er svaret på sentrale regulatoriske krav som det. Shield Platform Encryption krypterer felt og filer der de er lagret. Men «vi krypterte det, så vi etterlever regelverket» er feil på to måter. Kryptering er én kontroll blant tilgang, oppbevaring, revisjon, samtykke, overvåking, dataminimering og sletting. Og den har funksjonelle avveininger du designer for på forhånd. Med standardskjemaet, probabilistisk kryptering, kan et kryptert felt ikke brukes i SOQL-ledd som WHERE, GROUP BY eller ORDER BY, eller i filtre for datahåndtering; deterministisk kryptering gir fra seg litt styrke slik at du kan filtrere på feltet. Krypterte felt kan ikke styre kriteriebaserte delingsregler, og du kan ikke sortere listevisninger etter dem (General Shield Platform Encryption Considerations (opens in a new tab); Filter Encrypted Data with Deterministic Encryption (opens in a new tab)). Så kryptering er ikke en avkrysningsboks på slutten. Det er en arkitekturbeslutning. Kapitlet om datasikkerhet går dypere.
Ikke kopier produksjonsrisikoen inn i sandkassen
Section titled “Ikke kopier produksjonsrisikoen inn i sandkassen ”Produksjon er låst ned. Så oppdaterer noen en full sandkasse, og utviklere, testere, innleide konsulenter og testintegrasjoner har nå kopier av ekte personopplysninger de aldri trengte. Miljøet endret seg; sensitiviteten til dataene gjorde det ikke. Maskeringsverktøyene i Salesforce finnes nettopp for dette. Merk en endring: den administrerte pakken Data Mask når slutten av levetiden (end of service) 31. desember 2026, og etterfølgeren er Data Mask & Seed (Data Mask (Legacy) (opens in a new tab)). Men verktøyet støtter policyen, og spørsmålet kommer først: trenger dette miljøet ekte sensitive data i det hele tatt? Hvis realistiske, ikke-sensitive data kan gjøre testjobben, er det det bedre svaret.
Bruke: tillatelse handler ikke bare om mennesker
Section titled “Bruke: tillatelse handler ikke bare om mennesker ”Brukere, integrasjoner, analyse, partnere, automatisering og agenter bruker alle dataene. Samtykke (modul 5), eierskap (modul 1) og klassifisering (modul 3) møtes her mens systemet kjører. Skal denne brukeren se mottakerens telefonnummer? Skal denne integrasjonen få det, eller Snowflake, eller denne agenten som grounding? Svaret kan ikke være «tja, teknisk sett kan den det». Det er forskjellen mellom evne og styring: arkitekturen avgjør om den bør.
Oppbevare: å ta vare på alt for alltid er ikke nøytralt
Section titled “Oppbevare: å ta vare på alt for alltid er ikke nøytralt ”Mange organisasjoner har en tilfeldig oppbevaringspolicy: for alltid. Ingen bestemte det; lagringsplassen var der, så dataene ble liggende. Men å ta vare på data koster lagring og ytelse, øker eksponeringen for personvern og sikkerhet, gir flere plikter ved bevisinnhenting, og gir deg flere steder å lete når noen ber om å bli glemt. For hver viktig kategori: hvorfor ta vare på den, hvor lenge, hva starter klokken, finnes det et lovpålagt minimum eller et personvernmaksimum, og hva skjer ved slutten: arkivere, slette, avidentifisere?
Og arkivering er ikke det samme som å løse oppbevaringen. «Vi arkiverte det.» Forsvant oppbevaringskravet? Personvernkravet? Sikkerheten? Du endret hvor dataene bor, ikke hva de er. Et arkiv trenger tilgangskontroll, regler for oppbevaring og sletting, mulighet for søk og revisjon. Flytt personopplysninger inn i et arkiv alle glemmer, og styringen ble bare verre.
Slette: livssyklusen trenger en utgang
Section titled “Slette: livssyklusen trenger en utgang ”Sletting er ikke bare for enkeltpersoners personvernforespørsler. Data når slutten av oppbevaringstiden; midlertidige poster lever lenger enn bruken sin; arkiver utløper; en prosess avidentifiserer etter en fastsatt tid. Uansett hva policyen sier, trenger arkitekturen en utgang, ikke fange inn → lagre → lagre mer → lagre for alltid. Og som modul 5 viste, er det ikke nok å slette posten i Salesforce når kopier bor andre steder.
Historikk er også data
Section titled “Historikk er også data ”Noen ganger er ikke den nåværende verdien nok. En partners juridiske navn, en kundes klassifisering, en samtykkestatus, et økonomisk attributt: virksomheten eller en tilsynsmyndighet kan trenge å vite hva det var før, når det ble endret og hvem som endret det. Den historikken er data, og den trenger sin egen beslutning om oppbevaring.
Standard sporing av felthistorikk følger opptil 20 felt per objekt og tar vare på endringer i opptil 18 måneder, og opptil 24 måneder bare gjennom API-et, med Data Loader eller queryAll() (Field History Tracking Overview (opens in a new tab)). Og for lange tekstfelt registrerer den bare at feltet ble redigert, ikke hva det sto: et hull hvis det er dokumentasjonen din. Field Audit Trail, en del av Shield eller kjøpt for seg, følger opptil 200 felt per objekt og tar vare på historikken til du sletter den, i et arkiv du når gjennom API-et (Field Audit Trail (opens in a new tab)). Mitt standpunkt: standard felthistorikk er utgangspunktet; bruk Field Audit Trail når et regelverk eller en compliance-forpliktelse krever lengre historikk som kan bevises. Ikke fordi «revisjon høres bra ut».
Revisjon og overvåking er ikke det samme
Section titled “Revisjon og overvåking er ikke det samme ”Felthistorikk svarer på spørsmål om endringer i utvalgte felt. Bredere spørsmål (hvem logget inn, hvem eksporterte data, hvilke API-er ble kalt, hvem så hva) er overvåking, og det er Event Monitoring. Etter min erfaring trengs det typisk hos mer regulerte kunder, og her er mitt sterkeste standpunkt i dette kapitlet: sett det opp før du trenger det, og send hendelsene inn i et lager, som Splunk eller en annen SIEM, i god tid.
Her er grunnen. Hendelsesloggfiler oppbevares i 1 dag uten tilleggsproduktet, og bare for noen hendelsestyper; 30 dager som standard med Shield eller tilleggsproduktet Event Monitoring, og opptil 365 dager hvis du utvider oppbevaringen (Event Monitoring FAQ (opens in a new tab)). Alt som er eldre, er borte med mindre du eksporterte det. Og de betalte loggene kan ikke hentes for noen periode før kontrakten din startet (samme FAQ): å kjøpe tilleggsproduktet etter hendelsen bringer ikke fortiden tilbake. Så en av de verste samtalene en arkitekt kan ha, går slik: «Kan vi se hva som skjedde for seks måneder siden?» «Nei.» «Hvorfor ikke?» «Vi fanget det ikke opp.» Du vil ikke støte på et problem og så finne ut at du ikke har fanget opp og lagret de hendelsene. Da er svaret rett og slett borte.
Sett det opp før du trenger det.
Men ikke sving over til «logg alt». Hva prøver du å bevise? Hvilke hendelser betyr noe, hvem trenger dem, hvor lenge, hvem kan lese loggene, og kan loggene selv inneholde sensitive data? Logging skaper data, og de dataene trenger også styring. Og dokumentasjonen trenger en eier: hvem eier lageret, går gjennom varslene, sjekker at oppbevaringen virker, legger merke til at strømmen stille sluttet å virke for tre måneder siden? Teknologi uten eierskap er ikke styring; vi er tilbake ved eieren, forvalteren og forvareren fra modul 1.
Bevis kontrollen, ikke bare konfigurasjonen
Section titled “Bevis kontrollen, ikke bare konfigurasjonen ”«Mottakerdata er bare tilgjengelige for teamene som er tildelt stoppet.» Hvordan vet vi det? Sikkerhetskonfigurasjonen viser hva som bør skje. Operativ dokumentasjon (hvem som faktisk åpnet dataene, uvanlige eksporter, en integrasjon som henter dem, endrede tilgangskontroller) viser hva som faktisk skjedde. God styring trenger ofte begge.
Utover eksamen: hva KI endrer. Etter hvert som agenter går fra å svare til å handle, trenger styringen dokumentasjon på hva agenten så, hva den bestemte eller genererte, og hva den gjorde, og hvem eller hva som startet den, under hvilken policy. Loggingsmekanismene vil endre seg; kravet vil ikke det: hvis en autonom handling betyr noe, design nå hvordan du skal rekonstruere den senere.
Steve Trucking: livssyklusen på ett felt
Section titled “Steve Trucking: livssyklusen på ett felt ”Ta mottakerens telefonnummer. Fange inn: det kommer inn på partnerens manifest; sjekk at det er brukbart der prosessen trenger det. Klassifisere: personopplysning. Beskytte: bare mennesker og systemer med et operativt behov mottar det, og teamene ser det bare for sine egne stopp, den dagen. Bruke: teamet koordinerer leveringen; meldingstjenesten bruker det til et godkjent formål; en agent bruker det bare hvis policyen tillater det. Oppbevare: så lenge den godkjente forretnings- og personvernpolicyen sier. Slette eller avidentifisere: når den perioden er over eller en gyldig forespørsel kommer, i hver kopi i landskapet. Revidere: ta vare på dokumentasjonen på at kontrollene og tiltakene ble utført.
Ta så en kode for distribusjonssenter. Fang den inn nøyaktig, klassifiser den som ikke-sensitive referansedata, beskytt den med vanlig operativ tilgang, bruk den bredt, oppbevar den så lenge virksomheten trenger, og revider endringer hvis de betyr noe. Samme livssyklus, forskjellige kontroller. Det er det klassifisering er til for.
Styring blir aldri ferdig
Section titled “Styring blir aldri ferdig ”Et nytt regelverk dukker opp. Et nytt system eller en ny integrasjon lager enda en kopi. Et team finner på enda et felt. En ny plattform settes i drift. En agent får tilgang. En oppbevaringsregel endres. En ny detaljhandelspartner kommer til. Arkitekturen beveger seg, og styringen beveger seg med den. Målet er ikke perfekte data, uendelig mange kontroller eller et styringsdokument ingen leser. Det er bevisste beslutninger om dataene, bygd inn i arkitekturen.
Hva en arkitekt bestemmer her
Section titled “Hva en arkitekt bestemmer her ”- Hvilke beskyttelseskontroller hver kategori data får, basert på klassifisering, policy og faktisk bruk, inkludert krypteringens avveininger.
- Hvor lenge data og historikken deres oppbevares, hva som starter klokken, og hva som skjer ved slutten.
- Når standard felthistorikk er nok, og når et regelverk krever Field Audit Trail.
- Hvilke hendelser som fanges opp, hvor dokumentasjonen lagres utover plattformens oppbevaringstid, og hvem som eier den.
- Hvordan arkitekturen i ettertid beviser viktige handlinger utført av mennesker, integrasjoner og agenter.
Dette kapitlet startet med én idé: styring designes inn i orgen, den skrives ikke ved siden av. Eierne setter policyen, og arkitektene håndhever den. Hold dårlige data ute der det betyr noe. Vit hva dataene dine betyr, hvor de kom fra og hvor sensitive de er. Respekter lovene, modeller samtykke, kontroller hvor personopplysningene havner. Beskytt, oppbevar og slett etter policy. Og fang opp dokumentasjonen før noen ber om den, for seks måneder etter en hendelse er et forferdelig tidspunkt å oppdage at dokumentasjonen bare fantes i tretti dager.
Les mer
Section titled “Les mer ”- Salesforce Help, General Shield Platform Encryption Considerations (opens in a new tab) og Filter Encrypted Data with Deterministic Encryption (opens in a new tab), på engelsk, kontrollert 2026-10-14.
- Salesforce Help, Field History Tracking Overview (opens in a new tab), på engelsk, kontrollert 2026-10-14.
- Salesforce Help, Field Audit Trail (opens in a new tab), på engelsk, kontrollert 2026-10-14.
- Salesforce Help, Salesforce Event Monitoring Frequently Asked Questions (opens in a new tab), på engelsk, kontrollert 2026-10-14.
- Salesforce Help, Secure Your Sandbox Data with Salesforce Data Mask (Legacy) (opens in a new tab), på engelsk, kontrollert 2026-10-14.