Les om våre oppdateringsplaner heri.

Et sikkert system beskytter en organisasjons interessenter og data. Sikker arkitektur bekrefter brukeridentiteter, begrenser datatilgang til bare nødvendig informasjon og hindrer datakompromiss.

Salesforce prioriterer kundetillit og datasikkerhet. Salesforce Platform sikrer personvern og sikkerhet. Informasjon om systemytelse og sikkerhet i sanntid er tilgjengelig hos Salesforce Trust.

Beskyttelse av organisasjonens og kundedata er grunnlaget for å bygge sikre Salesforce-løsninger. Som Salesforce-arkitekt er du ansvarlig for å sikre organisasjonens og kundedata ved å bruke Salesforces innebygde sikkerhetsfunksjoner. Vurder geografisk fordeling, bransje, forretningsprosedyrer og kundedatatyper når du tar disse beslutningene.

Du kan gjøre løsningene dine sikrere ved å fokusere på tre områder: organisasjonssikkerhet, øktsikkerhet og datasikkerhet.

Organisasjonssikkerhet beskytter systemer mot uautorisert tilgang ved å sikre at bare validerte, autoriserte brukere får tilgang til et system og bare nødvendige funksjoner og data.

Tegn på at du har problematisk organisasjonssikkerhet, inkluderer følgende:

• Ad hoc-prosesser for å aktivere eller deaktivere brukere
• Uklargjorte trinn for å oppdatere godkjenning for bruker- eller systemrolleendringer
• Avhengig av den institusjonelle Knowledge av enkeltpersoner for riktig brukersikkerhet tildelinger
• manglende overholdelse av etablerte sikkerhetsrammeverk eller anbefalte bransjepraksis
• Fravær av et strukturert datastyringsrammeverk og støttende policyer

Du kan bygge bedre organisasjonssikkerhetskontroller for Salesforce-organisasjonene ved å fokusere på godkjenning og godkjenning.

Godkjenning er avgjørende for sikkerhets- og tilgangsbehandling for å bekrefte identiteten til brukere som forsøker å få tilgang til systemet. Dette gjelder både for brukere (ansatte, kunder) og automatiserte brukere (eksterne systemer, integrasjoner), der hver brukertype krever spesifikke godkjenningsskjemaer. For å sikre sikker tilgang på tvers av alle Salesforce-inngangspunkter i organisasjonen må du konfigurere ulike godkjenningsmetoder.

For å opprette sikre godkjenningsflyter i Salesforce:

• Opprett Salesforce-brukere basert på enkeltpersoner, ikke personer. Salesforces innebygde revisjonsfunksjonalitet er mest effektiv når hver brukerkonto tilsvarer én enkelt person som har tilgang til plattformen. Bruk av delte brukerkontoer kompromitterer effektiviteten av disse revisjonene, introduserer flere sikkerhetssårbarheter, eskalerer den potensielle innvirkningen av kontoinnbrudd og kompliserer muligheten til å opprette effektive godkjenningsskjemaer. Dette inkluderer brukerkontoer for integrasjonsbrukere.
• Sikre grensesnittbaserte tilgangsscenarier. De fleste brukere krever en slags grensesnittbasert tilgang (ofte kalt påloggingstilgang) for en Salesforce-organisasjon. Salesforce har flere lag med beskyttelse for disse påloggingsscenariene, inkludert:
  • Passordpolicyer. Cyberkriminelle målretter ofte brukernavn og passord for å få uautorisert tilgang til programmer. Konfigurering av passordpolicyer er et grunnleggende trinn for å beskytte påloggingstilgang, men det er viktig å merke seg at dette alene ikke er nok, siden Salesforce tillater overstyringer per bruker av disse policyene.
  • Godkendelse med flere faktorer (MFA). Salesforce krever MFA for alle grensesnittbaserte brukerpålogginger. MFA gir et viktig forsvar mot legitimasjonslekkasjer og brutto angrep ved å kreve at brukere oppgir en ekstra form for identifikasjon, eller faktor, etter at brukernavnet og passordet er riktig oppgitt. Denne ekstra faktoren tar vanligvis en fysisk form, som en mobilenhet, sikkerhetsnøkkel eller biometrisk markør.
  • Enkeltegn på (SSO). I SSO-scenarier bruker brukere bare ett legitimasjonssett på tvers av en organisasjons programmer. Tilgang til systemer klargjøres og behandles fra et sentralt sted, noe som forbedrer sikkerheten. Salesforce kan fungere som en tjenesteleverandør eller identitetsleverandør i SSO-scenarier. Pass på å tillate at noen eller alle administratorer logger seg på direkte til Salesforce slik at de kan løse avbrudd eller problemer med SSO-implementeringen.
  • Trinn etter pålogging. I enkelte brukstilfeller kan du kreve at brukere utfører flere trinn før de får tilgang til systemet. Tilpassede påloggingsflyter kan implementeres for å lede brukere gjennom disse ekstra prosesstrinnene. Eksempler er:
    • Godta vilkår og betingelser
    • Arbeide gjennom påloggingsoppdagelse og påloggingsscenarier uten passord
    • Begrense antall samtidige Salesforce-økter per bruker for å redusere sannsynligheten for øktbaserte angrep (se øktsikkerhet).
    • Koble til geofencing-tjenester
