Beskyt, opbevar og bevis
Findes også på 28 sprog
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 · Norsk bokmål · Suomi · Español (México) · Français (Canada) · Deutsch (Schweiz)
Modul 6 af 6 i kapitlet Datakvalitet og styring, kapitel 5 i kurset Data Architect. Hvert modul står på egne ben. Forrige: Samtykke og retten til at blive glemt · Næste: det næste kapitel, Masterdata og identitet
Spørgsmålet, dette modul besvarer: Hvordan beskytter du data, opbevarer dem så længe, det kræves, og beviser det?
Vi har fastlagt ejere og politikker, holdt dårlige data ude, skrevet ordbogen, sporet dataoprindelsen, klassificeret det, der betyder noget, lært lovene og modelleret samtykke. Nu skal vi køre det. Data kommer ind, bliver brugt, kopieret og ændret, bliver ældre, og til sidst skal noget af det væk. Og en dag vil nogen spørge: Bevis, hvad der skete.
Styringen følger dataene
Sektion kaldt “Styringen følger dataene ”Jeg tænker ikke på styring som én funktion. Jeg tænker på, hvad der sker med dataene, fra det øjeblik de kommer ind, til vi er færdige med dem:
Indsaml → Klassificér → Beskyt → Brug → Opbevar → Slet → Revidér
Ikke syv tekniske processer: syv spørgsmål, arkitekturen skal besvare. Indsamling og klassifikation har vi dækket: Hold de dyre fejl ude (modul 2), og vid, hvilke data der er følsomme (modul 3). Klassifikationen afgør, hvad der sker på hvert senere trin, så dette modul tager over derfra.
Syv spørgsmål gennem dataenes liv. Værktøjerne understøtter politikken; de definerer den ikke.
Beskyt: tilpas kontrollen til dataene
Sektion kaldt “Beskyt: tilpas kontrollen til dataene ”Hvem kan se dem, ændre dem, modtage dem? Skal de krypteres, maskeres uden for produktion, kunne eksporteres, kunne nås af en agent? Det er her, sikkerheden i Salesforce bliver en del af datastyringen: deling, objekt- og felttilladelser, kryptering, maskering, adgang for integrationer. De emner fylder hele kurser, så dem underviser jeg ikke i igen. Styringspointen: Beskyttelsen følger klassifikationen og politikken. Ikke alle felter har brug for samme beskyttelse, ikke alle brugere samme adgang, ikke alle systemer længere nede i kæden alle felter.
Kryptering er en kontrol, ikke compliance
Sektion kaldt “Kryptering er en kontrol, ikke compliance ”For regulerede data kan kryptering af lagrede data være et krav, og min holdning er, at Shield er svaret på vigtige regulatoriske krav som det. Shield Platform Encryption krypterer felter og filer, mens de er lagret. Men »vi har krypteret det, så vi er compliant« er forkert på to måder. Kryptering er én kontrol blandt adgang, opbevaring, revision, samtykke, overvågning, dataminimering og sletning. Og den har funktionelle afvejninger, som du skal designe efter fra starten. Med standardskemaet, det probabilistiske, kan et krypteret felt ikke bruges i SOQL-klausulerne WHERE, GROUP BY eller ORDER BY eller i filtre til datahåndtering; deterministisk kryptering giver lidt styrke afkald, så du kan filtrere på feltet. Krypterede felter kan ikke styre kriteriebaserede delingsregler, og du kan ikke sortere listevisninger efter dem (General Shield Platform Encryption Considerations (opens in a new tab); Filter Encrypted Data with Deterministic Encryption (opens in a new tab); på engelsk). Så kryptering er ikke et afkrydsningsfelt til sidst. Det er en arkitekturbeslutning. Kapitlet om datasikkerhed går i dybden.
Kopiér ikke produktionens risiko ind i sandboxen
Sektion kaldt “Kopiér ikke produktionens risiko ind i sandboxen ”Produktion er låst ned. Så opdaterer nogen en full sandbox, og udviklere, testere, eksterne konsulenter og testintegrationer har nu kopier af rigtige personoplysninger, som de aldrig havde brug for. Miljøet ændrede sig; dataenes følsomhed gjorde ikke. Salesforces maskeringsværktøjer findes netop til det. Bemærk en ændring: Den administrerede pakke Data Mask når end of service den 31. december 2026, og dens afløser er Data Mask & Seed (Data Mask (Legacy) (opens in a new tab), på engelsk). Men værktøjet understøtter politikken, og spørgsmålet kommer først: Har dette miljø overhovedet brug for rigtige følsomme data? Hvis realistiske, ikke-følsomme data kan klare testen, er det det bedre svar.
Brug: tilladelse handler ikke kun om mennesker
Sektion kaldt “Brug: tilladelse handler ikke kun om mennesker ”Brugere, integrationer, analyser, partnere, automatisering og agenter bruger alle dataene. Samtykke (modul 5), ejerskab (modul 1) og klassifikation (modul 3) mødes her, mens systemet kører. Skal denne bruger se modtagerens telefonnummer? Skal denne integration have det, eller Snowflake, eller denne agent som grounding? Svaret kan ikke være »tja, teknisk set kan den«. Det er forskellen mellem kunnen og styring: Arkitekturen afgør, om den bør.
Opbevar: at gemme alt for evigt er ikke neutralt
Sektion kaldt “Opbevar: at gemme alt for evigt er ikke neutralt ”Mange organisationer har en utilsigtet opbevaringspolitik: for evigt. Ingen besluttede det; der var lagerplads, så dataene blev liggende. Men at gemme data koster lagerplads og ydeevne, øger eksponeringen for databeskyttelse og sikkerhed, giver flere forpligtelser ved fremlæggelse af dokumentation og giver dig flere steder at lede, når nogen beder om at blive glemt. For hver vigtig kategori: Hvorfor gemme dem, hvor længe, hvad starter uret, er der et lovpligtigt minimum eller et maksimum af hensyn til databeskyttelse, og hvad sker der til sidst: arkivere, slette, afidentificere?
Og at arkivere er ikke det samme som at løse opbevaringen. »Vi har arkiveret det.« Forsvandt kravet om opbevaring? Kravet om databeskyttelse? Sikkerheden? Du ændrede, hvor dataene bor, ikke hvad de er. Et arkiv har brug for adgangskontrol, regler for opbevaring og sletning, mulighed for at finde dataene og revision. Flyt personoplysninger ind i et arkiv, som alle glemmer, og styringen er lige blevet dårligere.
Slet: livscyklussen har brug for en udgang
Sektion kaldt “Slet: livscyklussen har brug for en udgang ”Sletning er ikke kun til enkeltpersoners anmodninger om databeskyttelse. Data når slutningen af deres opbevaringsperiode; midlertidige poster overlever deres formål; arkiver udløber; en proces afidentificerer efter en fastsat tid. Uanset hvad politikken siger, har arkitekturen brug for en udgang, ikke indsaml → gem → gem mere → gem for evigt. Og som modul 5 viste, er det ikke nok at slette posten i Salesforce, når der findes kopier andre steder.
Historik er også data
Sektion kaldt “Historik er også data ”Nogle gange er den aktuelle værdi ikke nok. En partners juridiske navn, en kundes klassifikation, en samtykkestatus, en finansiel attribut: Forretningen eller en tilsynsmyndighed kan have brug for at vide, hvad værdien var før, hvornår den ændrede sig, og hvem der ændrede den. Den historik er data, og den har brug for sin egen beslutning om opbevaring.
Standard-felthistorik (field history tracking) følger op til 20 felter pr. objekt og gemmer ændringer i op til 18 måneder, og i op til 24 måneder kun via API’et, med Data Loader eller queryAll() (Field History Tracking Overview (opens in a new tab), på engelsk). Og for lange tekstfelter registrerer den kun, at feltet blev redigeret, ikke hvad der stod i det: et hul, hvis det er din dokumentation. Field Audit Trail, en del af Shield eller købt for sig, følger op til 200 felter pr. objekt og gemmer historikken, indtil du sletter den, i et arkiv, du når via API’et (Field Audit Trail (opens in a new tab), på engelsk). Min holdning: Standard-felthistorik er udgangspunktet; brug Field Audit Trail, når en regel eller en compliance-forpligtelse kræver længere historik, der kan bevises. Ikke fordi »revision lyder godt«.
Revision og overvågning er ikke det samme
Sektion kaldt “Revision og overvågning er ikke det samme ”Felthistorik besvarer spørgsmål om ændringer i udvalgte felter. Bredere spørgsmål (hvem loggede ind, hvem eksporterede data, hvilke API’er blev kaldt, hvem så hvad) er overvågning, og det er Event Monitoring. Efter min erfaring er der typisk brug for det hos mere regulerede kunder, og her er min stærkeste holdning i dette kapitel: Sæt det op, før du har brug for det, og send hændelserne til et lager, for eksempel Splunk eller et andet SIEM, i god tid.
Her er hvorfor. Hændelseslogfiler gemmes i 1 dag uden tilkøbet, og kun for nogle hændelsestyper; 30 dage som standard med Shield eller tilkøbet Event Monitoring, og op til 365 dage, hvis du forlænger opbevaringen (Event Monitoring FAQ (opens in a new tab), på engelsk). Alt, der er ældre, er væk, medmindre du har eksporteret det. Og de betalte logs kan ikke hentes for nogen periode før din kontrakt startede (samme FAQ): At købe tilkøbet efter hændelsen bringer ikke fortiden tilbage. Så en af de værste samtaler, en arkitekt kan have, lyder: »Kan vi se, hvad der skete for seks måneder siden?« »Nej.« »Hvorfor ikke?« »Vi opsamlede det ikke.« Du må ikke løbe ind i et problem og så opdage, at du ikke har opsamlet og gemt de hændelser. Til den tid er svaret simpelthen væk.
Sæt det op, før du har brug for det.
Men sving ikke over i »log alt«. Hvad prøver du at bevise? Hvilke hændelser betyder noget, hvem har brug for dem, hvor længe, hvem må læse logsene, og kan logsene selv indeholde følsomme data? Logning skaber data, og de data har også brug for styring. Og dokumentation har brug for en ejer: Hvem ejer lageret, gennemgår alarmer, tjekker, at opbevaringen virker, opdager, at feedet stille og roligt holdt op med at virke for tre måneder siden? Teknologi uden ejerskab er ikke styring; vi er tilbage ved ejeren, forvalteren og vogteren fra modul 1.
Bevis kontrollen, ikke kun konfigurationen
Sektion kaldt “Bevis kontrollen, ikke kun konfigurationen ”»Modtagerdata er kun tilgængelige for de teams, der er tildelt stoppet.« Hvordan ved vi det? Sikkerhedskonfigurationen viser, hvad der bør ske. Driftsdokumentation (hvem der faktisk tilgik dataene, usædvanlige eksporter, en integration, der trækker dem, ændrede adgangskontroller) viser, hvad der faktisk skete. God styring har ofte brug for begge dele.
Ud over eksamen: hvad AI ændrer. Efterhånden som agenter går fra at svare til at handle, har styringen brug for dokumentation for, hvad agenten så, hvad den besluttede eller genererede, og hvad den gjorde, og hvem eller hvad der startede den, under hvilken politik. Logningsmekanismerne vil ændre sig; kravet vil ikke: Hvis en autonom handling betyder noget, så design nu, hvordan du vil rekonstruere den senere.
Steve Trucking: livscyklussen på ét felt
Sektion kaldt “Steve Trucking: livscyklussen på ét felt ”Tag modtagerens telefonnummer. Indsaml: Det kommer ind på partnerens manifest; tjek, at det er brugbart der, hvor processen har brug for det. Klassificér: personoplysninger. Beskyt: Kun mennesker og systemer med et driftsmæssigt behov modtager det, og teamene ser det kun for deres egne stop, på dagen. Brug: Teamet koordinerer leveringen; beskedsystemet bruger det til et godkendt formål; en agent bruger det kun, hvis politikken tillader det. Opbevar: så længe den godkendte forretnings- og databeskyttelsespolitik siger. Slet eller afidentificér: når den periode slutter, eller en gyldig anmodning kommer, på tværs af hver kopi i landskabet. Revidér: Gem dokumentationen for, at kontrollerne og handlingerne fandt sted.
Tag nu en kode for et distributionscenter. Indsaml den korrekt, klassificér den som ikke-følsomme referencedata, beskyt den med almindelig driftsadgang, brug den bredt, opbevar den, så længe forretningen har brug for det, og revidér ændringer, hvis de betyder noget. Samme livscyklus, forskellige kontroller. Det er det, klassifikation er til.
Styring bliver aldrig færdig
Sektion kaldt “Styring bliver aldrig færdig ”En ny regel dukker op. Et nyt system eller en ny integration skaber endnu en kopi. Et team opfinder endnu et felt. En ny platform går i luften. En agent får adgang. En opbevaringsregel ændres. En ny detailpartner kommer til. Arkitekturen bevæger sig, og styringen bevæger sig med. Målet er ikke perfekte data, uendelige kontroller eller et styringsdokument, ingen læser. Det er bevidste beslutninger om dataene, bygget ind i arkitekturen.
Hvad en arkitekt beslutter her
Sektion kaldt “Hvad en arkitekt beslutter her ”- Hvilke beskyttelseskontroller hver kategori af data får, ud fra klassifikation, politik og faktisk brug, herunder krypteringens afvejninger.
- Hvor længe data og deres historik opbevares, hvad der starter uret, og hvad der sker til sidst.
- Hvornår standard-felthistorik er nok, og hvornår en regel kræver Field Audit Trail.
- Hvilke hændelser der opsamles, hvor dokumentationen gemmes ud over platformens opbevaringsperiode, og hvem der ejer den.
- Hvordan arkitekturen bagefter beviser vigtige handlinger foretaget af mennesker, integrationer og agenter.
Dette kapitel startede med én idé: Styring designes ind i org’en, den skrives ikke ved siden af. Ejerne fastsætter politikken, og arkitekterne håndhæver den. Hold dårlige data ude, hvor det betyder noget. Vid, hvad dine data betyder, hvor de kom fra, og hvor følsomme de er. Respektér lovene, modellér samtykke, styr, hvor personoplysninger havner. Beskyt, opbevar og slet efter politikken. Og opsaml dokumentationen, før nogen beder om den, for seks måneder efter en hændelse er et forfærdeligt tidspunkt at opdage, at dokumentationen kun fandtes i tredive dage.
Læs mere
Sektion kaldt “Læs mere ”- 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, kontrolleret 2026-10-14).
- Salesforce Help, Field History Tracking Overview (opens in a new tab) (på engelsk, kontrolleret 2026-10-14).
- Salesforce Help, Field Audit Trail (opens in a new tab) (på engelsk, kontrolleret 2026-10-14).
- Salesforce Help, Salesforce Event Monitoring Frequently Asked Questions (opens in a new tab) (på engelsk, kontrolleret 2026-10-14).
- Salesforce Help, Secure Your Sandbox Data with Salesforce Data Mask (Legacy) (opens in a new tab) (på engelsk, kontrolleret 2026-10-14).