Trust

Hos Salesforce er Trust vores største værdi. Det er grundlaget for enhver arkitektonisk beslutning på platformen. For arkitekter opnås Trust gennem et unikt partnerskab: Salesforce leverer en sikker, kompatibel platform – infrastruktur, metadata og værktøjer til at gøre den til din egen – mens du designer sikre løsninger, der er afhængige af dette fundament.

Dette partnerskab fungerer gennem Modellen for delt ansvar, som er en ramme, der tydeligt opdeler sikkerhedsansvar:

• Salesforce er ansvarlig for sikkerheden for platformen, herunder infrastruktur, fejlretning og overensstemmelsescertificeringer.
• Du er ansvarlig for sikkerheden på platformen, herunder konfiguration, adgangskontrol, tilpasset kode og dataadministration.

Denne division er vigtig, fordi den definerer arkitektonisk ansvarlighed. Salesforce kører en arkitektur med flere lejere, hvor tusindvis af organisationer deler infrastruktur. Platformen giver stærke sikkerhedsbeskyttelser på infrastrukturniveau. Dine arkitektoniske beslutninger bestemmer, om dine specifikke løsninger opnår interessenters tillid.

Den delte ansvarsmodel stiller dig til ansvar for at designe sikre løsninger, mens fysisk sikkerhed, netværksbeskyttelse, platformsfejlretning og infrastrukturkryptering håndteres for dig. Dette giver dig mulighed for at fokusere på at designe sikre løsninger, der er bygget på dette grundlag (f.eks. Identitets- og adgangsstyring, databeskyttelse, integrationssikkerhed, sikre udviklingspraksisser, overholdelse og overholdelse af bestemmelser og hændelsessvarfunktioner).

Forsinkelse Trust under design sammensætter teknisk gæld. En manglende krypteringsstrategi bliver en dyr tilpasning, når bestemmelserne ændres. En ikke-administreret integration bliver en sårbarhed, når legitimationsoplysninger kompromitteres. Det er altid billigere at opbygge Trust fra starten end at montere den senere.

Trust strækker sig over fire arkitektoniske dimensioner, der arbejder sammen:

• Sikkerhedskontroller beskytter systemer og data
• Identitetsstyring styrer adgang
• Fortrolighedspraksisser respekterer brugeragentur
• Overensstemmelsesstrukturer opfylder bestemmelsesmæssige forpligtelser

Arkitekter, der designer til alle fire dimensioner, skaber løsninger, der opnår og opretholder Trust gennem gennemsigtighed, kontrol og modstandsdygtighed.

I agenttiden udvides Trust til den betroede kontekst, som agenterne opererer i. Sikret kontekst betyder, at agenter får adgang til administrerede, bekræftede data med tydelige identitets- og tilladelsesgrænser, hvilket gør det muligt for AI-systemer at begrunde og reagere på vegne af brugere, mens de også vedligeholder sikkerhed, revisionsmulighed og compliance. Design af betroet kontekst er grundlæggende for Agent Enterprise-arkitekturen.

Denne søjle etablerer den basislinje for platformssikkerhed, som hver Salesforce-løsning afhænger af. Søjlen Agent Trust bygger på denne basislinje for at håndtere risici, der er unikke for autonome agenter, herunder hurtig indsprøjtning, styring af handlinger og de data, som agenter kan få adgang til under retningstidspunkter. Det er vigtigt at designe basislinjen først og derefter lagere agentspecifikke kontrolelementer ved brug af retningslinjerne for Agent Trust.

Denne søjle forbinder dybt med andre strukturproblemer.

• Pålideligheden afhænger af infrastruktur, der modstår angreb og genopretter fra indbrud.
• Operational Excellence kræver sikre implementeringspipelines og hændelsessvar.
• Retfærd kræver gennemsigtig, etisk håndtering af data og algoritmiske beslutninger.

Sammen udgør disse søjler en samlet, løsningsorienteret tilgang, som organisationer kan Trust med deres mest følsomme operationer.

I Modellen for delt ansvar skal Salesforce og arkitekter opfylde deres respektive ansvar for at opretholde Trust. Lad os se nærmere på, hvad hver side skal sikre.

Salesforce er ansvarlig for at sikre platformen og dens globale infrastruktur, herunder:

• Datacenteradgangskontrol, overvågning og miljøsikkerhed
• For Hyperforce håndterer den underliggende cloududbyder (f.eks. AWS, Azure eller Google Cloud, afhængigt af forekomsten) fysisk datacentersikkerhed via uddelegeret ansvar. Salesforce Infrastruktur- og underprocessordokumentationen identificerer udbyderen og underprocessorer for hver tjeneste.

• Sikkerhedskontroller på netværkslag, herunder DDoS-beskyttelse og trusselregistrering
• Trafikkryptering under transit (TLS 1.2+) og inaktive (typisk AES-256)

• Sårbarhedssvar og implementering af platformsfejlretning via Salesforce (for flere oplysninger om sikkerhedsadviseringer kan du besøge security.salesforce.com)
• Administration af operativsystem og infrastrukturssikkerhed

• Certificeringer og attesteringer: Salesforce har SOC 1/2/3, ISO 27001/27017/27018, FedRAMP-godkendelse (dækket til Government Cloud Plus og MuleSoft Government Cloud, ikke den kommercielle multi-lejer-platform) og PCI DSS niveau 1-validering.
• Regulerende støtte: Dette gælder for HIPAA-berettigede tjenester med Business Associate Agreements (BAAs) eller GDPR-overensstemmelsesprogrammer.
• Hvis du ønsker yderligere oplysninger, kan du besøge Trust.salesforce.com og compliance.salesforce.com.

• Arkitektur for lejerisolering: En delt, metadatastyret kerne partitionerer hver organisations data og metadata efter organisations-id, så en organisation ikke kan få adgang til en anden organisations registreringer, selvom de begge kører på en delt infrastruktur. Kernen håndhæver adskillelse på hver forespørgsel, ikke gennem en konfiguration, som du skal vedligeholde.
• Kryptering på infrastrukturniveau på pause- og backup-infrastruktur: Basisplatformslicenser inkluderer Classic Encryption (AES-128 indeholder kun tilpassede tekstfelter). Shield Platform Encryption kræver en separat licens (AES-256 giver dig mulighed for at medbringe din egen nøgle og indeholder standardfelter og tilpassede felter, filer og vedhæftede filer).

Disse kontroller sikrer, at platformen forbliver sikker, pålidelig og kompatibel.

Du er ansvarlig for at sikre dine data, konfigurationer og driftsprocesser.

• Identitet og forening: For SSO (single sign-on) og MFA (Multi-factor authentication - Godkendelse med flere faktorer) skal du bekræfte brugerens identitet.
• Adgangsbegrænsning: Teknisk set begrænser IP-områder og logintidspunkter, hvordan og hvornår identiteter opretter forbindelse.
• Populære rettigheder (PoLP): Brug PoLP til kun at tildele adgang til roller, profiler og tilladelsessæt, der er nødvendige for at udføre individuelle arbejdsopgaver.
• Livscyklusstyring: Øv dig i administration af brugerlivscyklus, og få adgang til retningslinjer for gencertificering.

• Brug dataklassificering, maskering og sikkerhed på objekt-/felt-/registreringsniveau
• Håndhæv CRUD-tilladelser og delingsregler
• Ejer, tester og implementerer en gennemprøvet strategi til at gendanne din organisations data, så du sikrer, at datatab eller korruptionsgendannelse forbliver under din kontrol.

• Brug API-godkendelse (f.eks. OAuth 2.0 eller JWT) og navngivne legitimationsoplysninger.
• Aktiver dedikerede integrationsbrugere med PoLP-tilladelsessæt, så hver integrations adgang er omfanget og kan revideres separat fra menneskelige brugere.
• Sikker slutpunkter og ekstern systemvalidering.

• Brug Begivenhedsovervågning, revisionsspor og SIEM-integration (Security Information and Event Management).
• Følg hændelsessvarprocedurer og sikkerhedsgennemgange.

• Brug sikker tilpasset kode (f.eks. Apex eller Lightning) og inputvalidering.
• Kør Apex i brugertilstand, så tilladelserne objekt, felt og deling håndhæves i kode.
• Følg indsprøjtningsforebyggelse og sikre udviklingspraksisser.

• Vedligehold tilstanden Løsningsoverensstemmelse.
• Følg politikker for fortroligheds-/samtykkeadministration og databevarelse.

Nogle ansvarsområder kræver samarbejde:

• Sikkerhedshændelsesangreb: Begge parter deltager i registrerings- og svaraktiviteter.
• Sårbarhedsstyring: Salesforce fejlretter platformen, arkitekter fejlretter tilpasset kode.
• Sikkerhedsovervågning: Kombiner platformsgenererede sikkerhedssignaler med arkitektanalyser.
• Konformitetscertificeringer: Salesforce certificerer platformen (f.eks. SOC, ISO og FedRAMP for Government Cloud); arkitekter ejer det, der er bygget på den – tilpassede objekter, kode, integrationer og konfiguration – inden for den certificerede position for at levere bevis for overholdelse for revisioner.
• Identity federation: Salesforce har tillid til de påstande, som arkitektidentitetsudbyderen stiller. Arkitekter sikrer udbyderen og Trust-relationen mellem udbyderen og Salesforce.
• Nøglestyring: Ved at bruge kryptering af din egen nøgle kører Salesforce krypteringstjenesten, mens arkitekter genererer, roterer og tilbagekalder det nøglemateriale, der beskytter dataene.

Hvert designprincip, emneafsnit og kontrolelement i dette dokument repræsenterer dit ansvar som arkitekt. Den delte ansvarsmodel rammer, hvad du skal designe og konfigurere for at opnå Trust på Salesforce-platformen.

Grænsen udvides til at omfatte bestemmelsesmæssige forpligtelser. Salesforce vedligeholder platformens certificeringer og attesteringer og sikrer infrastrukturen mod brud. Architekter er ansvarlige for de forpligtelser, der er knyttet til dine data og jurisdiktion (f.eks.: hvilke love der gælder, hvordan data klassificeres, hvilke bevarelses- og samtykkeregler der gælder for dem, og hvordan du registrerer og rapporterer overtrædelser af data, der er under din kontrol). I modsætning til de gældende bestemmelser for dine implementeringer skal arkitekter bestemme de specifikke tal bag disse forpligtelser (f.eks. bevarelsesperioder og adviseringsfrister) i forhold til de gældende bestemmelser for din implementering, da de kan variere efter jurisdiktion og ændres over tid.

Brug disse principper til at guide dine arkitektoniske beslutninger for sikkerhed på platformen.