• Sikre API-baserte tilgangsscenarier. Alle brukere kan be om API-basert tilgang for en Salesforce-organisasjon. Salesforce tilbyr flere lag med beskyttelse for API-baserte scenarier, inkludert:
  • API-tilgangskontroll. Uten API-tilgangskontroll kan alle med et gyldig legitimasjonssett benytte alle apper til å koble til organisasjonen, selv om den tilkoblede appen ikke er distribuert i organisasjonen. Datatilgangskontroller vil fremdeles håndheves, men brukere kan få tilgang til informasjon på ukontrollerte måter. En app kan for eksempel brukes til å laste ned store mengder data, eller til og med laste opp ødelagt informasjon, uten en systemadministrators godkjenning.
  • Bare API-tillatelser. Du kan konfigurere Bare API-brukertillatelser i Salesforce. Tildel dette som en del av et tillatelsessett til automatiserte eller integrasjonsbrukere for å blokkere grensesnittbasert tilgang fullstendig.
  • Sertifikater og nøkler. Med sertifikater og nøkler kan Salesforce validere om forespørsler kommer fra autoriserte virksomheter eller firmaer. Du må konfigurere sertifikater og nøkler hvis du vil bruke SSO med Salesforce.
  • Tilkoblede apper. Ved å konfigurere tilkoblede apper i Salesforce kan du styre ekstern systemtilgang til Salesforce, inkludert nødvendige godkjenningsprotokoller, godkjenningsomfang og øktvirkemåte i én enkelt definisjon.
  • Navngitt legitimasjon. Med navngitt legitimasjon kan du styre eksterne tilgangspunkter og godkjenningsprotokoller i én enkelt definisjon i Salesforce. Bruk dem til å sikkert definere og behandle godkjenning for oppkall fra Apex, eksterne tjenester og Salesforce Connect.
• Agentforce Agent-brukeres godkjenning. Agentforce, som er bygd på Salesforce, bruker agentbrukerobjekter med administrerbare tillatelser på samme måte som for virkelige brukere. Når du konfigurerer en agent, må du nøye tilpasse tilgangen til rollen agenten har, og begrense datatilgangen til bare det som kreves for å betjene sluttbrukerne. På samme måte kan agenter konfigureres med både felles og private handlinger. For private handlinger validerer og godkjenner du sluttbrukere ved å tilordne dem til agentkontekst. Dette gjør at agenten kan utgjøre og operere innenfor sluttbrukerens tilgangskontroller, samtidig som sikkerhet og Trust opprettholdes.

Listen over mønstre og motmønstre nedenfor viser hvordan riktig (og dårlig) godkjenningsarkitektur ser ut i en Salesforce-organisasjon. Bruk disse til å validere utforminger før du bygger, eller identifisere muligheter for ytterligere forbedringer.

Hvis du vil vite mer om godkjenningsverktøy som er tilgjengelig fra Salesforce, kan du se Verktøy som er relevante for sikkerhet.

Godkjenning definerer hvilke funksjoner, funksjonalitet og data en bruker kan få tilgang til, og hvilke handlinger de kan utføre med disse ressursene etter at de har blitt godkjent. Godkjenningskontroller er ikke bare for brukere, de må også skreddersys for Agentforce, spesielt agenter som tilbyr tjenester til ikke-godkjente sluttbrukere.

Å begrense hvem som kan godkjennes i organisasjonen, er et viktig første trinn, men det er like viktig å kombinere sterk godkjenning med robust godkjenning. Uten tilstrekkelige godkjenningskontroller kan brukere potensielt opprette, redigere og slette poster eller få tilgang til systemfunksjonalitet på måter som er skadelige for virksomheten og interessentene. Utilstrekkelig godkjenningskontroll kan også gjøre det vanskeligere å bruke systemer. Ved å kontrollere hva brukerne kan gjøre i systemet, fremmer du et høyere nivå av Trust, og beskytter både systemet og brukerne.

For å bygge sikre godkjenningsskjemaer for Salesforce:

• Følg prinsippet om minst privilegium. Ta i bruk prinsippet om minste rettigheter (PoLP) ved å tildele brukere bare de nødvendige tillatelsene for oppgavene. Utform detaljerte og modulære tillatelsessett for å følge dette prinsippet. Dette gir avanserte tilgangskontroller via tillatelsessettgrupper, slik at du kan administrere tillatelser nøyaktig, inkludert muligheten til å slå av, angi utløpsdatoer og mer. Juster systemets funksjonelle enheter med forretningsmuligheter for å definere detaljerte tillatelser og effektive tillatelsessettgrupper. Husk at tillatelser gjelder for tilgang til metadata i Salesforce. Hvis du vil vite mer om konfigurering av PoLP for Salesforce-tilgang til data, kan du se Deling og synlighet.
• Tenk på brukertilgang i form av personer, ikke enkeltpersoner. Å tenke på godkjenning (eller sikkerhet generelt) med hensyn til individuelle brukere vil ikke justere systemet og utvikle seg. Utform i stedet for og behandle personligheter som representerer grupper av brukere. Sikker Salesforce-løsninger bruker enkeltpersoner til godkjenning og personer til godkjenning. Ved å definere sikkerhetskonfigurasjoner for distinkte profiler får du detaljert kontroll over tilgang og rettigheter i sikkerhetsmodellen, noe som minimerer behovet for omstrukturering på lang sikt. Inkluder sikkerhetspersonene du definerer i designstandardene og -dokumentasjonen.
• Kontroller brukertilgang til metadata ved bruk av tillatelsessett og tillatelsessettgrupper. Tillatelsessett og tillatelsessettgrupper styrer hva metadatabrukere kan få tilgang til og hva de kan gjøre med disse metadataene. Hvis du vil vite mer om Salesforce-metadata, kan du se Metadata kontra Data. Konfigurer apptildelinger, funksjonslisensaktiveringer, administrert pakketilgang, systemtillatelser, CRUD-tilgang og tilgang på feltnivå via tillatelsessett og tillatelsessettgrupper. Inkluder denne tilgangen i designstandardene og -dokumentasjonen.
• Bruk organisasjonsomfattende standardinnstillinger (OWD-er) og deling til å kontrollere datatilgang for brukere. Data og metadata er separate enheter i Salesforce og krever separate tilgangskontroller for hver av dem. Bruk OWD-er og innebygde delingsverktøy til å konfigurere tilgang for Salesforce-data (enkeltposter, filer og dokumenter). Se Datasikkerhet for å få mer informasjon.
• Bruk OAuth-omfang til å kontrollere tilgang for tilkoblede apper. Når du konfigurerer en tilkoblet app, definerer du omfanget eller tilgangstillatelsene som appbrukere skal ha til Salesforce-ressurser. Hvis du vil vite mer om behandling av OAuth-tokener, kan du se Øktbehandling.
• Opprett én Salesforce-bruker for hver integrasjon. For å overholde prinsippet om minst rettigheter oppretter du en unik Salesforce-integrasjonsbruker for hver integrasjon. Da kan du tildele spesifikk datatilgang, forbedre kontrollen over operasjoner, sikre transaksjonssporing og minimere virkningen av potensielle sikkerhetsbrudd.
• Implementer unike kontoer med PoLP for alle Agent-brukere. Hver Agentforce skal være unik og ikke gjenbrukes på tvers av flere agenter. Tillatelser for disse kontoene må strengt overholde prinsippet om minst rettigheter. Husk at handlinger som utføres av en agentbruker, kan operere i en høy sikkerhetskontekst i Salesforce eller mot eksterne systemer som ikke respekterer Salesforce-tilgangskontroller. Dette kan føre til at handlinger får tilgang til eller viser sensitiv informasjon til brukere.
• Minimer bruken av profiler og overfør eventuelle tilgangskontroller fra profiler. Profiler gir mulighet til å begrense tilgang til påloggings-IP-områder, påloggingstider og funksjoner spesifikke for det tidligere Salesforce Classic brukergrensesnittet (spesielt standard posttyper og sideoppsettildelinger). Eventuell annen funksjonalitet som for øyeblikket finnes i profiler, må overføres til tilsvarende funksjonalitet i tillatelsessett og tillatelsessettgrupper. Funksjonalitet i profilene som er knyttet til Salesforce Classic, bør være målrettet for rettelse.

Listen over mønstre og motmønstre nedenfor viser hvordan gode (og dårlige) godkjenningsrutiner ser ut i en Salesforce-organisasjon. Bruk disse til å validere utforminger før du bygger, eller identifisere muligheter for ytterligere forbedringer.

Hvis du vil vite mer om godkjenningsverktøy som er tilgjengelig fra Salesforce, kan du se Verktøy som er relevante for sikkerhet.

Denne tabellen viser et utvalg av mønstre som du kan se etter (eller bygge) i organisasjonen, og motmønstre som du kan unngå eller målrette etter rettelse.

✨ Oppdag flere mønstre for organisasjonssikkerhet i Pattern & Anti-Pattern Explorer.

En økt er serien av forespørsler og svar som er knyttet til en bruker over en tidsperiode. En økt startes når en bruker godkjenner seg til Salesforce. Øktsikkerhet er praksisen med å konfigurere systemet for å hindre uautorisert tilgang og datainnbrudd ved å avverge øktinterferens eller kapring.

