Oversat med AI. Fællesskabet har endnu ikke gennemgået oversættelsen. Læs på engelsk

Blog · 19. september 2023 · Steve Simpson · Identitet

Et dybdedyk i sikkerheden i Salesforce: autentificering og autorisation forklaret

Velkommen til begyndelsen på en grundig gennemgang af sikkerheden i Salesforce, hvor vi starter med fundamentet: autentificering og autorisation. Denne artikel er den første i en serie, der skal rede trådene ud i Salesforces net af sikkerhedsmekanismer.

Det grundlæggende: autentificering og autorisation

Autentificering er processen, hvor man kontrollerer, at en part, hvad enten det er en bruger i en browser eller en maskine, der tilgår systemet, virkelig er den, den udgiver sig for at være. Autorisation afgør derimod, hvad den autentificerede part må gøre i Salesforce. Begge dele er afgørende for, at dine data i Salesforce forbliver sikre, og for at kun autoriserede brugere og systemer kan få adgang til dem.

Fra browsere til API’er: indgangene

Salesforce sørger for, at al indgående trafik bruger SSL og TLS til sikker datatransport. (Vi går i detaljer med de begreber i en kommende artikel.)

Når du forestiller dig, hvordan data kommer ind i Salesforce, kan du tænke på to hovedveje:

  1. Direkte via en browser, af en bruger
  2. Gennem en API-klientapplikation, for eksempel en mobilapp eller en anden server

Begge veje starter med at kommunikere med Salesforces autentificeringsserver.

[caption id="" align=“alignnone” width=“1800”]Et diagram, der viser de forskellige måder, eksterne systemer kan tilgå Salesforce Core på Et diagram, der viser de forskellige måder, eksterne systemer kan tilgå Salesforce Core på [/caption]

Lad os bryde dem yderligere ned:

Adgang via browser

For mennesker, der arbejder i Salesforce via en browser:

[caption id="" align=“alignnone” width=“1840”]Autentificeringsflow fra browseren ind i Salesforce Autentificeringsflow fra browseren ind i Salesforce [/caption]

Derefter styrer autorisationsmekanismerne adgangen til sider og ressourcer.

Adgang for API-klienter

For maskiner, der forsøger at tilgå Salesforce:

[caption id="" align=“alignnone” width=“1820”]Klientprocesser, der autentificerer sig mod Salesforces API'er Klientprocesser, der autentificerer sig mod Salesforces API’er [/caption]

OAuth-flows: Maskiner kan bruge et af flere OAuth-flows for at få adgang, fra web server-flowet til eksterne webservere til client credentials-flowet og mange imellem. Hvert har sin egen sekvens og sit eget formål.

Etablering af sessionen: Efter autentificeringen overdrager Salesforces autentificeringsserver et sessionstoken, som giver API-klienten adgang til ressourcerne i Salesforce.

Derefter kommer autorisationsreglerne i spil.

Opsummering: sådan hænger det hele sammen

Uanset indgang, browser eller API-klient, består processen af:

Sikkerhed på transportniveau: TLS, eventuelt med ekstra lag som tilladte IP-adresser og klientcertifikater for øget sikkerhed.

Autentificering: Dette trin identificerer brugeren eller systemet. Det er her, ting som MFA eller tredjeparts-IDP’er kommer ind.

Udstedelse af sessionstoken: Når parten er autentificeret, får den et sessionstoken, der fungerer som et pas til ressourcerne i Salesforce.

Autorisation: Den sidste barriere. Selv med et gyldigt sessionstoken er det her, det afgøres, hvilke ressourcer parten får adgang til.

Med denne grundviden er vi klar til at gå dybere ned i nuancerne i Salesforces sikkerhed i de kommende artikler. Hold øje med en endnu mere detaljeret gennemgang af hver af de dele, der er nævnt ovenfor.

Tak fordi du læste med, jeg håber, du fik noget ud af det. Gå ikke glip af næste afsnit med flere indsigter i sikkerheden i Salesforce.

Hold øje

Tag hul på din rejse med Salesforce Identity med selvtillid! For flere indsigter og tips, hold øje her på www.SteveTechArc.com og på YouTube-kanalen @SteveTechArc (opens in a new tab). Abonnér, og styrk din forståelse af Salesforce Identity.

Vi hjælper med at forandre verden ved at dele integrationsviden med andre arkitekter og med dem, der er på vej til at blive arkitekter!

Transskription med hjælp fra AI

STA 3.1