Trust

på

På Salesforce är Trust vårt främsta värde. Det är grunden för varje arkitektoniskt beslut på plattformen. För arkitekter uppnås Trust genom ett unikt partnerskap: Salesforce tillhandahåller en säker, efterlevnadsanpassad plattform—infrastrukturen, metadata och verktygen för att göra den till din egen—medan du utformar säkra lösningar som förlitar sig på denna grund.

Detta partnerskap fungerar genom modellen för delat ansvar, som är ett ramverk som tydligt delar upp säkerhetsansvar:

• Salesforce ansvarar för säkerheten för plattformen, inklusive infrastruktur, patchning och efterlevnadscertifieringar.
• Du ansvarar för säkerheten på plattformen, inklusive konfiguration, åtkomstkontroller, egen kod och datastyrning.

Denna avdelning är viktig eftersom den definierar arkitektonisk ansvarighet. Salesforce har en arkitektur med flera klienter där tusentals organisationer delar infrastruktur. Plattformen ger starka säkerhetsskydd på infrastrukturnivå. Dina arkitektoniska beslut avgör om dina specifika lösningar får intressenternas förtroende.

Modellen Delat ansvar låter dig utforma säkra lösningar medan fysisk säkerhet, nätverksskydd, plattformsuppdatering och infrastrukturkryptering hanteras åt dig. Detta låter dig fokusera på att utforma säkra lösningar som bygger på denna grund (till exempel identitets- och åtkomsthantering, dataskydd, integreringssäkerhet, säkra utvecklingsrutiner, efterlevnad och regelefterlevnad samt kapacitet för incidenthantering).

Neglecting Trust under design förvärrar den tekniska skulden. En saknad krypteringsstrategi blir en kostsam eftermontering när föreskrifter ändras. En ej styrd integrering blir en sårbarhet när inloggningsuppgifter äventyras. Att bygga Trust i från början är genomgående billigare än att bygga om det senare.

Trust sträcker sig över fyra arkitektoniska dimensioner som fungerar tillsammans:

• Säkerhetskontroller skyddar system och data
• Identitetshantering styr åtkomst
• Sekretessrutiner respekterar användarorgan
• Ramverk för efterlevnad uppfyller lagstadgade skyldigheter

Arkitekter som utformar för alla fyra dimensioner skapar lösningar som får och upprätthåller Trust genom transparens, kontroll och motståndskraft.

I Agentåldern omfattar Trust det betrodda sammanhang som agenter verkar inom. Betrodd kontext innebär att agenter får åtkomst till styrda, verifierade data med tydliga identitets- och behörighetsgränser, vilket låter AI-system resonera och agera åt användare samtidigt som säkerhet, granskningsbarhet och efterlevnad upprätthålls. Att utforma betrodda sammanhang är grundläggande för Agentic Enterprise-arkitektur.

Denna pelare etablerar den plattformssäkerhetsbaslinje som varje Salesforce-lösning är beroende av. Pelaren Agentic Trust bygger på denna baslinje för att hantera risker som är unika för autonoma agenter, inklusive snabb injektion, åtgärdsstyrning och de data som agenter kan komma åt under resonemangstider. Det är viktigt att först utforma baslinjen och sedan lagera agentspecifika kontroller med hjälp av riktlinjerna för Agentic Trust.

Denna pelare har en nära koppling till andra övergripande frågor.

• Tillförlitlighet beror på infrastruktur som motstår attacker och återställs från överträdelser.
• Operational Excellence kräver säkra pipelines för distribution och incidenthantering.
• Rättvisa kräver transparent, etisk hantering av data och algoritmiska beslut.

Tillsammans bildar dessa pelare ett enhetligt, lösningsfokuserat tillvägagångssätt som organisationer kan Trust med sina mest känsliga verksamheter.

I modellen Delat ansvar måste Salesforce och arkitekter uppfylla sina respektive skyldigheter för att upprätthålla Trust. Låt oss ta en närmare titt på vad varje sida måste säkra.

Salesforce ansvarar för att säkra plattformen och dess globala infrastruktur, inklusive:

• Åtkomstkontroller, övervakning och miljöskydd för datacenter
• För Hyperforce hanterar den underliggande molnleverantören (till exempel AWS, Azure eller Google Cloud, beroende på instans) fysisk datacentersäkerhet via delegerat ansvar. Salesforces infrastruktur- och underprocessordokumentation identifierar leverantören och underprocessorerna för varje tjänst.

• Säkerhetskontroller i nätverkslager, inklusive DDoS-skydd och hotdetektering
• Trafikkryptering under överföring (TLS 1.2+) och i vila (vanligtvis AES-256)

• Säkerhetssvar och distribuering av plattformspatchar via Salesforce (mer information om säkerhetsråd finns på security.salesforce.com)
• Hantering av operativsystem och infrastruktursäkerhet

• Certifikat och intyg: Salesforce upprätthåller auktoriseringarna SOC 1/2/3, ISO 27001/27017/27018, FedRAMP (omfattas av Government Cloud Plus och MuleSoft Government Cloud, inte den kommersiella plattformen med flera arrendatorer) och PCI DSS nivå 1-validering.
• Regelstöd: Detta gäller för HIPAA-berättigade tjänster med efterlevnadsprogram för Business Associate Agreements (BAAs) eller GDPR.
• Mer information finns på trust.salesforce.com och compliance.salesforce.com.

• Arkitektur för arrendatorisolering: En delad, metadatadriven kärna partitionerar varje organisations data och metadata efter organisations-ID, så en organisation kan inte nå en annan organisations poster även om de båda körs på delad infrastruktur. Kärnan tillämpar separation för varje sökfråga, inte genom en konfiguration som du måste upprätthålla.
• Infrastrukturnivåkryptering vid vila och reservinfrastruktur: Grundplattformslicenser inkluderar Classic Encryption (AES-128 tillhandahåller endast egna textfält). Shield Platform Encryption kräver en separat licens (AES-256 låter dig hämta din egen nyckel och tillhandahåller standardfält, filer och bilagor).

Dessa kontroller säkerställer att plattformen förblir säker, pålitlig och efterlevnad.

Du ansvarar för att säkra dina data, konfigurationer och driftsprocesser.

• Identitet och federation: För enkel inloggning (SSO) och flerfaktorsautentisering (MFA) måste du bekräfta användarens identitet.
• Åtkomstbegränsning: Tekniskt sett begränsar IP-intervall och inloggningstider hur och när identiteter ansluts.
• Principen om minsta privilegium (PoLP): Använd PoLP för att endast bevilja åtkomst för roller, profiler och behörighetsuppsättningar som behövs för att utföra individuella jobbuppgifter.
• Livscykelhantering: Öva på hantering av användares livscykel och riktlinjer för åtkomst till omcertifiering.

• Använd dataklassificering, maskering och säkerhet på objekt-/fält-/postnivå
• Tillämpa CRUD-behörigheter och delningsregler
• Äg, testa och distribuera en beprövad strategi för att återställa din organisations data, vilket säkerställer att dataförlust eller korrupt återställning förblir inom din kontroll.

• Använd API-autentisering (till exempel OAuth 2.0 eller JWT) och autentiseringsuppgifter.
• Aktivera dedikerade integreringsanvändare med PoLP-behörighetsuppsättningar så att varje integrerings åtkomst är begränsad och separat granskningsbar från mänskliga användare.
• Säkra slutpunkter och extern systemvalidering.

• Använd händelseövervakning, granskningsloggar och integrering av säkerhetsinformation och händelsehantering (SIEM).
• Följ procedurer för incidentsvar och säkerhetsgranskningar.

• Använd säker egen kod (till exempel Apex eller Lightning) och validering av indata.
• Kör Apex i användarläge så att objekt-, fält- och delningsbehörigheter tillämpas i kod.
• Följ förebyggande av injektioner och säkra utvecklingsrutiner.

• Upprätthåll efterlevnaden av lösningar.
• Följ sekretess-/samtyckeshantering och datalagringspolicyer.

Vissa ansvarsområden kräver samarbete:

• Säkerhetsincidentsvar: Båda parter deltar i aktiviteter för upptäckt och respons.
• Sårbarhetshantering: Salesforce patchar plattformen, arkitekter patchar egen kod.
• Säkerhetsövervakning: Kombinera plattformsskapade säkerhetssignaler med arkitektanalys.
• Efterlevnadscertifieringar: Salesforce certifierar plattformen (till exempel SOC, ISO och FedRAMP för Government Cloud). Arkitekter äger vad som byggs på den – egna objekt, kod, integreringar och konfiguration – inom den certifierade hållningen för att tillhandahålla bevis på efterlevnad för granskningar.
• Identitetsfederation: Salesforce litar på de kontroller som arkitektens identitetsleverantör utfärdar. Arkitekter upprätthåller säkringen av leverantören och Trust relationen mellan leverantören och Salesforce.
• Nyckelhantering: Med kryptering med hämta-din-egen-nyckel driver Salesforce krypteringstjänsten medan arkitekter skapar, roterar och återkallar det nyckelmaterial som skyddar data.

Varje designprincip, ämnessektion och checklista i detta dokument representerar ditt ansvar som arkitekt. Modellen Delat ansvar ramar in vad du måste utforma och konfigurera för att uppnå Trust på Salesforce Platform.

Gränsen sträcker sig till lagstadgade skyldigheter. Salesforce upprätthåller plattformens certifieringar och certifikat och säkrar infrastrukturen mot överträdelser. Arkitekter är ansvariga för de skyldigheter som är knutna till dina data och jurisdiktion (till exempel: vilka lagar som gäller, hur data klassificeras, vilka lagrings- och samtyckesregler som styr dem och hur du upptäcker och rapporterar överträdelser av de data du har kontroll över). Mot de styrande bestämmelserna för dina distribueringar måste arkitekter fastställa de specifika siffrorna bakom dessa skyldigheter (till exempel lagringsperioder och tidsfrister för meddelanden), mot de styrande bestämmelserna för din distribuering, eftersom de kan variera beroende på jurisdiktion och ändras över tid.

Använd dessa principer för att guida dina arkitektoniska beslut för säkerhet på plattformen.