All brukeraktivitet i systemet skjer innenfor konteksten av en økt, så det er viktig å ta hensyn til hvordan økter startes, hva som kan skje i løpet av en økt, hvilke enheter brukere vil (og bør) bruke, og hvordan du oppdager og svarer på mistenkelige eller unormale øktvirkemåter.

Du kan bygge øktsikkerhet i Salesforce ved å fokusere på tre nøkler: øktbehandling, enhetstilgang og trusseldeteksjon og -respons.

Økter startes når en bruker godkjenner og får tilgang til Salesforce. Disse øktene gir plattformen mulighet til å knytte bestemte forespørsler og svar til den bestemte brukeren.

HTTPS-protokollen letter kommunikasjonen mellom en frontend-klient og Salesforce Platform. Klienter kan inkludere nettlesere, mobilprogrammer, lokale programmer og så videre. HTTPS er en statløs protokoll, som betyr at all kommunikasjon er diskret og ikke relatert til tidligere eller fremtidige kommunikasjoner.

Denne tilgangen uten status øker hastigheten på nettverkskommunikasjonen og eliminerer feil som skyldes brutte lenker mellom pakker. Men nettapper trenger fremdeles en måte å holde oversikt over hver brukers identitet og annen relatert informasjon på tvers av flere interaksjoner mellom forespørsler og svar. Salesforce, som de fleste nettprogrammer, gjør dette ved bruk av økter og tokener.

• Med økter kan Salesforce knytte forespørsler og svar til brukere. Når en bruker er godkjent, sender plattformen en økt-ID tilbake til klientappen, som inkluderer denne IDen med eventuelle brukerforespørsler (som å navigere, søke og sende data).
• Med tokener kan brukere og tilkoblede programmer bekrefte identiteten sin én gang og deretter bruke et unikt tilgangstoken. Tokener har en begrenset levetid og gir tilgang bare til bestemte ressurser (se godkjenning for å få mer informasjon om konfigurering av tilgangsnivåer). Tokener gir tilgang til autoriserte ressurser uten at brukere må logge seg på.

Hvis økter og tokener ikke sikres riktig, kan dårlige aktører potensielt forstyrre dem og foregripe brukere eller utføre skadelig kode i systemet.

For å bygge sikker øktbehandling for Salesforce:

• Forstå hvordan Salesforce klassifiserer økttyper. Identifiser og tilordne godkjente økttyper til sikkerhetsbrukerpersoner, og registrer disse i dokumentasjonen.
• Kontroller hvordan økter kan opprettes og hvor økt trafikk kan gå. Når du har identifisert hvilke typer økter forskjellige brukere har tillatelse til å starte, konfigurerer du kontroller for å blokkere økter som kommer fra ikke-godkjente kilder eller kontekster. Salesforce tilbyr flere måter å kontrollere øktopphav og trafikk på, inkludert:
  • Inbygd øktbeskyttelse. Salesforce aktiverer automatisk organisasjonsomfattende beskyttelse for øktbasert skadelig aktivitet, inkludert skripting på tvers av nettsteder, forfalskning av forespørsler på tvers av nettsteder, innholdssniffing, klikkkapring og mer. Disse beskyttelsene bør aldri deaktiveres, noen kan ikke deaktiveres.
  • Domener og IP-områder. Alle Salesforce-organisasjoner har som standard aktivert Mitt domene, som oppretter et firmaspesifikt underdomene for Salesforce-tilgang. Du kan tilpasse eller endre navnet som er knyttet til en organisasjon, via Mitt domene. Videre støtter Salesforce flere domenekonfigurasjoner for Experience Cloud-nettsteder og andre programsider. Notat: Hvis brukerne trenger tilgang til Salesforce fra bak en firmamur, legger du til de nødvendige domenene i tillatelseslistene for brannmurer. Du kan konfigurere påloggings-IP-områder og klarerte IP-områder for å kontrollere innkommende pålogginger og øktforespørsler til Salesforce.
  • Påloggingstid. Hvis enkelte brukere har angitt arbeidstider, kan du begrense deres tilgang til Salesforce utenfor definerte påloggingstider.