• Anvend null Trust på tværs af alle lag. Antag aldrig Trust baseret på netværksplacering, brugervenlighed eller systemoprindelse. Bekræft hver adgangsanmodning eksplicit med godkendelse, autorisation og kryptering på data-, applikations-, integrations- og infrastrukturlagene. Flere lejerarkitektur betyder, at du deler infrastruktur med tusindvis af organisationer, så det netværk, som din løsning kører på, er ikke en perimeter, du kan behandle som betroet. Bekræft hver anmodning på dens egne fordele – identitet, autorisation og kontekst – i stedet for at have tillid til den, hvor den stammer fra.
• Tildel mindst rettighed som standard. Tildel det mindste adgangsniveau, der er nødvendigt for hver bruger, integration og automatiseret proces for at opfylde dens formål. Start med de mest restriktive indstillinger – OWD'er for hele organisationen og minimale tilladelser – og udvid med vilje baseret på dokumenterede forretningskrav. Brug adgangsmodellen på fire lag (organisation → objekt → felt → registrering), så hvert lag yderligere begrænser lagene ovenfor.
• Implementer forsvar i dybden. Lag flere sikkerhedskontroller, så fejl i en kontrol ikke kompromitterer hele systemet. Kombiner forebyggende kontrolelementer (f.eks. CRUD/FLS-håndhævelse og transaktionssikkerhedspolitikker, der blokerer handlinger), kriminalkontrolelementer (f.eks. Begivenhedsovervågning) og responsive kontrolelementer (f.eks. Godkendelse og advisering for trinvis transaktionssikkerhed). Design hvert lag, som om de tilstødende lag kan mislykkes. Husk, at sikkerhed på feltniveau beskytter data, selv når delingsregler er for tilladende.
• Integrer sikkerhed efter design. Integrer trusselmodellering, sikkerhedskrav og kontrolvalidering i hver arkitektonisk fase fra det indledende koncept til igangværende udvikling. Udfør trusselmodellering af typen Spoofing, Tampering, Afvisning, Offentliggørelse af oplysninger, Tjenesteafvisning og Elevation of Privilege (STRIDE), før opbygning begynder. Sikkerhed formaterer teknologivalg og designbeslutninger.
• Integreret sikkerhed i automatisering. Opbyg sikkerhedskontroller i automatiserede pipelines, konfigurationsskabeloner og platformsstandarder. Salesforce Code Analyzer i CI/CD fanger sårbarheder før implementering. Konfiguration-som-kode håndhæver sikkerhedsbasislinjer. Integreret sikkerhed sikrer ensartethed og gør det muligt for sikkerhed at skalere med løsningens kompleksitet.
• Design for privatliv. Inkluder fortrolighedsprincipper fra den indledende arkitektoniske fase. Design til dataminimering (saml kun nødvendige data), formålsbegrænsning (begræns adgang efter jobfunktion), samtykkestyring (håndhæv detaljeret, formålsspecifikt samtykke) og registrerets rettigheder (aktiver adgang, rettelse, sletning og portabilitetsarbejdsflows for at fuldføre inden for reguleringstidslinjer).
• Design til sporbarhed. Gør enhver efterfølgende handling tilskrivbar og rekonstruerbar efter fakta, før du er afhængig af at registrere afvigelser i den. Sørg for, at ændringer af data, tilladelser og konfiguration registreres i revisionsspor, felthistorik og begivenhedslogfiler, og bevar disse registreringer i manipulationsresistent lager. Sporbarhed er forudsætningen for registrering, forensik og ansvarlighed. Husk – du kan ikke undersøge, hvad der aldrig blev registreret.
• Design til hændelsessvar. Design til registrerbarhed gennem Begivenhedsovervågning og til intervention i realtid gennem transaktionssikkerhedspolitikker. Aktiver hurtigt svar gennem dokumenterede procedurer og isoleringsgrænser. Understøt gendannelse gennem sikkerhedskopifunktioner og forensisk bevarelse. Test svar gennem bordtræning og brudsimulationer.

Architekter er ansvarlige for at sikre løsninger på den platform, som Salesforce leverer.

De arbejdsbelastninger, der interagerer med Salesforce, kører i stigende grad uden for kerneplatformen – integrationstjenester, tilpassede applikationer og headless-klienter kalder ofte Salesforce-API'er, ofte på vegne af en bruger. For at sætte skub i dette mønster viser Salesforce platformens funktioner som API'er, værktøjer og kommandoer (f.eks. Salesforce Headless 360). Uanset hvem der kører disse applikationer, ejer arkitekten den Trust, hvor de møder Salesforce for at bestemme, hvordan de godkendes, hvilken identitet og tilladelser de bærer, hvilke hemmeligheder de bevarer, og hvilke data der krydser grænsen.

Principperne nedenfor gælder for enhver beholderintegrationsplatform (f.eks. MuleSoft CloudHub).

Når en ekstern klient godkendes som en navngivet bruger, anvendes Salesforces platformssikkerhedsmodel automatisk – objekttilladelser, sikkerhed på feltniveau og delingsregler håndhæves nøjagtigt, som de er i browseren. Pr. bruger-godkendelse omfatter hvert kald til den pågældende persons tilladelser og bevarer revisionssporet, hvilket betyder, at tilbagekaldelse af en brugers token straks fjerner klientens mulighed for at handle på vedkommendes vegne. Foretræk dette frem for en delt servicekonto, hvor arbejdet udføres for en bestemt bruger.

Design grænsen defensivt, fordi en klient, der har tokener til mange brugere, koncentrerer Trust og bliver en proxy af høj værdi for en angriber: et enkelt stjålet OAuth-token kan nå data på tværs af hver bruger, som klienten betjener. Dette er ikke hypotetisk. Salesloft Drift-hændelsen i 2025 så angribere stjæle OAuth-tokener og bruge dem til at få adgang til Salesforce-data på tværs af hundredvis af organisationer.

• Propagere brugeridentitet, ikke samle den. Brug pr. bruger-godkendelse eller OAuth 2.0-tokenudveksling til at overføre en brugers identitet på tværs af serviceshops (se Agentidentitet og godkendelse), så kompromisser omfatter en brugers kontekst i stedet for alle dem.
• Behandl OAuth-klientlegitimationsoplysninger og opdateringstokener som det primære mål. Gem dem i en lager for administrerede hemmeligheder, roter dem hyppigt, og vedligehold designs til øjeblikkelig tilbagekaldelse. Overvåg API-anvendelse for de afvigelser, der signalerer en proxidet angriber.
• Minimer omfanget på begge sider. Begræns eksterne klientapps (ECA) OAuth-omfang og integrationsbrugerens Salesforce-tilladelser til det mindste, som funktionen kræver, så en kompromitteret klient ikke kan pivotere til ikke-relaterede data.
• Administrer grænsen gennem eksterne klientapps. ECAs definerer, hvordan en ekstern applikation godkendes, hvilke forløb der er tilladt, og hvilke omfang der gælder – design nye integrationer op mod dem (se Godkendelsesarkitektur).

Udøv forsigtighed, hvor en klient kører som en agentbruger eller integrationsbruger: disse identiteter kan fungere i en forhøjet kontekst – ofte mod eksterne systemer, der ikke respekterer Salesforces adgangskontroller – så brug af den tilladelses- og overvågningsdisciplin, der er skitseret ovenfor, er det, der holder denne styrkebegrænsning.

Når integrationer køres i en beholderbaseret platform, betragtes isolering på beholderniveau i sig selv som en sikkerhedskontrol: hver applikation kører i en dedikeret beholder uden delt kørsel eller hukommelse mellem applikationer.

Denne isolering giver:

• Lejergrænsehåndhævelse: Kompromitterede applikationer kan ikke få adgang til data eller ressourcer fra tilstødende applikationer, der deler det samme miljø. Hver beholder har et isoleret filsystem og procesplads. Håndhæv netværksisolering gennem firewall- og TLS-konfiguration, og begræns eksplicit udgående trafik i stedet for at være afhængig af tilladende standarder.
• Defense-i-dybde: Beholderisolering tilføjer et sikkerhedslag ud over kontrolelementer på applikationsniveau. Selv hvis applikationskoden har sårbarheder, begrænser beholdergrænserne eksplosionsradius.
• Compliance-segmentering: Regulerede arbejdsbelastninger (f.eks. PCI og HIPAA) kan isoleres i dedikerede beholdere, hvilket forhindrer co-blanding med ikke-kompatible arbejdsbelastninger.

Architekter, der designer miljøer med flere applikationer, skal være afhængige af beholderisolering for at håndhæve adskillelse af opgaver og sikkerhedsdomæner. Integrationer af finansielle tjenester, der håndterer kortholderdata, skal køre i separate beholdere fra marketingintegrationer, selv i det samme miljø.

Trafik mellem beholdere skal krypteres, og gensidig TLS (mutual TLS) skal anvendes, hvor en reguleringsramme kræver godkendelse på begge sider:

Hvordan det fungerer:

• Konfigurer TLS-kontekster for at aktivere valgfri gensidig TLS (mutual TLS) for indgående forbindelser, når det er nødvendigt.
• Brug SSL på platformsniveau med klientcertifikatgodkendelse til at sikre kommunikation mellem platformstjenester og repliker.
• Konfigurer TLS-kontekster til at aktivere mTLS, når det kræves af bestemmelsesstrukturer.
• Administrer certifikater gennem platformens certifikatlager, så livscyklus og tilbagekaldelse forbliver centraliseret.
• Håndhæv grænser for netværksisolering, der forhindrer uautoriseret trafik mellem beholdere.

Kryptering af trafik på platformslag giver dybdeforsvar for data i overførsel. Selv hvis applikationslag-HTTPS er forkert konfigureret, forbliver beholdertrafikken krypteret.

Beholdere, der opretter forbindelse til lokale systemer via VPN, skal arkitektere for data-in-transit-beskyttelse:

• Tunnelkryptering: Distribuer al trafik mellem beholdere og lokale systemer gennem krypterede VPN-tunneler. Dette gælder uanset applikationslag-TLS. Forsvar i detaljer sikrer, at der er dobbeltkryptering for følsomme data.
• Håndhævelse af netværkssegmentering: VPN-tunnelpolitikker begrænser, hvilke interne netværk containere kan nå. Kompromitterede beholdere kan ikke pivotere til uautoriserede interne systemer ud over VPN-tilladte netværk.
• Bevis for overensstemmelse: VPN-kryptering er en af de accepterede mekanismer til beskyttelse af data, der overføres til og fra cloudmiljøer. Revisorer, der gennemser HIPAA-, PCI-DSS- eller SOX-kontrolelementer, forventer dokumenteret kryptering i overførslen for hybridintegrationer.

Arkitekter skal designe VPN-politikker, der håndhæver adgang til netværk med mindst rettigheder. Marketingintegrationsbeholdere skal ikke distribueres til interne finansielle systemer, selvom begge kan nås via VPN.

Ubrugelige domæner (f.eks. tilpassede URL'er for integrations-API'er) kræver, at arkitekter administrerer TLS-certifikater som Trust:

Ubrugelige domæner (f.eks. tilpassede URL'er for integrations-API'er) kræver, at arkitekter administrerer TLS-certifikater som Trust.

• Automatisering af certifikatlivscyklus: Implementer automatisk certifikatfornyelse og -implementering. Udløbne certifikater bryder integrations Trust; klienter afviser forbindelser med certifikatvalideringsfejl.
• Planlægning af tilbagekaldelse af certifikater: Design certifikatrotationsprocedurer for sikkerhedshændelser. Kompromitterede private nøgler kræver hurtig genudstedelse og implementering af certifikater på tværs af alle områder.
• Chip suite konfiguration: Ældre TLS-konfigurationer (TLS 1.0/1.1 og svage krypteringer) mislykkes overensstemmelsesrevisioner. Håndhæv TLS 1.2+ (minimumkrav), og juster certifikat- og klientkonfigurationer med organisationssikkerhedspolitikker.
• Gennemsigtighedsregistrering af certifikater: Moderne TLS-certifikater sendes til offentlige CT-logfiler (Certificate Transparency) af CA'er (Certificate Authorities). Hver CT-log returnerer et SCT (Signed Certificate Timestamp), et kryptografisk bevis på logføring, som CA integrerer i certifikatet via en X.509v3-udvidelse. Arkitekter bør overvåge CT-logfiler for uautoriseret certifikatudstedelse mod deres domæner ved brug af tjenester som crt.sh eller automatiseret advarsel.

Forkert administration af certifikater påvirker Trust:

• Udluttede certifikater: Forårsager godkendelsesfejl, der vises som afbrydelser. Overvågning skal inkludere afsendelse af advarsler inden for 30+ dage før udløbsdatoen for at tillade, at fornyelsesarbejdsflows starter.
• Selvsignerede certifikater: Afbryd Trust kæder for eksterne klienter. Produktionsintegrationer kræver certifikater, der er signeret af betroede certifikatautoriteter (CA'er).
• Wildcard certifikat spread: Henviser til overdrevent brede jokertegnscertifikater (f.eks. *.company.com), der opretter en stor eksplosionsradius, hvis de kompromitteres. Certifikater med smalt omfang foretrækkes pr. integrationsdomæne.

Beholderimplementeringsområder skal overholde dataplacerings- og compliancekrav.

• GDPR-dataplacering: GDPR kræver tilstrækkelig beskyttelse for personlige data, der forlader Den Europæiske Union (EU), men ikke EU-implementering som sådan. Implementering af integrationer i et EU-område bevarer beholderberegning og databehandling inden for bestemmelsesgrænser, hvilket er den mest direkte måde at opfylde dette krav på. Overførsler, der forekommer uden for EU, forbliver tilladelige under en tilstrækkelighedsbeslutning, SCC'er (Standard Contractual Clauses) eller Binding Corporate Rules (BCR'er).
• Love for datalokalisering: Lande med krav til datalokalisering omfatter: Rusland (Federal Law 152-FZ og obligatorisk lagring) og Kina (PIPL/CSL for CIIOs), som kan kræve containerimplementering i landet. Indiens DPDP-lov fra 2023 anvender en sortliste-metode, der ikke pålægger et generelt oplagringsmandat i landet. Dataoverførsler er tilladt til ethvert land, medmindre det er specifikt begrænset af en offentlig advisering. Architekter skal forstå juridikspecifikke bestemmelser.
• Mekanismer for grænseoverskridende dataoverførsel: Når der kræves en flerregional implementering, men dataene skal krydse grænser, skal arkitekter implementere SCC'er, BCR'er eller andre juridiske overførselsmekanismer.
• Analyse af overensstemmelsescertificering: Beholderimplementeringsområder skal matche Salesforce-overensstemmelsescertificeringer. FedRAMP-autoriserede arbejdsbelastninger kræver regional implementering i USA. For HITRUST-certificerede integrationer skal du kontrollere, at implementeringsområdet falder inden for en aktiv HITRUST-attesteringsomfang.

