Skydda, bevara och bevisa

🌐 Finns även 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 · العربية · עברית · Українська · हिन्दी · Русский · Dansk · Norsk bokmål · Suomi · Español (México) · Français (Canada) · Deutsch (Schweiz)

Bilden är skapad med AI

Översatt med AI. Gemenskapen har inte granskat översättningen än. Läs på engelska

Modul 6 av 6 i kapitlet Datakvalitet och styrning, kapitel 5 i kursen Data Architect. Varje modul står på egna ben. Föregående: Samtycke och rätten att bli bortglömd · Nästa: nästa kapitel, Masterdata och identitet

Frågan den här modulen besvarar: Hur skyddar du data, sparar dem så länge som krävs och bevisar det?

Vi har utsett ägare och satt policyer, hållit dåliga data ute, skrivit ordlistan, spårat härkomsten, klassificerat det som spelar roll, lärt oss lagarna och modellerat samtycke. Nu måste vi driva det. Data kommer in, används, kopieras och ändras, åldras, och till slut måste en del av dem bort. Och en dag kommer någon att säga: bevisa vad som hände.

Styrningen följer data

Jag tänker inte på styrning som en enda funktion. Jag tänker på vad som händer med data från det ögonblick de kommer in tills vi är klara med dem:

Fånga → Klassificera → Skydda → Använda → Bevara → Radera → Granska

Inte sju tekniska processer: sju frågor som arkitekturen måste besvara. Att fånga och klassificera har vi gått igenom: håll de dyra felen ute (modul 2), och vet vilka data som är känsliga (modul 3). Klassificeringen avgör vad som händer i varje senare steg, så den här modulen tar vid där.

Click to enlarge

Sju frågor genom datas livstid. Verktygen stöder policyn; de definierar den inte.

Skydda: anpassa kontrollen efter data

Vem kan se dem, ändra dem, ta emot dem? Ska de krypteras, maskeras utanför produktion, gå att exportera, vara nåbara för en agent? Det är här säkerheten i Salesforce blir en del av datastyrningen: delning, behörigheter på objekt och fält, kryptering, maskering, åtkomst för integrationer. De ämnena fyller hela kurser, så jag lär inte ut dem igen. Poängen för styrningen: skyddet följer klassificeringen och policyn. Alla fält behöver inte samma skydd, alla användare inte samma åtkomst, alla system längre ned i kedjan inte varje fält.

Kryptering är en kontroll, inte regelefterlevnad

För reglerade data kan kryptering i vila krävas, och min hållning är att Shield är svaret på viktiga regulatoriska krav som det. Shield Platform Encryption krypterar fält och filer i vila. Men ”vi krypterade det, så vi följer reglerna” är fel på två sätt. Kryptering är en kontroll bland åtkomst, lagringstid, granskning, samtycke, övervakning, minimering och radering. Och den har funktionella avvägningar som du designar för från början. Med standardschemat, probabilistisk kryptering, kan ett krypterat fält inte användas i SOQL-satserna WHERE, GROUP BY eller ORDER BY eller i filter för datahantering; deterministisk kryptering ger upp lite styrka så att du kan filtrera på fältet. Krypterade fält kan inte styra kriteriebaserade delningsregler, och du kan inte sortera listvyer efter dem (General Shield Platform Encryption Considerations (opens in a new tab); Filter Encrypted Data with Deterministic Encryption (opens in a new tab)). Så kryptering är ingen kryssruta i slutet. Det är ett arkitekturbeslut. Kapitlet om datasäkerhet går djupare.

Kopiera inte produktionens risk till sandboxen

Produktionen är låst. Sedan uppdaterar någon en full sandbox, och utvecklare, testare, konsulter och testintegrationer har nu kopior av riktiga personuppgifter som de aldrig behövde. Miljön ändrades; datas känslighet gjorde det inte. Maskeringsverktygen i Salesforce finns precis för det här. Notera en ändring: det hanterade paketet Data Mask når slutet av sin supportperiod den 31 december 2026, och efterföljaren är Data Mask & Seed (Data Mask (Legacy) (opens in a new tab)). Men verktyget stöder policyn, och frågan kommer först: behöver den här miljön riktiga känsliga data över huvud taget? Om realistiska, icke-känsliga data räcker för testningen är det det bättre svaret.

Använda: tillåtelse handlar inte bara om människor

Användare, integrationer, analys, partner, automatisering och agenter använder alla data. Samtycke (modul 5), ägarskap (modul 1) och klassificering (modul 3) möts här när systemet körs. Ska den här användaren se mottagarens (Recipient) telefonnummer? Ska den här integrationen få det, eller Snowflake, eller den här agenten som grounding? Svaret kan inte vara ”tja, tekniskt sett kan den det”. Det är skillnaden mellan förmåga och styrning: arkitekturen avgör om den bör.