• Kontroller aktiviteter som krever ekstra øktnivåsikkerhet. Som standard kan økter ha to typer sikkerhetsnivåer: standard og høy sikkerhet. Bruk disse sikkerhetsnivåene til å kontrollere hvordan brukere kan og ikke kan utføre aktiviteter som tilgang til rapporter og kontrollpaneler eller behandling av sikkerhetskonfigurasjoner i en Salesforce-organisasjon. Sikkerhetspolicyer på øktnivå kan kreve at brukere oppretter økter med høy sikkerhet for å utføre operasjoner eller hindrer brukere i å utføre sensitive operasjoner.
• Kontroller aktiviteter som krever ekstra øktbaserte tillatelser. Salesforce støtter aktivering av øktbaserte tillatelser for å gi brukere midlertidig høy godkjenning eller tilgang til tillatelser i en bestemt økt. Du kan aktivere og deaktivere øktbaserte tillatelser via Flyt- eller Salesforce-API-er.
• Behandle inaktive brukerøkter via tidsavbrudd. Avslutting av inaktive økter er en viktig del av behandling av øktsikkerhet. Dette bidrar til å beskytte systemet når en bruker for eksempel lar en Salesforce-økt være åpen i en nettleserfane, men arbeider aktivt i et annet program, eller når en brukers mobilenhet er logget på Salesforce, men ikke er overvåket. Salesforce har en standard tidsavbrudd for inaktiv økt på to timer. Du kan øke eller redusere tidsavbruddnivåer for inaktiv økt, men økning av tidsavbrudd bør bare gjøres med en overbevisende og veldokumentert begrunnelse.
• Behandle økter i tilkoblede apper via tokenkonfigurasjon. Når du konfigurerer en tilkoblet app, definerer du også omfanget, eller godkjenningsnivået, som skal gis til brukere som får tilgang til Salesforce via den tilkoblede appen. Dette omfanget håndheves på øktnivå via OAuth-tokener, som utstedes etter at en bruker av en tilkoblet app har godkjent. Du kan bestemme hvor lenge et token skal vare gjennom tokenoppdateringspolicyer. Organisasjonsadministratorer kan manuelt oppheve tokener per bruker og per organisasjon, om nødvendig.

Listen over mønstre og motmønstre nedenfor viser hvordan riktig (og dårlig) øktbehandling ser ut i en Salesforce-organisasjon. Bruk disse til å validere utforminger før du bygger, eller identifisere muligheter for ytterligere forbedringer.

Hvis du vil vite mer om øktbehandlingsverktøy som er tilgjengelig fra Salesforce, kan du se Verktøy som er relevante for sikkerhet.

I dagens sammenheng er en enhet ethvert element av elektronisk utstyr som en person vil bruke til å få tilgang til Salesforce, som en stasjonær arbeidsstasjon, bærbar datamaskin, nettbrett eller mobiltelefon.

Portable enheter gir brukere fleksibilitet til å få tilgang til Salesforce fra hvilket som helst sted. Denne bekvemmeligheten kan imidlertid introdusere flere angrepsvektorer for skadelige aktører. Disse trusselvektorene spenner fra enkle strategier, som å surfe på et offentlig sted for å stjele legitimasjon, til mer sofistikerte metoder som å installere skadelig programvare på en enhet eller opprette et falskt offentlig Wi-Fi-nettverk for å fange opp dataoverføringer. På grunn av dette er sikring av enheter, spesielt bærbare enheter, viktig for den generelle systemsikkerheten.

For å sikre enhetstilgang for Salesforce:

• Bruk mobilappløsninger fra Salesforce. Få brukere på mobilenheter som trenger tilgang til Salesforce, til å bruke de offisielle Salesforce-appene som er tilgjengelig for iOS og Android. Hvis forretningsbehov krever en tilpasset mobilløsning, bør du bruke Salesforce Mobile SDK, som tilbyr metoder for sikker godkjenning og godkjenning.
• Design mobile enhetsbruk i øktbehandling. Øktsikkerhetsnivåer, tidsavbrudd for økter og andre øktkontekstkontroller bør ta hensyn til eventuell forventet tilgang fra brukere på mobilenheter. Vurder hvilke enheter som skal og ikke skal ha tilgang til Salesforce, og hvilke typer brukere som skal ha tilgang til mobiløkter. Inkluder mobiltilgangsstandarder i dokumentasjonen for sikkerhetspersonlighet. Hvis du vil vite mer om dette emnet, kan du se Øktbehandling.
• Legg til sikkerheten på enhetsnivå med Mobile Device Management (MDM)-teknologi. Salesforce-appene for iOS og Android er kompatible med mange populære MDM-pakker. Du kan konfigurere flere tilgangskontroller for Salesforce-appen på brukerenheter via den foretrukne MDM-løsningen.
• Tilleggsikkerhet på appnivå med MAM-teknologi (Mobile Application Management). MAM-teknologi støtter kontroller på appnivå på mobilenheter. Salesforce tilbyr et betalt MAM-tillegg for Salesforce-mobilapper.

Listen over mønstre og motmønstre nedenfor viser hvordan riktig (og dårlig) enhetsbehandling ser ut i en Salesforce-organisasjon. Bruk disse til å validere utforminger før du bygger, eller identifisere muligheter for ytterligere forbedringer.

Hvis du vil vite mer om verktøy for enhetsbehandling som er tilgjengelig fra Salesforce, kan du se Verktøy som er relevante for sikkerhet.

