Trust

Hos Salesforce er Trust vår beste verdi. Det er grunnlaget for alle arkitektoniske beslutninger på plattformen. For arkitekter oppnås Trust gjennom et unikt partnerskap: Salesforce tilbyr en sikker og samsvarende plattform – infrastrukturen, metadataene og verktøyene som gjør den til din egen – mens du utformer sikre løsninger som bygger på det grunnlaget.

Dette partnerskapet fungerer gjennom modellen for delt ansvar, som er et rammeverk som tydelig deler opp sikkerhetsansvar:

• Salesforce er ansvarlig for sikkerheten på plattformen, inkludert infrastruktur, patching og samsvarssertifiseringer.
• Du er ansvarlig for sikkerheten på plattformen, inkludert konfigurasjon, tilgangskontroller, tilpasset kode og datastyring.

Denne divisjonen er viktig fordi den definerer arkitektonisk ansvarlighet. Salesforce driver en arkitektur for flere leietagere der tusenvis av organisasjoner deler infrastruktur. Plattformen gir sterke sikkerhetsbeskyttelser på infrastrukturnivå. Dine arkitektoniske beslutninger bestemmer om de spesifikke løsningene dine skal oppnå interessenters tillit.

Modellen for delt ansvar gir deg ansvar for å utforme sikre løsninger, mens fysisk sikkerhet, nettverksbeskyttelse, plattformoppdatering og infrastrukturkryptering håndteres for deg. Det lar deg fokusere på å utforme sikre løsninger som bygger på det grunnlaget (for eksempel identitets- og tilgangsbehandling, databeskyttelse, integrasjonssikkerhet, sikre utviklingsrutiner, overholdelse av og overholdelse av forskrifter og hendelsessvar).

Forsømmelse av Trust under utformingen utgjør teknisk gjeld. En manglende krypteringsstrategi blir en kostbar etterbehandling når forskrifter endres. En ikke-administrert integrasjon blir en sårbarhet når legitimasjon kompromitteres. Å bygge Trust i fra begynnelsen er konsekvent billigere enn å ettermontere det senere.

Trust spenner over fire arkitektoniske dimensjoner som fungerer sammen:

• Sikkerhetskontroller beskytter systemer og data
• Identitetsbehandling styrer tilgang
• Personvernrutiner respekterer brukeragentur
• Samsvarsrammeverk oppfyller lovpålagte forpliktelser

Arkitekter som utformer for alle fire dimensjoner, skaper løsninger som oppnår og opprettholder Trust gjennom transparens, kontroll og fleksibilitet.

I Agentic Era utvides Trust til den klarerte konteksten som agenter opererer i. Klarert kontekst betyr at agenter får tilgang til styrte, bekreftede data med tydelige identitet- og tillatelsesgrenser, noe som gir AI-systemer mulighet til å tenke og handle på vegne av brukerne, samtidig som de opprettholder sikkerhet, revisjonsmuligheter og samsvar. Utforming av klarert kontekst er grunnleggende for Agentisk forretningsarkitektur.

Denne søylen etablerer grunnlinjen for plattformsikkerhet som hver Salesforce-løsning avhenger av. Pilen Agent Trust bygger på denne grunnlinjen for å håndtere risikoer som er unike for autonome agenter, inkludert umiddelbar innsetting, handlingsstyring og dataene som agenter kan få tilgang til i løpet av vurderingstider. Det er viktig å utforme standarden først, og deretter lage agentspesifikke kontroller ved bruk av Agenttic Trust-retningslinjene.

Denne søylen er dypt knyttet til andre rammeproblemstillinger.

• Pålitelighet avhenger av infrastruktur som motstår angrep og gjenoppretter fra brudd.
• Operational Excellence krever sikre distribusjonsledninger og hendelsessvar.
• Rettferdighet krever en transparent og etisk håndtering av data og algoritmiske beslutninger.

Sammen danner disse stolpene en forent, løsningsfokusert tilnærming som organisasjoner kan Trust for sine mest sensitive operasjoner.

I modellen for delt ansvar må Salesforce og arkitekter oppfylle sine respektive forpliktelser for å opprettholde Trust. La oss ta en nærmere titt på hva hver side må sikre.

Salesforce er ansvarlig for å sikre plattformen og den globale infrastrukturen, inkludert:

• Datasentertilgangskontroller, overvåking og miljøbeskyttelser
• For Hyperforce håndterer den underliggende skyleverandøren (for eksempel AWS, Azure eller Google Cloud, avhengig av forekomsten) fysisk datasentersikkerhet via delegert ansvar. Salesforce Infrastruktur- og underbehandlingsdokumentasjonen identifiserer leverandøren og underbehandlerne for hver tjeneste.

• Sikkerhetskontroller på nettverksnivå, inkludert DDoS-beskyttelse og trusseldeteksjon
• Trafikkkryptering underveis (TLS 1.2+) og under lagring (vanligvis AES-256)

• Sårbarhetssvar og distribusjon av plattformoppdateringer via Salesforce (for mer informasjon om sikkerhetsvarsler kan du gå til security.salesforce.com)
• Administrasjon av operativsystem- og infrastruktursikkerhet

• Sertifikasjoner og attesteringer: Salesforce opprettholder SOC 1/2/3, ISO 27001/27017/27018, FedRAMP-godkjenning (omfattende Government Cloud Plus og MuleSoft Government Cloud, ikke den kommersielle plattformen for flere leietagere) og PCI DSS nivå 1-validering.
• Regulatorisk støtte: Dette gjelder for HIPAA-berettigede tjenester med Business Associate Agreements (BAA) eller GDPR-samsvarsprogrammer.
• Hvis du vil ha mer informasjon, kan du gå til trust.salesforce.com og compliance.salesforce.com.

• Leier isolasjon arkitektur: En delt, metadatastyrt kjerne partisjonerer hver organisasjons data og metadata etter organisasjons-ID, så én organisasjon kan ikke få tilgang til en annen organisasjons poster selv om begge kjører på en delt infrastruktur. Kjernen håndhever separasjon for hver spørring, ikke via en konfigurasjon som du må vedlikeholde.
• Infrastrukturnivåkryptering under lagring og reserveinfrastruktur: Basisplattformlisenser inkluderer Classic Encryption (AES-128 inneholder bare tilpassede tekstfelt). Shield Platform Encryption krever en separat lisens (AES-256 lar deg ta med din egen nøkkel og gir standard og tilpassede felt, filer og vedlegg).

Disse kontrollene sikrer at plattformen forblir sikker, pålitelig og samsvarende.

Du er ansvarlig for å sikre data, konfigurasjoner og driftsprosesser.

• Identitet og føderasjon: For enkeltpålogging (SSO) og godkjenning med flere faktorer (MFA) må du bekrefte identiteten til brukeren.
• Tilgangsbegrensning: Teknisk sett begrenser IP-adresseområder og påloggingstider hvordan og når identiteter kobles til hverandre.
• Principe of Least Privilege (PoLP): Bruk PoLP til å gi tilgang bare til roller, profiler og tillatelsessett som er nødvendige for å utføre individuelle jobboppgaver.
• Livssyklusbehandling: Øv deg i retningslinjer for livssyklusbehandling for brukere og ny tilgangssertifisering.

• Bruk dataklassifisering, maskering og objekt/felt/postnivåsikkerhet
• Håndheve CRUD-tillatelser og delingsregler
• Eier, test og distribuer en godt utprøvet strategi for å gjenopprette organisasjonens data, slik at du har kontroll over tap av data eller gjenoppretting av korrupsjon.

• Bruk API-godkjenning (for eksempel OAuth 2.0 eller JWT) og navngitt legitimasjon.
• Aktiver dedikerte integrasjonsbrukere med PoLP-tillatelsessett slik at hver integrasjons tilgang er omfangsgrenset og kan revideres separat fra brukere.
• Sikre endepunkter og ekstern systemvalidering.

• Bruk hendelsesovervåking, revisjonsspor og integrasjon av sikkerhetsinformasjon og hendelsesbehandling (SIEM).
• Følg hendelsessvarprosedyrer og sikkerhetsgjennomganger.

• Bruk sikker tilpasset kode (for eksempel Apex eller Lightning) og inndatavalidering.
• Kjør Apex i brukermodus slik at objekt-, felt- og delingstillatelser håndheves i kode.
• Følg fremgangsmåten for injeksjonsforebygging og sikker utvikling.

• Oppretthold overholdelse av krav om løsninger.
• Følg policyer for personvern/samtykkebehandling og dataoppbevaring.

Enkelte ansvarsområder krever samarbeid:

• Sikkerhetshendelser: Begge parter deltar i deteksjons- og responsaktiviteter.
• Sårbarhetsbehandling: Salesforce patcherer plattformen, arkitekter patcher tilpasset kode.
• Sikkerhetsovervåking: Kombiner plattformgenererte sikkerhetssignaler med arkitektanalyse.
• Samsvarssertifikasjoner: Salesforce sertifiserer plattformen (for eksempel SOC, ISO og FedRAMP for Government Cloud); arkitekter eier det som bygges på den – tilpassede objekter, kode, integrasjoner og konfigurasjon – innenfor den sertifiserte posisjonen for å gi bevis for samsvar for revisjoner.
• Identity Federation: Salesforce stoler på deklarasjonene som arkitektidentitetsleverandøren utsteder. Arkitekter sørger for å sikre leverandøren og Trust-relasjonen mellom leverandøren og Salesforce.
• Nøkkeladministrasjon: Ved å bruke kryptering med din egen nøkkel driver Salesforce krypteringstjenesten mens arkitekter genererer, roterer og opphever nøkkelmaterialet som beskytter dataene.

Alle utformingsprinsipper, emnedeler og sjekklisteelementer i dette dokumentet representerer ditt ansvar som arkitekt. Delt ansvarsmodell rammer det du må utforme og konfigurere for å oppnå Trust på Salesforce-plattformen.

Grensen omfatter også lovpålagte forpliktelser. Salesforce vedlikeholder plattformens sertifiseringer og attesteringer og sikrer infrastrukturen mot brudd. Arkitekter er ansvarlige for forpliktelsene som er knyttet til dataene og jurisdiksjonen din (for eksempel: hvilke lover som gjelder, hvordan data klassifiseres, hvilke oppbevarings- og samtykkeregler som styrer dem, og hvordan du oppdager og rapporterer brudd på dataene som du har kontroll over). I motsetning til de lovpålagte forskriftene for distribusjonene må arkitekter bestemme de spesifikke tallene bak disse forpliktelsene (for eksempel oppbevaringsperioder og tidsfrister for varsling), i forhold til de lovpålagte forskriftene for distribusjonen, fordi de kan variere etter jurisdiksjon og endres over tid.

Bruk disse prinsippene til å lede dine arkitektoniske beslutninger om sikkerhet på plattformen.

