Глибоке занурення в безпеку Salesforce: автентифікація й авторизація пояснено
Ласкаво просимо на початок всебічного дослідження безпеки Salesforce, що починається з базових елементів — автентифікації й авторизації. Ця стаття — перша в серії, що має на меті розплутати павутину механізмів безпеки Salesforce.
Основи: автентифікація й авторизація
Автентифікація — процес перевірки того, що сутність — чи то користувач у браузері, чи машина, що звертається до системи, — справді та, за кого себе видає. Авторизація ж визначає, які дії автентифікованій сутності дозволено виконувати в Salesforce. І те, й інше першочергово важливе, щоб ваші дані Salesforce лишалися захищеними і щоб до них мали доступ лише уповноважені користувачі й сутності.
Від браузерів до API: розуміння точок входу
Salesforce забезпечує, щоб увесь вхідний трафік використовував SSL і TLS для захищеного транспортування даних. (Ми детально торкнемося цих термінів у наступній статті.)
Уявляючи, як дані потрапляють у Salesforce, думайте про два основні шляхи:
- Безпосередньо через браузер — користувачем
- Через клієнтський застосунок API, як-от мобільний застосунок чи інший сервер
Обидва маршрути починають свій шлях зі зв’язку із сервером автентифікації Salesforce.
[caption id="" align=“alignnone” width=“1800”]
Діаграма різних способів, якими зовнішні системи можуть звертатися до Salesforce Core [/caption]
Розберімо їх детальніше:
Доступ через браузер
Для людей, що працюють із Salesforce через браузер:
[caption id="" align=“alignnone” width=“1840”]
Потоки автентифікації з браузера в Salesforce [/caption]
- Додаткові рівні безпеки автентифікації: багатофакторна автентифікація (MFA), діапазони IP і сертифікати на боці клієнта.
- Постачальники ідентичності: Salesforce може діяти як постачальник ідентичності (IDP), щоб перевіряти справжність користувача. Після автентифікації сервер Salesforce надає токен сесії відповідному екземпляру org клієнта.
- Сторонній IDP: Замість Salesforce автентифікацію може виконувати сторонній IDP, налаштований у відносинах SSO із Salesforce. У такому разі IDP надсилає SAML-твердження (assertion) в Salesforce, який після перевірки видає токен сесії.
Далі механізми авторизації контролюють доступ до сторінок і ресурсів.
Доступ клієнтів API
Для машин, що намагаються звернутися до Salesforce:
[caption id="" align=“alignnone” width=“1820”]
Клієнтські процеси, що автентифікуються в API Salesforce [/caption]
OAuth flows: Машини можуть використати один із кількох OAuth flows, щоб отримати доступ, — від web server flow для зовнішніх вебсерверів до client credentials flow і багатьох проміжних. Кожен має власну послідовність і призначення.
Встановлення сесії: Після автентифікації сервер автентифікації Salesforce передає токен сесії, що дає клієнтові API доступ до ресурсів Salesforce.
Далі вступають у дію правила авторизації.
Підсумок: як усе поєднується
Незалежно від точки доступу — браузер чи клієнт API — процес охоплює:
Безпеку на транспортному рівні: використання TLS і, можливо, додаткових рівнів, як-от білий список IP і сертифікати на боці клієнта, для посиленого захисту.
Автентифікацію: Цей крок ідентифікує користувача чи систему. Саме тут вступають такі елементи, як MFA чи сторонні IDP.
Видачу токена сесії: Після автентифікації сутність отримує токен сесії, що діє як паспорт до ресурсів Salesforce.
Авторизацію: Останній бар’єр. Навіть із дійсним токеном сесії вона визначає, до яких ресурсів сутність може мати доступ.
Із цими базовими знаннями ми готові глибше зануритися в нюанси безпеки Salesforce у наступних статтях. Слідкуйте за ще детальнішим розглядом кожного згаданого вище компонента.
Дякую, що прочитали, і сподіваюся, це було інформативно. Не пропустіть наступну частину, щоб дізнатися більше про безпеку Salesforce.
Слідкуйте за новинами
Вирушайте в подорож Salesforce Identity впевнено! Більше думок і порад — тут, на www.SteveTechArc.com, і на YouTube-каналі @SteveTechArc (opens in a new tab). Підпишіться й поглиблюйте розуміння Salesforce Identity.
Допомагаю змінювати світ, ділячись знаннями про інтеграцію з колегами-архітекторами і тими, хто йде до архітектури!
Транскрипт оброблено за допомогою ШІ
STA 3.1