• Tillämpa noll Trust i alla lager. Anta aldrig Trust baserat på nätverksplats, användarkännedom eller systemursprung. Verifiera varje åtkomstbegäran uttryckligen med autentisering, auktorisering och kryptering för data-, program-, integrerings- och infrastrukturlager. Arkitektur med flera arrendatorer innebär att du delar infrastruktur med tusentals organisationer, så nätverket som din lösning körs i är inte en omkrets som du kan behandla som betrodd. Verifiera varje begäran på dess egna meriter—identitet, auktorisering och sammanhang—istället för att lita på den där den ursprungligen startade.
• Bevilja minst privilegium som standard. Bevilja den lägsta åtkomstnivå som behövs för att varje användare, integrering och automatiserad process ska uppnå sitt syfte. Börja med de mest restriktiva inställningarna — Privata organisationsomfattande standarder (OWDs) och minimala behörigheter — och utöka avsiktligt baserat på dokumenterade verksamhetskrav. Använd åtkomstmodellen med fyra lager (organisation → objekt → fält → post) så att varje lager ytterligare begränsar lagren ovanför.
• Genomför försvar på djupet. Lager på lager av flera säkerhetskontroller så att fel på en kontroll inte äventyrar hela systemet. Kombinera förebyggande kontroller (till exempel tillämpning av CRUD/FLS och transaktionssäkerhetspolicyer som blockerar åtgärder), detektivkontroller (till exempel händelseövervakning) och responsiva kontroller (till exempel utökad autentisering och notiser för transaktionssäkerhet). Utforma varje lager som om de närliggande lagren kan misslyckas. Kom ihåg att fältnivåsäkerhet skyddar data även om delningsregler är för tillåtande.
• Integrera säkerhet genom design. Integrera hotmodellering, säkerhetskrav och kontrollvalidering i varje arkitekturfas från det inledande konceptet till den pågående utvecklingen. Utför hotmodellering med förfalskning, manipulation, avståndstagande, informationsutlämnande, överbelastning och förhöjd behörighet (STRIDE) innan byggandet påbörjas. Säkerhet formar teknikval och designbeslut.
• Bädda in säkerhet i automatisering. Bygg in säkerhetskontroller i automatiserade pipelines, konfigurationsmallar och plattformsstandarder. Salesforce Code Analyzer i CI/CD fångar upp sårbarheter innan distribuering. Configuration-as-code tillämpar säkerhetsbaslinjer. Inbäddad säkerhet säkerställer enhetlighet och låter säkerhet skalas upp med lösningars komplexitet.
• Utforma för sekretess. Införliva sekretessprinciper från den inledande arkitekturfasen. Utforma för dataminimering (endast samla in nödvändiga data), syftesbegränsning (begränsa åtkomst efter jobbfunktion), samtyckeshantering (tillämpa detaljerat, syftesspecifikt samtycke) och registrerades rättigheter (aktivera arbetsflöden för åtkomst, rättelse, radering och portabilitet att slutföras inom lagstadgade tidsramar).
• Design för spårbarhet. Gör så att varje efterföljande åtgärd kan tillskrivas och återskapas i efterhand, innan du förlitar dig på att upptäcka avvikelser i den. Se till att ändringar av data, behörigheter och konfiguration samlas in i granskningsloggar, fälthistorik och händelseloggar, och bevara dessa poster i otillåten lagring. Spårbarhet är förutsättningen för upptäckt, kriminalteknik och ansvarighet. Kom ihåg att du inte kan undersöka vad som aldrig registrerades.
• Utformning för incidenthantering. Utforma för detekterbarhet genom händelseövervakning och för ingripande i realtid genom transaktionssäkerhetspolicyer. Aktivera snabba svar genom dokumenterade procedurer och isoleringsgränser. Stöd för återställning genom säkerhetskopiering och kriminaltekniskt bevarande. Testa svar genom tabellövningar och intrångssimuleringar.

Arkitekter ansvarar för att säkra lösningar på den plattform som Salesforce tillhandahåller.

De arbetsbelastningar som interagerar med Salesforce körs allt oftare utanför huvudplattformen—integreringstjänster, egna program och sidhuvudlösa klienter anropar ofta Salesforce API:er, ofta åt en användare. För att påskynda detta mönster exponerar Salesforce plattformens kapacitet som API:n, verktyg och kommandon (till exempel Salesforce Headless 360). Oavsett vem som hanterar dessa program äger arkitekten Trust där de möter Salesforce för att avgöra hur de autentiserar, vilken identitet och behörigheter de bär, vilka hemligheter de har och vilka data som överskrider gränsen.

Principerna nedan gäller för alla integreringsplattformar med behållare (till exempel MuleSoft CloudHub).

När en extern klient autentiseras som en namngiven användare tillämpas Salesforces plattformssäkerhetsmodell automatiskt—objektbehörigheter, fältnivåsäkerhet och delningsregler tillämpas exakt som i webbläsaren. Autentisering per användare begränsar varje anrop till den personens behörigheter och bevarar granskningsloggen, vilket innebär att återkallande av en användares token omedelbart tar bort klientens möjlighet att agera åt dem. Föredrar detta framför ett delat servicekonto där arbetet utförs för en specifik användare.

Utforma gränsen defensivt eftersom en klient som har tokens för många användare koncentrerar Trust och blir en proxy med högt värde för en attackerare: en enskild stulen OAuth-token kan nå data över varje användare som klienten servar. Detta är inte hypotetiskt. Incidenten 2025 Salesloft Drift såg attacker stjäla OAuth-tokens och använda dem för att nå Salesforce-data i hundratals organisationer.

• Propagera användaridentitet, slå inte samman den. Använd autentisering per användare, eller OAuth 2.0-tokenutbyte, för att bära en användares identitet över servicehopp (se Agentidentitet och autentisering), så att kompromisser begränsas till en användares sammanhang snarare än till alla.
• Behandla OAuth-klientuppgifter och uppdateringstokens som det primära målet. Lagra dem i ett lager för hanterade hemligheter, rotera dem ofta och upprätthåll konstruktioner för omedelbar återkallande. Övervaka API-användning för de avvikande mönster som signalerar en attackerare med proxy.
• Minimera omfattningen på båda sidor. Begränsa OAuth-omfången för External Client App (ECA) och integreringsanvändarens Salesforce-behörigheter till det minimum som funktionen kräver, så att en komprometterad klient inte kan gå till orelaterade data.
• Styr gränsen genom externa klientappar. ECAs definierar hur ett externt program autentiseras, vilka flöden som är tillåtna och vilka omfattningar som gäller—utforma nya integreringar mot dem (se Autentiseringsarkitektur).

Var försiktig när en klient körs som agentanvändare eller integreringsanvändare: dessa identiteter kan fungera i ett upphöjt sammanhang—ofta mot externa system som inte respekterar Salesforces åtkomstkontroller—så att använda behörighets- och övervakningsdisciplinen som beskrivs ovan är det som håller denna makt bunden.

När integreringar körs i en behållarplattform anses isolering på behållarnivå i sig vara en säkerhetskontroll: varje program körs i en dedikerad behållare utan delad runtime eller minne mellan program.

Denna isolering ger:

• Upprätthållande av arrendatorgräns: Kompromissade program kan inte komma åt data eller resurser från närliggande program som delar samma miljö. Varje behållare har ett isolerat filsystem och processutrymme. Tillämpa nätverksisolering genom brandvägg och TLS-konfiguration och begränsa uttryckligen utgående trafik istället för att förlita dig på tillåtna standarder.
• Försvarsdjup: Behållarisolering lägger till ett säkerhetslager utöver kontroller på programnivå. Även om programkoden har sårbarheter begränsar behållargränser explosionsradien.
• Efterlevnadssegmentering: Reglerade arbetsbelastningar (till exempel PCI och HIPAA) kan isoleras i dedikerade behållare, vilket förhindrar sammanblandning med arbetsbelastningar som inte uppfyller kraven.

Arkitekter som utformar miljöer med flera program måste förlita sig på behållarisolering för att tillämpa separation av uppgifter och säkerhetsdomäner. Integreringar av finanstjänster som hanterar korthållardata måste köras i separata behållare från marknadsföringsintegreringar, även inom samma miljö.

Trafik mellan containrar bör krypteras och ömsesidiga TLS-system (mTLS) bör tillämpas om ett regelverk kräver autentisering på båda sidor:

Så här fungerar det:

• Konfigurera TLS-sammanhang för att aktivera valfri ömsesidig TLS (mTLS) för inkommande anslutningar vid behov.
• Använd SSL på plattformsnivå med klientcertifikatautentisering för att säkra kommunikationen mellan plattformstjänster och replikor.
• Konfigurera TLS-sammanhang för att aktivera mTLS när det krävs enligt regelverk.
• Hantera certifikat genom plattformens certifikatlagring så att livscykel och återkallande förblir centraliserade.
• Tillämpa gränser för nätverksisolering som förhindrar obehörig trafik mellan behållare.

Att kryptera trafik på plattformslagret ger försvar på djupet för data under överföring. Även om programlagrets HTTPS är felkonfigurerat förblir behållartrafiken krypterad.

Behållare som ansluter till system på plats via VPN måste skapa ett dataöverföringsskydd:

• Tunnelkryptering: Dirigera all trafik mellan behållare och system på plats genom krypterade VPN-tunnlar. Detta gäller oavsett programlagrets TLS. Försvar på djupet säkerställer att det finns dubbel kryptering för känsliga data.
• Tillämpning av nätverkssegmentering: VPN-tunnelpolicyer begränsar vilka nätverksbehållare på plats som kan nås. Komprometterade behållare kan inte gå till oauktoriserade interna system utöver VPN-tillåtna nätverk.
• Bevis för efterlevnad: VPN-kryptering är en av de accepterade mekanismerna för att skydda data under överföring till och från molnmiljöer. Granskare som granskar HIPAA-, PCI-DSS- eller SOX-kontroller förväntar sig dokumenterad kryptering under överföring för hybridintegreringar.

Arkitekter måste utforma VPN-policyer som tillämpar nätverksåtkomst med minst behörighet. Marknadsföringsintegreringsbehållare ska inte dirigera till interna finanssystem även om båda kan nås via VPN.

Fåfänga domäner (till exempel egna URL:er för integrerings-API:er) kräver att arkitekter hanterar TLS-certifikat som Trust anchors:

Fåfänga domäner (till exempel egna URL:er för integrerings-API:er) kräver att arkitekter hanterar TLS-certifikat som Trust anchors.

• Automatisering av certifikatlivscykel: Implementera automatiserad certifikatförnyelse och distribuering. Utgångna certifikat bryter integration Trust; klienter avvisar anslutningar med certifikatvalideringsfel.
• Planering av återkallande av certifikat: Utforma certifikatrotationsprocesser för säkerhetsincidenter. Kompromissade privata nycklar kräver snabbt utfärdande och distribuering av certifikat i alla regioner.
• Konfiguration av chiffersvit: Äldre TLS-konfigurationer (TLS 1.0/1.1 och svaga chiffer) misslyckas med efterlevnadsgranskningar. Tillämpa TLS 1.2+ (minimikrav) och anpassa certifikat- och klientkonfigurationer till organisationens säkerhetspolicyer.
• Loggning av certifikattransparens: Moderna TLS-certifikat skickas till offentliga loggar för certifikattransparens (CT) av certifikatutfärdare (CA). Varje CT-logg returnerar en signerad certifikattidsstämpel (SCT), ett kryptografiskt bevis på loggning, som CA bäddar in i certifikatet via ett X.509v3-tillägg. Arkitekter bör övervaka CT-loggar för oauktoriserad certifikatutfärdande mot sina domäner, med hjälp av tjänster som crt.sh eller automatiserad varning.

Felhantering av certifikat påverkar Trusts hållning direkt:

• Utgångna certifikat: Orsaka autentiseringsfel som visas som avbrott. Övervakning måste inkludera att skicka varningar inom 30+ dagar innan de går ut för att låta förnyelseflöden påbörjas.
• Självsignerade certifikat: Bryt Trust kedjor för externa klienter. Produktionsintegreringar kräver certifikat som signeras av betrodda certifikatutfärdare (CA).
• Wildcard-certifikatspridning: Hänvisar till alltför breda jokerteckencertifikat (till exempel *.company.com) som skapar en stor explosionsradie om de äventyras. Certifikat med smal omfattning föredras per integreringsdomän.

Behållardistribueringsregioner måste uppfylla kraven för datalagring och efterlevnad.

• GDPR-datalagring: Dataskyddsförordningen kräver adekvat skydd för personuppgifter som lämnar Europeiska unionen (EU), men inte EU-distribuering som sådan. Att distribuera integreringar i en EU-region håller behållarberäkningar och databearbetning inom lagstadgade gränser, vilket är det mest direkta sättet att uppfylla detta krav. Överföringar som sker utanför EU förblir tillåtna enligt ett beslut om adekvat skyddsnivå, standardavtalsklausuler eller bindande företagsregler.
• Datalokaliseringslagar: Länder med datalokaliseringskrav inkluderar: Ryssland (federal lag 152-FZ och obligatorisk lagring) och Kina (PIPL/CSL för CIIOs), som kan kräva containerdistribuering i landet. Indiens DPDP Act från 2023 använder en svartlistningsmetod som inte föreskriver ett allmänt lagringsmandat i landet. Dataöverföringar är tillåtna till vilket land som helst om de inte uttryckligen begränsas av ett statligt meddelande. Arkitekter måste förstå behörighetsspecifika föreskrifter.
• Gränsöverskridande mekanismer för dataöverföring: När en multiregional distribuering krävs, men data måste korsa gränser, måste arkitekter implementera SCC, BCR eller andra lagliga överföringsmekanismer.
• Anpassning av efterlevnadscertifiering: Regioner för behållardistribuering måste matcha Salesforces efterlevnadscertifieringar. FedRAMP-godkända arbetsbelastningar kräver amerikansk-regional distribuering. För HITRUST-certifierade integreringar måste du verifiera att distributionsregionen ingår i ett aktivt HITRUST-certifieringsomfång.