• Bruk null Trust på alle lag. Anta aldri Trust basert på nettverksplassering, brukerkjennskap eller systemopphav. Bekreft hver tilgangsforespørsel eksplisitt med godkjenning, godkjenning og kryptering på datalagene, programlaget, integrasjonen og infrastrukturlaget. Arkitektur for flere leietagere betyr at du deler infrastruktur med tusenvis av organisasjoner, så nettverket som løsningen kjører på, er ikke et område du kan behandle som klarert. Bekræft hver anmodning på dens egne værdier – identitet, autorisation og kontekst – i stedet for at tillide den for hvor den opstod.
• Tildel minste rettighet som standard. Gi det minste tilgangsnivået som er nødvendig for hver bruker, integrasjon og automatisert prosess for å oppnå formålet. Start med de mest restriktive innstillingene – private organisasjonsomfattende standarder (OWD-er) og minimale tillatelser – og utvid med vilje basert på dokumenterte forretningskrav. Bruk tilgangsmodellen med fire lag (organisasjon → objekt → felt → post) slik at hvert lag ytterligere begrenser lagene ovenfor.
• Implementer forsvar i dybden. Lag flere sikkerhetskontroller slik at feil i én kontroll ikke kompromitterer hele systemet. Kombiner preventive kontroller (for eksempel CRUD/FLS-håndhevelse og transaksjonssikkerhetspolicyer som blokkerer operasjoner), detektive kontroller (for eksempel Hendelsesovervåking) og responsive kontroller (for eksempel transaksjonssikkerhetsoppgradert godkjenning og varsel). Utform hvert lag som om de tilstøtende lagene kan mislykkes. Husk at feltnivåsikkerhet beskytter data selv om delingsregler er for tillatte.
• Integrere sikkerhet etter design. Integrer trusselmodellering, sikkerhetskrav og kontroller validering i alle arkitekturfaser fra det første konseptet til kontinuerlig utvikling. Utfør trusselmodellering av typen Spoofing, Tampering, Repudiation, Information Disclosure, Denial of Service og Elevation of Privilege (STRIDE) før byggingen starter. Sikkerhet former valg av teknologi og utformingsbeslutninger.
• Bygd sikkerhet i automatisering. Bygg sikkerhetskontroller i automatiserte pipelines, konfigurasjonsmaler og plattformstandarder. Salesforce Code Analyzer i CI/CD fanger opp sårbarheter før distribusjon. Configuration-as-code håndhever grunnleggende sikkerhetslinjer. Innebygd sikkerhet sikrer konsistens og gjør det mulig å skalere sikkerheten med løsningens kompleksitet.
• Design for privatliv. Inkorporer personvernprinsipper fra den første arkitekturfasen. Utforming for dataminimering (samle bare nødvendige data), formålsbegrensning (begrens tilgang etter jobbfunksjon), samtykkebehandling (håndheve detaljert, formålsspesifikt samtykke) og datasubjektrettigheter (aktiver tilgangs-, rettelses-, slettings- og portabilitetsarbeidsflyter for å fullføre innenfor lovpålagte tidslinjer).
• Design for sporbarhet. Gjør hver konsekvenshandling tilskrivbar og rekonstruerbar etter faktum, før du bruker det til å oppdage avvik i den. Forsikre deg om at endringer i data, tillatelser og konfigurasjon fanges opp i revisjonsspor, felthistorikk og hendelseslogger, og bevar disse postene i manipulasjonsresistent lagring. Sporbarhet er forutsetningen for deteksjon, forensikk og ansvarlighet. Husk – du kan ikke undersøke hva som aldri ble registrert.
• Design for hendelsessvar. Utforming for detekterbarhet via Hendelsesovervåking og for intervensjon i sanntid via policyer for transaksjonssikkerhet. Aktiver raske svar via dokumenterte prosedyrer og isolasjonsgrenser. Støtt gjenoppretting via sikkerhetskopifunksjonalitet og rettsmedisinsk bevaring. Test svar via bordopplæringer og bruddsimuleringer.

Arkitekter er ansvarlige for å sikre løsninger på plattformen som Salesforce leverer.

Arbeidsbelastningene som samhandler med Salesforce, kjøres i økende grad utenfor kjerneplattformen – integreringstjenester, tilpassede programmer og hodeløse klienter kaller ofte opp Salesforce-API-er, ofte på vegne av en bruker. For å øke hastigheten på dette mønsteret viser Salesforce plattformens funksjonalitet som API-er, verktøy og kommandoer (for eksempel Salesforce Headless 360). Uansett hvem som driver disse programmene, eier arkitekten Trust der de møter Salesforce for å bestemme hvordan de godkjennes, hvilken identitet og tillatelser de bærer, hvilke hemmeligheter de holder, og hvilke data som krysser grensen.

Prinsippene nedenfor gjelder for hvilken som helst beholderbasert integrasjonsplattform (for eksempel MuleSoft CloudHub).

Når en ekstern klient godkjennes som en navngitt bruker, brukes Salesforces plattformsikkerhetsmodell automatisk – objekttillatelser, feltnivåsikkerhet og delingsregler håndheves nøyaktig slik de er i nettleseren. Godkjenning per bruker omfatter alle kall til denne enkeltpersonens tillatelser og beholder revisjonssporet, som betyr at oppheving av et brukertoken umiddelbart fjerner klientens mulighet til å handle på vegne av brukeren. Foretrukk denne i stedet for en delt tjenestekonto der arbeidet utføres for en bestemt bruker.

Utform grensen defensivt, fordi en klient som har tokener for mange brukere, konsentrerer Trust og blir en høyverdi proxy for en angriper: ett enkelt stjålet OAuth-token kan nå data på tvers av alle brukere som klienten betjener. Dette er ikke hypotetisk. Salesloft Drift-hendelsen i 2025 så angripere stjele OAuth-tokener og bruke dem til å få tilgang til Salesforce-data på tvers av hundrevis av organisasjoner.

• Propagere brukeridentitet, ikke samle den. Bruk godkjenning per bruker eller OAuth 2.0-tokenutveksling til å bære en brukers identitet på tvers av tjenestehopper (se Agentisk identitet og godkjenning), slik at kompromisser omfanges til én brukers kontekst i stedet for alle.
• Behandle OAuth-klientlegitimasjon og oppdateringstokener som det primære målet. Lagre dem i et administrert hemmelighetslager, roter dem ofte og vedlikehold utforminger for umiddelbar oppheving. Overvåk API-bruk for å se etter avvikende mønstre som signaliserer en proxy-angriper.
• Minimer omfanget på begge sider. Begrens OAuth-omfangene for den eksterne klientappen (ECA) og integrasjonsbrukerens Salesforce-tillatelser til et minimum som funksjonen krever, slik at en kompromittert klient ikke kan pivere til ikke-relaterte data.
• Styre grensen gjennom eksterne klientapper. ECAs definerer hvordan et eksternt program godkjennes, hvilke flyter som er tillatt, og hvilke omfang som gjelder – utform nye integrasjoner mot dem (se Authentication Architecture).

Utfør forsiktighet når en klient kjører som agentbruker eller integrasjonsbruker: disse identitetene kan operere i en forhøyet kontekst – ofte mot eksterne systemer som ikke respekterer Salesforces tilgangskontroller – så bruk av tillatelses- og overvåkingsdisiplinen som er skissert ovenfor, er det som holder denne strømbegrensningen.

Når integrasjoner kjøres i en beholderbasert plattform, betraktes isolering på beholdernivå i seg selv som en sikkerhetskontroll: hvert program kjører i en dedikert beholder uten delt kjøretid eller minne mellom programmer

Denne isolasjonen gir følgende:

• Leier grense håndhevelse: Kompromitterte programmer får ikke tilgang til data eller ressurser fra nærliggende programmer som deler det samme miljøet. Hver beholder har et isolert filsystem og prosessplass. Håndhev nettverksisolasjon via brannmur- og TLS-konfigurasjon, og begrens eksplisitt utgående trafikk i stedet for å bruke tillatelsesstandarder.
• Defense-i-dybde: Beholderisolering legger til et sikkerhetslag utover kontroller på programnivå. Selv om programkoden har sårbarheter, begrenser beholdergrensene blastradiusen.
• Samsvarsegmentering: Regulerte arbeidsbelastninger (for eksempel PCI og HIPAA) kan isoleres i dedikerte beholdere for å hindre samblanding med ikke-samsvarende arbeidsbelastninger.

Arkitekter som utformer miljøer for flere programmer, må basere seg på beholderisolering for å håndheve adskillelse av oppgaver og sikkerhetsdomener. Finanstjenesteintegrasjoner som håndterer kortholderdata, må kjøre i separate beholdere fra markedsføringsintegrasjoner, selv i det samme miljøet.

Trafikk mellom beholdere bør krypteres, og gjensidig TLS (mTLS) bør brukes der et regelverk krever godkjenning på begge sider:

Hvordan det fungerer:

• Konfigurer TLS-kontekster for å aktivere valgfri gjensidig TLS (mTLS) for innkommende tilkoblinger når det er nødvendig.
• Bruk SSL på plattformnivå med klientsertifikatgodkjenning til å sikre kommunikasjon mellom plattformtjenester og kopier.
• Konfigurer TLS-kontekster for å aktivere mTLS når det kreves av lovpålagte rammeverk.
• Behandle sertifikater via plattformens sertifikatbutikk slik at livssyklusen og opphevingen holdes sentralisert.
• Håndhev grenser for nettverksisolasjon som hindrer uautorisert trafikk mellom beholdere.

Kryptering av trafikk på plattformlaget gir dybdeforsvar for data under overføring. Selv om programlagets HTTPS er feilkonfigurert, forblir beholdertrafikk kryptert.

Beholdere som kobler til systemer på stedet via VPN, må arkitektere for å beskytte data under overføring:

• Tunnelkryptering: Rut all trafikk mellom beholdere og systemer på stedet via krypterte VPN-tunneler. Dette gjelder uavhengig av TLS-et på programlaget. Defense-in-depth sikrer at det er dobbelt kryptering for sensitive data.
• Håndhevelse av nettverkssegmentering: VPN-tunnelpolicyer begrenser hvilke nettverk på stedet som beholdere kan nå. Kompromitterte beholdere kan ikke pivotere til uautoriserte interne systemer utover VPN-tillatte nettverk.
• Samsvarsbevis: VPN-kryptering er en av de godkjente mekanismene for å beskytte data under overføring til og fra skymiljøer. Revisorer som gjennomgår HIPAA-, PCI-DSS- eller SOX-kontroller, forventer dokumentert kryptering under overføring for hybridintegrasjoner.

Arkitekter må utforme VPN-policyer som håndhever nettverkstilgang med færrest rettigheter. Markedsføringsintegreringsbeholdere skal ikke rutes til interne økonomisystemer selv om begge er tilgjengelige via VPN.

Tomme domener (for eksempel tilpassede URL-adresser for integrasjons-API-er) krever at arkitekter behandler TLS-sertifikater som Trust anker:

Tomme domener (for eksempel tilpassede URL-adresser for integrasjons-API-er) krever at arkitekter behandler TLS-sertifikater som Trust anker.

• Automatisering av livssykluser for sertifikater: Implementer automatisk sertifikatfornyelse og distribusjon. Utløpte sertifikater bryter integrasjons Trust, klienter avviser tilkoblinger med sertifikatvalideringsfeil.
• Planlegging av oppheving av sertifikater: Utform roteringsprosedyrer for sertifikater for sikkerhetshendelser. Kompromitterte private nøkler krever rask ny utstedelse og distribusjon av sertifikater på tvers av alle regioner.
• Cipher suite konfigurasjon: Eldre TLS-konfigurasjoner (TLS 1.0/1.1 og svake krypteringer) mislykkes i samsvarsrevisjoner. Håndhev TLS 1.2+ (minimumskrav), og juster sertifikat- og klientkonfigurasjoner med organisasjonens sikkerhetspolicyer.
• Sertifikatgjennomsiktighetslogging: Moderne TLS-sertifikater sendes til offentlige sertifikatgjennomsiktighetslogger (CT) av sertifiseringsinstanser (CA). Hver CT-logg returnerer et SCT (Signed Certificate Timestamp), et kryptografisk bevis på logging, som CA bygger inn i sertifikatet via en X.509v3-utvidelse. Arkitekter bør overvåke CT-logger for uautorisert sertifikatutstedelse mot domenene sine, ved å bruke tjenester som crt.sh eller automatisert varsel.

Feil behandling av sertifikater påvirker direkte Trust:

• Utløpte sertifikater: Forårsake godkjenningsfeil som vises som avbrudd. Overvåking må inkludere sending av varsler innen 30 dager før utløp for å tillate at fornyelsesarbeidsflyter starter.
• Egensigterte sertifikater: Dele opp Trust for eksterne kunder. Produksjonsintegrasjoner krever sertifikater som er signert av klarerte sertifiseringsinstanser (CAs).
• Wildcard-sertifikatutvidelse: Henviser til for brede jokertegnsertifikater (for eksempel *.company.com) som oppretter en stor blast radius hvis de blir kompromittert. Sertifikater med smalt omfang foretrekkes per integrasjonsdomene.

Beholderdistribusjonsområder må være i samsvar med krav til dataoppbevaring og samsvar.