Regionale implementeringsbeslutninger er arkitektansvar, der direkte påvirker overholdelse af bestemmelser. Økonomiteams kan bestemme kun-amerikansk implementering for SOX-kontrollerede integrationer. Behandlingsteams kan kræve HITRUST-certificerede områder til behandling af personlige helbredsoplysninger (PHI).

Beholdere kræver adgang til legitimationsoplysninger, API-nøgler og krypteringsnøgler. Architekter skal designe hemmelighedsstyringsprocesser, der forhindrer eksponering:

• Ingen hardcodede hemmeligheder: Integrer aldrig legitimationsoplysninger i applikationskode eller konfigurationsfiler, der er implementeret på beholdere. Brug platformsadministrerede hemmelighedsbutikker.
• Platformsstyret hemmelig indsprøjtning: Løs hemmeligheder på kørselstidspunktet fra platformens administrerede butik (i stedet for at holde dem til filsystemet), og marker konfigurationsværdier, der indeholder legitimationsoplysninger, som beskyttede, så de ikke vises i logfiler eller på konsollen.
• Rotation af sekreter: Design integrationer til at håndtere roterede hemmeligheder på en god måde. OAuth-tokenopdateringsmønstre, API-nøglerotationsarbejdsflows og databaseadgangskodeændringer må ikke kræve beholdergenimplementering.
• Adgang til hemmeligheder med mindste rettighed: Tildel beholdere kun adgang til de hemmeligheder, der er påkrævede for deres funktion. Marketingintegrationer bør ikke få adgang til legitimationsoplysninger til finansielle systemer, selv når de deler det samme miljø.

Visne hemmeligheder er almindelige integrationssikkerhedshændelser. Arkitekter skal designe hemmeligheder, der håndterer processer, der kan overleve kodegennemgange, logfiler, fejlmeddelelser og overvågning af dashboards uden at lække legitimationsoplysninger.

Applikationer ved Salesforce-grænsen genererer revisionsbegivenheder, der opfylder kravene til overensstemmelseslogføring:

• Anmodning/svar logføring: Logfører API-anmodninger, svar og distributionsbeslutninger. Overensstemmelsesteams bruger disse logfiler til adgangsrevisioner til at bestemme, hvem der har adgang til hvilke data på hvilket tidspunkt.
• Fejl og undtagelsesregistrering: Registrerer sikkerhedsbegivenheder (f.eks. godkendelsesfejl, autorisationsnægtelser og ugyldige certifikater) i beholderens logfiler. SIEM-integration aktiverer overvågning af sikkerhed i realtid.
• Logbevarelsespolitikker: Architekter skal konfigurere bevarelsesperioder, der opfylder bestemmelseskrav. Disse minimumsværdier er angivet af bestemmelser, afviger efter struktur og ændres over tid, så de skal aflede dem fra en velvedliget overensstemmelseskilde, der bekræfter hvert tal i forhold til den regulerende bestemmelse snarere end hardcodeværdier.
• Logkryptering og adgangskontrol: Revisionslogfiler kan indeholde følsomme metadata. Logfiler skal kun krypteres som inaktive og adgangskontrolleres for autoriseret sikkerheds-/overensstemmelsespersonale. Utilstrækkelig logføring forhindrer hændelsesundersøgelse og mislykkes overensstemmelsesrevisioner. Architekter skal afbalancere logføringssprogbarhed (f.eks. ydeevnepåvirkning og lagringsomkostninger) med behov for overensstemmelse og sikkerhedsundersøgelse.

Trusselmodellering skal være en del af designet af dine løsninger, snarere end et separat trin, der forekommer før eller efter det. Så snart du har et kandidadesign at tænke over, skal du modellere dets potentielle trusler – og gennemse modellen igen, efterhånden som designet udvikles, så sikkerheden formaterer arkitekturen i stedet for at blive eftermonteret på den. Mens Salesforce administrerer infrastrukturssikkerhed (f.eks. netværksbeskyttelse, OS-hærdning og sårbarhedsstyring), skal du identificere applikationslagrisikoer i din konfiguration, integrationer og tilpasset kode. Anvend STRIDE-strukturen (Spoofing, Tampering, Afvisning, Offentliggørelse af oplysninger, Nægtelse af service, Hævelse af rettighed) på de Salesforce-specifikke trusselvektorer, der er angivet nedenfor. Identificer Trust, hvor data krydser systemer, netværk eller rettighedsniveauer.

Anvend STRIDE-strukturen på disse overvejelser i forbindelse med Salesforce-specifik trusselmodellering:

• Multi-org-dataforløb skaber yderligere Trust-grænser, der kræver eksplicit godkendelse og autorisation ved hver krydsning.
• Eksterne integrationer bruger API'er og middleware, hvilket potentielt introducerer angrebsvektorer, der tilsidesætter platformssikkerhedskontroller.
• Tilpassede Apex- og Lightning-komponenter kræver sikker kodningsanalyse for indsprøjtning, XSS og håndhævelse af adgangskontrol.
• Experience Cloud-lokaliteter udvider angrebsområdet til ikke-godkendte eller let godkendte brugere.
• Tredjepartskode og ISV-kode (f.eks. administrerede pakker, AgentExchange-oversigter, tilsluttede apps, tredjepartsforbindelser, JavaScript-biblioteker på klientsiden og de eksterne AI-tjenester, som dine agenter kalder) er en leverandørkædevektor, der passerer ind i din Trust-grænse, på installationstidspunktet eller på kørselstidspunktet.

Tredjepart og ISV-kode er en del af din Trust Grænse.

Administrerede pakker eller AgentExchange-oversigter kører i din organisation med de tilladelser, du tildeler dem, så deres sikkerhedstilstand bliver din sikkerhedstilstand i det øjeblik, du installerer dem. Salesforce Security Review kontrollerer hver angivet pakke, før den når AppExchange eller AgentExchange. Du ejer alt efter denne gate:

• Vurdering af pakken op mod din egen dataklassificering og risikostatus
• Tildele den den mindste mængde rettigheder, som dens dokumenterede funktionalitet kræver
• Bevar den opdateret med udgiverens versioner
• Og overvågning af dens aktivitet gennem de samme Begivenhedsovervågning og revisionskontrolelementer, som du anvender på din egen kode.

Anvend sikkerhedskontroller på hvert lag af løsningens stak. Husk på, at kompromis af et lag ikke må vise hele systemet.

Design hvert lag, som om lagene over og under kan mislykkes. Husk, at flere uafhængige kontroller skaber fleksibilitet.

Zero Trust eliminerer implicit Trust baseret på netværksposition eller tidligere godkendelsestilstand. Hver anmodning skal godkendes og autoriseres uafhængigt.

Anvend zero Trust til:

• Brugeradgang gennem kontinuerlig bekræftelse med MFA, sessionspolitikker og betinget adgang baseret på kontekst (f.eks. IP, enhed, tid og adfærd)
• Integrationsforbindelser gennem OAuth-tokenvalidering på hvert opkald, certifikatbaseret gensidig TLS og IP-tilladelsesliste
• Intersystemkommunikation gennem eksplicit godkendelse, hvilket også gælder for betroede interne systemer
• Dataadgang gennem CRUD- og FLS-håndhævelse på alle forespørgsler og handlinger uanset opkaldskontekst

Lager for sikkerhedsaktiv er et sikkerhedsdesigninput: du kun kan trusselmodelere, anvende mindst rettighed på og overvåge en angrebsoverflade, som du først har angivet, så sporing af dine sikkerhedsrelevante aktiver hører til de designbeslutninger, der afhænger af det. Dette er forskelligt fra den driftsmæssige konfigurationsstyring, som Operational Excellence dækker (f.eks. versionsindstillinger for organisationen og registrering af konfigurationsforskydning for driftsmæssig stabilitet). Med andre ord er bekymringen her mindre: hvilke aktiver der bærer sikkerhedsrisici, og hvorfor?

Vedligehold et aktuelt lager over alle sikkerhedsrelevante aktiver, herunder tilpassede objekter, der lagrer følsomme data, eksterne systemintegrationer, offentlige API'er, rettighedskonti, produktionsadgangstildelinger og installerede pakker med forhøjede tilladelser.

Dit sikkerhedsaktivlager skal indeholde:

• Tilpassede objekter og felter, der indeholder fortrolige eller begrænsede data
• Integrationsslutpunkter og godkendelsesmekanismer
• Brugere med forhøjede rettigheder (f.eks. Rediger alle data, Vis alle data og Administrer brugere)
• Kun API-integrationsbrugere og deres tilladelsesomfang
• Eksterne klientapps (ECA) og deres OAuth-omfang sammen med eventuelle ældre tilsluttede apps, der stadig findes i organisationen
• Installerede AgentExchange-pakker og deres tilladelsestildelinger
• Experience Cloud-lokaliteter og deres godkendelses- og eksterne delingsmodeller
• Tilpassede Apex med hævede delingstilstande
• Vær særlig opmærksom på ældre klasser: kode, der er kompileret ved API version 66.0 eller tidligere, som udelader en delingserklæring som standard til "uden deling" (f.eks. systemtilstand, der tilsidesætter den løbende brugers registreringsadgang). Husk på, at fra API version 67.0 (Summer '26) er en udeladt erklæring i stedet for "med deling", og databasehandlinger køres i brugertilstand. Men eksisterende klasser bevarer den gamle adfærd, indtil de er kompileret igen ved v67.0 (eller nyere) – så ikke-erklærede klasser, der er overført fra tidligere versioner, forbliver stille hævet.

Det er dit ansvar at designe og konfigurere identitetskontroller, der håndhæver mindst rettigheder.

Lad os se nærmere på, hvordan du korrekt designer og konfigurerer kontroller ved brug af PoLP.

Salesforce håndhæver adgangskontrol gennem fire forskellige lag: organisation, objekt, felt og registrering. Du skal designe løsninger, der bruger alle fire lag med vilje. Kerneadgangskontrol er tildelingsbaseret, hvilket betyder, at adgang er additiv, og brugere skal have den tildelt på hvert lag for at nå en registrering. Der er ingen generaliseret "afvis tilsidesættelser tillader"-regel i kerneplatformen, så du kan ikke spærre på en målrettet afvisning for at fortryde adgang til en bred tildeling, der allerede er tildelt.

tilladende højere lag koster ikke din mulighed for at begrænse, men de øger indsatsen: udvidelse af standarder for hele organisationen eller objekttilladelser tidligt betyder, at du er afhængig af sikkerhed på feltniveau og delingskonfiguration for at få adgang tilbage, der aldrig skulle have været tildelt.

Begrænsningsregler og deaktiveringstilladelser er to indbyggede undtagelser, der fratrækker adgang, men hver er begrænset – begrænsningsregler til filtrering på registreringsniveau og deaktivering til tilladelser, der er tildelt i en tilladelsessætgruppe – ikke et generaliseret afvisningslag.

Indstil OWD'er til Privat for objekter, der indeholder følsomme data. Åbning af OWD'er til Offentlig skrivebeskyttet – ikke mindst Offentlig Læs/Skriv – viser registreringer bredt og nedbryder din mulighed for at begrænse adgang senere uden potentielt væsentlig omarkitektur. Den mest almindelige Trust gæld i modne organisationer stammer fra tilladende OWD'er, der er fastsat under den indledende implementering.

Registreringslaget følger en tildeling-så-begrænsningsmodel, der ofte afbildes som en delingspyramide: OWD'er angiver den restriktive basislinje og rollehierarkiet, delingsregler og manuel deling - åben adgang op derfra. To kontroller inverterer dette forløb for at tage adgang væk i stedet for at tildele det, og begge er værd at designe med vilje.

• Begrænsningsregler filtrerer, hvad brugere kan se i registreringer, som de allerede har adgang til, så brugere med bred objektadgang stadig kun ser det undersæt, som en regel tillader.
• Deaktiveringstilladelser fratrækker specifikke tilladelser i en tilladelsessætgruppe, så du kan samle adgang fra genanvendelige grupper og derefter fjerne det, som en given population ikke bør have.
• Reager på disse regler, når bevillingsbaserede lag alene vil tvinge dig til enten at over-provisionere eller fragmentere adgang til mange smalle tilladelsessæt.

Håndhæv godkendelse med flere faktorer (MFA) for alle brugere, der logger på produktionsmiljøer gennem brugergrænsefladen, som Salesforce har angivet som et platformskrav. Dette krav udvides ikke til kun API-adgang: integrationer, der bruger JWT-bearer- eller klientlegitimationsoplysningsforløb, er fritaget, så du skal i stedet beskytte disse integrationer med certifikatstyring og IP-begrænsninger. Udvid MFA-krav til rettighedshandlinger.

For SSO (single sign-on) foretrækkes SAML 2.0- eller OpenID Connect-protokoller. Konfigurer sessionspolitikker for at afbalancere sikkerhed og anvendelighed:

• Sessionstimeout: Konfigurer sessionstimeouts, der er relevante for brugertilladelsesniveauer (kortere timeouts for konti med høj rettighed reducerer risici fra ikke-ansatte sessioner).
• IP-begrænsninger: Håndhæv begrænsninger for administrative profiler og integrationsbrugere.
• Logintid: Begræns servicekonti til forventede driftsmæssige vinduer.
• Enhedsaktivering: Afhæng af Salesforces oprindelige enhedsaktivering (identitetsbekræftelse for logins fra ukendte enheder), og tilføj MFA- og IP-begrænsninger for konti med høje rettigheder. Indbygget enheds Trust-stilling håndhæves gennem en ekstern identitetsudbyder.
• Sessions-IP-låsning: Lås sessioner til den IP-adresse, som de stammer fra, så et stjålet sessions-id ikke kan afspilles fra en anden netværksplacering. Dette indsnævrer sikkerheden, men tilføjer friktion for mobilbrugere og kan afbryde automatiserede integrationer – hvor låsning ikke er muligt, skal du håndhæve Streng IP-loginområder på profilniveau med "Håndhæv login-IP-områder på hver anmodning" som kompenserende kontrol.
• Sessioner med høj sikring: Kræv et sessionssikkerhedsniveau med Høj sikring gennem politikker for sessionssikkerhedsniveau og adgangspolitikker for følsomme handlinger (f.eks. at få adgang til rapporter eller administrere IP-områder), så et rutinemæssigt login ikke alene kan nå handlinger med høj påvirkning. I Lightning Experience understøttes det ikke at sætte en standardsession op til Høj sikring ved at bede om MFA igen, så anvend denne politik ved at vide, at standardsessionsbrugere blokeres fra den lukkede handling i stedet for at blive bedt om at rykke op.
• Session cookie-beskyttelse: Kræv attributten HttpOnly, så scripts ikke kan læse sessions-ID-cookien og låse sessioner til det domæne, hvor de først blev brugt, for at slette sessionsovertagelse.
• Kun API-adgang for integrationsbrugere: Begræns integration og servicekonti til kun API-godkendelse med tilladelsen Kun API-bruger, så de ikke kan logge ind gennem brugergrænsefladen. For nye opbygninger skal du tildele profilen Mindste adgang - Kun API-integrationer med Salesforce Integration-brugerlicensen. Den ældre Salesforce API Only Systems Integration-profil er ikke tilgængelig i organisationer, der er klargjort fra Spring '24 og fremover, så design nye integrationer op mod den aktuelle profil i stedet for den udfasede profil.

For API-godkendelse skal du vælge OAuth 2.0-forløb, der er relevante for integrationsmønsteret:

• JWT Bearer-forløb: Brug dette til server-til-server-integrationer, der kører som en integrationsbruger (certifikatbaseret, foretrukket for betroede miljøer).
• Webserverforløb (autorisationskode, med PKCE): Brug dette til webapplikationer, der kræver brugerautorisation, og til server-til-server-integrationer, der har brug for at vedligeholde specifik brugerkontekst (lagring af opdateringstokener på serversiden for at undgå gentagne browsermeddelelser).
• Gør forløbsgenafspilning af godkendelseskode sikker: Håndhæv PKCE, så en registreret autorisationskode ikke kan indløses af nogen, bortset fra den klient, der anmodede om det, og roter opdateringstokener – udsted et nyt på hver anvendelse og ugyldiggør det tidligere – så et stjålet opdateringstoken har et smalt gyldighedsvindue. Genbrug af et trukket token signaliserer kompromis.
• Hovedløs identitetsgodkendelseskode og legitimationsoplysningsforløb (med PKCE): Brug dette til virkelig headless, ingen-browser-klienter, der skal køre i en bestemt brugers kontekst – det omdirigeringsbaserede webserverforløb forudsætter en browser, som disse klienter ikke har.
• Enhedsforløb (for headless-enheder): Bemærk, at Salesforce fra den 28. august 2025 har blokeret OAuth 2.0-enhedsforløb permanent for den Salesforce CLI app. Brug webserverforløbet (sf-organisationsloginweb) eller JWT Bearer-forløbet (sf-organisationslogin-JWT) i stedet for CLI- og CI/CD-værktøjer.

Brug ikke forløbet Brugernavn-adgangskode. Salesforce blokerede det som standard for organisationer, der er oprettet i Summer '23 eller senere, og har udgivet tilbagetrækningsplaner for dette forløb. Eksisterende integrationer, der stadig er afhængige af brugernavn-adgangskode-forløbet, skal migreres til JWT Bearer-forløbet eller forløbet for klientlegitimationsoplysninger nu, snarere end at behandle migrering som forsinket teknisk gæld.

Disse forløb konfigureres på den appregistrering, der repræsenterer din integration. Fra og med Spring '26 flytter Salesforce denne registrering fra tilsluttede apps til eksterne klientapps (ECA): oprettelse af nye tilsluttede apps er som standard inaktiveret, og ECA er konstruktøren til at designe nye integrationer mod. Eksisterende tilsluttede apps forbliver installeret. Men når en organisation migreres, håndterer de ikke længere godkendelse, så tag højde for migreringen, når du overvåger, hvordan integrationer godkendes i stedet for at behandle tilsluttede apps som den permanente model.

Udover at vælge et godkendelsesforløb skal du oprette særskilt ledelse, som apps kan oprette forbindelse til:

• En registrering pr. integration: Registrer en dedikeret ekstern klientapp for hver ny integration og en særskilt tilsluttet app for hver eksisterende. Kun tilpasset de OAuth-omfang, som hver integration kræver, snarere end at dele en bred registrering på tværs af mange, bevarer en dedikeret registrering hver integrations adgang uafhængigt reviderbar og tilbagekaldelig.
• Forhåndsgodkend adgang eksplicit (anbefales): Indstil politikken Tilladte brugere for den eksterne klientapp til "Admin-godkendte brugere er forhåndsgodkendte", så en administrator tildeler adgang gennem profiler og tilladelsessæt i stedet for at lade brugere foretage egengodkendelse. Administratorer konfigurerer dette direkte i Opsætning, og det er Salesforces anbefalede kontrol for at bestemme, hvem der kan oprette forbindelse.
• API-adgangskontrol (strengere, tilladelseslistebaseret): For strengere kontroller begrænser API-adgangskontrol administratorgodkendte brugere til kun at tilladlistede tilsluttede apps. Aktivering af det kræver en anmodning til Salesforce Kundesupport, så planlæg dette trin, når du designer omkring det i stedet for at behandle det som en selvbetjeningsindstilling.

Integrer aldrig legitimationsoplysninger i kode, konfigurationsfiler eller versionskontrol. Brug navngivne legitimationsoplysninger og eksterne legitimationsoplysninger til at administrere godkendelse centralt med roteringsfunktioner.

I modsætning til traditionel brugergodkendelse kræver agenter særskilte identitetsmodeller, og den rigtige model afhænger af, om agenten betjener medarbejdere eller eksterne brugere. Korrekt design af identitet er grundlaget for agentsikkerhed: det bestemmer, hvilke data agenten kan få adgang til, og hvilke handlinger agenten kan få adgang til.

Lad os se nærmere på interne og eksterne agenter. nts.

• Medarbejderagenter (interne): Udfør opgaver i konteksten for den bruger, der er logget ind. De overtager denne brugers licenser, tilladelsessæt, sikkerhed på feltniveau og delingsregler, så der ikke klargøres nogen separat agentidentitet, og den eksisterende sikkerhedsstruktur styrer, hvad agenten kan gøre.
• Kundeagenter (eksterne): Interager gennem offentlige kanaler og kør som dedikerede agentbrugere, specialiserede integrationsbrugere – ikke gæstebrugere på offentlige lokaliteter. Kørsel som dedikerede integrationsbrugere giver agenten mulighed for at udføre backendhandlinger og få adgang til data (som ikke-godkendte gæsteprofiler ikke kan), mens de stadig er bundet af eksplicitte tilladelser med mindst rettigheder. Når du opretter en kundeagent, skal du klargøre en ny agentbruger med minimal adgang og kun tildele de specifikke tilladelser, som dens handlinger kræver.

Hvor en agents arbejde strækker sig over flere tjenester, skal du udbrede brugerens identitet på tværs af hvert servicehop i stedet for at falde tilbage til en delt eller gæsteidentitet. Salesforce OAuth 2.0-tokenudvekslingsforløb understøtter dette:

En klient præsenterer brugerens eksisterende identitetsudbydertoken, og en Apex tilknytter den til en Salesforce-bruger og udsteder et Salesforce-adgangstoken, så den oprindelige brugers kontekst følger anmodningen i stedet for at folde sammen til en servicekonto. Overvåg agentaktivitet gennem Begivenhedsovervågning ved brug af agentens brugeridentitet til at registrere afvigelse.

Valg af den rigtige model afhænger af, hvem der starter forbindelsen, og i hvilken kontekst arbejdet skal køre.

Almindelige forbindelsesscenarier knyttes til anbefalede tilgange på følgende måde:

Design rollehierarkier omkring dataadgangsbehov (som brugere skal have adgang til registreringer, som andre ejer) – ikke administrationsrapporteringsdiagrammet. Lad rolle-hierarki dybde følge ægte data-adgangsrelationer i stedet for at tilføje niveauer, der ikke giver nogen yderligere adgang, da hvert niveau tilføjer delingsberegning overhead – en overvejelse, der bærer mere vægt i organisationer med private OWD-indstillinger og store datamængder.

Tilladelsessæt og tilladelsessætgrupper reducerer behovet for profiludbredelse ved at give fleksibel, yderligere adgang. Tildel funktionel adgang gennem tilladelsessæt og tilladelsessætgrupper i stedet for profiler, som bevarer adgangen additiv og kan revideres. Profiler forbliver nødvendige: Sammen med logintidspunkter og IP-begrænsninger kontrollerer de sidelayouttildeling, registreringstypestandarder og appsynlighed. Behandl profiler som en holdbar del af adgangsmodellen, snarere end en konstruktion, der skal elimineres.

Politikker for transaktionssikkerhed er ikke en del af basislinjen. De er en tilføjelsesfunktion, der supplerer kerneautorisationsmodellen: identitets-, rolle-, profil-, tilladelsessæt- og delingskontrollerne ovenfor etablerer allerede en sikker autorisationstilstand efter sig selv, og transaktionssikkerhed tilføjer kontekstuel evaluering i realtid øverst. Konfigurer politikker til at registrere og blokere uregelmæssig adfærd, herunder massedatadownloads, der overskrider normale mønstre, logins fra uventede geografiske områder og tilladelsesændringer uden for ændringsvinduer.

Sikkerhedskontroller bærer tilgængelighedsafvejninger, der er et arkitektonisk ansvar. En overdrevent bred IP-begrænsning kan låse lovlige brugere ude under en netværksændring, og en politik for transaktionssikkerhed, der er tilpasset for aggressivt, kan blokere gyldig forretningsaktivitet – så omfang disse kontrolelementer til reel risiko, fase dem i kun overvågningstilstand, før du håndhæver dem, og design en brudglassti for, når en kontrol mislykkes.

Din ansvar: Design rollehierarki, opret tilladelsessæt, konfigurer transaktionssikkerhedspolitikker.

Traditionel rollebaseret adgangskontrol) tildeler tilladelser baseret på en brugers rolle. ABAC (attributbaseret adgangskontrol) træffer autorisationsbeslutninger baseret på attributterne for data, brugeren og konteksten.