Regionala distributionsbeslut är arkitektansvar som direkt påverkar efterlevnad av föreskrifter. Finansteam kan godkänna distribution endast i USA för SOX-styrda integreringar. Vårdteam kan kräva HITRUST-certifierade regioner för bearbetning av personlig hälsoinformation (PHI).

Behållare behöver åtkomst till inloggningsuppgifter, API-nycklar och krypteringsnycklar. Arkitekter måste utforma processer för hantering av hemligheter som förhindrar exponering:

• Inga hårdkodade hemligheter: Bädda aldrig in inloggningsuppgifter i programkod eller konfigurationsfiler som distribueras till behållare. Använd plattformshanterade hemlighetsaffärer.
• Plattformshanterad hemlig injektion: Lös hemligheter vid körning från plattformens hanterade lagring (istället för att behålla dem till filsystemet) och markera konfigurationsvärden som håller inloggningsuppgifter som skyddade så att de inte visas i loggar eller på konsolen.
• Hemlig rotation: Utforma integreringar för att hantera roterade hemligheter smidigt. OAuth-tokenuppdateringsmönster, arbetsflöden för API-nyckelrotation och ändringar av databaslösenord får inte kräva omdistribuering av behållare.
• Åtkomst till hemligheter med minst privilegier: Ge behållare åtkomst endast till de hemligheter som behövs för deras funktion. Marknadsföringsintegreringar ska inte ha åtkomst till inloggningsuppgifter för finanssystemet även om de delar samma miljö.

Exponerade hemligheter är vanliga integreringssäkerhetsincidenter. Arkitekter måste utforma processer för hantering av hemligheter som kan överleva kodgranskningar, loggar, felmeddelanden och övervaka instrumentpaneler utan att inloggningsuppgifter läcker ut.

Program vid Salesforce-gränsen skapar granskningshändelser som uppfyller kraven för efterlevnadsloggning:

• Loggning av begäran/svar: Loggar API-begäranden, svar och dirigeringsbeslut. Efterlevnadsteam använder dessa loggar för åtkomstgranskningar för att avgöra vem som öppnade vilka data vid vilken tidpunkt.
• Fel- och undantagsloggning: Samlar in säkerhetshändelser (till exempel autentiseringsfel, auktoriseringsavvisande och ogiltiga certifikat) i behållarens loggar. SIEM-integrering möjliggör säkerhetsövervakning i realtid.
• Logglagringspolicyer: Arkitekter måste konfigurera lagringsperioder som uppfyller lagstadgade krav. Dessa minimivärden fastställs av förordningar, skiljer sig åt mellan ramverk och ändras över tid, så de måste derivera dem från en väl underhållen efterlevnadskälla som verifierar varje siffra mot den styrande förordningen snarare än hårdkodar värden.
• Loggkryptering och åtkomstkontroller: Granskningsloggar kan innehålla känsliga metadata. Loggar måste endast krypteras vid vila och åtkomstkontrolleras till auktoriserad säkerhetspersonal/efterlevnadspersonal. Otillräcklig loggning förhindrar incidentutredning och misslyckas med efterlevnadsgranskningar. Arkitekter måste balansera loggning (till exempel prestandapåverkan och lagringskostnader) mot efterlevnad och säkerhetsutredningar.

Hotmodellering måste vara en del av utformningen av dina lösningar, snarare än ett separat steg som inträffar före eller efter den. Så fort du har en kandidatdesign att resonera kring måste du modellera dess potentiella hot—och gå igenom modellen igen medan designen utvecklas, så att säkerhet formar arkitekturen istället för att monteras om den. Salesforce hanterar infrastruktursäkerhet (till exempel nätverksskydd, OS-härdning och sårbarhetshantering), men du måste identifiera risker i programlager i din konfiguration, integreringar och egen kod. Tillämpa STRIDE-ramverket (Förvrängning, Manipulering, Avvisande, Informationsutlämnande, Överbelastning, Förhöjd behörighet) för Salesforce-specifika hotvektorer som anges nedan. Identifiera Trusts gränser där data korsar system, nätverk eller behörighetsnivåer.

Tillämpa STRIDE-ramverket för dessa Salesforce-specifika överväganden vad gäller hotmodeller:

• Dataflöden med flera organisationer skapar ytterligare Trust-gränser som kräver uttrycklig autentisering och auktorisering vid varje korsning.
• Externa integreringar använder API:n och mellanprogramvara, vilket potentiellt kan introducera attackvektorer som kringgår plattformssäkerhetskontroller.
• Egna Apex- och Lightning-komponenter kräver säker kodanalys för injektion, XSS och tillämpning av åtkomstkontroll.
• Experience Cloud-webbplatser utökar attackytan till ej inloggade eller lätt inloggade användare.
• Tredjeparts- och ISV-kod (till exempel hanterade paket, AgentExchange-listningar, anslutna appar, JavaScript-bibliotek på klientsidan och de externa AI-tjänster som dina agenter anropar) är en vektor för leveranskedjan som går över gränsen för din Trust, vid installation eller vid runtime.

Kod från tredje part och ISV är en del av din Trust Boundary.

Hanterade paket eller AgentExchange-listningar körs inuti din organisation med de behörigheter du beviljar dem, så deras säkerhetsstatus blir din säkerhetsstatus i det ögonblick du installerar dem. Salesforces säkerhetsgranskning kontrollerar varje listat paket innan det når AppExchange eller AgentExchange. Du äger allt efter den grinden:

• Utvärdera paketet mot din egen dataklassificering och riskhållning
• Ge den den den minsta mängd privilegier som dess dokumenterade funktionalitet kräver
• Hålla den uppdaterad med utgivarens utgåvor
• Och bevaka dess aktivitet genom samma händelseövervakning och granskningskontroller som du tillämpar för din egen kod.

Tillämpa säkerhetskontroller på varje lager i lösningsstacken. Kom ihåg att kompromisser av ett lager inte får exponera hela systemet.

Utforma varje lager som om lagren ovan och under kan misslyckas. Kom ihåg att flera oberoende kontroller skapar motståndskraft.

Zero Trust eliminerar implicit Trust baserat på nätverksposition eller tidigare autentiseringsstatus. Varje begäran måste autentiseras och auktoriseras oberoende.

Tillämpa noll Trust för:

• Användaråtkomst genom kontinuerlig verifiering med MFA, sessionspolicyer och villkorlig åtkomst baserat på sammanhang (till exempel IP, enhet, tid och beteende)
• Integreringsanslutningar genom OAuth-tokenvalidering för varje anrop, certifikatbaserad ömsesidig TLS och IP-tillåtelselista
• Intersystemkommunikation genom uttrycklig autentisering, vilket även gäller för betrodda interna system
• Dataåtkomst genom tillämpning av CRUD och FLS för varje sökfråga och åtgärd oavsett anropssammanhang

Inventering av säkerhetstillgångar är en indata för säkerhetsdesign: du kan endast hotmodellera, tillämpa minst behörighet för och övervaka en attackyta som du först har räknat upp, så att spåra dina säkerhetsrelevanta tillgångar hör till de designbeslut som beror på det. Detta skiljer sig från den hantering av operativ konfiguration som Operational Excellence täcker (till exempel versionshantering av organisationsinställningar och att upptäcka konfigurationsdrift för operativ stabilitet). Med andra ord är bekymret här smalare: Vilka tillgångar medför säkerhetsrisker och varför?

Upprätthåll ett aktuellt lager av alla säkerhetsrelevanta tillgångar, inklusive egna objekt som lagrar känsliga data, externa systemintegreringar, offentliga API:n, privilegierade konton, beviljande av produktionsåtkomst och installerade paket med utökade behörigheter.

Ditt lager av säkerhetstillgångar ska innehålla:

• Egna objekt och fält som innehåller konfidentiella eller begränsade data
• Integreringsslutpunkter och autentiseringsmekanismer
• Användare med utökade behörigheter (till exempel Ändra alla data, Visa alla data och Hantera användare)
• Integreringsanvändare endast med API och deras behörighetsområden
• Externa klientappar (ECA) och deras OAuth-omfång, tillsammans med äldre anslutna appar som fortfarande finns i organisationen
• Installerade AgentExchange-paket och deras behörighetsbeviljanden
• Experience Cloud-webbplatser och deras autentisering och externa delningsmodeller
• Egna Apex klasser med förhöjda delningslägen
• Var särskilt uppmärksam på äldre klasser: kod kompilerad vid API version 66.0 eller tidigare, som utelämnar en delningsdeklaration blir som standard "utan delning" (till exempel systemläge, förbigå den aktuella användarens poståtkomst). Kom ihåg att från API version 67.0 (Summer '26) blir en utelämnad deklaration istället "med delning" och databasoperationer körs i användarläge. Befintliga klasser behåller dock det gamla beteendet tills de kompileras igen vid v67.0 (eller senare)—så odeklarerade klasser som förs vidare från tidigare versioner fortsätter vara tysta upphöjda.

Det är ditt ansvar att utforma och konfigurera identitetskontroller som tillämpar minst behörighet.

Låt oss ta en närmare titt på hur man korrekt utformar och konfigurerar kontroller med PoLP.

Salesforce tillämpar åtkomstkontroll genom fyra olika lager: organisation, objekt, fält och post. Du måste utforma lösningar som utnyttjar alla fyra lager avsiktligt. Kärnåtkomstkontroll är beviljandebaserad, vilket innebär att åtkomst är additiv och att användare måste ha den beviljad i varje lager för att nå en post. Det finns ingen generell regel för att neka åsidosättningar i huvudplattformen, så du kan inte muta in ett riktat avvisande för att ångra åtkomst till ett brett beviljande som redan har tilldelats.

tillåtande högre lager kostar inte din möjlighet att begränsa, men de ökar ansträngningen: utöka organisationsomfattande standarder eller objektbehörigheter tidigt innebär att förlita sig på fältnivåsäkerhet och delningskonfiguration för att återkräva åtkomst som aldrig borde ha beviljats.

Begränsningsregler och ignoreringsbehörigheter är två inbyggda undantag som subtraherar åtkomst, men vart och ett har ett snävt tillämpningsområde—begränsningsregler till filtrering på postnivå och ignorering till behörigheter beviljade inom en behörighetsuppsättningsgrupp—inte ett generaliserat avvisandelager.

Sätt OWDs till Privat för objekt som innehåller känsliga data. Att öppna OWDs för Offentligt skrivskyddat — än mindre Offentligt Läsa/Skriva — exponerar poster brett och urholkar din möjlighet att begränsa åtkomsten senare utan att potentiellt behöva omstrukturera dem. Den vanligaste Trust debt i mogna organisationer kommer från tillåtande OWD som ställts in under den inledande implementeringen.

Postlagret följer en grant-then-restrict-modell, ofta avbildad som en delningspyramid: OWD ställer in den restriktiva baslinjen och rollhierarki, delningsregler och manuell delning öppnar åtkomst uppåt därifrån. Två kontroller inverterar detta flöde för att ta bort åtkomst istället för att bevilja den, och båda är värda att designa i avsiktligt.

• Begränsningsregler filtrerar vad användare kan se i poster som de redan har åtkomst till, så användare med bred objektåtkomst ser fortfarande endast den underuppsättning som en regel tillåter.
• Ignorera behörigheter drar ifrån specifika behörigheter inuti en behörighetsuppsättningsgrupp så att du kan samla åtkomst från återanvändbara grupper och sedan ta bort det som en given population inte ska ha.
• Nå dessa regler när enbart beviljandebaserade lager skulle tvinga dig att antingen överprovisionera eller fragmentera åtkomst till många smala behörighetsuppsättningar.

Tillämpa MFA (flerfaktorsautentisering) för alla användare som loggar in i produktionsmiljöer via användargränssnittet, som Salesforce kräver som ett plattformskrav. Detta krav gäller inte endast API-åtkomst: integreringar som använder JWT-bärare eller klientinloggningsuppgifter undantas, så du måste skydda dessa integreringar med certifikathantering och IP-begränsningar istället. Utöka MFA-kraven till privilegierade operationer.

För SSO (enkel inloggning) föredras SAML 2.0- eller OpenID Connect-protokoll. Konfigurera sessionspolicyer för att balansera säkerhet och användbarhet:

• Sessionstimeout: Konfigurera sessionstimeouter som är lämpliga för användarbehörighetsnivåer (kortare timeouter för konton med hög behörighet minskar riskerna från obevakade sessioner).
• IP-begränsningar: Tillämpa begränsningar för administrativa profiler och integreringsanvändare.
• Inloggningstider: Begränsa servicekonton till förväntade operativa fönster.
• Enhetsaktivering: Förlita dig på Salesforces inbyggda enhetsaktivering (identitetsbekräftelse för inloggningar från okända enheter) och lägg till MFA- och IP-begränsningar för konton med hög behörighet. Inbyggd enhetsförtroende upprätthålls genom en extern identitetsleverantör.
• Låsning av sessions-IP: Lås sessioner till den IP-adress de ursprungligen kommer ifrån så att ett stulet sessions-ID inte kan spelas upp igen från en annan nätverksplats. Detta skärper säkerheten, men skapar friktion för mobila användare och kan bryta automatiserade integreringar—där låsning inte är genomförbart, tillämpa IP-intervall för strikt inloggning på profilnivå med "Tillämpa IP-intervall för inloggning för varje begäran" som kompensationskontroll.
• Hög garantisessioner: Kräv en sessionsäkerhetsnivå med hög garanti, genom Sessionsäkerhetsnivåpolicyer och Åtkomstpolicyer, för känsliga åtgärder (som att öppna rapporter eller hantera IP-intervall), så att en rutininloggning inte i sig själv kan nå åtgärder med hög påverkan. I Lightning Experience stöds inte att flytta upp en standardsession till Hög garanti genom att be om MFA igen, så omfånget för denna policy är att användare av standardsessioner är blockerade från den gated operationen istället för att uppmanas att flytta upp.
• Skydd för sessionscookie: Kräv attributet HttpOnly så att skript inte kan läsa session-ID-cookien, och lås sessioner till den domän där de först användes, för att förhindra sessionsövertagande.
• API-endast åtkomst för integreringsanvändare: Begränsa integrerings- och servicekonton till endast API-autentisering med behörigheten Endast API-användare så att de inte kan logga in via användargränssnittet. För nya versioner, tilldela profilen Minimum Access - API Only Integrations med användarlicensen Salesforce Integration. Den äldre Salesforce API Only Systems Integration-profilen är inte tillgänglig i organisationer provisionerade från utgåvan Spring '24 och framåt, så utforma nya integreringar mot den aktuella profilen istället för den föråldrade.

För API-autentisering, välj OAuth 2.0-flöden som är lämpliga för integreringsmönstret:

• JWT-bärarflöde: Använd detta för server-till-server-integreringar som körs som en integreringsanvändare (certifikatbaserad, föredras för betrodda miljöer).
• Webserverflöde (auktoriseringskod, med PKCE): Använd detta för webbprogram som kräver användarauktorisering och för server-till-server-integreringar som behöver upprätthålla specifika användarsammanhang (lagra uppdateringstokens på serversidan för att undvika upprepade webbläsaruppmaningar).
• Gör repris av auktoriseringskodflödet säkert: Tillämpa PKCE så att en avlyssnad auktoriseringskod inte kan lösas in av någon annan än klienten som begärde den, och rotera uppdateringstokens—utfärda en ny vid varje användning och ogiltigförklara den föregående—så att en stulen uppdateringstoken har ett smalt giltighetsfönster. Återanvändning av en tillbakadragen token signalerar kompromiss.
• Flöde för auktorisering av sidhuvudlös identitet och inloggningsuppgifter (med PKCE): Använd detta för genuint sidhuvudlösa klienter utan webbläsare som måste köras i en specifik användares sammanhang—det omdirigeringsbaserade webbserverflödet förutsätter en webbläsare som dessa klienter inte har.
• Enhetsflöde (för sidhuvudlösa enheter): Observera att Salesforce sedan 28 augusti 2025 permanent har blockerat OAuth 2.0-enhetsflöde för den anslutna appen Salesforce CLI som standard. Använd webbserverflödet (sf-organisationens inloggningswebb) eller JWT-bärarflödet (sf-organisationens inloggningsjwt) istället för CLI- och CI/CD-verktyg.

Använd inte Användarnamn-Lösenord-flödet. Salesforce blockerade det som standard för organisationer som skapats i utgåvan Summer '23 eller senare, och har publicerat pensionsplaner för detta flöde. Befintliga integreringar som fortfarande förlitar sig på användarnamn-lösenord-flödet ska migrera till JWT-bärarflödet eller klientinloggningsuppgifterflödet nu, istället för att behandla migreringen som uppskjuten teknisk skuld.

Dessa flöden konfigureras i appregistreringen som representerar din integrering. Från och med utgåvan Spring '26 flyttar Salesforce denna registrering från Anslutna appar till Externa klientappar (ECA): skapa nya anslutna appar är inaktiverat som standard och ECA är konstruktionen att designa nya integreringar mot. Befintliga anslutna appar fortsätter vara installerade, men när en organisation har migrerats hanterar de inte längre autentisering, så ta hänsyn till migreringen när du granskar hur integreringar autentiserar istället för att behandla anslutna appar som den permanenta modellen.

Utöver att välja ett autentiseringsflöde, skapa distinkt styrning för vilka appar som kan anslutas:

• En registrering per integrering: Registrera en dedikerad extern klientapp för varje ny integrering och en separat ansluten app för varje befintlig. Omfattas endast av de OAuth-omfång som varje integrering kräver istället för att dela en bred registrering över många, en dedikerad registrering håller varje integrerings åtkomst oberoende granskningsbar och återkallelig.
• Förauktorisera åtkomst uttryckligen (rekommenderas): Ställ in policyn Tillåtna användare för appen Extern klient till "Administratörsgodkända användare auktoriserade i förväg" så att en administratör beviljar åtkomst genom profiler och behörighetsuppsättningar istället för att låta användare auktorisera sig själva. Administratörer konfigurerar detta direkt i Inställningar och det är Salesforces rekommenderade kontroll för att avgöra vem som kan ansluta.
• API-åtkomstkontroll (striktare, tillåtelselistbaserad): För striktare kontroller begränsar API-åtkomstkontroll administratörsgodkända användare till endast tillåtelselistade anslutna appar. Att aktivera det kräver en begäran till Salesforces kundsupport, så planera för det steget när du utformar runt det istället för att behandla det som en självbetjäningsinställning.

Bädda aldrig in inloggningsuppgifter i kod, konfigurationsfiler eller versionshantering. Använd autentiseringsuppgifter och externa inloggningsuppgifter för att hantera autentisering centralt med rotationsfunktioner.

Till skillnad från traditionell användarautentisering kräver agenter distinkta identitetsmodeller och rätt modell beror på om agenten servar anställda eller externa användare. Att utforma identitet korrekt är grunden för agentsäkerhet: det avgör vilka data agenten har åtkomst till och vilka åtgärder agenten har åtkomst till.

Låt oss ta en närmare titt på interna och externa agenter. nts.

• Anställdas agenter (interna): Utför uppgifter inom sammanhanget för den inloggade användaren. De ärver användarens licenser, behörighetsuppsättningar, fältnivåsäkerhet och delningsregler, så ingen separat agentidentitet provisioneras och det befintliga säkerhetsramverket styr vad agenten kan göra.
• Kundagenter (externa): Interagera genom offentliga kanaler och kör som dedikerade agentanvändare, specialiserade integreringsanvändare—inte gästanvändare på offentliga webbplatser. Att köra som dedikerade integreringsanvändare låter agenten utföra backendåtgärder och nå data (vilket ej inloggade gästprofiler inte kan), samtidigt som de är bundna av uttryckliga, minst privilegierade behörigheter. När du skapar en kundagent, provisionera en ny agentanvändare med minimal åtkomst och bevilja endast de specifika behörigheter som dess åtgärder kräver.

Om en agents arbete sträcker sig över flera tjänster, propagera användarens identitet över varje service hop istället för att falla tillbaka till en delad identitet eller gästidentitet. Salesforce OAuth 2.0-tokenutbytesflöde har stöd för detta:

En klient presenterar användarens befintliga identitetsleverantörstoken och en Apex tokenutbyteshanterare mappar den till en Salesforce-användare och utfärdar en Salesforce-åtkomsttoken, så att den ursprungliga användarens sammanhang följer begäran istället för att minimeras till ett servicekonto. Övervaka agentaktivitet genom händelseövervakning, med agentens användaridentitet för att upptäcka avvikande beteenden.

Att välja rätt modell beror på vem som inleder anslutningen och i vilket sammanhang arbetet måste köras.

Vanliga anslutningsscenarion mappar till rekommenderade metoder enligt följande:

Utforma rollhierarkier kring dataåtkomstbehov (vilka användare behöver åtkomst till poster som ägs av andra)—inte diagrammet för hanteringsrapportering. Låt rollhierarkidjup följa äkta dataåtkomstrelationer istället för att lägga till nivåer som inte beviljar någon ytterligare åtkomst, eftersom varje nivå lägger till delningsberäkningsoverhead – en faktor som väger tyngre i organisationer med privata OWD-inställningar och stora datavolymer.

Behörighetsuppsättningar och behörighetsuppsättningsgrupper minskar behovet av profilspridning genom att ge flexibel, additiv åtkomst. Bevilja funktionell åtkomst genom behörighetsuppsättningar och behörighetsuppsättningsgrupper istället för profiler, vilket håller åtkomsten additiv och granskningsbar. Profiler är fortfarande nödvändiga: Utöver inloggningstider och IP-begränsningar styr de sidlayouttilldelning, standardposttyper och appsynlighet. Behandla profiler som en hållbar del av åtkomstmodellen, snarare än en konstruktion att eliminera.

Transaktionssäkerhetspolicyer är inte en del av baslinjen, de är en tilläggskapacitet som kompletterar den centrala auktoriseringsmodellen: Identitets-, roll-, profil-, behörighetsuppsättnings- och delningskontrollerna ovan etablerar redan en säker auktorisering på egen hand, och Transaktionssäkerhet lägger till sammanhangsutvärdering i realtid ovanpå. Konfigurera policyer för att upptäcka och blockera avvikande beteenden, inklusive massnedladdningar av data som överskrider normala mönster, inloggningar från oväntade geografiska områden och behörighetsändringar utanför ändringsfönster.

Säkerhetskontroller medför kompromisser om tillgänglighet som är ett arkitektoniskt ansvar. En alltför bred IP-begränsning kan låsa ute legitima användare under en nätverksändring, och en transaktionssäkerhetspolicy som är inställd för aggressivt kan blockera giltig verksamhetsaktivitet—så begränsa dessa kontroller till verklig risk, fasa dem i endast-övervaka-läge innan de tillämpas, och utforma en krossningsväg för när en kontroll går fel.

Ditt ansvar: Utforma rollhierarki, skapa behörighetsuppsättningar, konfigurera transaktionssäkerhetspolicyer.

Traditionell rollbaserad åtkomstkontroll) beviljar behörigheter baserat på en användares roll. ABAC (attributbaserad åtkomstkontroll) fattar auktoriseringsbeslut baserat på attribut för datan, användaren och sammanhanget.