• GDPR data residence: GDPR krever tilstrekkelig beskyttelse for personopplysninger som forlater EU, men ikke EU-distribusjon som sådan. Distribusjon av integrasjoner i et EU-område holder beholderberegning og databehandling innenfor lovpålagte grenser, som er den mest direkte måten å oppfylle dette kravet på. Overføringer som skjer utenfor EU, forblir tillatte i henhold til en tilstrekkelighetsbeslutning, standardkontraktsvilkår (SCC-er) eller bindende firmaregler (BCR-er).
• Datalokaliseringsregler: Land med krav til datalokalisering inkluderer følgende: Russland (forbundsforskrift 152-FZ og obligatorisk lagring) og Kina (PIPL/CSL for CIIOs), som kan kreve distribusjon av beholdere i landet. Indias DPDP Act fra 2023 bruker en svart liste-tilnærming som ikke pålegger et generelt lagringsmandat i landet. Dataoverføringer er tillatt til hvilket som helst land med mindre det er spesifikt begrenset av et myndighetsvarsel. Arkitekter må forstå jurisdiksjonsspesifikke forskrifter.
• Mekanismer for grenseoverskridende dataoverføring: Når det kreves en flerområdedistribusjon, men dataene må krysse grenser, må arkitekter implementere SCC-er, BCR-er eller andre juridiske overføringsmekanismer.
• Samsvarsertifiseringsjustering: Beholderdistribusjonsområder må samsvare med Salesforce-samsvarssertifiseringer. FedRAMP-godkjente arbeidsbelastninger krever regional distribusjon i USA. For HITRUST-sertifiserte integrasjoner må du kontrollere at distribusjonsområdet er innenfor et aktivt HITRUST-attesteringsomfang.

Regionale distribusjonsbeslutninger er arkitektansvar som direkte påvirker etterlevelse av forskrifter. Finansteam kan bestemme distribusjon bare for USA for SOX-kontrollerte integrasjoner. Behandlingsteam kan kreve HITRUST-sertifiserte regioner for behandling av personlig helseinformasjon (PHI).

Beholdere krever tilgang til legitimasjon, API-nøkler og krypteringsnøkler. Arkitekter må utforme prosesser for behandling av hemmeligheter som hindrer eksponering:

• Ingen hardkodede hemmeligheter: Bygg aldri inn legitimasjon i programkode- eller konfigurasjonsfiler som er distribuert til beholdere. Bruk plattformadministrerte hemmeligheter for butikker.
• Plattformadministrert hemmelig injeksjon: Løs hemmeligheter ved kjøretid fra plattformens administrerte butikk (i stedet for å beholde dem til filsystemet), og merk konfigurasjonsverdier som inneholder legitimasjon, som beskyttet slik at de ikke vises i logger eller på konsollen.
• Secrets rotasjon: Utform integrasjoner for å håndtere roterte hemmeligheter på en god måte. OAuth-tokenoppdateringsmønstre, arbeidsflyter for API-nøkkelrotasjon og endringer i databasepassord må ikke kreve ny distribusjon av beholdere.
• Tilgang til hemmeligheter med minst rettigheter: Gi beholdere tilgang bare til hemmelighetene som er nødvendige for funksjonen. Markedsføringsintegrasjoner bør ikke få tilgang til finanssystemlegitimasjon selv om de deler det samme miljøet.

Viste hemmeligheter er vanlige integrasjonssikkerhetshendelser. Arkitekter må utforme hemmeligheter som håndterer prosesser som kan overleve kodegjennomganger, logger, feilmeldinger og overvåke kontrollpaneler uten å lekke legitimasjon.

Programmer ved Salesforce-grensen genererer revisjonshendelser som oppfyller kravene til logging av samsvar:

• Forespørsels/svarlogging: Logger API-forespørsler, svar og rutingsbeslutninger. Samsvarsteam bruker disse loggene til tilgangsrevisjoner for å finne ut hvem som hadde tilgang til hvilke data på hvilket tidspunkt.
• Feil- og unntakslogging: Fanger opp sikkerhetshendelser (for eksempel godkjenningsfeil, autorisasjonsnektelser og ugyldige sertifikater) i beholderens logger. SIEM-integrering aktiverer sanntids sikkerhetsovervåking.
• Loggoppbevaringspolicyer: Arkitekter må konfigurere oppbevaringsperioder som oppfyller lovpålagte krav. Disse minimumsverdiene er angitt av forskrifter, avviker etter rammeverk og endres over tid, så de må utledes fra en godt vedlikeholdt samsvarskilde som kontrollerer hvert tall mot gjeldende forskrifter i stedet for hardkodingsverdier.
• Loggkryptering og tilgangskontroller: Revisjonslogger kan inneholde sensitive metadata. Logger må bare være kryptert under lagring og tilgangskontrollert for autorisert sikkerhets- eller samsvarspersonell. Utilstrekkelig logging hindrer hendelsesundersøkelse og mislykkes i samsvarsrevisjoner. Arkitekter må balansere omfattende loggføring (for eksempel ytelsesinnvirkning og lagringskostnader) med behov for samsvar og sikkerhetsundersøkelser.

Trusselmodellering må være en del av utformingen av løsningene, i stedet for et separat trinn som skjer før eller etter den. Så snart du har en kandidatutforming du kan tenke deg om, må du modellere dens potensielle trusler – og se på modellen på nytt etter hvert som utformingen utvikler seg, slik at sikkerhet former arkitekturen i stedet for å bli justert ned linjen på den. Salesforce administrerer infrastruktursikkerhet (for eksempel nettverksbeskyttelse, operativsystemherding og sårbarhetsbehandling), men du må identifisere applikasjonsnivårisikoer i konfigurasjonen, integrasjonene og den tilpassede koden. Bruk STRIDE-rammeverket (Spoofing, Tampering, Repudiation, Information Disclosure, Denial of Service, Elevation of Privilege) på de Salesforce-spesifikke trusselvektorene som er oppført nedenfor. Identifiser Trust der data krysser systemer, nettverk eller rettighetsnivåer.

Bruk STRIDE-rammeverket på disse viktige punktene om Salesforce-spesifikk trusselmodellering:

• Dataflyter for flere organisasjoner oppretter flere Trust-grenser som krever eksplisitt godkjenning og godkjenning ved hver overgang.
• Ekstern integrasjon bruker API-er og mellomprogramvare, som potensielt introduserer angrepsvektorer som omgår plattformsikkerhetskontroller.
• Tilpassede Apex- og Lightning-komponenter krever sikker kodingsanalyse for injeksjon, XSS og håndheving av tilgangskontroll.
• Experience Cloud-nettsteder utvider angrepsflaten til ikke-godkjente eller lettgodkjente brukere.
• Tredjeparts- og ISV-kode (for eksempel administrerte pakker, AgentExchange-oppføringer, tilkoblede apper, tredjepartskoblinger, JavaScript-biblioteker på klientsiden og de eksterne AI-tjenestene agentene kaller opp) er en leverandørkjedevektor som krysser inn i Trust-grensen, ved installering eller ved kjøretid.

Tredjepart og ISV-kode er en del av Trust grensen.

Administrerte pakker eller AgentExchange-oppføringer kjører i organisasjonen med tillatelsene du gir dem, så deres sikkerhetstilstand blir din sikkerhetstilstand så snart du installerer dem. Salesforce Security Review kontrollerer hver oppført pakke før den når AppExchange eller AgentExchange. Du eier alt etter denne porten:

• Vurdere pakken mot din egen dataklassifisering og risikostilling
• gi den den minste mengden rettigheter som dens dokumenterte funksjonalitet krever
• holde den oppdatert med publiseringens utgivelser
• Og overvåke aktiviteten via de samme Hendelsesovervåking- og revisjonskontrollene som du bruker på din egen kode.

Bruk sikkerhetskontroller på alle lag i løsningsstakken. Husk at kompromiss av ett lag ikke må eksponere hele systemet.

Utform hvert lag som om lagene ovenfor og nedenfor kan mislykkes. Husk at flere uavhengige kontroller skaper fleksibilitet.

Zero Trust eliminerer implisitt Trust basert på nettverksposisjon eller tidligere godkjenningsstatus. Hver forespørsel må være uavhengig godkjent og godkjent.

Bruk Zero Trust på:

• Brukertilgang gjennom kontinuerlig verifisering med MFA, øktpolicyer og betinget tilgang basert på kontekst (for eksempel IP, enhet, klokkeslett og virkemåte)
• Integreringstilkoblinger gjennom OAuth-tokenvalidering på alle samtaler, sertifikatbasert gjensidig TLS og IP-tillatelsesliste
• Kommunikasjon mellom systemer gjennom eksplisitt godkjenning, som også gjelder for klarerte interne systemer
• Datatilgang gjennom CRUD og FLS-håndhevelse for alle spørringer og operasjoner uavhengig av samtalekontekst

Aktivumbeholdning for sikkerhet er inndata for sikkerhetsutforming: du kan bare trusselmodellere, bruke minste rettigheter på og overvåke en angrepsflate som du først har oppført, så sporing av sikkerhetsrelevante aktiva tilhører utformingsbeslutningene som avhenger av den. Dette skiller seg fra den driftskonfigurasjonsbehandlingen som Operational Excellence dekker (for eksempel versjonsinnstillinger for organisasjonen og deteksjon av konfigurasjonsavvik for driftsstabilitet). Med andre ord er problemet her mer begrenset: Hvilke aktiva bærer sikkerhetsrisikoer, og hvorfor?

Oppretthold en oppdatert oversikt over alle sikkerhetsrelevante aktiva, inkludert tilpassede objekter som lagrer sensitive data, eksterne systemintegrasjoner, offentlig tilgjengelige API-er, privilegerte kontoer, produksjonstilgangstildelinger og installerte pakker med forhøyede tillatelser.

Varebeholdningen for sikkerhetsaktiva bør inkludere følgende:

• Tilpassede objekter og felt som inneholder konfidensielle eller begrensede data
• Integreringssluttpunkter og godkjenningsmekanismer
• Brukere med forhøyede rettigheter (for eksempel Endre alle data, Vise alle data og Behandle brukere)
• API-integrasjonsbrukere og deres tillatelsesomfang
• Eksterne klientapper (ECA) og deres OAuth-omfang sammen med eventuelle tidligere tilkoblede apper som fremdeles finnes i organisasjonen
• Installerte AgentExchange-pakker og deres tillatelsestildelinger
• Experience Cloud-nettsteder og deres godkjennings- og eksterne delingsmodeller
• Tilpassede Apex med forhøyede delingsmoduser
• Vær spesielt oppmerksom på eldre klasser: kode kompilert med API-versjon 66.0 eller tidligere, som utelater en delingsdeklarasjon, bruker "uten deling" som standard (for eksempel systemmodus, omgåelse av den kjørende brukerens posttilgang). Husk at fra API-versjon 67.0 (Summer '26-utgivelsen) er en utelatt deklarasjon som standard "med deling", og databaseoperasjoner kjøres i brukermodus. Eksisterende klasser beholder imidlertid den gamle virkemåten til de er kompilert på nytt ved v67.0 (eller nyere) – så ikke-deklarerte klasser som overføres fra tidligere versjoner, forblir stille hevet.

Det er ditt ansvar å utforme og konfigurere identitetskontroller som håndhever minst rettigheter.

La oss se nærmere på hvordan du utformer og konfigurerer kontroller riktig ved bruk av PoLP.

Salesforce håndhever tilgangskontroll gjennom fire distinkte lag: organisasjon, objekt, felt og post. Du må utforme løsninger som bruker alle fire lag med vilje. Kjernetilgangskontroll er tildelingsbasert, som betyr at tilgang er additiv, og brukere må ha den gitt på hvert lag for å nå en post. Det er ingen generalisert "nei overstyring tillater"-regel i kjerneplattformen, så du kan ikke bruke en målrettet avvisning til å angre tilgang til en omfattende tildeling som allerede er tildelt.

Tillatte høyere lag koster ikke muligheten til å begrense, men de øker innsatsen: å utvide organisasjonsomfattende standardinnstillinger eller objekttillatelser tidlig betyr å basere seg på feltnivåsikkerhet og delingskonfigurasjon for å hindre tilbaketilgang som aldri burde ha blitt gitt.

Begrensningsregler og tillatelser for avslåing er to innebygde unntak som subtraherer tilgang, men hver av dem har et smalt omfang – begrensningsregler for filtrering på postnivå og avslåing for tillatelser gitt i en tillatelsessettgruppe – ikke et generalisert avslagslag.

Angi OWD-er til Privat for objekter som inneholder sensitive data. Å åpne OWD-er til Felles skrivebeskyttet, og ikke minst Felles lese/skrive, eksponerer poster bredt og ødelegger muligheten til å begrense tilgang senere uten potensielt betydelig rearkitektur. Den vanligste Trust i modne organisasjoner kommer fra tillatte OWD-er som er angitt ved første implementering.

Postlaget følger en gitt-så-restriksjonsmodell, ofte vist som en delingspyramide: OWD-er angir den restriktive standarden, og rollehierarki, delingsregler og manuell deling gir åpen tilgang oppover derfra. To kontroller reverserer denne flyten for å fjerne tilgang i stedet for å gi den, og begge er verdt å utforme med vilje.

• Begrensningsregler filtrerer hva brukere kan se i poster som de allerede har tilgang til, slik at brukere med bred objekttilgang fremdeles ser bare delsettet som en regel tillater.
• Tillatelser til å dempe trekker fra bestemte tillatelser i en tillatelsessettgruppe slik at du kan sette sammen tilgang fra grupper som kan brukes på nytt, og deretter fjerne det en gitt populasjon ikke skal ha.
• Du kan nå disse reglene når bare tilskuddbaserte lag tvinger deg til å overlever eller dele tilgang til mange smale tillatelsessett.

Håndhev godkjenning med flere faktorer (MFA) for alle brukere som logger seg på produksjonsmiljøer via brukergrensesnittet, som Salesforce gir som plattformkrav. Dette kravet gjelder ikke bare for API-tilgang: integrasjoner som bruker JWT-bærer- eller klientlegitimasjonsflyter, er unntatt, så du må i stedet beskytte disse integrasjonene med sertifikatbehandling og IP-restriksjoner. Utvid MFA-kravene til privilegerte operasjoner.

For enkeltpålogging foretrekkes SAML 2.0- eller OpenID Connect-protokoller. Konfigurer øktpolicyer for å balansere sikkerhet og brukbarhet:

• Session timeout: Konfigurer tidsavbrudd for økter som passer brukertillatelsesnivåer (kortere tidsavbrudd for kontoer med høy privilegiering reduserer risikoen for økter uten veiledning).
• IP-restriksjoner: Håndhev restriksjoner for administrative profiler og integrasjonsbrukere.
• Påloggingstid: Begrens tjenestekontoer til forventede driftsvinduer.
• Enhetsaktivering: Baser deg på Salesforces innebygde enhetsaktivering (identitetsbekreftelse for pålogginger fra ikke-gjenkjente enheter), og legg til MFA- og IP-restriksjoner for kontoer med høy privilegium. Trust for innebygd enhet håndheves via en ekstern identitetsleverandør.
• Økt-IP-låsing: Lås økter til IP-adressen de opprinnelig kommer fra, slik at en stjålet økt-ID ikke kan spilles av på nytt fra et annet nettverkssted. Dette skjerper sikkerheten, men øker friksjonen for mobilbrukere og kan bryte automatiserte integrasjoner – der låsing ikke er mulig, håndhever du strenge IP-områder for pålogging på profilnivå med "Håndhev IP-områder for pålogging på hver forespørsel" som kompenserende kontroll.
• Høy sikkerhetssessioner: Krev øktsikkerhetsnivået Høy sikkerhet via policyer for øktsikkerhetsnivå og tilgangspolicyer for sensitive operasjoner (som å få tilgang til rapporter eller behandle IP-områder), slik at en rutinepålogging ikke alene kan nå handlinger med stor innvirkning. I Lightning Experience støttes det ikke å overføre en standardøkt til høy sikkerhet ved å sende en ny melding om MFA, så omfang denne policyen ved å vite at brukere av standardøkter blokkeres fra den lukkede operasjonen i stedet for å bli bedt om å heve.
• Sessjonsinformasjonskapselbeskyttelse: Krev attributtet HttpOnly slik at skript ikke kan lese økt-ID-informasjonskapselen og låse økter til domenet de først ble brukt i, for å unngå øktkapring.
• API-tilgang for integrasjonsbrukere: Begrens integrasjons- og tjenestekontoer til godkjenning bare med API med tillatelsen Bare API-bruker, slik at de ikke kan logge seg på via brukergrensesnittet. For nye bygninger tildeler du profilen Minimum Access - Only API Integrations med Salesforce Integration-brukerlisensen. Den eldre Salesforce Only Systems Integration-profilen er ikke tilgjengelig i organisasjoner klargjort fra Spring '24 og fremover, så utform nye integrasjoner mot den gjeldende profilen i stedet for den foreldede.

For API-godkjenning velger du OAuth 2.0-flyter som passer til integrasjonsmønsteret:

• JWT bærerflyt: Bruk denne til server-til-server-integrasjoner som kjører som en integrasjonsbruker (sertifikatbasert, foretrukket for klarerte miljøer).
• Webserverflyt (godkjenningskode, med PKCE): Bruk dette for nettprogrammer som krever brukergodkjenning, og for server-til-server-integrasjoner som må opprettholde en bestemt brukerkontekst (lagring av oppdateringstokener på serversiden for å unngå gjentatte nettlesermeldinger).
• Gjør godkjenningskodeflyt gjentakelsessikker: Håndhev PKCE slik at en oppfanget godkjenningskode ikke kan løses inn av noen andre enn klienten som ba om den, og roter oppdateringstokener – utstede et nytt på hver bruk og ugyldiggjøre det forrige – slik at et stjålet oppdateringstoken har et smalt gyldighetsvindu. Gjenbruk av et trukket ut token signaliserer kompromiss.
• Hovedløs identitetsgodkjenningskode og legitimasjonsflyt (med PKCE): Bruk dette for klienter uten nettleser som kjører i en bestemt brukers kontekst – den omdirigeringsbaserte nettserverflyten forutsetter at disse klientene ikke har en nettleser.
• Enhetens flyt (for hodeløse enheter): Vær oppmerksom på at fra og med 28. august 2025 har Salesforce blokkert OAuth 2.0 enhetsflyt permanent for den tilkoblede standardappen Salesforce CLI. Bruk nettserverflyten (sf-organisasjonslogin-nett) eller JWT-bærerflyten (sf-organisasjonslogin jwt) i stedet for CLI- og CI/CD-verktøy.

Ikke bruk brukernavn-passord-flyten. Salesforce blokkerte den som standard for organisasjoner opprettet i Summer '23-utgivelsen eller nyere, og har publisert pensjonsplaner på plass for denne flyten. Eksisterende integrasjoner som fremdeles er avhengige av brukernavn-passord-flyten, bør nå overføres til JWT-bærerflyten eller klientlegitimasjonsflyten, i stedet for å behandle overføring som utsatt teknisk gjeld.

Disse flytene konfigureres i appregistreringen som representerer integrasjonen. Fra og med Spring '26-utgivelsen flytter Salesforce denne registreringen fra Tilkoblede apper til Eksterne klientapper (ECA): oppretting av nye tilkoblede apper er deaktivert som standard, og ECA er konstruksjonen for å utforme nye integrasjoner mot. Eksisterende tilkoblede apper beholdes installert, men når en organisasjon er overført, håndterer de ikke lenger godkjenning, så ta hensyn til overføringen når du reviderer hvordan integrasjoner godkjennes i stedet for å behandle tilkoblede apper som den permanente modellen.

I tillegg til å velge en godkjenningsflyt, oppretter du en distinkt styring for hvilke apper som kan koble til:

• En registrering per integrasjon: Registrer en dedikert ekstern klientapp for hver ny integrasjon, og en distinkt tilkoblet app for hver eksisterende. Med omfanget bare for OAuth-omfangene som hver integrasjon krever, i stedet for å dele én omfattende registrering på tvers av mange, holder en dedikert registrering hver integrasjons tilgang uavhengig reviderbar og opphevbar.
• Forhåndsgodkjenn tilgang eksplisitt (anbefales): Angi policyen for tillatte brukere i External Client-appen til Administratorgodkjente brukere er forhåndsgodkjent, slik at en administrator gir tilgang via profiler og tillatelsessett i stedet for å la brukere godkjenne selv. Administratorer konfigurerer dette direkte i Oppsett, og det er Salesforces anbefalte kontroll for å bestemme hvem som kan koble til.
• API-tilgangskontroll (strengere, tillatelseslistebasert): For strengere kontroller begrenser API-tilgangskontroll administratorgodkjente brukere til bare tillatelseslistede tilkoblede apper. Aktivering av den krever en forespørsel til Salesforces kundestøtte, så planlegg dette trinnet når du utformer rundt det i stedet for å behandle det som en selvbetjeningsinnstilling.

Bygg aldri inn legitimasjon i kode, konfigurasjonsfiler eller versjonskontroll. Bruk navngivne legitimationsoplysninger og eksterne legitimationsoplysninger til at administrere godkendelse centralt med rotationsfunktioner.

Til forskjell fra tradisjonell brukergodkjenning krever agenter distinkte identitetsmodeller, og den riktige modellen avhenger av om agenten betjener ansatte eller eksterne brukere. Riktig utforming av identitet er grunnlaget for agentsikkerhet: den bestemmer hvilke data agenten har tilgang til og hvilke handlinger agenten kan nå.

La oss ta en nærmere titt på interne og eksterne agenter. nts.

• Agenter (interne): Utfør oppgaver innenfor konteksten til brukeren som er logget på. De arver brukerens lisenser, tillatelsessett, feltnivåsikkerhet og delingsregler, så ingen separat agentidentitet klargjøres, og det eksisterende sikkerhetsrammeverket styrer hva agenten kan gjøre.
• Kundeagenter (eksterne): Samhandle via felles kanaler og kjør som dedikerte agentbrukere, spesialiserte integrasjonsbrukere – ikke gjestebrukere for offentlige nettsteder. Ved å kjøre som dedikerte integrasjonsbrukere kan agenten utføre serverdelhandlinger og få tilgang til data (som ikke-godkjente gjesteprofiler ikke kan) samtidig som de fortsatt er bundet av eksplisitte tillatelser med færrest rettigheter. Når du oppretter en kundeagent, klargjør du en ny agentbruker med minimal tilgang og gir bare de spesifikke tillatelsene handlingene krever.

Når en agents arbeid spenner over flere tjenester, overfører du brukerens identitet på tvers av hvert tjenestehopp i stedet for å falle tilbake til en delt eller gjesteidentitet. Flyten Salesforce OAuth 2.0-tokenutveksling støtter dette:

En klient presenterer brukerens eksisterende identitetsleverandørtoken, og en Apex tilordner den til en Salesforce-bruker og utsteder et Salesforce-tilgangstoken, så den opprinnelige brukerens kontekst følger forespørselen i stedet for å skjule til en tjenestekonto. Overvåk agentaktivitet via Hendelsesovervåking ved å bruke agentens brukeridentitet til å oppdage avvikende virkemåte.

Valg av riktig modell avhenger av hvem som initierer tilkoblingen og i hvilken kontekst arbeidet må kjøres.

Vanlige tilkoblingsscenarier tilordnes til anbefalte tilnærminger på følgende måte:

Utform rollehierarkier rundt behov for datatilgang (som brukere trenger tilgang til poster som eies av andre), ikke rapporteringsdiagrammet for behandling. La rollehierarkihyppighet følge ekte datatilgangsrelasjoner i stedet for å legge til nivåer som ikke gir noen ekstra tilgang, fordi hvert nivå legger til overhead for delingsberegning – en vurdering som bærer mer vekt i organisasjoner med private OWD-innstillinger og store datavolumer.

Tillatelsessett og tillatelsessettgrupper reduserer behovet for profilfordeling ved å gi fleksibel, additiv tilgang. Gi funksjonell tilgang via tillatelsessett og tillatelsessettgrupper i stedet for profiler, som holder tilgangen additiv og reviderbar. Profiler er fremdeles nødvendige: Sammen med påloggingstider og IP-restriksjoner bestemmer de sideoppsettildeling, standardposttyper og synlighet av apper. Behandle profiler som en varig del av tilgangsmodellen i stedet for en konstruksjon som skal elimineres.

Transaksjonssikkerhetspolicyer er ikke en del av standarden, de er en tilleggsfunksjon som supplerer kjernetillatelsesmodellen: identitets-, rolle-, profil-, tillatelsessett- og delingskontrollene ovenfor etablerer allerede en sikker autorisasjonsstilling alene, og Transaksjonssikkerhet legger til sanntids kontekstuell evaluering øverst. Konfigurer policyer for å oppdage og blokkere avvikende virkemåte, inkludert massedatasnedlastinger som overskrider normale mønstre, pålogginger fra uventede geografier og tillatelsesendringer utenfor endringsvinduer.

Sikkerhetskontroller medfører tilgjengelighetskompromisser som er et arkitektonisk ansvar. En altfor omfattende IP-restriksjon kan låse ut legitime brukere under en nettverksendring, og en transaksjonssikkerhetspolicy som er for aggressivt avstemt, kan blokkere gyldig forretningsaktivitet – så omfang disse kontrollene til ekte risiko, faser dem i overvåkingsmodus før du håndhever dem, og utform en bryteglassbane for når en kontroll mislykkes.

Ditt ansvar: Utform rollehierarki, opprett tillatelsessett, konfigurer policyer for transaksjonssikkerhet.

Tradisjonell rollebasert tilgangskontroll) gir tillatelser basert på en brukers rolle. ABAC (attributtbasert tilgangskontroll) tar godkjenningsbeslutninger basert på attributtene til dataene, brukeren og konteksten.

