Оптимізація доступу: як в Universe вирішили запит безпеки з SSO

Усі статті, обговорення, новини про DevOps — в одному місці. Підписуйтеся на DOU | DevOps!

Усім привіт!

Я Максим, у DevOps вже чотири роки, з яких майже два роки в Universe — продуктовій IT-компанії, яка створює мобільні застосунки для iOS та розвиває власний R&D-центр. Попрацював на аутсорс і аутстафом, маю досвід роботи від малих проєктів, хостерів, VPN і новинних ресурсів до великих фінансових та медичних організацій. В Universe ми разом будуємо продуктову компанію та слідкуємо за максимальним спрощенням та оптимізацією всіх процесів в нашій структурі.

У цьому матеріалі я розповім про SSO, за допомогою якої ми автоматизували та оптимізували процеси доступу до робочих інструментів для всіх наших співробітників.

SSO (single sign on) — це система, за допомогою якої користувач переходить з одного розділу порталу в інший або з однієї системи в іншу, не пов’язану з попередньою, без повторної аутентифікації.

Цей матеріал буде корисним для DevOps-інженерів, технічних команд, CEO і CTO та для всіх команд і проєктів, які цікавляться організацією системи безпечного доступу до інструментів та ресурсів компанії.

Запит на сек’юріті

Продуктами Universe користуються 55 млн юзерів зі 180 країн світу. У компанії працює вже понад 80 співробітників, які використовують в щоденній роботі понад 100 різноманітних сервісів, до кожного з яких є окремі креди для ідентифікації.

В межах росту кампанії акаунти часто залишаються незмінними, а співробітники можуть змінюватися, виникає проблема з безпекою. SSO дозволяє автоматично керувати доступами, надавати або забирати їх. Це корисно, коли компанія активно росте та розвивається, адже спрощує процес онбордингу співробітників і забезпечує безпеку аутентифікації та авторизації.

Простими словами: це система, у якій користувач авторизується один раз, використовуючи свій ідентифікатор провайдера, і після цього отримує доступ до різних сервісів без повторної аутентифікації. Цим провайдером можуть бути Facebook або Google профіль. І спрощення зайвих регламентних робіт після звільнення співробітника. Зміна паролів або перевипуск токенів для всіх облікових записів, до яких мав доступ співробітник у процесі роботи. Такі кейси та багато іншого можна автоматизувати за допомогою SSO.

Виклики перед командою

Однією з найскладніших частин було те, що більшість інструментів для підключення ідентифікатора провайдера та створення облікового запису кожному користувачеві були доступні тільки на рівні ентерпрайз чи ентерпрайз+. Перед впровадженням SSO рекомендую провести дослідження всіх інструментів і сервісів та перевірити, на якому тарифному плані підтримується підключення власних identity provider.

У багатьох випадках для певної утиліти, якою користуються 5-6 співробітників, зазвичай створюється один обліковий запис, який усі використовують для входу. Це підвищує імовірність втрати паролів та доступів до утиліти.

А SSO-система дозволяє розв’язувати цю проблему повністю. Також вона забезпечує вищий рівень безпеки, оскільки користувачі не бачать своїх паролів і можуть себе ідентифікувати лише за логіном свого провайдера.

Для того, щоб вирішити питання доступів співробітників до різних сервісів і забезпечити секʼюрність, ми проаналізували майже всі наявні сервіси та підходи на ринку. Спочатку вибір впав на FreeIPA та Open LDAP, але розгортати та обслуговувати власні сервери не хотілося. Потім розглядали Microsoft Active Directory, але ціна для нас була занадто великою, і це трохи не підходило нам у стек. Зупинилися на сервісі Okta.

Okta — це ідентифікаційна платформа, яка надає рішення для управління доступом і безпекою в інтернет-просторі. Вона дозволяє організаціям легко керувати автентифікацією, авторизацією та управлінням обліковими записами користувачів в різноманітних додатках і сервісах.

Переваги

Основними факторами були співвідношення ціни та якості, а також зручність інтеграції в наш процес. З Okta немає потреби у вузькоспеціалізованих фахівцях, як, наприклад, для інтеграції Microsoft Active Directory або власних серверів для зберігання та налаштування Open LDAP.

Okta дозволяє працювати з обліковими записами користувачів з базовими знаннями та User friendly інтерфейс.

В Okta є багато інформації та документації. Єдиний мінус — вони досить довго відповідають на форумах, але фактично все необхідне є відкритою інформацією.

