Tekoälyn kääntämä. Yhteisö ei ole vielä tarkistanut käännöstä. Lue englanniksi

Blogi · 19. syyskuuta 2023 · Steve Simpson · Identiteetti

Syväsukellus Salesforcen tietoturvaan: todennus ja valtuutus selitettyinä

Tervetuloa Salesforcen tietoturvan perusteelliseen läpikäyntiin, jonka aloitamme perusasioista: todennuksesta ja valtuutuksesta. Tämä artikkeli on ensimmäinen sarjassa, jonka tavoitteena on purkaa Salesforcen tietoturvamekanismien verkko auki.

Perusteet: todennus ja valtuutus

Todennus on prosessi, jossa varmistetaan, että osapuoli, oli se sitten käyttäjä selaimessa tai järjestelmään yhteyttä ottava kone, todella on se, joka se väittää olevansa. Valtuutus taas ratkaisee, mitä todennettu osapuoli saa tehdä Salesforcessa. Molemmat ovat ratkaisevan tärkeitä, jotta Salesforcen tietosi pysyvät turvassa ja jotta vain valtuutetut käyttäjät ja järjestelmät pääsevät niihin käsiksi.

Selaimista rajapintoihin: sisäänkäynnit

Salesforce varmistaa, että kaikki saapuva liikenne käyttää SSL:ää ja TLS:ää turvalliseen tiedonsiirtoon. (Käymme nämä käsitteet tarkemmin läpi tulevassa artikkelissa.)

Kun mietit, miten tieto tulee Salesforceen, voit ajatella kahta päätietä:

  1. Suoraan selaimen kautta, käyttäjän toimesta
  2. API-asiakassovelluksen kautta, esimerkiksi mobiilisovelluksesta tai toiselta palvelimelta

Molemmat tiet alkavat yhteydenotolla Salesforcen todennuspalvelimeen.

[caption id="" align=“alignnone” width=“1800”]Kaavio, joka näyttää eri tavat, joilla ulkoiset järjestelmät voivat käyttää Salesforce Corea Kaavio, joka näyttää eri tavat, joilla ulkoiset järjestelmät voivat käyttää Salesforce Corea [/caption]

Puretaan nämä vielä tarkemmin:

Käyttö selaimella

Ihmisille, jotka käyttävät Salesforcea selaimella:

[caption id="" align=“alignnone” width=“1840”]Todennusvirrat selaimesta Salesforceen Todennusvirrat selaimesta Salesforceen [/caption]

Tämän jälkeen valtuutusmekanismit ohjaavat pääsyä sivuille ja resursseihin.

API-asiakkaiden käyttö

Koneille, jotka yrittävät käyttää Salesforcea:

[caption id="" align=“alignnone” width=“1820”]Asiakasprosessit, jotka todentautuvat Salesforcen rajapintoihin Asiakasprosessit, jotka todentautuvat Salesforcen rajapintoihin [/caption]

OAuth-virrat: Koneet voivat saada pääsyn jollakin useista OAuth-virroista, ulkoisille verkkopalvelimille sopivasta web server -virrasta client credentials -virtaan ja moniin muihin siltä väliltä. Jokaisella on oma kulkunsa ja tarkoituksensa.

Istunnon muodostaminen: Todennuksen jälkeen Salesforcen todennuspalvelin luovuttaa istuntotunnuksen, joka antaa API-asiakkaalle pääsyn Salesforcen resursseihin.

Sitten valtuutussäännöt astuvat kuvaan.

Yhteenveto: miten kaikki sopii yhteen

Sisäänkäynnistä riippumatta, oli se selain tai API-asiakas, prosessiin kuuluu:

Siirtotason tietoturva: TLS, ja mahdollisesti lisäkerroksia, kuten sallittujen IP-osoitteiden lista ja asiakasvarmenteet, tietoturvan parantamiseksi.

Todennus: Tässä vaiheessa käyttäjä tai järjestelmä tunnistetaan. Tässä kohdassa mukaan tulevat esimerkiksi MFA tai kolmannen osapuolen IDP:t.

Istuntotunnuksen myöntäminen: Kun osapuoli on todennettu, se saa istuntotunnuksen, joka toimii passina Salesforcen resursseihin.

Valtuutus: Viimeinen este. Vaikka istuntotunnus olisi voimassa, tämä ratkaisee, mihin resursseihin osapuoli pääsee.

Näiden perustietojen pohjalta olemme valmiita sukeltamaan syvemmälle Salesforcen tietoturvan yksityiskohtiin tulevissa artikkeleissa. Pysy kuulolla, niin käymme jokaisen yllä mainitun osan läpi vielä tarkemmin.

Kiitos lukemisesta, toivottavasti sait tästä jotain irti. Älä missaa seuraavaa osaa, jossa on lisää näkökulmia Salesforcen tietoturvaan.

Pysy kuulolla

Lähde Salesforce Identity -matkallesi luottavaisin mielin! Lisää näkemyksiä ja vinkkejä löydät täältä www.SteveTechArc.com-sivustolta ja YouTube-kanavalta @SteveTechArc (opens in a new tab). Tilaa kanava ja syvennä ymmärrystäsi Salesforce Identitystä.

Autamme muuttamaan maailmaa jakamalla integraatio-osaamista muille arkkitehdeille ja kaikille, jotka ovat matkalla arkkitehdiksi!

Litterointi tekoälyn avulla

STA 3.1