For de fleste krav uttrykker kjernedelingsmodellen full tilgang. Nå for dedikert ABAC når tilgang må følge dataklassifisering som deling per post ikke kan uttrykke: Data 360 ABAC sørger for dette via koder og merknader.

Data 360 ABAC fungerer via

• Kodebaserte policyer som definerer tilgangsregler basert på koder som brukes på dataobjekter (for eksempel Personlig identifiserbar informasjon (PII), økonomiske, helsemessige og konfidensielle koder).
• Kommentarer brukes på dataobjekter for å støtte policybaserte godkjenningsbeslutninger.
• Tillat alle-policy som standard for nye og eksisterende organisasjoner, som eksplisitt må slettes for å aktivere detaljerte styringspolicyer.

Den primære arkitektoniske bruken er å håndheve dataklassifisering – se Dataklassifisering under Databeskyttelse og personvern for å finne ut hvordan klassifiseringsnivåer fremmer ABAC-håndhevelse.

Dette detaljnivået medfører en driftskostnad. Kjernedeling besvarer spørsmålet "Hvem kan se denne posten og hvorfor?" fra et lite sett regler som kan inspiseres (OWD-er, rollehierarki og delingsregler), mens ABAC utleder svarene sine på evalueringstidspunktet fra kombinasjonen av datakoder, brukerattributter og kontekst, så effektiv tilgang blir vanskeligere å forklare og revidere etter hvert som policyer og koder akkumuleres.

Håndhev revisjon som et utformingskrav: bruk koder konsekvent, hold policysettet lite og navngitt for klassifiseringen det håndhever, og bevar muligheten til å rekonstruere hvorfor en bruker nådde en gitt post. Reserver ABAC for klassifiseringsdrevne saker som deling per post faktisk ikke kan uttrykke, i stedet for å behandle den som en generell erstatning for den eierskapsbaserte modellen.

Identifiser og beskytt kontoer med forhøyede rettigheter, inkludert systemadministratorer, integrasjonsbrukere og kontoer for automatiserte prosesser. Disse kontoene er verdifulle mål for angripere.

Bruk forbedrede kontroller på viktige innvirkningskontoer.

• Krev phishingresistent MFA
• Begrense IP-områder for pålogging til kjente administrative steder
• Aktivere påloggingsvarsler og tillatelsesendringsvarsler
• Utføre periodiske tilgangsvurderinger med dokumentert attestering for kontoer med høy privilegium, der frekvensen bestemmes av krav til organisasjonell risikotoleranse og samsvar
• Opprettholde gjennomgangsprosedyrer for tilgang i hasteavtaler og revisjon etter bruk

For integrasjons- og tjenestekontoer:

• Bruk OAuth-flyter, aldri brukernavn-passord-flyter
• Håndheve IP-restriksjoner
• Implementere roteringsplaner for legitimasjon
• Overvåke avvikende API-bruksmønstre via Hendelsesovervåking

Ditt ansvar: Identifiser viktige kontoer, bruk forbedrede kontroller, utfør kvartalsvise vurderinger.

Utform automatiserte prosesser for å klargjøre brukere med den riktige første tilgangen, justere tillatelser etter hvert som roller utvikles, og oppheve klargjøring umiddelbart når tilgang ikke lenger er nødvendig.

Implementer et System for Cross-Domain Identity Management (SCIM) for automatisk klargjøring fra identitetsleverandører. SAML eller OpenID Connect JIT-klargjøring er et alternativ som oppretter en bruker ved første pålogging, men det deaktiverer ikke brukere. Med andre ord er SCIM livssyklusens ryggrad, ikke et valg mot den.

Identitetslivssyklusen inkluderer følgende:

• Klargjøring: Opprett kontoer med standardtilgang som samsvarer med jobbfunksjonen, som utløses av HR-systemhendelser.
• Tilgangsjusteringer: Gi flere tillatelser etter hvert som roller utvides, og opphev tillatelser når roller endres.
• Periodisk ny sertifisering: Se gjennom og valider tilgang kvartalsvis.
• Avlevering: Opphev tilgang umiddelbart når ansettelsen avsluttes eller roller ikke lenger krever Salesforce-tilgang.

Implementer nye tilgangssertifiseringsprosesser når ledere regelmessig ser gjennom og validerer teamets tillatelser. Gennemgangsfrekvens er baseret på risiko og overensstemmelseskrav.

Ditt ansvar: Implementer SCIM, utform arbeidsflyter for klargjøring, utfør kvartalsvis ny sertifisering.

Opdeling av data i flere organisasjoner settes noen ganger bare på som en kostnads- eller oppholdsbeslutning. Arkitektonisk sett er det en sikkerhetskompromiss, og konsekvensene av styringen er innenfor tilgangsutformingen.

Isolasjon er den viktigste fordelen. Separate organisasjoner sørger for den sterkeste mulige grensen mellom datasett. Det er ingen kollektiv delingsmodell og ingen blødning av tillatelser på tvers av leietagere, men det er en tydelig regellinje for jurisdiksjoner som krever en. Den samme grensen fragmenterer styring. Alle tilgangskontroller som du bare trenger å vedlikeholde én gang i en enkelt organisasjon (for eksempel tillatelsessettutforming, rollehierarki, herding av kritisk innvirkningskonto, standardinnstillinger for tilstandssjekk, hendelsesovervåking og SIEM-korrelasjon), multipliseres nå per organisasjon, noe som betyr at den må opprettholde konsistens på tvers av alle. Glidning mellom organisasjoner oppretter sin egen angrepsflate fordi en tillatelse som er begrenset i én organisasjon og mangler i en annen, oppretter en inkonsistens som angripere kan finne og utnytte. Integrasjoner på tvers av organisasjoner legger til godkjente Trust som ikke fantes før. Hver integrasjon på tvers av organisasjoner er en tilkobling som du må sikre og overvåke.

Det er derfor det er viktig å vekte fordelene med isolasjon mot styringsmultiplikatoren før du deler opp en organisasjon. Reserver flere organisasjoner for saker der et hardt lokaliseringsmandat eller en kundes krav til kontraktsmessig isolasjon ikke kan oppfylles i en enkelt organisasjon. Når du tar den i bruk, må du utforme tilgangsmodellen, overvåkings- og konfigurasjonsstandardene slik at de håndheves identisk på tvers av alle organisasjoner fra begynnelsen av.

Ditt ansvar: Behandle en beslutning for flere organisasjoner som en sikkerhetskompromiss, ikke bare en kostnad. Når flere organisasjoner kreves, håndhever du tilgangskontroller, overvåking og tilstandssjekk konsistent på tvers av alle organisasjoner, og sikrer hver integrasjon på tvers av organisasjoner som en Trust.

Det er ditt ansvar å klassifisere data, konfigurere kryptering og utforme personvernkontroller.

La oss ta en nærmere titt på hvordan du beskytter data og personvern riktig.

For å kunne klassifisere dataene riktig må du kjenne til dataene dine. Den overordnede arkitektoniske oppgaven er å forstå forretningsdomenet og vedlikeholde en datakode som katalogiserer hvilke data du har, hva de betyr og hvor sensitive data befinner seg. Du kan bare klassifisere – eller beskytte – data som du har identifisert først.

Opprett et dataklassifiseringsskjema som styrer riktige beskyttelseskontroller. En klassifiseringsetikett beskytter ikke noe alene. Det er inndataene til kontrollene som du bruker, så hver klassifisering du tildeler, må tilordnes til en konkret krypterings-, tilgangs-, oppbevaring- eller overvåkingsbeslutning. Klassifiseringsbeslutninger som tas under datamodellering, påvirker direkte krypteringskrav, tilgangskontroller, oppbevaringspolicyer og overholdelsesforpliktelser.

I Salesforce bruker vi et firenivåskjema som gir et rammeverk som du kan tilpasse til organisasjonens lovpålagte krav og forretningsbehov. Mange virksomheter bruker lignende modeller som er i samsvar med bransjestandarder (for eksempel ISO 27001 og NIST). Din spesifikke implementering skal gjenspeile dine overholdelsesforpliktelser (for eksempel HIPAA, PCI DSS, GDPR og bransjeforskrifter) og forretningskontekst.

Bruk klassifisering på feltnivå. En enkelt Konto-post kan inneholde Felles-felt (for eksempel firmanavn), Konfidensielle felt (for eksempel firmaomsetning) og Begrensede felt (for eksempel personnummer). Feltnivåsikkerhet må gjenspeile disse forskjellene.

Klassifisering blir håndhevbar via attributtbasert tilgangskontroll, som leser kodene du tildeler og bruker tilgangsregler. Dette er et metadatastyrt lag som supplerer OWD- og delingsregler.

Ved å tilpasse ABAC til klassifiseringsskjemaet kan plattformen

• Begrens tilgang til data som er kodet Begrenset eller Konfidensiell, fra selve klassifiseringen i stedet for fra en delingsregel som vedlikeholdes per objekt.
• Tilpass tilgang etter hvert som en posts klassifisering endres over tid. En post som nylig er kodet som Regulert, arver strengere tilgang uten en manuell regelendring.
• Kombiner dataattributter (for eksempel klassifisering og sensitivitet) med brukerattributter (for eksempel avdeling og klargjøring) og kontekst (for eksempel klokkeslett og sted) i én enkelt godkjenningsbeslutning.

Utform ABAC-policyer for å være i samsvar med dette skjemaet slik at klassifisering av et felt som Begrenset er den handlingen som driver dens tilgangskontroller og holder håndheving forankret i klassifiseringen i stedet for å opprettholde delingsregler separat.

Ditt ansvar: Definer klassifiseringsskjema, lær opp datamodellerere, klassifiser felt under utforming, konfigurer kontroller og juster ABAC-policyer til klassifiseringsnivåene slik at koder fremmer håndhevelse.

StartBegynn med informasjonen som plattformen allerede gir for hver organisasjon. Data som er lagret, krypteres som standard. Hyperforce bruker kryptering på volumnivå som beskytter hele lagringsvolumet under en enkelt nøkkel som Salesforce eier og administrerer. Denne standarden er alltid på og gjennomsiktig for løsningen, men den fungerer på volumnivået (ikke per felt), så det å velge hva som skal krypteres og kontrolleres i nøkkellivssyklusen, avhenger av plattformen, ikke av deg.

Når denne standarden ikke kan oppfylle en overholdelses-, kontrakts- eller dataklassifiseringsforpliktelse, bruker du Shield Platform Encryption. Spesifikt når du trenger en av de tre tingene som kryptering på volumnivå ikke gir:

• Kontroll over livssyklusen til nøkkelen slik at du selv kan generere, rotere og oppheve nøkkelmaterialet
• Selektivitet over hvilke standardfelt, tilpassede felt, filer og vedlegg som er kryptert under lagring
• Mulighet til å gjøre data utilgjengelige for Salesforce.

Begrensede data og data som er underlagt eksplisitte lovpålagte nøkkelkontrolmandater (for eksempel HIPAA, PCI DSS og GDPR) er de vanlige utløserne. Basislinjen dekker allerede beskyttelse på infrastrukturnivå for alt annet.

Shield Platform Encryption krypterer på feltnivå, og den tilbyr to skjemaer som utveksler sikkerhet for spørringsmuligheter.

Sannsynlighetskryptering er et sterkt, standardskjema, men feltene som er kryptert med det, kan ikke brukes i filterkriterier, sortering eller aggregeringsfunksjoner (for eksempel MAX(), MIN() og COUNT_DISTINCT()-funksjoner).

Deterministisk kryptering muliggjør nøyaktig samsvarsfiltrering i rapporter, listevisninger og SOQL WHERE-setninger – som skiller mellom små og store bokstaver – med redusert styrke fordi den samme ren tekst alltid produserer den samme krypteringstekst.