For de fleste krav udtrykker kernedelingsmodellen adgang fuldt ud. Ræk til dedikeret ABAC, når adgang skal følge dataklassificering, som pr. registrering-deling ikke kan udtrykke: Data 360 ABAC leverer dette gennem tags og anmærkninger.

Data 360 ABAC fungerer gennem:

• Tag-baserede politikker, der definerer adgangsregler baseret på tags, der anvendes på dataobjekter (f.eks. Personligt identificerbare oplysninger (PII), økonomiske, sundhedsmæssige og fortrolige tags).
• Anmærkninger anvendes på dataobjekter for at understøtte politikbaserede autorisationsbeslutninger.
• Standard "Tillad alle"-politik for nye og eksisterende organisationer, der skal slettes eksplicit for at aktivere detaljerede styringspolitikker.

Dets primære arkitektoniske anvendelse er håndhævelse af dataklassificering – se Dataklassificering under Databeskyttelse og fortrolighed for at få at vide, hvordan klassificeringsniveauer styrer ABAC-håndhævelse.

Dette detaljeniveau medfører en driftsmæssig udgift. Kernedeling besvarer spørgsmålet "Hvem kan se denne registrering og hvorfor?" fra et lille sæt regler, der kan undersøges (OWD'er, rollehierarki og delingsregler), mens ABAC afleder sine svar på evalueringstidspunktet fra kombinationen af datatags, brugerattributter og kontekst, så effektiv adgang bliver vanskeligere at begrunde og overvåge, efterhånden som politikker og tags akkumuleres.

Håndhæv revisionsmulighed som et designkrav: anvende tags ensartet, holde politiksættet lille og navngivet for den klassificering, det håndhæver, og bevare muligheden for at rekonstruere, hvorfor en bruger nåede en angivet registrering. Reserver ABAC for klassificeringsstyrede sager, som pr. registrering-deling virkelig ikke kan udtrykke, i stedet for at behandle det som en generel erstatning for den ejerskabsbaserede model.

Identificer og beskyt konti med forhøjede rettigheder, herunder systemadministratorer, integrationsbrugere og automatiserede proceskonti. Disse konti er mål for angribere af høj værdi.

Anvend forbedrede kontroller på konti med kritisk påvirkning.

• Kræv phishing-resistent MFA
• Begræns login-IP-områder til kendte administrative placeringer
• Aktiver loginadvarsler og tilladelsesændringsadviseringer
• Udfør periodiske adgangsgennemgange med dokumenteret attestation for konti med høje rettigheder, hvor frekvensen er bestemt af organisationens risikotolerance og compliancekrav
• Vedligehold break-glass-procedurer for nødadgang og efter brug-revision

For integrations- og servicekonti:

• Anvend OAuth-forløb, aldrig brugernavn-adgangskode-forløb
• Håndhæv IP-begrænsninger
• Implementer roteringsplaner for legitimationsoplysninger
• Overvåg for uregelmæssige API-anvendelsesmønstre gennem Begivenhedsovervågning

Din ansvar: Identificer kritiske konti, anvend forbedrede kontroller, udfør kvartalsvise gennemgange.

Design automatiserede processer for at klargøre brugere med den relevante indledende adgang, justere tilladelser, efterhånden som roller udvikles, og fjern provision hurtigt, når der ikke længere kræves adgang.

Implementer et SCIM-system (Cross-Domain Identity Management) til automatiseret provisionering fra identitetsudbydere. SAML eller OpenID Connect Just-in-Time-provisionering er et alternativ, der opretter en bruger ved første login, men det fjerner ikke provisionering af brugere. Med andre ord er SCIM grundlaget for livscyklussen, ikke et valg imod det.

Identitetens livscyklus inkluderer:

• Provisionering: Opret konti med basisadgang, der matcher jobfunktion, som udløses af HR-systembegivenheder.
• Adgangsjusteringer: Tildel yderligere tilladelser, når roller udvides, og tilbagekald tilladelser, når roller ændres.
• Periodisk omcertificering: Gennemse og valider adgang kvartalsvis.
• Afvikling: Tilbagekald adgang straks, når beskæftigelsen slutter, eller når roller ikke længere kræver Salesforce-adgang.

Implementer gencertificeringsprocesser for adgang, når managers regelmæssigt gennemser og validerer deres teams tilladelser. Gennemgangsfrekvens er baseret på risiko og compliancekrav.

Din ansvar: Implementer SCIM, design klargøring af arbejdsflows, udfør kvartalsvis gencertificering.

Adskillelse af data i flere organisationer ses nogle gange som en ren omkostnings- eller opholdsbeslutning. Arkitektonisk set er det en sikkerhedsudskiftning, og styringskonsekvenserne hører til dit adgangsdesign.

Isolering er nøglefordelene. Separate organisationer giver den stærkeste grænse mellem datasæt. Der er ingen kollektiv delingsmodel og ingen grænseoverskridende lejertilladelser, men der er en tydelig regulering for jurisdiktioner, der kræver en. Den samme grænse opdeler styring. Hver adgangskontrol, som du kun har brug for at vedligeholde en gang i en enkelt organisation (f.eks. tilladelsessætdesign, rollehierarki, hardening af kritisk-påvirkningskonto, basislinjer for tilstandscheck, begivenhedsovervågning og SIEM-korrelation), ganges nu pr. organisation, hvilket betyder, at den skal vedligeholde ensartethed på tværs af dem alle. Afvigelse mellem organisationer skaber sin egen angrebsoverflade, fordi en tilladelse, der er indsnævret i en organisation, og som mangler i en anden, skaber en inkonsekvens, som angribere kan finde og udnytte. Krydsorganisationsintegrationer tilføjer godkendte Trust, der ikke eksisterede før. Hver krydsorganisationsintegration er en forbindelse, som du skal sikre og overvåge.

Derfor er det vigtigt at veje isolationsfordelen op mod styringsmultiplikatoren, før du opdeler en organisation. Reserver multi-organisationer for sager, hvor en hard localization-mandat eller en kundes kontraktmæssige isoleringskrav faktisk ikke kan opfyldes i en enkelt organisation. Når du anvender den, skal du designe adgangsmodellen, overvågningen og konfigurationsbasislinjerne, så de håndhæves identisk på tværs af hver organisation fra starten.

Din ansvar: Behandl en beslutning for flere organisationer som en sikkerhedsudskiftning, ikke kun en udgift. Hvor der kræves flere organisationer, skal du håndhæve adgangskontroller, overvågning og basislinjer for tilstandscheck ensartet på tværs af hver organisation og sikre hver krydsorganisationsintegration som en Trust.

Det er dit ansvar at klassificere data, konfigurere kryptering, designe fortrolighedskontroller.

Lad os se nærmere på, hvordan du beskytter data og fortrolighed korrekt.

Hvis du vil klassificere dine data korrekt, skal du kende dine data. Den overordnede arkitektoniske opgave er at forstå dit forretningsdomæne og vedligeholde en dataordbog, der katalogiserer, hvilke data du har, hvad det betyder, og hvor følsomme data findes. Du kan kun klassificere – eller beskytte – data, som du identificerede først.

Opret en dataklassificeringsplan, der styrer relevante beskyttelseskontrolelementer. En klassificeringsbetegnelse beskytter ikke noget i sig selv. Det er inputtet til de kontroller, som du anvender, så hver klassificering, som du tildeler, skal knyttes til en konkret krypterings-, adgangs-, bevarelses- eller overvågningsbeslutning. Klassificeringsbeslutninger, der træffes under datamodellering, påvirker direkte krypteringskrav, adgangskontroller, bevarelsespolitikker og overholdelsesforpligtelser.

I Salesforce bruger vi en skema på fire niveauer, der leverer en struktur, som du kan tilpasse til din organisations bestemmelseskrav og forretningsbehov. Mange virksomheder bruger lignende modeller, der er i overensstemmelse med branchestandarder (f.eks. ISO 27001 og NIST). Din specifikke implementering skal afspejle dine overholdelsesforpligtelser (f.eks. HIPAA, PCI DSS, GDPR og branchebestemmelser) og forretningskontekst.

Anvend klassificering på feltniveauet. En enkelt kontoregistrering kan indeholde offentlige felter (f.eks. firmanavne), fortrolige felter (f.eks. firmaomsætninger) og begrænsede felter (f.eks. personnumre). Sikkerhed på feltniveau skal afspejle disse forskelle.

Klassificering bliver håndhævet gennem attributbaseret adgangskontrol, som læser de tags, du tildeler, og anvender adgangsregler. Dette er et metadatastyret lag, der supplerer OWD- og delingsregler.

Tilpasning af ABAC til din klassificeringsplan giver platformen mulighed for at:

• Begræns adgang til data, der er tagget begrænset eller fortrolig, fra selve klassificeringen i stedet for fra en delingsregel, der vedligeholdes pr. objekt.
• Tilpas adgang, efterhånden som en registrerings klassificering ændres over tid. En registrering, der netop er tagget som Reguleret, overtager strengere adgang uden en manuel regelændring.
• Kombiner dataattributter (f.eks. klassificering og følsomhed) med brugerattributter (f.eks. afdeling og klargøring) og kontekst (f.eks. tid og placering) i en enkelt autorisationsbeslutning.

Design ABAC-politikker, så de passer til denne ordning, så klassificering af et felt som begrænset er den handling, der styrer adgangskontrollen og holder håndhævelsen forankret i klassificeringen i stedet for at vedligeholde delingsregler separat.

Din ansvar: Definer klassificeringsskema, træn datamodelbrugere, klassificer felter under design, konfigurer kontroller, og juster ABAC-politikker til klassificeringsniveauerne, så tags styrer håndhævelse.

StartBegin med de oplysninger, som platformen allerede leverer for hver organisation. Data, der er inaktive, krypteres som standard. Hyperforce anvender kryptering på mængdeniveau, der beskytter en hel lagervolumen under en enkelt nøgle, som Salesforce ejer og administrerer. Denne basislinje er altid tilgængelig og gennemsigtig for din løsning, men den fungerer på mængdeniveau (ikke pr. felt), så valg af, hvad der skal krypteres og kontrolleres inden for nøglelivscyklussen, afhænger af platformen, ikke af dig.

Når denne basislinje ikke kan opfylde en overensstemmelses-, kontraktmæssig eller dataklassificeringsforpligtelse, skal du bruge Shield Platform Encryption. Når du har brug for en af de tre ting, som kryptering på mængdeniveau ikke leverer:

• Kontrol af nøglelivscyklussen, så du selv kan generere, rotere og tilbagekalde nøglematerialet
• Selektivitet over hvilke standardfelter, tilpassede felter, filer og vedhæftede filer, der er krypteret, mens de er inaktive
• Muligheden for at gøre data utilgængelige for Salesforce.

Begrænsede data og data, der er under eksplicitte regulerende nøglekontrolmandater (f.eks. HIPAA, PCI DSS og GDPR) er de sædvanlige udløsere. Basislinjen dækker allerede beskyttelse på infrastrukturniveau af alt andet.

Shield Platform Encryption krypterer på feltniveau, og det tilbyder to ordninger, der handler om sikkerhed for forespørgsel.

Sandsynlighedskryptering er et stærkt standardskema, men de felter, der er krypteret med det, kan ikke bruges i filterkriterier, sorteringsfunktioner eller aggregeringsfunktioner (f.eks. MAX(), MIN() og COUNT_DISTINCT() funktioner).

Deterministisk kryptering muliggør exact-match-filtrering i rapporter, listevisninger og SOQL WHERE-sætninger – hvor der skelnes mellem store og små bogstaver – med mindre styrke, fordi den samme almindelige tekst altid producerer den samme kodetekst.

Vi anbefaler, at du krypterer med sandsynlighedskemaet som standard og reserverer deterministisk kryptering for de specifikke felter, som du skal filtrere eller sortere. Evaluer disse afvejninger under datamodeldesign, herunder påvirkninger af formelfeltreferencer, rapportaggregering og SOQL-handlinger.

Kundekontrollerede nøgler findes i to forskellige former:

• Bring Your Own Key (BYOK) giver dig mulighed for at generere nøglemateriale uden for Salesforce – ved brug af dine egne kryptobiblioteker, virksomhedsnøgleadministrationssystem eller hardware-sikkerhedsmodul – og levere det til platformen.
• Key Service bevarer din datakrypteringsnøgle i en nøgletjeneste, som du kontrollerer. Salesforce henter den efter behov i stedet for at lagre den.

Med begge formularer kan du rotere og ødelægge nøglemateriale efter din egen tidsplan. Ødelæggelse af nøglemateriale gør de data, som den beskyttede, ugenererbare, hvilket er en effektiv, bevidst kontrol i stedet for en rutine. Det er også vigtigt at dokumentere dine nøglerotations- og tilbagekaldelsesprocedurer.

Alle integrationer skal bruge TLS 1.2 eller nyere (Salesforce-platformen håndhæver dette), men du skal implementere certifikatbaseret gensidig godkendelse for integrationer, der håndterer begrænsede data (ved brug af din egen konfiguration).

Din ansvar: Beslut, hvor platformens basislinje på mængdeniveau er tilstrækkelig, og hvor en overensstemmelses-, kontrakt- eller klassificeringsforpligtelse berettiger Shield Platform Encryption, vælg derefter krypteringsplaner, vælg og kør en kundekontrolleret nøglestrategi og implementer certifikatbaseret godkendelse for følsomme integrationer.

Beskyt følsomme data i ikke-produktionsmiljøer ved brug af strategier, der forhindrer Begrænsede data i at komme i sandboxes.

• Delvis sandbox-kopiering udelader Begrænsede data fra sandbox-opdateringer.
• Regler for datamaskering forvirrer følsomme feltværdier i sandboxes ved at bruge mønstre, der bevarer dataegenskaber.
• Syntetisk datagenerering gælder for udviklingsmiljøer, der aldrig kræver produktionsdata.
• Sandbox-skabeloner definerer, hvilke objekter og felter der skal inkluderes i hver sandbox-type.

Design til overensstemmelsestest er et arkitektonisk ansvar. Opbyg udviklings- og testcyklusser på syntetiske data med realistiske egenskaber, så teams kan validere op mod produktionslignende betingelser, mens regulerede data forbliver inden for deres produktionsgrænse.

Din ansvar: Design sandbox-strategi, konfigurer Data Mask, generer syntetiske testdata.

Design løsninger, der respekterer brugerfortrolighed via arkitektoniske beslutninger.

• Dataminimering: Indsaml kun data, der er nødvendige til angivne forretningsformål. Udfordre alle felttilføjelser ved at spørge "Hvilken arkitektonisk beslutning kræver disse data?" Husk, at de sikreste data er de data, som du aldrig indsamler.
• Begrænsning af formål: Design dataadgangsmønstre, der gennemtvinger formålsbegrænsning teknisk. Brug tilladelsessæt og delingsregler til at begrænse adgang til data baseret på en jobfunktions formål. Marketingbrugere bør f.eks. ikke få adgang til supportsagsdetaljer, medmindre deres job kræver det.
• Samtykkestyring: Implementer samtykkesporing på individuelt niveau for marketing, analyser og valgfri databehandling. Design arbejdsflows for samtykketilbagetrækning, der udbredes på tværs af integrerede systemer. Med andre ord er samtykket detaljeret og formålsspecifikt.
• Rettigheder for registrerede: Opbyg arbejdsflows for adgangsanmodninger (f.eks. levering af datakopier), rettelse (f.eks. rettelse af unøjagtigheder), sletning (f.eks. sletning af data, når det er juridisk tilladt at gøre det) og portabilitet (f.eks. eksport til et maskinlæsbart format). Design disse arbejdsflows til at blive fuldført inden for den tidsfrist for svar, som hver styringsstruktur pålægger. Disse tidsfrister varierer efter jurisdiktion – og de ændres regelmæssigt – så det er vigtigt at parametrisere arbejdsflowets SLA fra en vedvarende overensstemmelseskilde og bekræfte hvert vindue op mod den gældende bestemmelse (i stedet for at hardcode en enkelt værdi).

Din ansvar: Design datamodeller med minimering, konfigurer adgang efter formål, implementer samtykkearbejdsflows, opbyg automatisering af registrerets rettigheder.

Dataplacering er et arkitektonisk beslutningsvalg, som du foretager før klargøring, ikke en indstilling, som du skifter til efterfølgende. Hyperforce tilbyder regional implementering – men der findes kun et område, hvor Salesforce driver et – og en organisations bopæl er fastsat på provisionering. Dit ansvar er at etablere, hvor hver datakategori skal være placeret, bekræfte, om der er et passende område tilgængeligt, og designe de dataoverførselsmekanismer, der legitimt krydser grænser.

I stedet for at bruge standardlagring i landet, er det vigtigt at klassificere dine bopælsforpligtelser, før du starter.:

• Påkrævet lokalisering. Et lille sæt af jurisdiktioner kræver, at visse data forbliver inden for nationale grænser (nogle gange gælder dette kun for regulerede sektorer). Når Salesforce ikke fungerer i et landegion, kan oprindeligt lager ikke opfylde mandatet alene, så du har brug for en dataplaceringsoverlejring eller en separat organisation for disse data. Da denne liste kan skifte, er det vigtigt at bekræfte den specifikke mandat i forhold til den gældende bestemmelse.
• Baserede rammer. De fleste systemer pålægger ikke en lokaliseringsmandat. De er tilfredse med en regional hub med en relevant grænseoverskridende overførselsmekanisme. I disse situationer er beslutningen baseret på, hvilket område der minimerer forsinkelse og forenkler overholdelse.

Når data krydser en kant, handler det om bevidsthed før konfiguration. Med andre ord skal du vide, hvilke overførsler der forekommer, og på hvilket retsgrundlag, og derefter designe adgang, så dataene styres fra ende til ende. Der, hvor de findes, bærer tilstrækkelighedsbeslutninger den mindste friktion. Binding af virksomhedsregler (BCR'er) og standardkontraktklausuler (SCC'er) dækker de fleste resterende overførsler. Brug kun eksplicit samtykke som sidste udvej.

Par overførselsmekanismen med restriktiv registreringsadgang (f.eks. private OWD'er og tilpasset deling), så en tilladelig overførsel ikke bliver for bred. Dokumentdataforløbstilknytter til at vise, hvor hver datakategori stammer fra, forløber og findes. Gennemse dem igen, når bestemmelser eller regionale tilgængeligheder ændres.

Din ansvar: Klassificer bopælsforpligtelser efter datakategori, bekræft regional tilgængelighed, før klargøring, vælg overførselsmekanismer (tilstrækkelighed, BCR'er/SCC'er) for grænseoverskridende forløb, og dokumenter dataforløbskort.

Det er dit ansvar at designe løsninger, der vedligeholder den overensstemmelsestilstand, som platformen leverer.

Denne vejledning er retningsgivende. Bestemmelseskrav varierer efter jurisdiktion og ændring over tid. Du skal altid bekræfte specifikke forpligtelser i forhold til den regulerende bestemmelse (f.eks. den gældende statut, supervisionsmyndighed eller Salesforce-overensstemmelsesdokumentation) for din implementering.

Salesforce har omfattende overensstemmelsescertificeringer (tilgængelig på Trust.salesforce.com og compliance.salesforce.com): SOC 2-type II, ISO 27001, FedRAMP (for Government Cloud-tilbud), HIPAA, PCI DSS og regionale certificeringer. Disse certificeringer dækker Salesforce-ansvar for platformsinfrastruktur og delte tjenester.

Platformscertificeringer reducerer din compliancebyrde, men de eliminerer ikke dit arkitektoniske ansvar. Dine tilpassede objekter, Apex, integrationer og konfigurationer skal bevare den overensstemmelsestilstand, som platformen leverer.

Din ansvar: Design løsninger, der vedligeholder overensstemmelsestilstand, og dokumenter, hvordan arkitekturen opfylder bestemmelseskrav.

• Aktiver Shield Platform Encryption for alle felter, der indeholder beskyttede helbredsoplysninger (PHI).
• For at opnå HIPAA-overensstemmelse skal du aktivere Field Audit Trail med bevarelsespolitikker for at opfylde HIPAA's registreringsbevarelseskrav. Bekræft den aktuelle periode op mod den gældende bestemmelse.
• Konfigurer begivenhedsovervågning til at registrere uautoriserede PHI-adgangsmønstre.
• Implementer alle tekniske sikkerhedsforanstaltninger, der kræves af HIPAA-sikkerhedsreglen, herunder adgangskontroller, revisionslogføring og transmissionssikkerhed.

• Implementer SoD (separation of duties) via tilladelsessætdesign for at forhindre enkeltbrugere i at oprette og godkende finansielle transaktioner.
• For PCI-miljøer skal du undgå at lagre komplette primære kontonumre (PAN) i Salesforce for at minimere omfanget af PCI DSS-overensstemmelse.
• Når det er muligt, skal du bruge betalingsgatewaytokenisering.

• For GDPR og LGPD skal du designe samtykkestyring, der registrerer detaljeret, formålsspecifikt samtykke.
• CCPA/CPRA følger en frameldingsmodel. Angiv tydelige mekanismer til at framelde sig salg eller deling af personlige oplysninger i stedet for detaljeret formålsbaseret samtykke.
• Opbyg arbejdsflows for registrerets rettigheder, der er fuldført inden for hver struktures tidsfrist for svar og bekræftes i forhold til den regulerende bestemmelse.
• Implementer databevarelsesautomatisering, der fjerner data, når samtykket udløber.

• Brug Salesforce Government Cloud til regulerede offentlige arbejdsbelastninger.
• Implementer NIST 800-53-kontrolelementer, der er tilknyttet Salesforce-konfigurationen.
• Aktiver kontinuerlig overvågning via Begivenhedsovervågning, der distribueres til den offentlige SIEM-infrastruktur.

Din ansvar: Konfigurer Shield, Feltrevisionsspor, adskillelse af pligter, samtykkestyring, databevarelse baseret på bestemmelseskrav.

Bestemmelser for databeskyttelse og fortrolighed varierer væsentligt på tværs af jurisdiktioner – og specifikke forpligtelser ændres hurtigt – så dette niveau kræver beslutningstagning snarere end en land-for-land-tabel.

De to arkitektoniske hævepaneler er opholdssted og grænseoverskridende overførsel, som er omfattet af databeskyttelse og fortrolighed.

Hvis du vil overholde disse bestemmelser, skal du:

• Klassificer, hvor hver datakategori skal være placeret
• Bekræft, at der findes et passende område, før klargøring
• Design en juridisk overførselsmekanisme for data, der krydser en grænse.

Hvis du ønsker yderligere oplysninger, kan du se Dataophold og suverænitet for at få flere detaljer om beslutningsstrukturen.

Alt uden for dette betragtes som et punkt-i-tid-tal (f.eks. hvilken samtykkemodel en jurisdiktion bruger, tidsfristen for en anmodning om registreret, vinduet for at advisere regulerende myndigheder eller påvirkede personer efter et brud og den mindste bevarelsesperiode for revisionsregistreringer). Disse tal er angivet af bestemmelser, de er forskellige pr. struktur, og de redigeres på regulatorernes tidsplaner.

Hardcode dem ikke her. Du skal bestemme de næste trin baseret på den regulerende bestemmelse for din implementering – eller en vedligeholdt overensstemmelseskilde, der citerer en – og skalere dit design til det tætteste vindue i dit driftsområde.

Her er de varige arkitektoniske konsekvenser, der hører til designet.

• En deadline for anmodning om registreret, der måles i enkeltcifrede dage, kan ikke opfyldes af en ad hoc-manuel proces, så du skal automatisere DSR-fuldførelse, når du opererer i en jurisdiktion med kort tidsfrist. Brug Experience Cloud til registrering, Service Cloud til sagssporing, Center for beskyttelse af personlige oplysninger til udforskning og Forløb til fuldførelse.
• Et brudadviseringsvindue er for tæt til at improvisere, så du skal opbygge arbejdsflowet for brud-svar på forhånd. Bestem afvigelsesregler for begivenhedsovervågning, forhåndstildelte roller, forhåndkladde regulator- og registreringsemneadviseringer og en eskaleringssti, der antager den strameste deadline inden for dit fodaftryk. Individuelle adviseringer udløses generelt af en højrisikobestemmelse, så du skal inkludere en risikovurdering i arbejdsflowet.
• Nogle jurisdiktioner kræver eller anbefaler bevarelse i landet af revisionslogfiler – med minimumsområder, der strækker sig over flere år – så du skal tilpasse SIEM-bevarelse til det længste minimum inden for dit fodaftryk og bekræfte, om logfiler kan forlade jurisdiktionen.

Din ansvar: Design bopæl og overførsel pr. databeskyttelse og fortrolighed, automatiser DSR- og breach-respons-arbejdsflows til den strameste deadline i dit fodaftryk, og bekræft alle juridikspecifikke tal i forhold til den gældende bestemmelse snarere end en værdi, der er skrevet i denne vejledning.

Design til kontinuerlig overensstemmelsesvalidering i stedet for forberedelse af revision på tidspunktet.

• Sikkerhedstilstandscheck vurderer konfigurationen i forhold til Salesforce-sikkerhedsbasislinjer og angiver risikoscores. Kør kontroller regelmæssigt for at overvåge overholdelse af Salesforce-sikkerhedsbasislinjeanbefalinger. Vedligehold scores på 80 % eller højere (Meget gode bands eller Fremragende bands).
• Begivenhedsovervågning registrerer detaljerede logfiler for brugeraktivitet, API-kald, godkendelsesbegivenheder og dataadgangsmønstre. Distribuer begivenhedslogfiler til ekstern SIEM for langsigtet bevarelse, der overskrider de oprindelige bevarelsesgrænser.
• Transaktionssikkerhed evaluerer begivenheder i forhold til policer i realtid, og det kan blokere begivenheder, kræve en stigning i MFA eller advisere dig om politikovertrædelser.

Det er vigtigt at automatisere overensstemmelseskontroller i implementeringspipelines for at validere, at implementeringer ikke svækker tilladelsesmodeller, inaktiverer revisionsindstillinger eller introducerer ikke-kompatible konfigurationer.

Din ansvar: Kør tilstandscheck kvartalsvist, distribuer Begivenhedsovervågning til SIEM, konfigurer transaktionssikkerhedspolitikker, automatiser overensstemmelsesvalidering i CI/CD.

Design revisionssporstrategier, der er baseret på overensstemmelseskrav, undersøgelsesbehov og bevarelsesforpligtelser.

For regulerede miljøer skal du implementere Begivenhedsovervågning med ekstern SIEM-integration for langsigtet logbevarelse og krydssystemkorrelation. Design Felts revisionsspor-politikker, der dækker alle begrænsede og fortrolige felter, der er underlagt bestemmelser om registreringskrav.

Din ansvar: Aktiver feltrevisionsspor for følsomme felter, distribuer Begivenhedsovervågning til SIEM, konfigurer transaktionssikkerhedspolitikker.

Det er dit ansvar at integrere sikkerhed gennem udvikling, ikke som en eftertænkning.

Integrer sikkerhedspraksisser på den tidligst mulige udviklingsfase. Trusselmodellering under arkitektonifasen forhindrer sårbarheder på designniveau. Sikkerhedskrav, der registreres sammen med funktionelle krav, forhindrer dig i at behandle sikkerhed som en eftertænkning.

Sikkerhedsfejl koster væsentligt mere at afhjælpe, når de opdages i produktion, snarere end under design- eller udviklingsfaserne. En sikkerhedsfejl på designniveau, der registreres under arkitekturen, kan kun tage en samtale at rette. Men når den samme fejl findes i produktion, kræver det rearkitektur, datamigrering, overensstemmelseshjælp og potentiel brudadvisering.

Derfor praktiserer vi vagtsikkerhed, som fokuserer på:

• Trusselmodellering før designfinalisering
• Sikkerhedskrav i brugerhistorier
• Sikker kodningsuddannelse for udviklere
• Statisk analyse, der er integreret i id'er
• Sikkerhedsfokuserede kodegennemgange
• Automatiseret sikkerhedstest i CI/CD
• Sikkerhedsvalidering før produktionsimplementering

Din ansvar: Udføre trusselmodellering, træne udviklere, integrere Code Analyzer i CI/CD, kræve sikkerhedsbevidste kodegennemgange.

Det er vigtigt at designe forsvar mod almindelige sårbarheder i en Salesforce-kontekst. Lad os se nærmere på, hvordan vi knytter os til Salesforces OWASP Top 10 i 2025.

• A01:2025 - Brudt adgangskontrol: Håndhæv CRUD og sikkerhed på feltniveau (FLS) programmeringsmæssigt i al Apex.
  • I API version 67.0 eller nyere kører Apex som standard i brugerkontekst, hvilket betyder, at den aktuelle brugers tilladelser og FLS håndhæves under kørsel af kode.
    • WITH SECURITYENFORCED blev fjernet, hvilket forårsager en kompileringsfejl. Erstat eventuelle eksisterende anvendelser med WITH USER_MODE. Platformen håndhæver adgang i standardbrugergrænsefladen.
  • I API version 66.0 eller tidligere er systemtilstand standarden. Brug WITH USERMODE i SOQL-forespørgsler eller Security.stripInaccessible() til DML-handlinger.
• A01:2025 - Data-API'er på klientsiden: Lightning Data Service og brugergrænsefladens API håndhæver automatisk den løbende brugers FLS, CRUD og deling, så en komponent, der er bygget på dem, overtager som standard mindst rettigheder.
  • Denne beskyttelse går tabt, når en komponent kalder en tilpasset Apex. Imperativ Apex håndhæver kun adgang, når den kører i brugertilstand, så en klasse, der er erklæret uden deling, fungerer som en escape-lukke, der støjsvagt tilsidesætter modellen.
  • Brug Lightning Data Service og brugergrænsefladens API til dataadgang.
  • Du skal bekræfte CRUD, FLS og deling igen for hvert obligatorisk Apex fra en komponent.
• A02:2025 - Sikkerhedsfejlkonfiguration: Overvåg konfigurationsforskydning fra sikkerhedsbasislinjer ved brug af tilstandscheck.
  • Inaktiver gæstebrugeradgang på Experience Cloud-lokaliteter (medmindre det er eksplicit påkrævet under en dokumenteret forretningsjustering).
• A05:2025 - Indsprøjtning: 2025-injiceringskategorien dækker SOQL/SOSL-injicering og XSS (cross-site scripting).
  • For forespørgselsinjektion skal du bruge bindingsvariabler til alle dynamiske forespørgsler. Sammenkæd aldrig brugerinput direkte i forespørgselsstrenge. Platformens parametrerede forespørgselsmekanismer eliminerer injektionsrisiko, når de bruges korrekt.
  • SOQL- eller SOSL-injektioner omfatter en læsning, der viser registreringer eller felter, som opkalderen ikke skal kunne nå ved at udvide forespørgselsbetingelser. Da disse sprog læser data, mens skrivning kører gennem separate DML-handlinger, skaber dette en adgangskontrol og fortrolighedsrisiko, fordi det sammensættes, når objekttilladelser og felttilladelser ikke håndhæves på forespørgslen.
  • For XSS giver Lightning Web-komponenter automatisk beskyttelse via LWC-gengivelsessystemet.
  • For Aura-komponenter og Visualforce skal du anvende platformskodningsfunktioner (f.eks. HTMLENCODE, JSENCODE og URLENCODE) ved gengivelse af dynamisk indhold.

Din ansvar: Håndhæv CRUD/FLS i tilpasset kode, anvend kodningsfunktioner, brug bindingsvariabler, overvåg konfigurationsforskydning.

Design CI/CD-pipelines med sikkerhedsportaler i hver fase. Sikkerhed skal automatiseres for at skalere med udviklingshastighed.

Lad os se nærmere på pipeline-sikkerhedsfaserne.

• Kildekontrol bruger forgreningsbeskyttelsesregler med påkrævede kodegennemgange. Der er ingen direkte bekræftelser til hovedforgreninger eller signerede bekræftelser.
• Statiske analyser bruger Salesforce Code Analyzer, som integrerer PMD, ESLint og RetireJS til at registrere indsprøjtning, XSS og usikre mønstre.
• Sikkerhedsscanning bruger SAST-værktøjer og hemmelighedsregistrering til at forhindre bekræftelse af legitimationsoplysninger og scanning af afhængighedssårbarheder.
• Tilladelsesvalidering bruger automatiske sammenligningsteknikker til at gennemse tilladelsesændringer i forhold til sikkerhedsbasislinjer, som sender advarsler om rettighedsudvidelse.
• Implementeringsgateways afbryder implementering af kritiske sikkerhedsresultater, der kræver godkendelse af sikkerhedsteamet for tilladelsesudvidende ændringer.
• Overvågning efter implementering bruger Event Monitoring-advarsler for afvigelse efter implementering.

Din ansvar: Integrer Code Analyzer i CI/CD, konfigurer forgreningsbeskyttelse, implementer implementeringsgateways, valider tilladelser automatisk.

Omfattende sikkerhedstest inkluderer flere teknikker, der håndterer forskellige sårbarhedsklasser. Lad os se nærmere på hver strategi.

• Statiske analyser kører Salesforce Code Analyzer i udvikler-IDE'er for øjeblikkelig feedback og i CI/CD-pipelines som automatiserede porte. Statisk analyse identificerer sårbarheder i kildekode uden at køre applikationen.
• Penetration Testing udfører penetrationstest for tilpassede applikationer, der udsættes for brugere, der ikke har tillid til, især Experience Cloud-lokaliteter og offentlige API'er.
  • For AppExchange og AgentExchange-sikkerhedsgennemgang kræves der altid statiske analyserapporter.
  • Der kræves en dynamisk scanningsrapport (penetrationstest), når løsningen integrerer en tredjepartsapplikation eller tjeneste.
  • Penetrationstest simulerer angriberteknikker mod liveapplikationer.
• Sikkerhedsfokuserede enhedstest skriver Apex-test, der validerer håndhævelse af adgangskontrol ved at køre som brugere med forskellige tilladelsesprofiler. Det er vigtigt at bekræfte, at CRUD/FLS-håndhævelse blokerer uautoriseret adgang.
• Afhængighedsscanning overvåger AgentExchange-pakker og JavaScript-biblioteker for kendte sårbarheder. Det er vigtigt at abonnere på sikkerhedsadviseringer for installerede pakker.

Din ansvar: Kør Code Analyzer, udfør penetrationstest, skriv sikkerhedsenhedstest, scan afhængigheder.

I Salesforce fokuserer sikkerheds- og datahændelsessvar på at registrere, indeholde og gendanne fra overtrædelser, uautoriseret adgang og ondsindet dataødelæggelse. Hændelsessvarteams arbejder sammen med to tilstødende søjler, der ejer tilstødende ansvarsområder:

• Operational Excellence dækker den operationelle mekanisme for hændelsesstyring (f.eks. sværhedsniveauer, on-call rotation, eskalering og efter-hændelsesgennemgang)
• Pålidelighed dækker tilgængelighedsgenoprettelse i forhold til RTO- og RPO-mål, herunder backup- og katastrofegenoprettelsesstrategi.

Som arkitekt er det dit ansvar at designe for sikkerhedshændelsesregistrerbarhed, -svar og -gendannelse.

Registrerbarhed er en arkitektonisk kvalitet, som du skal designe eksplicit for. Uden omfattende overvågning forbliver sikkerhedshændelser muligvis uregistrerede i længere tidsperioder.

Det er vigtigt at implementere registrering gennem flere kanaler.

• Begivenhedsovervågning registrerer rå begivenhedslogfiler, der dækker logins, rapporteksporter og dataeksporter, tilladelsesændringer og API-kald. Du skal identificere, hvilke begivenheder der er afvigelser, hvilket kræver transaktionssikkerhedspolitikker eller SIEM-korrelation oven på de logfiler, som du konfigurerer for at bestemme registreringslogikken.
• Transaktionssikkerhedspolitikker evaluerer begivenheder i realtid og blokerer mistænkelige handlinger. Du skal konfigurere disse politikker.
• Opsæt revisionsspor sporer de administrative ændringer, som platformen leverer, men du skal overvåge dem.
• Tilpasset applikationslogføring registrerer sikkerhedsrelevante begivenheder i Apex, som du skal implementere.

Distribuer begivenhedsovervågningslogfiler til SIEM-platforme for korrelation med virksomhedssikkerhedstelemetri. Design advarselsregler, der registrerer mistænkelige mønstre, mens du også minimerer falske positive gennem adfærdsmæssige basislinjer.

Din ansvar: Distribuer Begivenhedsovervågning til SIEM, konfigurer transaktionssikkerhedspolitikker, implementer tilpasset logføring, etabler adfærdsmæssige basislinjer.

Det er vigtigt at dokumentere arkitektoniske beslutninger, der understøtter hændelsessvar, før der forekommer hændelser.

• Isolationsgrænser designer løsninger til at isolere kompromitterede komponenter uden at forstyrre vigtige forretningsfunktioner. Du skal konfigurere tilbagekaldelse af tilladelsessæt, IP-begrænsningsændringer og sessionsafslutning for at levere hurtige isoleringsfunktioner.
• Forensisk bevarelse bruger Begivenhedsovervågning til at levere detaljerede aktivitetslogfiler (platformsfunktion). Feltrevisionsspor bevarer dataændringshistorik baseret på din konfiguration. Designlogfiler distribueres til uændret lager, så angribere ikke kan redigere din arkitektur.
• Gendannelsesprocedurer dokumenterer testede gendannelsesprocesser for almindelige hændelsestyper. Det er vigtigt at validere sikkerhedskopieringsintegritet regelmæssigt. Du skal kende dit RTO (Recovery Time Objective) og RPO (Recovery Point Objective) for sikkerhedshændelsesscenarier.
• Kommunikationsarbejdsflows designer adviseringsmekanismer, der fungerer under hændelser (f.eks. kommunikationskanaler uden for båndet, skabeloner, der er udarbejdet på forhånd, og eskaleringsprocedurer, der ikke er afhængige af potentielt kompromitterede systemer).
• Sårbarhedsangivelseskanalen er til offentlige Experience Cloud-lokaliteter. Den giver eksterne forskere en dokumenteret, overvåget måde til at rapportere sikkerhedsproblemer til dig via en offentliggørelsespolitik, der er udgivet i RFC 9116 security.txt-standarden. En ekstern rapport er ofte det første signal om en hændelse, så det er vigtigt at etablere denne adgangssti som en del af den arkitektur, som du er ansvarlig for.

Din ansvar: Dokumentaisoleringsprocedurer, distribuere logfiler til uforanderligt eksternt lager, teste gendannelsesprocedurer kvartalsvis, etablere kommunikation uden for båndet og udgive en sårbarhedsvisningerskanal for offentlige lokaliteter.

I Salesforce er det vigtigt at forberede svarfunktioner til platformsspecifikke scenarier.

• Kompromitterede brugerkonti registreres via afvigelser i Event Monitoring-login (f.eks. uventet geografi, usædvanlige tider og nye enheder). Når konti er kompromitteret, skal du fryse brugeren, gennemtvinge nulstilling af legitimationsoplysninger, gennemse revisionssporet for opsætning og dataadgangslogfiler for at bestemme kompromisperioden.
• Massedataudløb registreres via Event Monitoring-rapporteksporter og API-dataadgangsmængdeafvigelser. Når der forekommer dataudfiltrering, skal du straks tilbagekalde sessioner, begrænse tilladelser og identificere påvirkede registreringer og klassificeringsniveauer.
• Uautoriseret kodeimplementering registreres via implementeringsovervågning og ændringer af konfigurationen af revisionsspor for opsætning. Når uautoriseret kode er implementeret, skal du straks tilbagerulle implementeringen og overvåge alle ændringer fra de kompromitterede implementeringslegitimationsoplysninger.
• Eskalering af rettigheder registreres via overvågning af revisionsspor for opsætning for tilladelsesændringer, der er uden for godkendte ændringsvinduer. Når der forekommer rettighedseskalering, skal du straks tilbagekalde eskalerede rettigheder og overvåge aktiviteter, der er udført med forhøjet adgang.

Din ansvar: Dokumentsvarprocedurer for platformsspecifikke scenarier, konfigurer overvågning til at registrere hvert scenarie, testprocedurer gennem tabulatorøvelser.

Efter en hændelse er det vigtigt at udføre en vurderingfri efterhændelsesgennemgang, der er fokuseret på arkitektoniske forbedringer. Du skal dokumentere, hvad der skete, hvorfor de eksisterende kontroller ikke kunne forhindre eller registrere hændelsen, og hvilke arkitektoniske ændringer der er nødvendige for at reducere fremtidige risici.

Mål for efterhændelsesgennemgang:

• Bestem hændelsens tidslinje og angriberteknikker.
• Identificer de kontrolfejl, der aktiverede hændelsen.
• Dokumenter alle arkitektoniske svagheder, som hændelsen afslørede.
• Prioriter afhjælpning, der er baseret på risikobegrænsning.
• Del læringen på tværs af teams.
• Opdater registreringsregler og svarprocedurer.

Det er vigtigt at spore hændelsesmetrikker over tid for at bestemme den gennemsnitlige tid til at registrere (MTTD), den gennemsnitlige tid til at svare (MTTR) og påvirkningsomfanget.

Din ansvar: Udfør en rettidig efterhændelsesgennemgang, dokumenter forbedringer i ADR'er, spor MTTD- og MTTR-tendenser, del de lærte lektioner.

Brug denne tjekliste under arkitektoniske gennemgange, før produktionsimplementering og regelmæssigt til løbende vurdering. Hvert element repræsenterer dine ansvarsområder som en Salesforce-arkitekt.

Delt ansvar

• Dokumenter alt, som Salesforce sikrer (f.eks. infrastruktur, platform og compliancecertifikater).
• Dokumenter alt, hvad du skal sikre (f.eks. konfiguration, adgang, tilpasset kode og dataadministration).
• Identificer områder med delt ansvar (f.eks. hændelsessvar, sårbarhedsstyring og overvågning).
• Kommuniker ansvarsområder til interessenter og implementeringsteams så tydeligt og præcist som muligt.

Sikkerhedsarkitektur

• Fuldfør trusselmodellering ved brug af STRIDE-metodologien, før du begynder at opbygge.
• Anvend forsvar i detaljer på data-, applikations-, identitet- og integrationslag.
• Implementer nul-trust-principper, der kræver eksplicit bekræftelse for hver adgangsanmodning.
• Vedligehold aktuel lager for sikkerhedsaktiv, der dækker følsomme data, integrationer, API'er og rettighedskonti.
• Beslutninger for dokumentsikkerhedsarkitektur i ADR'er, herunder trusselanalyser og kontroljustering.
• Sikkerhed uden headless og på vegne af klienter ved Trust grænse ved at udbrede pr. bruger-identiteter i stedet for pooltokener.
• Gem, roter og opbevar OAuth-legitimationsoplysninger med mindst rettighedsomfang via eksterne klientapps.
• For beholderintegrationer skal du håndhæve beholderisolering som en sikkerhedsgrænse, kryptere mellembeholder- og hybrid VPN-trafik med mTLS (når strukturen kræver det), og justere implementeringsområder med dataplacering og compliancecertifikater

Identitets- og adgangsstyring

• Indstil OWD'er til Privat for objekter, der indeholder følsomme data.
• Reserver Populær skrivebeskyttet for objekter, hvor bred læseadgang er et dokumenteret krav.
• Håndhæv MFA for al adgang til produktionsbrugergrænsefladen og hardware-sikkerhedsnøgler for rettighedskonti. Kun API-integrationer, der bruger JWT Bearer- eller klientlegitimationsoplysninger, er fritaget.
• Implementer SSO ved brug af SAML 2.0 eller OpenID Connect med stærk IdP-godkendelse.
• Brug OAuth 2.0 (JWT Bearer foretrukket) til al API-godkendelse. Brug aldrig OAuth 2.0 til integrerede legitimationsoplysninger.
• Tildel adgang via tilladelsessæt, der er baseret på dokumenterede krav til mindste rettigheder.
• Anvend forbedrede kontroller på konti med kritisk påvirkning (f.eks. IP-begrænsning, loginadvarsler og periodiske adgangsgennemgange).
• Udfør periodiske adgangsgennemgange ved brug af dokumenteret attestation for konti med høje rettigheder, hvor frekvensen er bestemt af organisationens risikotolerance og compliancekrav.
• Automatiser identitetslivscyklussen via SCIM-provisionering og 90 dages inaktive kontoregistrering.
• Kør medarbejderagenter i den påloggede brugers kontekst, og klargør dedikerede, mindst-rettigheds-agentbrugere for kundeagenter. Gør aldrig dette for en gæstebruger på et offentligt sted.
• Implementer JWT for agentgodkendelse ved brug af agentforekomst- og botdefinitionsidentifikatorer.
• Definer ABAC-politikker, der er i overensstemmelse med dataklassificering og ensartede metadatataggingstandarder.

Databeskyttelse og fortrolighed

• Klassificer alle data, og anvend beskyttelseskontroller, der er relevante for hvert klassificeringsniveau.
• Aktiver Shield Platform Encryption for begrænsede data ved brug af dokumenteret nøgleadministration.
• Kræv TLS 1.2+ for alle integrationer med certifikatbaseret godkendelse for begrænsede data.
• Forhindr, at begrænsede data kommer ind i ikke-produktionsmiljøer via maskering eller udeladelse.
• Implementer samtykkestyring med detaljerede sporings- og tilbagetrækningsarbejdsflows pr. formål.
• Opbyg arbejdsflows for registrerets rettigheder, der fuldføres inden for hver styringsstruktures svarfrist. Disse skal være dimensioneret til det tætteste vindue i dit driftsfodaftryk og parametreret pr. jurisdiktion fra en vedligeholdt overensstemmelseskilde, hvor hvert tal er bekræftet i forhold til den gældende bestemmelse.
• Dokumenter dataplaceringskrav, og valider Hyperforce.

Overensstemmelse og overholdelse af bestemmelser

• Valider platformscertificeringer, der opfylder bestemmelseskravene for din branche.
• Aktiver Begivenhedsovervågning med SIEM-distribution for bevarelse, der overskrider de oprindelige bevarelsesgrænser.
• Konfigurer feltrevisionsspor til at dække begrænsede felter for at sikre, at bevarelsen opfylder de regulerende minimumskrav.
• Vedligehold scores for Sikkerhedstilstandscheck på 80 % eller højere (Meget godt eller Fremragende-bånd), og dokumenter eventuelle undtagelser.
• Automatiser overensstemmelsesvalidering for CI/CD-pipelines, der afbrydes under kritiske overtrædelser.
• Implementer transaktionssikkerhedspolitikker for afvigelsesregistrering og -svar i realtid.

Livscyklus for sikker udvikling

• Udfør trusselmodellering under designfasen (før du foretager væsentlige investeringer i opbygning).
• Håndhæv CRUD/FLS i alle Apex.
• Afhæng af automatisk håndhævelse af brugertilstand for API version 67.0 eller nyere, eller brug WITH USERMODE eller stripInaccessible() for API version 66.0 eller tidligere.
• Bruges ikke med SECURITYENFORCED, som blev fjernet i API version 67.0.
• Kør Salesforce Code Analyzer i CI/CD, når vigtige resultater blokerer implementering.
• Kræv kodeanmeldelser af sikkerhedsbevidste korrekturlæsere for alle produktionsændringer.
• Udfør penetrationstest for alle offentlige applikationer og Experience Cloud-lokaliteter.
• Valider og saniter alt brugerinput, der forhindrer injektion på tværs af SOQL-, SOSL- og HTML-kontekster.

Sikkerhedshændelsessvar

• Design begivenhedsovervågningsadvarselsregler for at registrere mistænkelige mønstre via adfærdsmæssige basislinjer.
• Distribuer logfiler til uforanderligt eksternt lager for retsmedicinsk bevarelse.
• Dokumenter og test hændelsessvarprocedurer for platformsspecifikke scenarier.
• Udfør skadesløse efterhændelsesgennemgange med ADR'er for at registrere arkitektoniske forbedringer.
• Spor MTTD- og MTTR-metrikker for at identificere registrerings- og svarmangler.

Del din feedback om den veludformede ramme.