För de flesta krav uttrycker huvuddelningsmodellen åtkomst fullständigt. Nå för dedikerad ABAC när åtkomst måste följa dataklassificering som delning per post inte kan uttrycka: Data 360 ABAC tillhandahåller detta genom taggar och annoteringar.

Data 360 ABAC fungerar genom:

• Taggbaserade policyer som definierar åtkomstregler baserat på taggar som tillämpas på dataobjekt (t.ex. Personligt identifierande information (PII), Finans, Hälsovård och Konfidentiell).
• Annoteringar tillämpas på dataobjekt för att stödja policybaserade auktoriseringsbeslut.
• Standardpolicyn "Tillåt alla" för nya och befintliga organisationer som uttryckligen måste tas bort för att aktivera detaljerade styrningspolicyer.

Dess primära arkitektoniska användning är att tillämpa dataklassificering—se Dataklassificering under Dataskydd och sekretess för hur klassificeringsnivåer driver ABAC-tillämpning.

Denna detaljnivå medför en driftskostnad. Kärndelning besvarar frågan "Vem kan se denna post och varför?" från en liten uppsättning regler som går att inspektera (OWD, rollhierarki och delningsregler), medan ABAC hämtar sina svar vid utvärdering från kombinationen av datataggar, användarattribut och sammanhang, så effektiv åtkomst blir svårare att resonera kring och granska allt eftersom policyer och taggar ackumuleras.

Tillämpa granskningsbarhet som ett designkrav: tillämpa taggar konsekvent, hålla policyuppsättningen liten och namngiven för den klassificering den tillämpar och bevara möjligheten att rekonstruera varför en användare nådde en given post. Reservera ABAC för klassificeringsdrivna kundcase som delning per post verkligen inte kan uttrycka, istället för att behandla det som en allmän ersättning för den ägarbaserade modellen.

Identifiera och skydda konton med utökade behörigheter, inklusive systemadministratörer, integreringsanvändare och automatiserade processkonton. Dessa konton är mål med högt värde för attacker.

Tillämpa utökade kontroller för konton med kritisk påverkan.

• Kräv nätfiskeresistent MFA
• Begränsa IP-intervall för inloggning till kända administrativa platser
• Aktivera inloggningsvarningar och notiser om behörighetsändringar
• Utför regelbundna åtkomstgranskningar med dokumenterade intyg för konton med hög behörighet där frekvensen avgörs av organisationens risktolerans och efterlevnadskrav
• Upprätthåll rutiner för krossat glas för nödåtkomst och granskning efter användning

För integrerings- och servicekonton:

• Tillämpa OAuth-flöden; aldrig användarnamn-lösenord-flöden
• Tillämpa IP-begränsningar
• Implementera rotationsscheman för inloggningsuppgifter
• Bevaka avvikande API-användningsmönster genom händelseövervakning

Ditt ansvar: Identifiera viktiga konton, tillämpa utökade kontroller, utför kvartalsvisa granskningar.

Utforma automatiserade processer för att ge användare lämplig inledande åtkomst, justera behörigheter allt eftersom roller utvecklas och avprovisionera snabbt när åtkomst inte längre behövs.

Implementera ett system för Cross-domain Identity Management (SCIM) för automatiserad provisionering från identitetsleverantörer. SAML- eller OpenID Connect Just-in-Time-provisionering är ett alternativ som skapar en användare vid första inloggningen, men det avprovisionerar inte användare. Med andra ord är SCIM ryggraden i livscykeln, inte ett val mot den.

Identitetslivscykeln inkluderar:

• Provisionering: Skapa konton med grundläggande åtkomst som matchar jobbfunktionen, som utlöses av HR-systemhändelser.
• Åtkomstjusteringar: Bevilja ytterligare behörigheter när roller utökas och återkalla behörigheter när roller ändras.
• Regelbunden återcertifiering: Granska och validera åtkomst kvartalsvis.
• Avprovisionering: Återkalla åtkomst direkt när anställningen avslutas eller roller inte längre behöver Salesforce-åtkomst.

Implementera omcertifieringsprocesser för åtkomst när chefer regelbundet granskar och validerar sina teams behörigheter. Granskningsfrekvens baseras på krav på risk och efterlevnad.

Ditt ansvar: Implementera SCIM, utforma provisioneringsflöden, utför kvartalsvis omcertifiering.

Att dela upp data i flera organisationer ses ibland som ett rent kostnads- eller hemvistbeslut. Arkitektoniskt sett är det en säkerhetsavvägning och de styrande konsekvenserna hör hemma inom din åtkomstdesign.

Isolering är den viktigaste fördelen. Separata organisationer ger den starkaste möjliga gränsen mellan datauppsättningar. Det finns ingen kollektiv delningsmodell och ingen överlappning mellan behörigheter för arrendatorer, men det finns en tydlig regelgräns för jurisdiktioner som kräver en. Samma gräns fragmenterar styrningen. Varje åtkomstkontroll som du endast behöver upprätthålla en gång inom en organisation (till exempel utformning av behörighetsuppsättningar, rollhierarki, härdning av kritisk påverkan-konton, baslinjer för Hälsokontroll, Händelseövervakning och SIEM-korrelation) multipliceras nu per organisation, vilket innebär att den måste upprätthålla enhetlighet över dem alla. Drift mellan organisationer skapar sin egen attackyta eftersom en behörighet som är åtstramad i en organisation och missad i en annan skapar en inkonsekvens som attacker kan hitta och utnyttja. Korsorganisationsintegreringar lägger till autentiserade Trust som inte fanns tidigare. Varje korsorganisationsintegrering är en anslutning som du behöver säkra och övervaka.

Därför är det viktigt att väga isoleringsfördelen mot styrningsmultiplikatorn innan du delar upp en organisation. Reservera flera organisationer för fall där ett hårt lokaliseringsmandat eller en kunds avtalsenliga isoleringskrav inte kan uppfyllas inom en enskild organisation. När du börjar använda den måste du utforma åtkomstmodellen, övervakningen och konfigurationsbaslinjerna som ska tillämpas identiskt i alla organisationer från början.

Ditt ansvar: Behandla ett beslut om flera organisationer som en säkerhetsavvägning, inte bara en kostnad. Om flera organisationer krävs, tillämpa åtkomstkontroller, övervakning och hälsokontrollbaslinjer enhetligt i alla organisationer och säkra varje korsorganisationsintegrering som en Trust.

Det är ditt ansvar att klassificera data, konfigurera kryptering och utforma sekretesskontroller.

Låt oss ta en närmare titt på hur du skyddar data och sekretess korrekt.

För att korrekt klassificera dina data måste du känna till dina data. Den övergripande arkitektoniska uppgiften är att förstå din verksamhetsdomän och upprätthålla ett datalexikon som katalogiserar vilka data du har, vad det innebär och var känsliga data finns. Du kan endast klassificera—eller skydda—data som du har identifierat först.

Upprätta ett dataklassificeringsschema som driver lämpliga skyddskontroller. En klassificeringsetikett skyddar ingenting på egen hand. Det är indata till kontrollerna du tillämpar, så varje klassificering du tilldelar måste mappa till ett konkret beslut om kryptering, åtkomst, lagring eller övervakning. Klassificeringsbeslut som fattas under datamodellering påverkar direkt krypteringskrav, åtkomstkontroller, lagringspolicyer och efterlevnadsskyldigheter.

På Salesforce använder vi ett system med fyra nivåer som tillhandahåller ett ramverk som du kan anpassa till din organisations lagstadgade krav och verksamhetsbehov. Många företag använder liknande modeller som är anpassade till branschstandarder (till exempel ISO 27001 och NIST). Din specifika implementering ska återspegla dina efterlevnadskrav (till exempel HIPAA, PCI DSS, GDPR och branschföreskrifter) och verksamhetssammanhang.

Tillämpa klassificering på fältnivå. En enskild kontopost kan innehålla offentliga fält (till exempel företagsnamn), konfidentiella fält (till exempel företagsintäkter) och begränsade fält (till exempel personnummer). Fältnivåsäkerhet måste återspegla dessa skillnader.

Klassificeringen blir verkställbar genom attributbaserad åtkomstkontroll, som läser de taggar du tilldelar och tillämpar åtkomstregler. Detta är ett metadatadrivet lager som kompletterar OWD och delningsregler.

Att anpassa ABAC till ditt klassificeringsschema låter plattformen:

• Begränsa åtkomsten till data som är märkta Begränsad eller Konfidentiell från själva klassificeringen istället för från en delningsregel som upprätthålls per objekt.
• Anpassa åtkomsten när en posts klassificering ändras över tid. En post som nyligen taggats som Reglerad ärver striktare åtkomst utan en manuell regeländring.
• Kombinera dataattribut (till exempel klassificering och känslighet) med användarattribut (till exempel avdelning och behörighet) och sammanhang (till exempel tid och plats) i ett enda auktoriseringsbeslut.

Utforma ABAC-policyer så att de stämmer överens med detta schema så att klassificering av ett fält som Begränsat är den åtgärd som driver dess åtkomstkontroller och håller tillämpningen förankrad till klassificeringen istället för att upprätthålla delningsregler separat.

Ditt ansvar: Definiera klassificeringsschema, utbilda datamodellerare, klassificera fält under design, konfigurera kontroller och justera ABAC-policyer till klassificeringsnivåerna så att taggar driver tillämpning.

Börja med den information som plattformen redan tillhandahåller för varje organisation. Data i vila krypteras som standard. Hyperforce tillämpar volymnivåkryptering som skyddar en hel lagringsvolym under en enda nyckel som Salesforce äger och hanterar. Denna baslinje är alltid på och transparent för din lösning, men den fungerar på volymnivå (inte per fält), så att välja vad som ska krypteras och styras inom nyckelns livscykel ligger hos plattformen, inte hos dig.

Om denna baslinje inte kan uppfylla en efterlevnads-, kontrakts- eller dataklassificeringsskyldighet, använd Shield Platform Encryption. Mer specifikt, om du behöver en av de tre saker som volymnivåkryptering inte ger:

• Styr nyckellivscykeln så att du själv kan skapa, rotera och återkalla nyckelmaterialet
• Selektivitet över vilka standardfält, egna fält, filer och bilagor som krypteras vid vila
• Möjligheten att göra data oåtkomliga för Salesforce.

Begränsade data och data som är under uttryckliga lagstadgade nyckelkontrollmandat (till exempel HIPAA, PCI DSS och GDPR) är de vanliga utlösarna. Baslinjen täcker redan skydd på infrastrukturnivå för allt annat.

Shield Platform Encryption krypterar på fältnivå och erbjuder två scheman som byter säkerhet mot sökbarhet.