Vi anbefaler at du som standard krypterer med sannsynlighetsskjemaet og reserverer deterministisk kryptering for de spesifikke feltene som du må filtrere eller sortere. Evaluer disse avveiningene under datamodelleringsutformingen, inkludert innvirkninger på referanser til formelfelt, rapportaggregering og SOQL-operasjoner.

Kundekontrollerte nøkler kommer i to distinkte former:

• Med Bruk din egen nøkkel (BYOK) kan du generere nøkkelmateriale utenfor Salesforce – ved å bruke dine egne kryptobiblioteker, virksomhetens nøkkeladministrasjonssystem eller maskinvaresikkerhetsmodulen – og levere det til plattformen.
• Cache-Only Key Service beholder datakrypteringsnøkkelen i en nøkkeltjeneste som du kontrollerer. Salesforce henter det på forespørsel i stedet for å lagre det.

Med begge skjemaene kan du rotere og ødelegge nøkkelmateriale etter din egen tidsplan. Når nøkkelmateriale ødelegges, blir dataene som det beskyttet, ikke gjenopprettet, noe som er en kraftig, bevisst kontroll i stedet for en rutine. Det er også viktig å dokumentere nøkkelrotasjons- og opphevingsprosedyrene.

Alle integrasjoner må bruke TLS 1.2 eller høyere (Salesforce-plattformen håndhever dette), men du må implementere sertifikatbasert gjensidig godkjenning for integrasjoner som håndterer begrensede data (ved å bruke din egen konfigurasjon).

Ditt ansvar: Bestem deg for hvor plattformens basislinje på volumnivå er tilstrekkelig og hvor en samsvars-, kontrakts- eller klassifiseringsforpliktelse berettiger Shield Platform Encryption, velg deretter krypteringsskjemaer, velg og bruk en kundekontrollert nøkkelstrategi og implementer sertifikatbasert godkjenning for sensitive integrasjoner.

Beskytt sensitive data i ikke-produksjonsmiljøer ved å bruke strategier som hindrer at begrensede data kommer inn i Sandbox-organisasjoner.

• Delvis Sandbox-kopiering utelukker Begrensede data fra Sandbox-oppdateringer.
• Regler for datamaskering forvirrer sensitive feltverdier i Sandbox-organisasjoner ved å bruke mønstre som beholder dataegenskaper.
• Syntetisk datagenerering gjelder for utviklingsmiljøer som aldri krever produksjonsdata.
• Sandbox-maler definerer hvilke objekter og felt som skal inkluderes i hver Sandbox-type.

Utforming for samsvarstesting er et arkitektonisk ansvar. Bygg utviklings- og testsykluser på syntetiske data med realistiske egenskaper slik at team kan validere mot produksjonslignende betingelser mens regulerte data forblir innenfor produksjonsgrensen.

Ditt ansvar: Utform Sandbox-strategi, konfigurer Data Mask, generer syntetiske testdata.

Utform løsninger som respekterer brukerpersonvern via arkitektoniske beslutninger.

• Data minimering: Innhent data som er nødvendige bare for angitte forretningsformål. Utfordre alle felttillegg ved å spørre: "Hvilken arkitektonisk beslutning krever disse dataene?" Husk at de sikreste dataene er dataene som du aldri samler inn.
• Begrensning av formål: Utform datatilgangsmønstre som teknisk håndhever begrensning av formål. Bruk tillatelsessett og delingsregler til å begrense tilgang til data basert på formålet med en jobbfunksjon. Markedsføringsbrukere bør for eksempel ikke få tilgang til kundestøttesaksdetaljer med mindre jobben krever det.
• Samtykkebehandling: Implementer samtykkesporing på individuelt nivå for markedsføring, analyse og valgfri databehandling. Utform arbeidsflyter for tilbaketrekking av samtykke som overføres på tvers av integrerte systemer. Med andre ord er samtykket detaljert og spesifikt for formålet.
• Rettigheter for registrerte: Bygg arbeidsflyter for tilgangsforespørsler (for eksempel å levere datakopier), korrigering (for eksempel å rette opp unøyaktigheter), sletting (for eksempel å slette data når det er juridisk tillatt å gjøre det) og portabilitet (for eksempel å eksportere til et maskinlesbart format). Utform disse arbeidsflytene slik at de fullføres innen tidsfristen for svar som hvert styringsrammeverk krever. Disse tidsfristene varierer etter jurisdiksjon – og de endres regelmessig – så det er viktig å parametere arbeidsflytens tjenestenivåavtale fra en vedlikeholdt samsvarskilde og bekrefte hvert vindu mot den aktuelle forskriften (i stedet for å hardkode en enkelt verdi).

Ditt ansvar: Utform datamodeller med minimering, konfigurer tilgang etter formål, implementer samtykkearbeidsflyter, bygg automatisering av registrertes rettigheter.

Dataoppbevaring er et arkitektonisk valg du gjør før klargjøring, ikke en innstilling som du bytter etterpå. Hyperforce tilbyr regional distribusjon – men det finnes bare et område der Salesforce driver en – og organisasjonens opphold er fast bestemt på klargjøring. Det er ditt ansvar å fastslå hvor hver datakategori skal ligge, bekrefte om et egnet område er tilgjengelig, og utforme dataoverføringsmekanismer som legitimt krysser grenser.

I stedet for å bruke landlagring som standard er det viktig å klassifisere oppholdsforpliktelsene før du begynner:

• Nødvendig lokalisering. Et lite sett jurisdiksjoner krever at bestemte data forblir innenfor nasjonale grenser (noen ganger gjelder dette bare for regulerte sektorer). Når Salesforce ikke opererer i et område i landet, kan ikke innebygd lagring tilfredsstille mandatet alene, så du trenger et data-residency-overlegg eller en separat organisasjon for disse dataene. I og med at denne listen kan skifte, er det viktig å bekrefte det spesifikke mandatet mot den aktuelle forskriften.
• Baserte rammeverk. De fleste systemer håndhever ikke et lokaliseringsmandat. De blir tilfredsstilt av et regionalt knutepunkt med en egnet mekanisme for overføring over grenser. I disse tilfellene baseres beslutningen på hvilket område som minimerer latens og forenkler overholdelsen.

Når data krysser en kantlinje, handler det om bevissthet før konfigurasjon. Med andre ord må du vite hvilke overføringer som skjer og på hvilket juridisk grunnlag, og deretter utforme tilgangen slik at dataene styres fra ende til ende. Der de finnes, har tilstrekkelighetsbeslutninger minst friksjon. Bindende forretningsregler (BCR-er) og standardkontraktsvilkår (SCC-er) dekker de fleste gjenværende overføringer. Bruk eksplisitt samtykke bare som en siste utvei.

Par overføringsmekanismen med restriktiv posttilgang (for eksempel private OWD-er og formålsomfattende deling) slik at en tillatt overføring ikke blir for omfattende. Dokumenter dataflyttilordninger for å vise hvor hver datakategori kommer fra, går gjennom og befinner seg. Se på dem på nytt når forskrifter eller regionale tilgjengeligheter endres.

Ditt ansvar: Klassifiser oppholdsforpliktelser per datakategori, bekreft regional tilgjengelighet før klargjøring, velg overføringsmekanismer (tilstrekkelighet, punktlister/SCC-er) for grenseoverskridende flyter og dokumenter dataflytkart.

Det er ditt ansvar å utforme løsninger som opprettholder samsvarstilstanden som plattformen tilbyr.

Denne veiledningen er retningsorientert. Lovpålagte krav varierer etter jurisdiksjon og endres over tid. Du må alltid kontrollere spesifikke forpliktelser i forhold til gjeldende forskrifter (for eksempel gjeldende statut, overordnet myndighet eller Salesforce-samsvarsdokumentasjon) for distribusjonen.

Salesforce vedlikeholder omfattende samsvarssertifiseringer (tilgjengelig på Trust.salesforce.com og compliance.salesforce.com): SOC 2 Type II, ISO 27001, FedRAMP (for Government Cloud-tilbud), HIPAA, PCI DSS og regionale sertifiseringer. Disse sertifiseringene dekker Salesforces ansvar for plattforminfrastruktur og delte tjenester.

Plattformsertifiseringer reduserer samsvarsbelastningen, men de eliminerer ikke ditt arkitektoniske ansvar. Dine tilpassede objekter, Apex, integrasjoner og konfigurasjoner må opprettholde samsvarstilstanden som plattformen tilbyr.

Ditt ansvar: Utform løsninger som opprettholder samsvarstilstanden, og dokumenter hvordan arkitekturen oppfyller lovpålagte krav.

• Aktiver Shield Platform Encryption for alle felt som inneholder beskyttet helseinformasjon (PHI).
• For å oppfylle HIPAA-samsvar aktiverer du Field Audit Trail med oppbevaringspolicyer for å oppfylle HIPAAs krav til arkivering. Bekreft gjeldende periode mot den aktuelle forskriften.
• Konfigurer hendelsesovervåking for å oppdage uautoriserte PHI-tilgangsmønstre.
• Implementer alle tekniske sikkerhetsforanstaltninger som kreves av HIPAA-sikkerhetsregelen, inkludert tilgangskontroller, revisjonslogging og overføringssikkerhet.

• Implementer segregering av oppgaver (SoD) via tillatelsessettutforminger for å hindre at enkeltbrukere oppretter og godkjenner økonomiske transaksjoner.
• For PCI-miljøer unngår du å lagre fullstendige primære kontonumre (PAN) i Salesforce for å minimere omfanget av PCI DSS-samsvar.
• Bruk betalingsportstokenisering når det er mulig.

• For GDPR og LGPD utformer du samtykkebehandling som fanger opp detaljert samtykke som er spesifikk for formålet.
• CCPA/CPRA følger en reservasjonsmodell. Sørg for tydelige mekanismer for å velge bort salg eller deling av personlig informasjon i stedet for detaljert formålsbasert samtykke.
• Bygg arbeidsflyter for registrertes rettigheter som er fullført innen hvert rammes tidsfrist for svar, og som er bekreftet mot den aktuelle forskriften.
• Implementer dataoppbevaringsautomatisering som sletter data når samtykke utløper.

• Bruk Salesforce Government Cloud til regulerte offentlige arbeidsbelastninger.
• Implementer NIST 800-53-kontroller som er tilordnet til Salesforce-konfigurasjon.
• Aktiver kontinuerlig overvåking via Hendelsesovervåking som rutes til statlig SIEM-infrastruktur.

Ditt ansvar: Konfigurer Shield, Feltrevisjonsspor, oppgavesegmentering, samtykkebehandling og dataoppbevaring basert på lovpålagte krav.

Databeskyttelses- og personvernforskrifter varierer betydelig mellom jurisdiksjoner – og spesifikke forpliktelser endres raskt – så dette nivået krever beslutningstaking i stedet for en tabell for hvert land.

De to arkitektoniske faktorene er opphold og grenseoverskridende overføring, som dekkes under Databeskyttelse og Personvern.

For å overholde disse forskriftene må du

• Klassifisere hvor hver datakategori må ligge
• Kontroller at det finnes et egnet område før klargjøring
• Utform en juridisk overføringsmekanisme for data som krysser en grense.

Hvis du vil ha mer informasjon, kan du se Data Residence and Sovereignty for å få flere detaljer om beslutningsrammeverket.

Alt utenfor dette anses som et punkt-i-tid-tall (for eksempel hvilken samtykkemodell en jurisdiksjon bruker, tidsfristen for en datasubjektforespørsel, vinduet for å varsle regulatorer eller berørte enkeltpersoner etter et brudd og minimumsoppbevaringsperioden for revisjonsposter). Disse tallene angis av forskrifter, de varierer etter rammeverk, og de endres etter reguleringens tidsplaner.

Ikke hardkod dem her. Du må bestemme de neste trinnene basert på den regulerende forskriften for distribusjonen – eller en vedlikeholdt samsvarskilde som siterer en – og måle utformingen til det mest omfattende vinduet i driftsfotavtrykket.

Her er de varige arkitektoniske konsekvensene som tilhører utformingen.