Trusseldeteksjon er prosessen med å identifisere atferdsmønstre i systemet som kan indikere skadelig aktivitet. Dette kan inkludere datavolumer som er større enn gjennomsnittet, som lastes ned, eller at en bruker endrer felt som inneholder sensitive data i flere poster, i en kortere tidsperiode enn gjennomsnittet. Svar på trusler kan inkludere automatisk øktutløp, varsler og andre varsler.

Målet med trusseldeteksjon er å identifisere og svare på potensielle problemer så raskt som mulig. Handling basert på sanntids trusseldeteksjon kan stoppe skadelig virkemåte i sporet. Salesforce tilbyr sanntids hendelsesovervåking som et tillegg eller som en del av Salesforce Shield. Bruk en av disse løsningene hvis du har svært sensitive programmer eller krever robust sanntids trusseldeteksjon og -responsfunksjonalitet.

Slik bygger du en effektiv trusseldeteksjons- og responsstrategi for Salesforce-løsningene dine:

• Bruk innebygde revisjonsfunksjoner. Salesforce tilbyr en rekke innebygde verktøy for å spore og revidere endringer i organisasjonen. Med Oppsettrevisjonsspor kan du for eksempel vise revisjonshistorikken for administrative handlinger. Salesforce sporer endringer på feltnivå i en begrenset tidsperiode som standard, men du kan aktivere felthistorikksporing for å vise feltendringer i opptil 18 måneder i brukergrensesnittet og opptil 24 måneder via API-et. I tillegg kan du aktivere Field Audit Trail for å beholde en revisjonshistorikk for endringer på feltnivå på ubestemt tid (til du sletter dataene manuelt).
• Innføre regelmessige revisjonsgjennomganger. Revisjon er avgjørende for å identifisere avvikende endringer som det kan mangle ved deteksjon av trusler i sanntid. Vurder et scenario der en bruker med legitim tilgang konsekvent sletter et lite antall poster daglig over en utvidet periode. I og med at denne brukeren har gyldig påloggingslegitimasjon, riktig autorisasjon til å slette poster og ikke sletter et stort antall poster samtidig, er det lite sannsynlig at aktiviteten oppdages som en sanntidstrussel. Et revisjonsteam som ser gjennom brukeraktivitetsrapporter, vil imidlertid tydelig identifisere denne trenden med overdreven sletting av poster av en enkelt bruker over tid, noe som gjør det enklere å løse problemet. Som en del av styringspolicyer må du etablere regelmessige intervaller for revisjon av påloggingshistorikk, brukerøktaktivitet og bruk av tilkoblede apper.
• Utvikle en trusselresponsstrategi og ta den med i sikkerhetspolicyene. Opprett en trusselsvarstrategi som dekker følgende:
  • Definisjoner av trusselsvarstyper (for eksempel varsler og automatiseringer) og eventuelle interessentgrupper som bør involveres. Hvis du vil vite mer om utforming av meldinger eller varsler, kan du se Feil og varsler.
  • Spesifikke kategorier for sanntidsendringer eller aktiviteter som kan vurderes som trusler, og den tilknyttede svartypen for hver av dem
  • En tydelig liste over alle automatiserte trusselsvar (som å oppheve tokener, avslutte økter, deaktivere brukerkontoer eller blokkere tilgang til ressurser) og automatiseringsutløsere

Hendelsesovervåking gir data som er nødvendige for å håndheve dette prinsippet, ved å aktivere deteksjon og svar på trusler i sanntid. Transaksjonssikkerhet bruker firmaets policydrevne handlinger, og hendelsestyper støtter overvåking av brukertilgang og programtilgang over tid.

Salesforces innebygde Trusseldeteksjon-tjeneste bruker statistiske og maskinlæringsmodeller til å identifisere mistenkelig virkemåte. Denne tjenesten genererer bestemte hendelser som beskytter mot cyberangrep og mistenkelig datatilgang.

Transaksjonssikkerhet tar sikkerheten et skritt videre fordi den gir et rammeverk som fanger opp viktige hendelser som skjer i organisasjonen, og bruker firmaets policydrevne handlinger. Dette transformerer Hendelsesovervåking fra et loggverktøy til en viktig komponent i et automatisert sikkerhetsforsvar.

Listen over mønstre og motmønstre nedenfor viser hvordan riktig (og dårlig) trusseldeteksjon og -respons ser ut i en Salesforce-organisasjon. Bruk disse til å validere utforminger før du bygger, eller identifisere muligheter for ytterligere forbedringer.

Hvis du vil vite mer om verktøy for trusseldeteksjon, varsling og svarautomatisering som er tilgjengelig fra Salesforce, kan du se Verktøy som er relevante for sikkerhet.

Denne tabellen viser et utvalg av mønstre som du kan se etter (eller bygge) i organisasjonen, og motmønstre som du kan unngå eller målrette etter rettelse.

✨ Oppdag flere mønstre for øktsikkerhet i Pattern & Anti-Pattern Explorer.