Probabilistisk kryptering är ett starkt standardschema, men fälten som krypteras med det kan inte användas i filterkriterier, sortering eller aggregeringsfunktioner (till exempel funktionerna MAX(), MIN() och COUNT_DISTINCT().

Deterministisk kryptering möjliggör exakt matchningsfiltrering i rapporter, listvyer och SOQL WHERE-klausuler – skiftlägeskänsliga eller ej skiftlägeskänsliga – med reducerad styrka eftersom samma klartext alltid producerar samma chiffertext.

Vi rekommenderar att kryptera med det probabilistiska schemat som standard och reservera deterministisk kryptering för de specifika fält som du måste filtrera eller sortera. Utvärdera dessa kompromisser under utformningen av datamodeller, inklusive påverkan på formelfältreferenser, rapportaggregering och SOQL-operationer.

Kundstyrda nycklar finns i två olika former:

• Med Bring Your Own Key (BYOK) kan du skapa nyckelmaterial utanför Salesforce—med hjälp av dina egna kryptobibliotek, hanteringssystem för företagsnycklar eller hårdvarusäkerhetsmoduler—och leverera det till plattformen.
• Endast-cache-nyckel-tjänsten håller din datakrypteringsnyckel i en nyckeltjänst som du styr. Salesforce hämtar den på begäran istället för att lagra den.

Båda formulären låter dig rotera och förstöra nyckelmaterial enligt ditt eget schema. Att förstöra nyckelmaterial gör att de data som det skyddade inte går att återställa, vilket är en kraftfull, avsiktlig kontroll istället för en rutin. Det är även viktigt att dokumentera dina rutiner för nyckelrotation och återkallande.

Alla integreringar måste använda TLS 1.2 eller senare (Salesforce Platform tillämpar detta), men du måste implementera certifikatbaserad ömsesidig autentisering för integreringar som hanterar begränsade data (med din egen konfiguration).

Ditt ansvar: Bestäm var plattformens baslinje på volymnivå räcker och var en efterlevnads-, kontrakts- eller klassificeringsskyldighet motiverar Shield Platform Encryption, välj sedan krypteringsscheman, välj och hantera en kundstyrd nyckelstrategi och implementera certifikatbaserad autentisering för känsliga integreringar.

Skydda känsliga data i icke-produktionsmiljöer med strategier som förhindrar att begränsade data kommer in i sandboxar.

• Delvis sandboxkopiering utesluter begränsade data från sandboxuppdateringar.
• Datamaskeringsregler förvirrar känsliga fältvärden i sandboxar genom att använda mönster som bevarar dataegenskaper.
• Syntetiskt dataskapande gäller för utvecklingsmiljöer som aldrig kräver produktionsdata.
• Sandboxmallar definierar vilka objekt och fält som ska inkluderas i varje sandboxtyp.

Att utforma för efterlevnadstester är ett arkitektoniskt ansvar. Bygg utvecklings- och testcykler på syntetiska data med realistiska egenskaper, så att team kan validera mot produktionsliknande förhållanden medan reglerade data håller sig inom produktionsgränsen.

Ditt ansvar: Utforma sandboxstrategi, konfigurera Data Mask regler, skapa syntetiska testdata.

Utforma lösningar som respekterar användarens integritet via arkitektoniska beslut.

• Dataminimering: Samla in data som endast behövs för angivna verksamhetssyften. Utmana varje fälttillägg genom att fråga "Vilket arkitektoniskt beslut kräver dessa data?" Kom ihåg att de säkraste data är de data du aldrig samlar in.
• Syftesbegränsning: Utforma dataåtkomstmönster som tillämpar syftesbegränsning tekniskt. Använd behörighetsuppsättningar och delningsregler för att begränsa åtkomst till data baserat på en jobbfunktions syfte. Till exempel bör marknadsföringsanvändare inte få åtkomst till detaljer om supportkundcase om inte deras jobb kräver det.
• Samtyckeshantering: Implementera samtyckesspårning på individnivå för marknadsföring, analys och valfri databearbetning. Utforma arbetsflöden för tillbakadragande av samtycke som propagerar över integrerade system. Med andra ord, samtycke är detaljerat och syftesspecifikt.
• Registrerades rättigheter: Bygg arbetsflöden för åtkomstbegäranden (till exempel att tillhandahålla datakopior), rättelse (till exempel att korrigera felaktigheter), radering (till exempel att ta bort data när det är tillåtet enligt lag) och portabilitet (till exempel att exportera till ett maskinläsbart format). Utforma dessa arbetsflöden så att de slutförs inom den svarstid som varje styrande ramverk ålägger. Dessa deadlines varierar beroende på jurisdiktion—och de ändras periodiskt—så det är viktigt att parametrisera arbetsflödets servicenivåavtal från en bibehållen efterlevnadskälla och bekräfta varje fönster mot den styrande förordningen (istället för att hårdkoda ett enskilt värde).

Ditt ansvar: Utforma datamodeller med minimering, konfigurera åtkomst efter syfte, implementera samtyckesflöden, bygg automatisering av registrerades rättigheter.

Datalagring är ett arkitektoniskt beslutsval som du gör innan provisionering, inte en inställning som du växlar efteråt. Hyperforce erbjuder regional distribuering—men en region finns endast där Salesforce driver en—och en organisations hemvist är fast vid provisioneringen. Ditt ansvar är att fastställa var varje datakategori måste finnas, bekräfta om en lämplig region är tillgänglig och utforma de dataöverföringsmekanismer som lagligen korsar gränser.

Istället för att som standard lagra i landet är det viktigt att klassificera dina bosättningsskyldigheter innan du börjar.:

• Obligatorisk lokalisering. En liten uppsättning jurisdiktioner kräver att vissa uppgifter stannar inom nationella gränser (ibland gäller detta endast reglerade sektorer). Om Salesforce inte är verksamt i en region i landet kan inbyggd lagring inte uppfylla mandatet på egen hand, så du behöver ett överlägg för datalagring eller en separat organisation för dessa data. Eftersom denna lista kan ändras är det viktigt att bekräfta det specifika mandatet mot den styrande förordningen.
• Redovisningsbaserade ramverk. De flesta regimer tillämpar inte ett lokaliseringsmandat. De är nöjda med ett regionalt nav med en lämplig gränsöverskridande överföringsmekanism. I dessa fall baseras beslutet på vilken region som minimerar latens och förenklar efterlevnad.

När data korsar en gräns är poängen medvetenhet innan konfiguration. Med andra ord måste du veta vilka överföringar som sker och på vilken rättslig grund, och sedan utforma åtkomsten så att data styrs från början till slut. Där sådana finns medför beslut om adekvat skyddsnivå minst friktion. Bindande företagsregler (BCR) och standardavtalsklausuler (SCC) täcker de flesta återstående överföringar. Använd endast uttryckligt samtycke som en sista utväg.

Para ihop överföringsmekanismen med restriktiv poståtkomst (till exempel privata OWD:er och syftesomfångsdelning) så att en tillåten överföring inte blir för bred. Dokumentera dataflödeskartor för att visa var varje datakategori kommer ifrån, transiteras och finns. Gå tillbaka till dem när föreskrifter eller regionala tillgänglighet ändras.

Ditt ansvar: Klassificera hemvistskyldigheter per datakategori, bekräfta regional tillgänglighet innan provisionering, välj överföringsmekanismer (adekvans, BCR/SCC) för gränsöverskridande flöden och dokumentera dataflödeskartor.

Det är ditt ansvar att utforma lösningar som upprätthåller den efterlevnad som plattformen tillhandahåller.

Denna vägledning är riktad. Lagstadgade krav varierar beroende på jurisdiktion och ändras över tid. Du måste alltid verifiera specifika skyldigheter mot den styrande förordningen (till exempel tillämplig stadga, tillsynsmyndighet eller Salesforces efterlevnadsdokumentation) för din distribuering.

Salesforce upprätthåller omfattande efterlevnadscertifieringar (finns på Trust.salesforce.com och compliance.salesforce.com): SOC 2 Type II, ISO 27001, FedRAMP (för Government Cloud-erbjudanden), HIPAA, PCI DSS och regionala certifieringar. Dessa certifieringar täcker Salesforces ansvar för plattformsinfrastruktur och delade tjänster.

Plattformscertifieringar minskar din efterlevnadsbörda, men de eliminerar inte ditt arkitektoniska ansvar. Dina egna objekt, Apex kod, integreringar och konfigurationer måste upprätthålla den efterlevnad som plattformen tillhandahåller.

Ditt ansvar: Utforma lösningar som upprätthåller efterlevnad, dokumentera hur arkitektur uppfyller lagstadgade krav.

• Aktivera Shield Platform Encryption för alla fält som innehåller skyddad hälsoinformation.
• För efterlevnad av HIPAA, aktivera fältgranskningsloggen med lagringspolicyer för att uppfylla HIPAA:s krav på registrering. Bekräfta den aktuella perioden mot den styrande förordningen.
• Konfigurera händelseövervakning för att upptäcka obehöriga åtkomstmönster för PHI.
• Implementera alla tekniska skyddsåtgärder som krävs enligt HIPAA-säkerhetsregeln, inklusive åtkomstkontroller, granskningsloggning och överföringssäkerhet.

• Implementera uppdelning av uppgifter (SoD) via behörighetsuppsättningsdesigner för att förhindra enskilda användare från att skapa och godkänna ekonomiska transaktioner.
• För PCI-miljöer, undvik att lagra fullständiga primära kontonummer (PAN) i Salesforce för att minimera efterlevnadsomfånget för PCI DSS.
• När det är möjligt, använd tokenisering av betalningsgateway.

• För GDPR och LGPD, utforma samtyckeshantering som samlar in detaljerat, syftesspecifikt samtycke.
• CCPA/CPRA följer en modell för att avböja. Tillhandahåll tydliga mekanismer för att avböja försäljning eller delning av personlig information istället för detaljerat syftesbaserat samtycke.
• Bygg arbetsflöden för registrerades rättigheter som slutförs inom varje ramverks svarstid och bekräftas mot den styrande förordningen.
• Implementera datalagringsautomatisering som rensar data när samtycket går ut.

• Använd Salesforce Government Cloud för reglerade myndighetsarbetsbelastningar.
• Implementera NIST 800-53-kontroller som är mappade till Salesforce-konfigurationen.
• Aktivera kontinuerlig övervakning via händelseövervakning som dirigeras till statlig SIEM-infrastruktur.

Ditt ansvar: Konfigurera Shield, Fältgranskningslogg, separering av uppgifter, samtyckeshantering, datalagring baserat på lagstadgade krav.

Dataskydds- och sekretessföreskrifter varierar avsevärt mellan olika jurisdiktioner — och specifika skyldigheter ändras snabbt — så denna nivå kräver beslutsfattande snarare än en tabell för varje land.

De två arkitektoniska inslagen är vistelse och gränsöverskridande överföring, som omfattas av dataskydd och integritet.

För att följa dessa föreskrifter måste du:

• Klassificera var varje datakategori måste finnas
• Bekräfta att en lämplig region finns innan provisionering
• Utforma en laglig överföringsmekanism för data som korsar en gräns.

Mer information finns i Dataresidens och suveränitet för mer information om beslutsramverket.

Allt utöver detta anses vara en tidpunktssiffra (till exempel vilken samtyckesmodell en jurisdiktion använder, tidsfristen för en begäran om registrerad, fönstret för att meddela tillsynsmyndigheter eller berörda individer efter en överträdelse och den kortaste lagringstiden för granskningsposter). Dessa siffror fastställs av föreskrifter, de skiljer sig åt per ramverk och de ändras i tillsynsmyndigheternas scheman.

Hårdkoda dem inte här. Du måste bestämma nästa steg baserat på den styrande förordningen för din distribuering — eller en underhållsefterlevnadskälla som refererar till en sådan — och anpassa din design till det snävaste fönstret i ditt verksamhetsavtryck.

Här är de hållbara arkitektoniska konsekvenserna som hör hemma i designen.

• En deadline för dataämnesbegäran som mäts i dagar med en enda siffra kan inte uppfyllas av en ad hoc manuell process, så du måste automatisera DSR-uppfyllande när du arbetar i en jurisdiktion med kort tidsfrist. Använd Experience Cloud för intag, Service Cloud för kundcasespårning, Sekretesscenter för upptäckt och Flöde för uppfyllande.
• Ett fönster för överträdelsenotis är för trångt för att improviseras, så du måste bygga arbetsflödet för överträdelsesvar i förväg. Bestäm avvikelseregler för händelseövervakning, förtilldelade roller, förutfattade notiser om tillsynsmyndigheter och registrerade, och en omflyttningsväg som antar den snävaste deadlinen inom ditt fotavtryck. Enskilda notiser utlöses i allmänhet av en högriskanalys, så du måste inkludera en riskbedömning i arbetsflödet.
• Vissa jurisdiktioner kräver eller rekommenderar lagring av granskningsloggar i landet — med minimala tidsintervall på flera år — så du måste anpassa SIEM-lagringen till det längsta minimum inom ditt fotavtryck och bekräfta om loggar kan lämna jurisdiktionen.

Ditt ansvar: Utforma hemvist och överföring per Dataskydd och sekretess, automatisera arbetsflöden för DSR och överträdelsesvar till den snävaste deadlinen i ditt fotavtryck och bekräfta varje jurisdiktionsspecifik siffra mot den styrande förordningen istället för ett värde som skrivits in i denna guide.

Utforma för kontinuerlig validering av efterlevnad istället för granskningsförberedelser vid olika tidpunkter.

• Säkerhetshälsokontroll utvärderar konfigurationen mot Salesforces säkerhetsbaslinjer och ger riskbetyg. Kör kontroller regelbundet för att övervaka efterlevnaden av Salesforces grundläggande rekommendationer för säkerhet. Upprätthåll betyg på 80% eller högre (mycket bra eller utmärkta band).
• Händelseövervakning samlar in detaljerade loggar för användaraktivitet, API-anrop, autentiseringshändelser och dataåtkomstmönster. Dirigera händelseloggfiler till externa SIEM för långtidslagring som överskrider inbyggda lagringsgränser.
• Transaktionssäkerhet utvärderar händelser mot policyer i realtid och kan blockera händelser, kräva en ökning av MFA eller meddela dig om policybrott.

Det är viktigt att automatisera efterlevnadskontroller i distributionspipelines för att validera att distribueringar inte försvagar behörighetsmodeller, inaktiverar granskningsinställningar eller introducerar konfigurationer som inte följer reglerna.

Ditt ansvar: Kör Hälsokontroll varje kvartal, dirigera händelseövervakning till SIEM, konfigurera transaktionssäkerhetspolicyer, automatisera validering av efterlevnad i CI/CD.

Utforma strategier för granskningsloggar som baseras på efterlevnadskrav, undersökningsbehov och lagringsskyldigheter.

För reglerade miljöer, implementera händelseövervakning med extern SIEM-integrering för långsiktig logglagring och korssystemkorrelation. Utforma fältgranskningsloggpolicyer som täcker alla fält med begränsningar och konfidentiella fält som omfattas av lagstadgade krav på registrering.

Ditt ansvar: Aktivera Fältgranskningslogg för känsliga fält, dirigera händelseövervakning till SIEM, konfigurera transaktionssäkerhetspolicyer.

Det är ditt ansvar att integrera säkerhet genom hela utvecklingen, inte som en eftertanke.

Integrera säkerhetsrutiner så tidigt som möjligt i utvecklingsfasen. Hotmodellering under arkitekturfasen förhindrar sårbarheter på designnivå. Säkerhetskrav som samlats in tillsammans med funktionella krav förhindrar dig från att behandla säkerhet som en eftertanke.

Säkerhetsfel kostar betydligt mer att åtgärda när de upptäcks i produktion än under design- eller utvecklingsfaserna. En säkerhetsbrist på designnivå som upptäcks under arkitekturgranskning kanske bara tar en konversation att åtgärda. Om samma fel hittas i produktion krävs dock omarkitektur, datamigrering, avhjälpande av efterlevnad och meddelande om potentiella överträdelser.

Därför arbetar vi med skift-vänster-säkerhet, som fokuserar på:

• Hotmodellering innan design slutförs
• Säkerhetskrav i användarberättelser
• Säker kodningsutbildning för utvecklare
• Statisk analys som är integrerad i IDE
• Säkerhetsfokuserad kodgranskning
• Automatiserade säkerhetstester i CI/CD
• Säkerhetsvalidering innan produktionsdistribuering

Ditt ansvar: Utför hotmodellering, utbilda utvecklare, integrera Code Analyzer i CI/CD, kräv säkerhetsmedveten kodgranskning.

Det är viktigt att utforma försvar mot vanliga sårbarheter i ett Salesforce-sammanhang. Låt oss ta en närmare titt på hur vi mappar till 2025 OWASP Top 10 på Salesforce.

• A01:2025 – Kontroll av bruten åtkomst: Tillämpa CRUD och fältnivåsäkerhet (FLS) programmatiskt i all Apex dataåtkomst.
  • I API version 67.0 eller senare körs Apex i användarsammanhang som standard, vilket innebär att den aktuella användarens behörigheter och FLS tillämpas under kodkörning.
    • MED SECURITYENFORCED togs bort, vilket orsakar ett kompileringsfel. Ersätt befintliga användningar med MED USER_MODE. Plattformen tillämpar åtkomst i standardgränssnitt.
  • I API version 66.0 eller tidigare är systemläget standard. Använd MED USERMODE i SOQL-frågor eller Security.stripInaccessible() för DML-operationer.
• A01:2025 - Data API:n på klientsidan: Lightning Data Service och användargränssnittets API tillämpar automatiskt den aktuella användarens FLS, CRUD och delning, så en komponent som är byggd på dem ärver minst behörighet som standard.
  • Detta skydd förloras när en komponent anropar en egen Apex. Imperativ Apex tillämpar endast åtkomst när den körs i användarläge, så en klass som deklareras utan delning fungerar som en utrymningslucka som tyst förbigår modellen.
  • Använd Lightning Data Service och användargränssnittets API för dataåtkomst.
  • Du måste bekräfta CRUD, FLS och delning igen för varje viktigt Apex från en komponent.
• A02:2025 - Säkerhetsfelkonfiguration: Övervaka konfigurationsdrift från säkerhetsbaslinjer med hjälp av Hälsokontroll.
  • Inaktivera gästanvändaråtkomst på Experience Cloud-webbplatser (om det inte uttryckligen krävs enligt en dokumenterad verksamhetsmotivering).
• A05:2025 - Injektion: Kategorin 2025 Injektion omfattar SOQL/SOSL-injektion och skript för flera webbplatser (XSS).
  • För sökfrågeinjektion, använd bundna variabler för alla dynamiska sökfrågor. Sammanlänka aldrig användarinmatning direkt i sökfrågesträngar. Plattformens parametriserade sökfrågemekanismer eliminerar injektionsrisk när de används korrekt.
  • SOQL- eller SOSL-injektioner är begränsade till en läsning som avslöjar poster eller fält som anroparen inte bör kunna nå genom att utöka sökfrågevillkoren. Eftersom dessa språk läser data medan skrivningar körs genom separata DML-operationer skapar detta en risk för åtkomstkontroll och sekretess eftersom det förvärras när objekt- och fältbehörigheter inte tillämpas för sökfrågan.
  • För XSS ger Lightning automatiskt skydd via LWC-återgivningsmotorn.
  • För Aura-komponenter och Visualforce måste du tillämpa plattformskodningsfunktioner (till exempel HTMLENCODE, JSENCODE och URLENCODE) när du återger dynamiskt innehåll.

Ditt ansvar: Tillämpa CRUD/FLS i egen kod, tillämpa kodningsfunktioner, använd bundna variabler, övervaka konfigurationsdrift.

Utforma CI/CD-pipelines med säkerhetsgrindar i varje steg. Säkerhet måste automatiseras för att skalas med utvecklingshastighet.

Låt oss ta en närmare titt på pipelinesäkerhetsstegen.

• Källkontroll använder filialskyddsregler med obligatoriska kodgranskningar. Det finns inga direkta åtaganden till huvudgrenar eller undertecknade åtaganden.
• Statisk analys använder Salesforce Code Analyzer, som innehåller PMD, ESLint och RetireJS för att upptäcka injektioner, XSS och osäkra mönster.
• Säkerhetsskanning använder SAST-verktyg och upptäckt av hemligheter för att förhindra inloggningsuppgifter och skanning av beroendesårbarhet.
• Behörighetsvalidering använder automatiserade jämförelsetekniker för att granska behörighetsändringar mot säkerhetsbaslinjer, vilket skickar varningar om utökad behörighet.
• Distribueringsgrindar avbryter distribuering av viktiga säkerhetsbrister som kräver godkännande av säkerhetsteam för ändringar av behörigheter.
• Övervakning efter distribuering använder händelseövervakningsvarningar för avvikande beteenden efter distribueringar.

Ditt ansvar: Integrera Code Analyzer i CI/CD, konfigurera grenskydd, implementera distributionsgrindar, validera behörigheter automatiskt.

Omfattande säkerhetstester inkluderar flera tekniker som hanterar olika sårbarhetsklasser. Låt oss ta en närmare titt på varje strategi.

• Statisk analys kör Salesforce Code Analyzer i utvecklar-IDE:n för omedelbar feedback och i CI/CD-pipeline som automatiserade grindar. Statisk analys identifierar sårbarheter i källkod utan att köra programmet.
• Penetrationstester utför penetrationstester för egna program som exponeras för opålitliga användare, särskilt Experience Cloud-webbplatser och offentliga API:n.
  • För AppExchange och AgentExchanges säkerhetsgranskning krävs alltid statiska analysrapporter.
  • En dynamisk skanningsrapport (penetreringstest) krävs när lösningen integrerar ett webbprogram eller en tjänst från tredje part.
  • Penetreringstest simulerar attackertekniker mot liveprogram.
• Säkerhetsfokuserade enhetstester skriver Apex tester som validerar tillämpningen av åtkomstkontroll genom att köra som användare med olika behörighetsprofiler. Det är viktigt att verifiera att CRUD/FLS-tillämpning blockerar obehörig åtkomst.
• Beroendeskanning bevakar AgentExchange-paket och JavaScript-bibliotek för kända sårbarheter. Det är viktigt att prenumerera på säkerhetsråd för installerade paket.

Ditt ansvar: Kör Code Analyzer, utför penetrationstester, skriv säkerhetsenhetstester, skanna beroenden.

På Salesforce fokuserar säkerhet och dataincidentsvar på att upptäcka, innehålla och återställa från överträdelser, obehörig åtkomst och skadlig dataförstöring. Incidenthanteringsteam arbetar tillsammans med två närliggande pelare som äger angränsande ansvar:

• Operational Excellence omfattar den operativa maskinen för incidenthantering (till exempel allvarlighetsnivåer, jourrotation, omflyttning och granskning efter incident)
• Tillförlitlighet täcker tillgänglighetsåterställning mot RTO- och RPO-mål, inklusive säkerhetskopiering och katastrofåterställningsstrategi.

Som arkitekt är det ditt ansvar att utforma för upptäckbarhet, svar och återställning av säkerhetsincidenter.

Detekterbarhet är en arkitektonisk kvalitet som du uttryckligen måste utforma. Utan omfattande övervakning kan säkerhetsincidenter förbli oupptäckta under längre tidsperioder.

Det är viktigt att implementera upptäckt genom flera kanaler.

• Händelseövervakning samlar in råa händelseloggar som täcker inloggningar, rapport- och dataexporter, behörighetsändringar och API-anrop. Du måste identifiera vilka händelser som är avvikande, vilket kräver transaktionssäkerhetspolicyer eller SIEM-korrelation ovanpå de loggar du konfigurerar för att avgöra detekteringslogiken.
• Transaktionssäkerhetspolicyer utvärderar händelser i realtid och blockerar misstänkta åtgärder. Du måste konfigurera dessa policyer.
• Konfigurationsgranskningslogg följer de administrativa ändringar som plattformen tillhandahåller, men du måste övervaka dem.
• Egen programloggning samlar in säkerhetsrelevanta händelser i Apex som du behöver implementera.

Dirigera händelseövervakningsloggar till SIEM-plattformar för korrelation med företagets säkerhetstelemetri. Utforma varningsregler som upptäcker misstänkta mönster och samtidigt minimerar falska positiva resultat genom beteendebaslinjer.

Ditt ansvar: Dirigera händelseövervakning till SIEM, konfigurera transaktionssäkerhetspolicyer, implementera egen loggning, etablera beteendebaslinjer.

Det är viktigt att dokumentera arkitektoniska beslut som stöder incidentsvar innan incidenter inträffar.

• Isoleringsgränser utformar lösningar för att isolera komprometterade komponenter utan att störa viktiga verksamhetsfunktioner. Du måste konfigurera återkallande av behörighetsuppsättning, IP-begränsningsändringar och sessionsavslut för att ge snabb isoleringskapacitet.
• Forensiskt bevarande använder händelseövervakning för att tillhandahålla detaljerade aktivitetsloggar (plattformsfunktion). Fältgranskningslogg bevarar dataändringshistorik baserat på din konfiguration. Designloggar dirigeras till oföränderlig lagring så att hackers inte kan ändra din arkitektur.
• Återställningsprocesser dokumenterar testade återställningsprocesser för vanliga incidenttyper. Det är viktigt att validera säkerhetskopieringsintegritet regelbundet. Du behöver känna till ditt mål för återställningstid (RTO) och mål för återställningspunkt (RPO) för scenarion med säkerhetsincidenter.
• Kommunikationsflöden utformar notismekanismer som fungerar under incidenter (till exempel kommunikationskanaler utanför bandet, färdigutformade mallar och omflyttningsprocesser som inte är beroende av potentiellt komprometterade system).
• Kanalen för sårbarhetsvisning är till för Experience Cloud-webbplatser som visas offentligt. Den ger externa forskare ett dokumenterat, övervakat sätt att rapportera säkerhetsproblem till dig via en visningspolicy som publiceras i standarden RFC 9116 security.txt. En extern rapport är ofta den första signalen för en incident, så det är viktigt att etablera denna intagningsväg som en del av den arkitektur du är ansvarig för.

Ditt ansvar: Dokumentisoleringsprocesser, dirigera loggar till oföränderlig extern lagring, testa återställningsprocesser varje kvartal, etablera kommunikation utanför bandet och publicera en kanal för att avslöja sårbarhet för offentliga webbplatser.

På Salesforce är det viktigt att förbereda svarskapacitet för plattformsspecifika scenarion.

• Försämrade användarkonton upptäcks via avvikelser i inloggningen för händelseövervakning (till exempel oväntad geografi, ovanliga tider och nya enheter). Om konton äventyras, frys användaren, tvinga återställning av inloggningsuppgifter, gå igenom granskningsloggen för inställningar och dataåtkomstloggar för att avgöra kompromissperioden.
• Exfiltrering av massdata upptäcks via exporter av händelseövervakningsrapporter och avvikelser i API-dataåtkomstvolym. När dataexfiltrering inträffar, återkalla sessioner omedelbart, begränsa behörigheter och identifiera poster och klassificeringsnivåer som påverkas.
• Oauktoriserad koddistribuering upptäcks via distributionsövervakning och ändringar av konfigurationen för Inställning av granskningslogg. När oauktoriserad kod distribueras, dra omedelbart tillbaka distributionen och granska alla ändringar från den komprometterade inloggningsuppgifterna för distributionen.
• Omflyttning av behörigheter upptäcks via övervakning av granskningslogg för behörighetsändringar som är utanför godkända ändringsfönster. När omflyttning av privilegier inträffar, återkalla omedelbart omflyttade privilegier och granska aktiviteter som utförts med utökad åtkomst.

Ditt ansvar: Dokumentera svarsprocesser för plattformsspecifika scenarion, konfigurera övervakning för att upptäcka varje scenario, testa procedurer genom tabellövningar.

Efter en incident är det viktigt att utföra en omdömesfri granskning efter incident som fokuserar på arkitektoniska förbättringar. Du måste dokumentera vad som hände, varför de befintliga kontrollerna inte kunde förhindra eller upptäcka incidenten och vilka arkitektoniska ändringar som behövs för att minska framtida risker.

Granskningsmål efter incident:

• Bestäm tekniker för incidenttidslinje och attacker.
• Identifiera de kontrollfel som aktiverade incidenten.
• Dokumentera alla arkitektoniska svagheter som incidenten avslöjade.
• Prioritera sanering som baseras på riskminskning.
• Dela lärdomar mellan team.
• Uppdatera detektionsregler och svarsprocesser.

Det är viktigt att följa incidentmått över tid för att avgöra genomsnittlig tid att upptäcka (MTTD), genomsnittlig tid att svara (MTTR) och påverkanomfång.

Ditt ansvar: Utför en snabb granskning efter incidenten, dokumentera förbättringar i ADR, följ trender för MTTD och MTTR, dela med dig av dina erfarenheter.

Använd denna checklista under arkitekturgranskningar, innan produktionsdistribuering och regelbundet för löpande utvärdering. Varje objekt representerar ditt ansvar som Salesforce-arkitekt.

Delat ansvar

• Dokumentera allt som Salesforce säkrar (till exempel certifieringar för infrastruktur, plattform och efterlevnad).
• Dokumentera allt du måste säkra (till exempel konfiguration, åtkomst, egen kod och datastyrning).
• Identifiera områden med delat ansvar (till exempel incidentsvar, sårbarhetshantering och övervakning).
• Kommunicera ansvar till intressenter och implementeringsteam så tydligt och koncist som möjligt.

Säkerhetsarkitektur

• Slutför hotmodellering med STRIDE-metoden innan du börjar bygga.
• Tillämpa djuplodande kontroller på data-, program-, identitets- och integreringslager.
• Implementera noll-trust principer som kräver uttrycklig verifiering för varje åtkomstbegäran.
• Upprätthåll aktuellt lager av säkerhetstillgångar som täcker känsliga data, integreringar, API och privilegierade konton.
• Dokumentera beslut om säkerhetsarkitektur i ADR, inklusive hotanalys och kontrollmotivering.
• Säkra sidhuvudlösa klienter och klienter på uppdrag vid Salesforce Trusts gräns genom att propagera identiteter per användare istället för pooltokens.
• Lagra, rotera och OAuth-inloggningsuppgifter med minst behörighet via externa klientappar.
• För behållarintegreringar, tillämpa behållarisolering som en säkerhetsgräns, kryptera VPN-trafik mellan behållare och hybrider med mTLS (när ramverket kräver det) och anpassa distributionsregioner efter datalagring och efterlevnadscertifieringar

Identitets- och åtkomsthantering

• Sätt OWD till Privat för objekt som innehåller känsliga data.
• Reservera Offentlig skrivskyddad för objekt där bred läsåtkomst är ett dokumenterat krav.
• Tillämpa MFA för all åtkomst till produktionsgränssnittet och hårdvarusäkerhetsnycklar för privilegierade konton. API-integreringar som endast använder JWT Bearer eller klientuppgifter undantas.
• Implementera SSO med SAML 2.0 eller OpenID Connect med stark IdP-autentisering.
• Använd OAuth 2.0 (JWT-bärare föredras) för all API-autentisering. Använd aldrig OAuth 2.0 för inbäddade inloggningsuppgifter.
• Bevilja åtkomst via behörighetsuppsättningar som baseras på dokumenterade krav på minst behörighet.
• Tillämpa utökade kontroller för konton med kritisk påverkan (till exempel IP-begränsning, inloggningsvarningar och periodiska åtkomstgranskningar).
• Utför regelbundna åtkomstgranskningar med dokumenterade intyg för konton med hög behörighet där frekvensen avgörs av organisationens risktolerans och efterlevnadskrav.
• Automatisera identitetens livscykel via SCIM-provisionering och 90-dagars detektering av vilande konto.
• Kör anställdas agenter i den inloggade användarens sammanhang och provisionera dedikerade agentanvändare med minst behörighet för kundagenter. Gör aldrig detta för en gästanvändare på en offentlig webbplats.
• Implementera JWT för agentautentisering med hjälp av identifierare för agentinstans och botdefinition.
• Definiera ABAC-policyer som överensstämmer med dataklassificering och enhetliga standarder för metadatataggning.

Dataskydd och sekretess

• Klassificera alla data och tillämpa skyddskontroller som är lämpliga för varje klassificeringsnivå.
• Aktivera Shield Platform Encryption för begränsade data med dokumenterad nyckelhantering.
• Kräv TLS 1.2+ för alla integreringar med certifikatbaserad autentisering för begränsade data.
• Förhindra att begränsade data kommer in i icke-produktionsmiljöer via maskering eller uteslutning.
• Implementera samtyckeshantering med detaljerade arbetsflöden för spårning och tillbakadragande per syfte.
• Bygg arbetsflöden för registrerades rättigheter som slutförs inom varje styrande ramverks svarstid. Dessa ska vara av den storlek som är kortast i ditt verksamhetsavtryck och parametriseras per jurisdiktion från en upprätthållen efterlevnadskälla där varje siffra bekräftas mot den styrande förordningen.
• Dokumentera kraven för datalagring och validera Hyperforce regionanpassning.

Efterlevnad och regelefterlevnad

• Validera plattformscertifieringar som uppfyller lagstadgade krav för din bransch.
• Aktivera händelseövervakning med SIEM-dirigering för lagring som överskrider inbyggda lagringsgränser.
• Konfigurera fältgranskningsloggen så att den täcker begränsade fält för att säkerställa att lagringen uppfyller lagstadgade minimikrav.
• Upprätthåll betyg för säkerhetshälsokontroll på 80 % eller högre (mycket bra eller utmärkt band) och dokumentera eventuella undantag.
• Automatisera validering av efterlevnad för CI/CD-pipelines som går sönder under kritiska överträdelser.
• Implementera transaktionssäkerhetspolicyer för upptäckt och svar på avvikelser i realtid.

Säker utvecklingslivscykel

• Utför hotmodellering under designfasen (innan du gör betydande bygginvesteringar).
• Tillämpa CRUD/FLS i alla Apex miljöer.
• Förlita dig på automatisk tillämpning av användarläge för API version 67.0 eller senare, eller använd MED USERMODE eller stripInaccessible() för API version 66.0 eller tidigare.
• Använd inte MED SECURITYENFORCED, som togs bort i API version 67.0.
• Kör Salesforce Code Analyzer i CI/CD när viktiga upptäckter blockerar distribuering.
• Kräv kodgranskningar av säkerhetsmedvetna granskare för alla produktionsändringar.
• Utför penetrationstester för alla offentliga program och Experience Cloud-webbplatser.
• Validera och rengör all användarinmatning som förhindrar injektion i SOQL-, SOSL- och HTML-sammanhang.

Säkerhetsincidentsvar

• Utforma varningsregler för händelseövervakning för att upptäcka misstänkta mönster via beteendebaslinjer.
• Dirigera loggar till oföränderlig extern lagring för rättsmedicinskt bevarande.
• Dokumentera och testa incidentsvarsprocesser för plattformsspecifika scenarion.
• Utför klanderfria granskningar efter incidenter med ADR för att samla in arkitektoniska förbättringar.
• Följ MTTD- och MTTR-mått för att identifiera upptäckts- och svarsluckor.

Dela din feedback om det välarkitektoniska ramverket.