• En tidsfrist for datasubjektforespørsler som måles i enkeltsifrede dager, kan ikke oppfylles av en manuell ad hoc-prosess, så du må automatisere DSR-innfrielse når du opererer i en jurisdiksjon med kort tidsfrist. Bruk Experience Cloud til inntak, Service Cloud til sakssporing, Personvernsenter til oppdagelse og Flyt til innfrielse.
• Et bruddvarslingsvindu er for stramt til å improvisere, så du må bygge arbeidsflyten for brudd-svar på forhånd. Bestem avviksregler for hendelsesovervåking, forhåndstildelte roller, forhåndsutkastede regulator- og datasubjektvarsler, og en eskaleringsbane som forutsetter den strengeste tidsfristen innenfor fotavtrykket. Individuelle varsler utløses vanligvis av en høyrisikobestemmelse, så du må inkludere en risikovurdering i arbeidsflyten.
• Enkelte jurisdiksjoner krever eller anbefaler oppbevaring av revisjonslogger i landet – med minimumsverdier som strekker seg over flere år – så du må dimensjonere SIEM-oppbevaring til det lengste minimumet innenfor avtrykket ditt og bekrefte om logger kan forlate jurisdiksjonen.

Ditt ansvar: Utform opphold og overføring per Databeskyttelse og Personvern, automatiser DSR- og bruddresponsarbeidsflyter til den strengeste tidsfristen i ditt avtrykk, og bekreft alle jurisdiksjonsspesifikke tall mot den aktuelle forskriften i stedet for en verdi skrevet i denne veiledningen.

Utforming for kontinuerlig validering av samsvar i stedet for tidsavbrudd for revisjon.

• Sikkerhetstilstandssjekk vurderer konfigurasjonen mot Salesforces sikkerhetskriterier og gir risikoscore. Utfør kontroller regelmessig for å overvåke samsvar med Salesforces grunnleggende sikkerhetsanbefalinger. Oppretthold score på 80 % eller høyere (Veldig bra eller Utmerket-bånd).
• Event Monitoring fanger opp detaljerte logger for brukeraktivitet, API-kall, godkjenningshendelser og datatilgangsmønstre. Rut hendelsesloggfiler til ekstern SIEM for langsiktig oppbevaring som overskrider grensene for innebygd oppbevaring.
• Transaksjonssikkerhet evaluerer hendelser mot poliser i sanntid, og den kan blokkere hendelser, kreve en økning i MFA eller varsle deg om brudd på policyer.

Det er viktig å automatisere samsvarskontroller i distribusjonsledninger for å validere at distribusjoner ikke svekker tillatelsesmodeller, deaktiverer revisjonsinnstillinger eller introduserer ikke-samsvarende konfigurasjoner.

Ditt ansvar: Kjør tilstandssjekk kvartalsvis, rut hendelsesovervåking til SIEM, konfigurer policyer for transaksjonssikkerhet, automatiser validering av samsvar i CI/CD.

Utform revisjonssporestrategier som er basert på samsvarskrav, undersøkelsesbehov og oppbevaringskrav.

For regulerte miljøer implementerer du Hendelsesovervåking med ekstern SIEM-integrering for langsiktig loggoppbevaring og korrelasjon på tvers av systemer. Utform policyer for feltrevisjonsspor som dekker alle begrensede og konfidensielle felt som er underlagt lovpålagte krav til arkivering.

Ditt ansvar: Aktiver Feltrevisjonsspor for sensitive felt, ruter Hendelsesovervåking til SIEM, konfigurerer policyer for transaksjonssikkerhet.

Det er ditt ansvar å integrere sikkerhet i løpet av utviklingen, ikke som en ettertanke.

Integrer sikkerhetsrutiner i den tidligste utviklingsfasen. Trusselmodellering i arkitekturfasen hindrer sårbarheter på utviklingsnivå. Sikkerhetskrav som fanges opp sammen med funksjonelle krav, hindrer deg i å behandle sikkerhet som en ettertanke.

Sikkerhetsdefekter koster betydelig mer å rette opp når de oppdages i produksjonsorganisasjonen, i stedet for i utformings- eller utviklingsfasene. En sikkerhetsfeil på utformingsnivå som fanges opp under arkitekturgjennomgang, kan ta bare én samtale å rette opp. Men når samme feil blir funnet i produksjonsorganisasjonen, kreves det rearkitektur, dataoverføring, samsvarsbehandling og varsel om potensielle brudd.

Derfor praktiserer vi sikkerhet med skift til venstre, som fokuserer på følgende:

• Trusselmodellering før utformingsdefinisjon
• Sikkerhetskrav i brukerhistorier
• Sikker kodingopplæring for utviklere
• Statisk analyse som er integrert i IDE-er
• Sikkerhetsfokuserte kodevurderinger
• Automatisert sikkerhetstesting i CI/CD
• Sikkerhetsvalidering før produksjonsdistribusjon

Ditt ansvar: Utfør trusselmodellering, lær utviklere, integrer Code Analyzer i CI/CD, krev sikkerhetsbevisste kodevurderinger.

Det er viktig å utforme forsvar mot vanlige sårbarheter i en Salesforce-kontekst. La oss ta en nærmere titt på hvordan vi tilordner til 2025 OWASP Top 10 hos Salesforce.

• A01:2025 - Brutt tilgangskontroll: Håndhev CRUD- og feltnivåsikkerhet (FLS) programmatisk i all Apex.
  • I API-versjon 67.0 eller nyere kjører Apex som standard i brukerkontekst, som betyr at gjeldende brukers tillatelser og FLS håndheves under kodeutføring.
    • MED SECURITYENFORCED ble fjernet, noe som fører til en kompileringsfeil. Erstatt eventuelle eksisterende bruk med WITH USER_MODE. Plattformen fremtvinger tilgang i standardgrensesnitt.
  • I API-versjon 66.0 eller tidligere er systemmodus standard. Brukes med USERMODE i SOQL-spørringer eller Security.stripInaccessible() for DML-operasjoner.
• A01:2025 - API-er for data på klientsiden: Lightning Data Service og brukergrensesnittets API håndhever automatisk den kjørende brukerens FLS, CRUD og deling, slik at en komponent som bygges på dem, arver minst rettigheter som standard.
  • Denne beskyttelsen mistes når en komponent kaller opp en tilpasset Apex. Imperativ Apex håndhever tilgang bare når den kjører i brukermodus, så en klasse som er erklært uten deling, fungerer som en isolasjonsluke som stille omgår modellen.
  • Bruk Lightning Data Service og brukergrensesnittet API til datatilgang.
  • Du må deklarere CRUD, FLS og deling på nytt for hvert imperative Apex fra en komponent.
• A02:2025 - Sikkerhetsfeilkonfigurasjon: Overvåk konfigurasjonsavvik fra sikkerhetens grunnleggende verdier med Tilstandssjekk.
  • Deaktiver gjestebrukertilgang på Experience Cloud-nettsteder (med mindre det eksplisitt kreves under en dokumentert forretningsbegrunnelse).
• A05:2025 - Injeksjon: Innsettingskategorien 2025 dekker SOQL/SOSL-innsetting og skripting på tvers av nettsteder (XSS).
  • Til spørringsinnsetting bruker du bindvariabler for alle dynamiske spørringer. Koble aldri brukerinndata direkte til spørringsstrenger. Plattformens parameteriserte spørringsmekanismer eliminerer injiseringsrisiko når de brukes riktig.
  • SOQL- eller SOSL-injeksjoner omfanges til en avlesning som viser poster eller felt som anroperen ikke skal kunne nå ved å utvide spørringsbetingelsene. Fordi disse språkene leser data mens skriving kjører gjennom separate DML-operasjoner, skaper dette en tilgangskontroll- og konfidensialitetsrisiko fordi den sammensettes når objekt- og felttillatelser ikke håndheves i spørringen.
  • For XSS tilbyr Lightning Web Components automatisk beskyttelse via LWC-gjengivelsesmotoren.
  • For Aura-komponenter og Visualforce må du bruke plattformkodingsfunksjoner (for eksempel HTMLENCODE, JSENCODE og URLENCODE) når du gjengir dynamisk innhold.

Ditt ansvar: Håndhev CRUD/FLS i tilpasset kode, bruk kodingsfunksjoner, bruk bindvariabler, overvåk konfigurasjonsdrift.

Utform CI/CD pipelines med sikkerhetsportaler i hver fase. Sikkerhet må være automatisert for å skalere med utviklingshastigheten.

La oss ta en nærmere titt på pipelinens sikkerhetsfaser.

• Kildekontroll bruker grensebeskyttelsesregler med nødvendige kodegjennomganger. Det er ingen direkte bekreftelser til hovedforgrener eller signerte bekreftelser.
• Statiske analyser bruker Salesforce Code Analyzer, som integrerer PMD, ESLint og RetireJS for å oppdage injeksjons-, XSS- og usikre mønstre.
• Sikkerhetsskanning bruker SAST-verktøy og hemmelighetsdeteksjon for å hindre bekreftelse av legitimasjon og skanning av avhengighetssårbarhet.
• Tillatelsesvalidering bruker automatiske sammenligningsteknikker til å se gjennom endringer i tillatelser mot sikkerhetsstandarder, som sender varsler om rettighetsutvidelse.
• Distribusjonsportaler avbryter distribusjon på kritiske sikkerhetsfunn som krever godkjenning av sikkerhetsteamet for endringer som utvider tillatelser.
• Overvåking etter distribusjon bruker Hendelsesovervåking-varsler for avvikende virkemåte etter distribusjoner.

Ditt ansvar: Integrer Code Analyzer i CI/CD, konfigurer grenbeskyttelse, implementer distribusjonsportaler, valider tillatelser automatisk.

Omfattende sikkerhetstesting inkluderer flere teknikker som håndterer forskjellige sårbarhetsklasser. La oss se nærmere på hver strategi.

• Statisk analyse kjører Salesforce Code Analyzer i utvikler-ID-er for umiddelbar tilbakemelding, og i CI/CD pipelines som automatiserte porter. Statisk analyse identifiserer sårbarheter i kildekoden uten å utføre programmet.
• Penetration Testing utfører penetrasjonstester for tilpassede programmer som eksponeres for brukere som ikke er klarert, spesielt Experience Cloud-nettsteder og offentlig tilgjengelige API-er.
  • For AppExchange og AgentExchange Security Review kreves alltid statiske analyserapporter.
  • En dynamisk skannerapport (inntrengningstest) kreves når løsningen integrerer et tredjeparts nettprogram eller -tjeneste.
  • Penetrasjonstesting simulerer angriperteknikker mot aktive programmer.
• Sikkerhetsfokuserte enhetstester skriver Apex-tester som validerer håndheving av tilgangskontroll ved å kjøre som brukere med forskjellige tillatelsesprofiler. Det er viktig å kontrollere at CRUD/FLS-håndhevelse blokkerer uautorisert tilgang.
• Avhengighetsskanning overvåker AgentExchange-pakker og JavaScript-biblioteker for kjente sårbarheter. Det er viktig å abonnere på sikkerhetsvarsler for installerte pakker.

Ditt ansvar: Kjør Code Analyzer, utfør penetrasjonstesting, skriv sikkerhetsenhetstester, skann avhengigheter.

I Salesforce fokuserer sikkerhets- og datahendelsesrespons på å oppdage, inneholde og gjenopprette fra brudd, uautorisert tilgang og ødeleggelse av skadelige data. Hendelsessvarteam arbeider sammen med to nærliggende søyler som eier tilstøtende ansvarsområder:

• Operational Excellence dekker den operasjonelle mekanismen for hendelsesbehandling (for eksempel alvorlighetsnivåer, rotasjon ved oppkall, eskalering og vurdering etter hendelse)
• Pålitelighet dekker gjenoppretting av tilgjengelighet i forhold til RTO- og RPO-målene, inkludert sikkerhetskopiering og katastrofegjenoppretting.

Som arkitekt er det ditt ansvar å utforme deteksjon, respons og gjenoppretting av sikkerhetshendelser.

Detekterbarhet er en arkitektonisk kvalitet som du eksplisitt må utforme for. Uten omfattende overvåking kan sikkerhetshendelser forbli uoppdaget i lengre tidsperioder.

Det er viktig å implementere deteksjon via flere kanaler.

• Event Monitoring fanger opp rå hendelseslogger som dekker pålogginger, rapport- og dataeksporter, tillatelsesendringer og API-kall. Du må identifisere hvilke hendelser som er unormale, noe som krever policyer for transaksjonssikkerhet eller SIEM-korrelasjon ovenfor loggene som du konfigurerer for å bestemme deteksjonslogikken.
• Transaksjonssikkerhetspolicyer evaluerer hendelser i sanntid og blokkerer mistenkelige handlinger. Du må konfigurere disse policyene.
• Oppsettrevisjonsspor sporer de administrative endringene som plattformen tilbyr, men du må overvåke dem.
• Tilpasset programlogging fanger opp sikkerhetsrelevante hendelser i Apex som du må implementere.