Datasikkerhet er praksisen med å beskytte dataene mot uautorisert tilgang, korrupsjon eller utilsiktet sletting. Datasikkerhet innebærer å sikre data både underveis og under lagring.

Sterk datasikkerhet minimerer risikoen og potensiell skade fra uautorisert tilgang til systemet. Utilstrekkelig datasikkerhet gjør at systemer er sårbare for datainnbrudd, noe som kan få alvorlige konsekvenser for kunder og firmaet. Beskyttelse av dataene dine er derfor grunnleggende for å bygge sikre arkitekturer.

Forbedring av datasikkerhet starter med en klar forståelse av hva som anses som data i Salesforce, sammen med deres klassifisering. De individuelle postene, filene og dokumentene som er lagret i en Salesforce-organisasjon, er dens data. Hvis du vil vite mer om forskjellen mellom metadata og data, kan du se Grunnleggende om Salesforce-arkitektur.

Du kan bygge sterkere datasikkerhet i Salesforce-løsningene ved å fokusere på deling og synlighet i tillegg til bruk av kryptering.

Notat: Når du utformer for datasikkerhet, må du passe på å ta hensyn til datapersonvern samt arkivering og sletting, da begge disse konseptene vil påvirke den generelle datasikkerheten til løsningene dine.

Identifiser og klassifiser alle data som er lagret i Salesforce-plattformen, basert på dens følsomhet (for eksempel felles, interne, konfidensielle, begrensede). Definer en tydelig dataklassifiseringspolicy som beskriver hvordan hver datatype skal håndteres og beskyttes. Implementer riktige sikkerhetskontroller, som feltnivåsikkerhet, kryptering og datamaskering, for å håndheve policyen og beskytte sensitive data mot uautorisert tilgang eller eksponering. Se gjennom og revider regelmessig disse klassifiseringer og kontrollene for å sikre at de forblir i samsvar med forretnings- og samsvarskravene.

Deling og synlighet innebærer å konfigurere systemet for å kontrollere hvordan brukere får tilgang til data i Salesforce. Det er viktig å merke seg at deling og synlighet bestemmer hvilke individuelle poster en bruker kan få tilgang til, men disse innstillingene alene bestemmer ikke hva en bruker kan gjøre med en bestemt post, eller hvilke spesifikke felt i denne posten som er synlige. Tillatelser til å utføre databehandlinger (som CRUD) tildeles brukere via metadatatilgangskontroller, som kan konfigureres for en bruker på det individuelle objekt- og feltnivået. Hvis du vil vite mer om dette, kan du se Godkjenning.

Agentforce kan vise data til både godkjente og anonyme brukere som vanligvis mangler direkte tilgang. Når du bygger Agentforce, bør du vurdere og dokumentere alle handlinger som er tildelt til agenten. For hver handling må du forstå:

• Hvilke data handlingene har tilgang til.
• Hvilken sikkerhetskontekst handlingene kjører i.
• Om handlingene har Knowledge eller annen funksjonalitet som kan innlemme sensitive eller begrensede data i Agent-økten.

For å konfigurere effektiv deling og synlighet i Salesforce:

• Design tilgang rundt meningsfylte jobbfunksjoner. Opprett en sikkerhetsmatrise som tilordner dine brukerpersonligheter til forretningsfunksjoner de skal utføre. Bruk denne malen som grunnlag for å utforme deling og synlighet. Hvis du vil vite mer om identifisering av meningsfylte forretningsfunksjoner, kan du se Funksjonelle enheter.
• Velg den enkleste veien til å bruke prinsippet om minst privilegium. Når du bruker prinsippet om minst privilegium når du utformer delings- og synlighetsordninger, gjør du det på den enkleste måten. Unngå overutviklede databegrensninger og delingsskjemaer, som kan føre til nedstrøms problemer for systemvedlikehold, skalerbarhet og tilpassbarhet. I stedet kan du dra nytte av den fleksible, lagdelte datadelingen i Salesforce for å konfigurere detaljerte regler for brukertilgang på datanivå.
• Angi interne organisasjonsomfattende standardinnstillinger (OWD-er) til Felles skrivebeskyttet med mindre virksomheten din håndterer sensitive data – bruk deretter Privat. OWD-er bestemmer nivået av "minste" rettigheter brukere vil ha på datanivået. Du kan ikke begrense tilgang under OWD-nivået. Private OWD-er kan virke ideelle i alle brukstilfeller, men brukere i hele virksomheten kan ofte slutte å utilsiktet replikere en mer tillatelsesrik OWD gjennom komplekse delingsskjemaer. I tillegg kan private OWD-er føre til at brukere oppretter duplikatdata. Delingsberegninger (og omberegninger) kan ta en betydelig tid å fullføre avhengig av datavolum og overordnet-underordnet- eller eierskapsforskyvning – Private OWD-er forverrer dette. Det er viktig å merke seg at OWD-er ikke kontrollerer CRUD-tillatelser og synlighet på feltnivå. Velg bare en OWD av Privat når det er berettiget av forretningsbehov – oftest vil slike berettigelser være relatert til overholdelse.
• Angi eksterne organisasjonsomfattende standardinnstillinger (OWD-er) til Privat med mindre du har en tvingende forretningsårsak til å tillate større tilgang. Ekstern OWD-er gjelder for brukere som har tilgang til Salesforce-data fra Experience Cloud-nettsteder, portaler og så videre. Da kan du konfigurere separate OWD-standardlinjer for interne og eksterne brukere for å tillate forskjellige typer "minste" rettigheter. Angi alltid OWD for eksterne brukere til Privat – unntak for et mer åpent nivå må være klart begrunnet av forretningsbehov.