Bevara: att spara allt för alltid är inte neutralt

Många organisationer har en oavsiktlig policy för lagringstid: för alltid. Ingen bestämde det; lagringsutrymme fanns, så data blev kvar. Men att spara data kostar lagring och prestanda, ökar exponeringen för integritets- och säkerhetsrisker, lägger till skyldigheter vid utredningar och ger dig fler ställen att leta på när någon ber om att bli glömd. För varje viktig kategori: varför spara den, hur länge, vad startar klockan, finns det ett rättsligt minimum eller ett integritetsmaximum, och vad händer i slutet: arkivera, radera, avidentifiera?

Och att arkivera är inte samma sak som att lösa lagringstiden. ”Vi arkiverade det.” Försvann kravet på lagringstid? Integritetskravet? Säkerheten? Du ändrade var data bor, inte vad de är. Ett arkiv behöver åtkomstkontroller, regler för lagringstid och radering, möjlighet att söka och granska. Flytta personuppgifter till ett arkiv som alla glömmer bort, så har styrningen just blivit sämre.

Radera: livscykeln behöver en utgång

Radering är inte bara till för enskilda integritetsbegäranden. Data når slutet av sin lagringstid; tillfälliga poster lever längre än sin användning; arkiv löper ut; en process avidentifierar efter en bestämd tid. Vad policyn än säger behöver arkitekturen en utgång, inte fånga → lagra → lagra mer → lagra för alltid. Och som modul 5 visade räcker det inte att radera posten i Salesforce när kopior bor någon annanstans.

Historik är också data

Ibland räcker inte det nuvarande värdet. En partners juridiska namn, en kunds klassificering, en samtyckesstatus, ett finansiellt attribut: verksamheten eller en tillsynsmyndighet kan behöva veta vad det var tidigare, när det ändrades och vem som ändrade det. Den historiken är data, och den behöver ett eget beslut om lagringstid.

Vanlig spårning av fälthistorik (field history tracking) följer upp till 20 fält per objekt och sparar ändringar i upp till 18 månader, och i upp till 24 månader bara via API:et, med Data Loader eller queryAll() (Field History Tracking Overview (opens in a new tab)). Och för långa textfält registrerar den bara att fältet redigerades, inte vad det stod: en lucka om det är ditt bevis. Field Audit Trail, en del av Shield eller köpt separat, följer upp till 200 fält per objekt och sparar historiken tills du raderar den, i ett arkiv som du når via API:et (Field Audit Trail (opens in a new tab)). Min hållning: vanlig fälthistorik är standardvalet; använd Field Audit Trail när ett regelverk eller en compliance-skyldighet kräver längre historik som går att bevisa. Inte för att ”granskning låter bra”.

Granskning och övervakning är inte samma sak

Fälthistorik besvarar frågor om ändringar i utvalda fält. Bredare frågor (vem loggade in, vem exporterade data, vilka API:er anropades, vem tittade på vad) är övervakning, och det är Event Monitoring. Min erfarenhet är att det oftast behövs hos mer reglerade kunder, och här är min starkaste hållning i det här kapitlet: sätt upp det innan du behöver det, och kanalisera händelserna till ett lager, som Splunk eller en annan SIEM, i förväg.

Här är varför. Händelseloggfiler sparas i 1 dag utan tillägget, och bara för vissa händelsetyper; 30 dagar som standard med Shield eller tillägget Event Monitoring, och upp till 365 dagar om du förlänger lagringstiden (Event Monitoring FAQ (opens in a new tab)). Allt äldre är borta om du inte exporterade det. Och de betalda loggarna kan inte hämtas för någon period före att ditt avtal började gälla (samma FAQ): att köpa tillägget efter incidenten tar inte tillbaka det förflutna. Så ett av de värsta samtal en arkitekt kan ha går så här: ”Kan vi se vad som hände för sex månader sedan?” ”Nej.” ”Varför inte?” ”Vi fångade det inte.” Du vill inte råka ut för ett problem och sedan upptäcka att du inte har fångat och lagrat de händelserna. Då är svaret helt enkelt borta.

Click to enlarge

Sätt upp det innan du behöver det.

Men svinga inte över till ”logga allt”. Vad försöker du bevisa? Vilka händelser spelar roll, vem behöver dem, hur länge, vem får läsa loggarna, och kan loggarna själva innehålla känsliga data? Loggning skapar data, och de data behöver också styras. Och bevis behöver en ägare: vem äger lagret, går igenom larmen, kontrollerar att lagringstiden fungerar, märker att flödet tyst slutade fungera för tre månader sedan? Teknik utan ägarskap är inte styrning; vi är tillbaka hos ägaren, förvaltaren och förvararen från modul 1.