Rut hendelsesovervåkingslogger til SIEM-plattformer for korrelasjon med telemetri for virksomhetens sikkerhet. Utform varsleregler som oppdager mistenkelige mønstre og samtidig minimerer usanne positive gjennom grunnleggende virkemåter.

Ditt ansvar: Rut hendelsesovervåking til SIEM, konfigurer policyer for transaksjonssikkerhet, implementer tilpasset logging, etabler grunnleggende virkemåter.

Det er viktig å dokumentere arkitektoniske beslutninger som støtter hendelsessvar før hendelser skjer.

• Isolasjonsgrenser utformer løsninger for å isolere kompromitterte komponenter uten å forstyrre viktige forretningsfunksjoner. Du må konfigurere opphevingen av tillatelsessett, endringer i IP-restriksjoner og øktavslutning for å gi rask isoleringsfunksjonalitet.
• Forensisk preservasjon bruker hendelsesovervåking til å gi detaljerte aktivitetslogger (plattformfunksjon). Feltrevisjonsspor beholder dataendringshistorikk basert på konfigurasjonen. Utformingen logger rute til uforanderlig lagringsplass slik at angripere ikke kan endre arkitekturen din.
• Gjenopprettingsprosedyrer dokumenterer testede gjenopprettingsprosesser for vanlige hendelsestyper. Det er viktig å validere sikkerhetskopien regelmessig. Du må kjenne gjenopprettingstidsmål (RTO) og gjenopprettingspunktmål (RPO) for sikkerhetshendelsesscenarier.
• Kommunikasjonsarbeidsflyter utformer varselmekanismer som fungerer under hendelser (for eksempel kommunikasjonskanaler utenfor båndet, forhåndsutkastede maler og eskaleringsprosedyrer som ikke er avhengige av potensielt kompromitterte systemer).
• Vulnerability Disclosure Channel er for offentlig tilgjengelige Experience Cloud-nettsteder. Den gir eksterne forskere en dokumentert, overvåket måte å rapportere sikkerhetsproblemer på via en erklæringspolicy som er publisert i RFC 9116 security.txt-standarden. En ekstern rapport er ofte det første signalet for en hendelse, så det er viktig å etablere denne inntaksbanen som en del av arkitekturen som du er ansvarlig for.

Ditt ansvar: Dokumentisoleringsprocedurer, rutelogger til uforanderlig ekstern lagring, teste gjenopprettingsprosedyrer kvartalsvis, etablere kommunikasjon utenfor båndet og publisere en sårbarhetsinngjøringskanal for offentlig tilgjengelige nettsteder.

I Salesforce er det viktig å klargjøre svarfunksjoner for plattformspesifikke scenarier.

• Kompromitterte brukerkontoer oppdages via Event Monitoring-påloggingsavvik (for eksempel uventet geografi, uvanlige klokkeslett og nye enheter). Når kontoer er kompromittert, fryser du brukeren, fremtvinger tilbakestilling av legitimasjon, ser gjennom Revisjonsspor for oppsett og datatilgangslogger for å bestemme kompromissperioden.
• Masseutfiltrering av data oppdages via hendelsesovervåking-rapporteksporter og avvik i API-datatilgang. Når datautfiltrering skjer, opphever du økter umiddelbart, begrenser tillatelser og identifiserer berørte poster og klassifiseringsnivåer.
• Uautorisert kodedistribusjon oppdages via distribusjonsovervåking og konfigurasjonsendringer i Revisjonsspor for oppsett. Når uautorisert kode distribueres, ruller du distribusjonen umiddelbart tilbake og reviderer alle endringer fra den kompromitterte distribusjonslegitimasjonen.
• Privilege-eskalering oppdages via Revisjonsspor-overvåking for tillatelsesendringer som er utenfor godkjente endringsvinduer. Når rettighetseskalering skjer, opphever du umiddelbart eskalerte rettigheter og reviderer aktiviteter som ble utført med økt tilgang.

Ditt ansvar: Dokumenter responsprosedyrer for plattformspesifikke scenarier, konfigurer overvåking for å oppdage hvert scenario, test prosedyrer via bordopplæringer.

Etter en hendelse er det viktig å utføre en vurderingsløs, etter hendelsesgjennomgang som er fokusert på arkitektoniske forbedringer. Du må dokumentere hva som skjedde, hvorfor de eksisterende kontrollene mislyktes med å hindre eller oppdage hendelsen, og hvilke arkitektoniske endringer som er nødvendige for å redusere fremtidige risikoer.

Mål for post-hendelsesgjennomgang:

• Bestem hendelsestidslinjen og angriperteknikkene.
• Identifiser kontrollfeilene som aktiverte hendelsen.
• Dokumenter alle arkitektoniske svakheter som hendelsen avslørte.
• Prioriter tiltak som er basert på risikoreduksjon.
• Del erfaringer på tvers av team.
• Oppdater deteksjonsregler og svarprosedyrer.

Det er viktig å spore hendelsesmålinger over tid for å bestemme gjennomsnittstiden for deteksjon (MTTD), gjennomsnittstiden for svar (MTTR) og innvirkningsomfanget.

Ditt ansvar: Utfør en rettidig etterhendelsesgjennomgang, dokumenter forbedringer i ADR-er, spor MTTD- og MTTR-trender, del erfaringer.

Bruk denne sjekklisten under arkitekturgjennomganger, før produksjonsdistribusjon og regelmessig for pågående vurdering. Hvert element representerer ansvarsområdene dine som Salesforce-arkitekt.

Delt ansvar

• Dokumenter alt som Salesforce sikrer (for eksempel infrastruktur, plattform og samsvarssertifiseringer).
• Dokumenter alt du må sikre (for eksempel konfigurasjon, tilgang, tilpasset kode og datastyring).
• Identifiser områder med delt ansvar (for eksempel hendelsessvar, sårbarhetsbehandling og overvåking).
• Kommuniser ansvarsområder til interessenter og implementeringsteam så tydelig og presist som mulig.

Sikkerhetsarkitektur

• Fullfør trusselmodellering med STRIDE-metodologien før du begynner å bygge.
• Bruk defensivt detaljerte kontroller på data-, program-, identitet- og integrasjonslag.
• Implementer Trust-prinsippene som krever eksplisitt verifisering for hver tilgangsforespørsel.
• Vedlikehold gjeldende sikkerhetsaktivumbeholdning som dekker sensitive data, integrasjoner, API-er og privilegerte kontoer.
• Dokumenter sikkerhetsarkitekturbeslutninger i ADR-er, inkludert trusselanalyse og kontrollbegrunnelse.
• Sikre kunder uten hoder og på vegne av Trust ved å overføre identiteter per bruker i stedet for pooltokener.
• Lagre, roter OAuth-legitimasjon og OAuth-legitimasjon med minst omfang via eksterne klientapper.
• For beholderisolerte integrasjoner håndhever du beholderisolering som en sikkerhetsgrense, krypterer trafikk mellom beholderer og hybrid VPN-trafikk med mTLS (når rammeverket krever det), og justerer distribusjonsområder med dataoppholds- og samsvarssertifiseringer

Identitets- og tilgangsbehandling

• Angi OWD-er til Privat for objekter som inneholder sensitive data.
• Reservere Felles skrivebeskyttet for objekter der bred lesetilgang er et dokumentert krav.
• Håndhev MFA for all produksjonsgrensesnitttilgang og maskinvaresikkerhetsnøkler for privilegerte kontoer. Integrasjoner bare for API som bruker JWT Bearer eller klientlegitimasjon, er unntatt.
• Implementer SSO med SAML 2.0 eller OpenID Connect med sterk identitetsleverandørgodkjenning.
• Bruk OAuth 2.0 (foretrukket JWT-bærer) til all API-godkjenning. Bruk aldri OAuth 2.0 til innebygd legitimasjon.
• Gi tilgang via tillatelsessett som er basert på dokumenterte krav om færrest rettigheter.
• Bruk forbedrede kontroller på viktige innvirkningskontoer (for eksempel IP-restriksjoner, påloggingsvarsler og periodiske tilgangsvurderinger).
• Utfør regelmessige tilgangsvurderinger ved å bruke dokumentert attestering for kontoer med høy privilegium, der frekvensen bestemmes av krav til organisasjonsrisikotoleranse og samsvar.
• Automatiser identitetslivssyklusen via SCIM-klargjøring og 90-dagers oppdagelse av hvilende kontoer.
• Kjør ansattagenter i den påloggede brukerens kontekst, og klargjør dedikerte, minst privilegerte agentbrukere for kundeagenter. Gjør aldri dette for gjestebrukere på offentlige nettsteder.
• Implementer JWT for agentgodkjenning ved bruk av identifikatorer for agentforekomst og robotdefinisjoner.
• Definer ABAC-policyer som er i samsvar med dataklassifisering og konsistente metadatakodestandarder.

Databeskyttelse og personvern

• Klassifiser alle data, og bruk beskyttelseskontroller som er riktige for hvert klassifiseringsnivå.
• Aktiver Shield Platform Encryption for begrensede data med dokumentert nøkkeladministrasjon.
• Krev TLS 1.2+ for alle integrasjoner med sertifikatbasert godkjenning for begrensede data.
• Hindre at begrensede data kommer inn i ikke-produksjonsmiljøer via maskering eller ekskludering.
• Implementer samtykkebehandling med detaljerte arbeidsflyter for sporing og tilbaketrekking per formål.
• Bygg arbeidsflyter for registrertes rettigheter som fullføres innen hvert styringsrammes tidsfrist for svar. Disse skal dimensjoneres til det mest omfattende vinduet i driftsfotavtrykket og parametere etter jurisdiksjon fra en vedlikeholdt overholdelseskilde der hvert tall er bekreftet mot den aktuelle forskriften.
• Dokumenter kravene til dataoppbevaring og valider Hyperforce.

Samsvar og overholdelse av forskrifter

• Valider plattformsertifiseringer som oppfyller lovpålagte krav for bransjen.
• Aktiver Hendelsesovervåking med SIEM-ruting for oppbevaring som overskrider innebygde oppbevaringsgrenser.
• Konfigurer Feltrevisjonsspor til å dekke Begrensede felt for å sikre at oppbevaring oppfyller lovpålagte minimumskrav.
• Oppretthold tilstandssjekkscorer på 80 % eller høyere (Veldig bra eller Utmerket-bånd), og dokumenter eventuelle unntak.
• Automatiser validering av samsvar for CI/CD pipelines som brytes under kritiske brudd.
• Implementer policyer for transaksjonssikkerhet for deteksjon og svar på avvik i sanntid.

Sikker utvikling livssyklus

• Utfør trusselmodellering i utformingsfasen (før du gjør betydelige bygginvesteringer).
• Håndhev CRUD/FLS i alle Apex.
• Baser deg på automatisk brukermodushåndhevelse for API-versjon 67.0 eller nyere, eller bruk med USERMODE eller stripInaccessible() for API-versjon 66.0 eller tidligere.
• Ikke bruk MED SECURITYENFORCED, som ble fjernet i API-versjon 67.0.
• Kjør Salesforce Code Analyzer i CI/CD når kritiske funn blokkerer distribusjon.
• Krev kodegjennomganger av sikkerhetsbevisste kontrollører for alle produksjonsendringer.
• Utfør penetrasjonstester for alle offentlig tilgjengelige programmer og Experience Cloud-nettsteder.
• Valider og fjern alle brukerinndata som hindrer innsetting på tvers av SOQL-, SOSL- og HTML-kontekster.

Sikkerhetshendelsesrespons

• Utform varsleregler for hendelsesovervåking for å oppdage mistenkelige mønstre via grunnleggende virkemåter.
• Rut logger til uforanderlig ekstern lagring for rettsmedisinsk bevaring.
• Dokumenter og test hendelsessvarprosedyrer for plattformspesifikke scenarier.
• Utfør skamløse etterhendelsesgjennomganger med ADR-er for å fange opp arkitektoniske forbedringer.
• Spor MTTD- og MTTR-målinger for å identifisere deteksjons- og responshull.

Dele tilbakemeldingene dine om det velbygde rammeverket.