Listen over mønstre og motmønstre nedenfor viser hvordan riktig (og dårlig) deling og synlighet ser ut i en Salesforce-organisasjon. Bruk disse til å validere utforminger før du bygger, eller identifisere muligheter for ytterligere forbedringer.

Hvis du vil vite mer om verktøy for deling og synlighet fra Salesforce, kan du se Verktøy som er relevante for sikkerhet.

Kryptering konverterer lesbare data til et ukrypterbart, kodet format. Krypterte data kan dekrypteres, eller oversettes tilbake til sin opprinnelige form, via en nøkkel. Resultatet er at kryptering er blant de mest effektive metodene for å sikre data både under lagring og under overføring, slik at selv om uautoriserte parter får tilgang til dataene, blir de ulesbare.

Slik utformer du for riktig bruk av kryptering i Salesforce-løsninger:

• Altid tilstrekkelig kryptere data i transitt. Salesforce bruker Transport Layer Security (TLS) for alle økter som skjer i en Salesforce-støttet nettleser, og krever at utgående samtaler som bruker HTTPS, oppfyller spesifikke sikkerhetsstandarder. Plattform-API-er bruker også HTTPS som standard. I tillegg blir data som sendes mellom et Salesforce Experience Cloud-nettsted eller en portal og tilhørende Salesforce-organisasjon, som standard kryptert under overføring. Hvis du bruker Salesforces innebygde e-posttjenester, finnes det standardnivåer for Transport Layer Security (TLS) som Salesforce bruker til å sende og forsøke levering av e-post. Du bør som et minimum forsikre deg om at organisasjonsinnstillingene ikke er lavere enn standardinnstillingene, med mindre du har klare forretningsmessige begrunnelser. Basert på klassifiseringen og sensitiviteten til dataene kan du vurdere å benytte en privat nettverkstilkobling til Salesforce via AWS Direct Connect eller Salesforce Private Connect. Dette sikrer at dataene ikke går gjennom det offentlige Internett, men i stedet flyter sikkert over en privat nettverkstilkobling for både brukertilgang og integrasjoner.
• Hvis virksomheten krever det, krypter data ved lagring. Salesforce tilbyr forskjellige måter å kryptere data på under lagring.
  • Hyperforce. Data krypteres under lagring i organisasjoner som bruker Hyperforce. Kryptering behandles for organisasjonen av Salesforce. Du kan ikke opprette (eller ødelegge) dine egne krypteringsnøkler.
  • Salesforce Shield. Med Salesforce Shield kan du kryptere data som er lagret i en Salesforce-organisasjon, på flere lag, inkludert program- og databaselag. Med Shield har du full behandlingsfunksjonalitet for leietagerens krypteringsnøkler, inkludert robuste BYOK-alternativer (Bruk din egen nøkkel). Du kan også kryptere ustrukturerte data (inkludert filer, vedlegg, søkeindekser og hendelser). Hyperforce forekomster gir deg mulighet til å bruke en ekstern nøkkeladministrator slik at du kan ta med deg ditt eget AWS KMS. Med denne funksjonen beholder du full kontroll over krypteringsnøklene i KMS-et som brukes til å kryptere og dekryptere dataene som er lagret i Salesforce, noe som styrker sikkerheten og samsvarer med organisasjonens krav til samsvar.

Listen over mønstre og motmønstre nedenfor viser hvordan riktig (og dårlig) bruk av kryptering ser ut i en Salesforce-organisasjon. Bruk disse til å validere utforminger før du bygger, eller identifisere muligheter for ytterligere forbedringer.

Hvis du vil vite mer om krypteringsverktøy som er tilgjengelig fra Salesforce, kan du se Verktøy som er relevante for sikkerhet.

Denne tabellen viser et utvalg av mønstre som du kan se etter (eller bygge) i organisasjonen, og motmønstre som du kan unngå eller målrette etter rettelse.

✨ Oppdag flere mønstre for datasikkerhet i Pattern & Anti-Pattern Explorer.

Hjelp oss å holde Salesforce Well-Architected relevant for deg, ta vår undersøkelse for å gi tilbakemelding om dette innholdet og fortell oss hva du vil se videre.