Bevisa kontrollen, inte bara konfigurationen

”Mottagarnas uppgifter är bara tillgängliga för de team som är tilldelade stoppet.” Hur vet vi det? Säkerhetskonfigurationen visar vad som ska hända. Operativa bevis (vem som faktiskt kom åt uppgifterna, ovanliga exporter, en integration som hämtar dem, ändrade åtkomstkontroller) visar vad som faktiskt hände. Bra styrning behöver ofta båda.

Bortom provet: vad AI ändrar. När agenter går från att svara till att agera behöver styrningen bevis på vad agenten såg, vad den beslutade eller genererade och vad den gjorde, och vem eller vad som startade den, under vilken policy. Loggningsmekanismerna kommer att ändras; kravet kommer inte att göra det: om en autonom handling spelar roll, designa nu hur du ska rekonstruera den senare.

Steve Trucking: livscykeln för ett enda fält

Ta mottagarens telefonnummer. Fånga: det kommer in på partnerns manifest; kontrollera att det går att använda där processen behöver det. Klassificera: personuppgifter. Skydda: bara människor och system med ett operativt behov får det, och teamen ser det bara för sina egna stopp, under dagen. Använda: teamet samordnar leveransen; meddelandetjänsten använder det för ett godkänt ändamål; en agent använder det bara om policyn tillåter. Bevara: så länge som den godkända policyn för verksamhet och integritet säger. Radera eller avidentifiera: när den perioden tar slut eller en giltig begäran kommer, i varje kopia i landskapet. Granska: behåll beviset för att kontrollerna och åtgärderna genomfördes.

Ta nu en kod för en distributionscentral. Fånga den korrekt, klassificera den som icke-känsliga referensdata, skydda den med vanlig operativ åtkomst, använd den brett, bevara den så länge verksamheten behöver, och granska ändringar om de spelar roll. Samma livscykel, olika kontroller. Det är vad klassificering är till för.

Styrning blir aldrig klar

Ett nytt regelverk dyker upp. Ett nytt system eller en ny integration skapar ännu en kopia. Ett team hittar på ännu ett fält. En ny plattform driftsätts. En agent får åtkomst. En regel för lagringstid ändras. En ny detaljhandelspartner (Retail Partner) kommer till. Arkitekturen rör sig, och styrningen rör sig med den. Målet är inte perfekta data, oändliga kontroller eller ett styrningsdokument som ingen läser. Det är medvetna beslut om data, inbyggda i arkitekturen.

Vad en arkitekt bestämmer här

• Vilka skyddskontroller varje kategori av data får, utifrån klassificering, policy och verklig användning, inklusive krypteringens avvägningar.
• Hur länge data och deras historik sparas, vad som startar klockan och vad som händer i slutet.
• När vanlig fälthistorik räcker och när ett regelverk kräver Field Audit Trail.
• Vilka händelser som fångas, var bevisen lagras längre än plattformens lagringstid, och vem som äger dem.
• Hur arkitekturen i efterhand bevisar viktiga handlingar av människor, integrationer och agenter.

Det här kapitlet började med en idé: styrning designas in i orgen, den skrivs inte bredvid. Ägarna sätter policyn och arkitekterna genomdriver den. Håll dåliga data ute där det spelar roll. Vet vad dina data betyder, var de kom ifrån och hur känsliga de är. Respektera lagarna, modellera samtycke, kontrollera vart personuppgifterna tar vägen. Skydda, bevara och radera enligt policy. Och fånga bevisen innan någon ber om dem, för sex månader efter en incident är en fruktansvärd tidpunkt att upptäcka att bevisen bara fanns i trettio dagar.

Utforska vidare

• Salesforce Help, General Shield Platform Encryption Considerations (opens in a new tab) och Filter Encrypted Data with Deterministic Encryption (opens in a new tab) (på engelska, kontrollerad 2026-10-14).
• Salesforce Help, Field History Tracking Overview (opens in a new tab) (på engelska, kontrollerad 2026-10-14).
• Salesforce Help, Field Audit Trail (opens in a new tab) (på engelska, kontrollerad 2026-10-14).
• Salesforce Help, Salesforce Event Monitoring Frequently Asked Questions (opens in a new tab) (på engelska, kontrollerad 2026-10-14).
• Salesforce Help, Secure Your Sandbox Data with Salesforce Data Mask (Legacy) (opens in a new tab) (på engelska, kontrollerad 2026-10-14).