Недоліки

Щодо пробного періоду: Okta надає можливість отримати 30-денний тестовий доступ одразу. Його можна значно продовжити, спілкуючись з менеджером Okta. Це дозволяє тестувати різні рішення та перевіряти, чи вони відповідають вашим потребам. Проте є і зворотна сторона медалі: тестове середовище «помирає» після тестування і неможливо перенести налаштування в продакшн.

Ми також зіштовхнулись із цим, і це було досить прикро, тому що місяць усе налаштовували. Але після підписання контракту виявилось, що наш Dev більше не буде в доступі, і нам довелося дуже швидко переносити все на нові ендпоінти та переналаштовувати.

Від слів до дій: технічні налаштування системи

Спершу нам потрібно було побудувати грамотну систему керування доступом (RBAC). Ми взяли типовий приклад проєкту з аналітиками, бекендом, фронтендом, HR, PR, рекрутингом та іншими командами, кожна з яких мала свого ліда. Ліди власне відповідають за співробітників, які є всередині команди, за облікові записи своєї команди та керували ними. Кожен лід має право додавати або видаляти користувачів та застосунки у свою групу.

Ось вам приклад:

Після побудови грамотного RBAC постає наступний челендж: зрозуміти, як додавати туди програми. Існують три основних методи додавання: SAML, OIDC та SWA.

SAML (Security Assertion Markup Language) — це стандарт обміну даними щодо безпеки, заснований на XML, який дозволяє різним онлайн-сервісам обмінюватися інформацією щодо аутентифікації користувача.

SAML 2.0 — це версія протоколу SAML, який дозволяє провайдерам ідентифікації (Identity Providers, IdP) передавати інформацію щодо аутентифікації користувача та атрибути провайдерам послуг (Service Providers, SP). Так, користувач може увійти до системи в одного провайдера та отримати доступ до ресурсів іншого провайдера без необхідності повторного входу.

Принцип роботи SAML 2.0

Запит аутентифікації: коли користувач намагається отримати доступ до застосунку або ресурсу (постачальника послуг), цей ресурс може перенаправити запит до провайдера ідентифікації з проханням підтвердити особу користувача.

Аутентифікація: провайдер ідентифікації аутентифікує користувача. Це може бути зроблено різними способами, наприклад, за допомогою імені користувача та пароля, багатофакторної аутентифікації або інших методів.

Відповідь SAML: після успішної аутентифікації провайдер ідентифікації створює заяву SAML, яка містить інформацію про користувача та його атрибути. Ця заява потім шифрується та надсилається назад до провайдера послуг.

Обробка відповіді: постачальник послуг розшифровує заяву SAML і, якщо вона справжня та успішно пройшла перевірку, надає користувачеві доступ до ресурсу.

Одноразовий вхід (Single Sign-On, SSO): однією з ключових особливостей SAML є можливість одноразового входу. Якщо користувач вже аутентифікувався у провайдера ідентифікації, йому не потрібно повторно проходити процес аутентифікації для доступу до інших додатків або ресурсів, що підтримують SAML.



OIDC (OpenID Connect) — це ідентифікаційний шар, побудований на основі протоколу OAuth 2.0. Він дозволяє клієнтам підтверджувати особу користувача на основі аутентифікації, проведеної у провайдера OpenID, а також отримувати базову інформацію про профіль користувача.

OpenID Connect надає метод для отримання інформації про сесію користувача та інформації про профіль користувача. На відміну від SAML, OIDC базується на легшому форматі — JSON.

Принцип роботи OIDC

Запит авторизації: коли користувач намагається отримати доступ до застосунку, цей застосунок може перенаправити його на сервер аутентифікації OIDC для входу.

Аутентифікація: користувач увійшов до системи на сервері аутентифікації OIDC (якщо він ще не увійшов). Це може містити введення логіну та пароля, багатофакторну аутентифікацію або інші методи.

Токени: після успішної аутентифікації сервер надсилає додатку ID-токен (який містить інформацію про користувача) та, за потреби, access-токен (який дозволяє додатку звертатися до захищених ресурсів).

Перевірка ID-токена: застосунок може перевірити ID-токен на його актуальність і валідність, використовуючи відкритий ключ сервера аутентифікації OIDC.

Використання access токена: якщо застосунку потрібний доступ до конкретних ресурсів або даних користувача (наприклад, його електронної пошти), воно може використовувати access-токен для доступу до цих ресурсів на сервері.

Одноразовий вхід (Single Sign-On, SSO): Аналогічно до SAML, OIDC також підтримує функцію одноразового входу.



SWA (Secure Web Authentication) — це простий метод інтеграції для одноразового входу (Single Sign-On, SSO) між застосунок та провайдером ідентичності, який, в основному, емулює процедуру введення імені користувача та пароля. Зазвичай це метод автоматичного заповнення полів форми аутентифікації на вебсайтах.

Принцип роботи SWA

Збереження облікових даних: під час початкового налаштування SWA облікові дані для конкретного застосунку (зазвичай ім’я користувача та пароль) зберігаються на боці провайдера ідентичності або в застосункові SSO.

Запит аутентифікації: коли користувач намагається отримати доступ до застосунку, його браузер перенаправляється на сторінку входу цього застосунку.

Автоматичне введення: замість того, щоб користувач вводив свої облікові дані вручну, SWA автоматично заповнює форму аутентифікації, використовуючи збережені облікові дані.

Доступ до застосунку: після успішної «автоматичної» аутентифікації користувач отримує доступ до застосунку, ніби він вручну ввів свої облікові дані.

Що ж обирати

Якщо розглядати SAML та OIDC, то нічого особливого там немає. В обох ви визначаєте Okta як провайдера ідентифікації, який повністю керує обліковим записом. У разі SWA можливі різні фішки. Наприклад, коли потрібно, щоб до скриньки служби підтримки мали доступ пʼять осіб. SWA дозволяє це зробити, ніхто не бачить пароль (логін видно).

Ви можете автоматично логінити співробітника до ресурсу через Okta, це може бути пошта Google, обліковий запис в eSputnik для відправлення електронних листів, Dropbox або будь-який інший сервіс, де є логіни та паролі.

Розуміння цих трьох методів дозволяє вам ефективно використовувати їх для вашої компанії.

Ще кілька цікавих tips

З SWA пароль не завжди автоматично підставляється. Тоді є спеціальна документація, де описано, як саме Okta пояснює поле для введення логіна та пароля.

Okta має чудові плагіни для всіх браузерів. Рекомендую використовувати їх відразу. Це значно знижує поріг входу для користувачів. Усі ми знаємо, що переїзди на нові інструменти або зміни в регламенті роботи часто негативно сприймаються колективом.

З OIDC ви просто авторизуєтесь як холд провайдера, дозволяєте провіжинінг користувачів, потім схвалюєте це в тому сервісі, до якого ви його приєднуєте, і він повністю хендлить ваш обліковий запис.

Але знову ж таки: що SAML, що OIDC можливі тільки там, де сама служба дозволяє вам вибирати ідентифікаційного провайдера.

З SAML потрібно бути більш уважним. Якщо ви активуєте SAML-авторизацію в сервісі, автоматично відмикаються логіни з паролем для всіх наявних облікових записів. Відповідно в налаштуваннях потрібно вказати правило, що дозволяє авторизуватися з паролем.

Висновки

На мою думку, варто використовувати Okta. На ринку немає нічого кращого за ціну та якість, яку вона пропонує.

Важливо протестувати кожен з методів, щоб зрозуміти їхні тонкощі та переваги. Навчитися користуватися всіма доступними налаштуваннями та вивчити необхідну документацію.

Щодо термінів у нас також був цікавий кейс: ми враховували три напрями, понад 80 співробітників, які постійно додаються. У нас понад 100 сервісів. І для повної інтеграції в робочі процеси витратили три місяці.

Моя остання рекомендація — планувати SSO, якщо ваша компанія нараховує 40+ співробітників і планує подальше масштабування, або якщо тісно співпрацює з фріланс-розробниками.

👍ПодобаєтьсяСподобалось2
До обраногоВ обраному1
LinkedIn
Дозволені теги: blockquote, a, pre, code, ul, ol, li, b, i, del.
Ctrl + Enter
Дозволені теги: blockquote, a, pre, code, ul, ol, li, b, i, del.
Ctrl + Enter

Kubernetes також інтегрували з Okta?

Окта супер, а користуємося нею більш ніж для ста сервісів упродовж 8 років.

Після побудови грамотного RBAC постає наступний челендж: зрозуміти, як додавати туди програми.

Про які «програми» йде мова?

Дякую за запитання! Ми додали абсолютно всі програми та інструменти з обліковими записами, які необхідні для роботи співробітників. Починаючи від Google аккаунтів, закінчуючи Figma, Postman або Notion...

Підписатись на коментарі