Keycloak: єдина точка входу для всіх сервісів
Поки сервісів три, саморобний вхід виглядає розумним рішенням: форма, таблиця користувачів, видача токена.
Проблема проявляється на десятому сервісі, коли облікові записи розходяться по базах, у частини співробітників доступ залишається після звільнення, а пароль доводиться змінювати в кожному застосунку окремо.
Кожна нова інтеграція — це ще один спосіб автентифікації сервісів, який потрібно підтримувати, тестувати й захищати.
Keycloak прибирає цю розгалуженість: єдиний вхід будується поверх одного провайдера ідентичності, а застосунки перестають зберігати паролі та перевіряти їх самостійно.
Сервіс отримує підписаний токен і довіряє йому — правила випуску, термін життя та склад даних описані в одному місці. Управління доступом переїжджає з коду кожного застосунку в ролі та групи, які адміністратор змінює без релізу.
Далі працює федерація: каталог співробітників підключається як джерело користувачів, зовнішні підрядники входять через корпоративний провайдер, а сервіс-сервісні звернення авторизуються машинними обліковими записами.
Користувач проходить автентифікацію один раз і потрапляє в усі системи без повторного введення пароля, а відкликання доступу спрацьовує централізовано — сесія закривається, токени перестають оновлюватися.
Розбираємо, як це розгортається: від схеми реалмів і клієнтів до відмовостійкого контуру з резервним вузлом, щоб єдиний вхід не став єдиною точкою відмови.
Що дає керована ідентифікація
Єдина точка входу знімає з команди ручну роботу, яка раніше з'їдала час на кожному новому сервісі.
Замість окремої бази користувачів і саморобної авторизації в кожному застосунку сервіс реєструється як клієнт у Keycloak — підключення нового застосунку займає години, а не дні, і не потребує писати та супроводжувати власний код автентифікації.
Ручні операції скорочуються завдяки централізації. Користувачі, групи та права живуть в одному місці: прихід співробітника, переведення між відділами, звільнення — це одна операція, яка одразу відображається в усіх підключених системах.
Відкликаємо доступ в одному місці — він зникає всюди, і не залишається «забутих» облікових записів в окремих сервісах.
Єдина політика доступу перестає бути набором домовленостей і стає виконуваним правилом. Вимоги до паролів, обов'язкова двофакторна автентифікація, термін життя сесії, обмеження за ролями — усе налаштовується один раз і застосовується однаково до всіх застосунків. Новий сервіс успадковує цю політику при підключенні, а не збирає свою.
Прозорість входів закриває цілий клас інцидентів із доступом. Кожен вхід, відмова та зміна прав фіксуються в єдиному журналі: видно, хто, коли і через який сервіс заходив, у кого залишилися активні сесії.
Під час розбору інциденту не потрібно збирати логи по десятках систем — картина збирається з одного джерела, а підозрілу сесію можна завершити примусово.
Окремо знімається ризик, який зазвичай спливає під час аудиту: розсинхрон облікових записів між системами.
Коли джерело істини одне, а підключення сервісів іде за відпрацьованим шаблоном, доступи перестають «жити своїм життям» — а це і є та сама керована ідентифікація, яку замовник отримує як результат.
Варіанти розгортання та їхні обмеження
Розгортання Keycloak рідко буває «просто підняти контейнер»: вибір майданчика визначає, хто відповідає за доступність, оновлення та юридичну чистоту зберігання облікових даних. Нижче — три схеми, між якими реально обирають на старті, та їхні обмеження.
| Варіант | Коли підходить | Обмеження |
|---|---|---|
| Керований контур на нашій стороні | Потрібен швидкий запуск, немає власної команди супроводу, допустиме розміщення поза вашим периметром | Менше контролю над мережевою ізоляцією та оновленнями; потрібне узгодження щодо даних |
| Розгортання в інфраструктурі замовника | Суворі вимоги до зберігання персональних даних, є власні потужності та чергова зміна | Оновлення та відмовостійкість — на вашій стороні; потрібен доступ для супроводу |
| Гібридна схема | Основний контур усередині периметра, а частина сервісів або зовнішніх партнерів — зовні | Складніша маршрутизація та синхронізація сесій; потрібне акуратне налаштування федерації |
Що визначає вибір
Керований контур дає передбачуваний старт: ми тримаємо кластер, реплікацію та резервні копії, ви отримуєте працюючий вхід без своєї інфраструктури. Обмеження — дані лежать поза вашим периметром, і це не завжди проходить узгодження.
Розгортання у вас — зворотний бік: повний контроль над мережею та зберіганням, але супровід, оновлення та відновлення лягає на вашу команду. Гібрид знімає частину обмежень, додаючи роботу з федерації між контурами.
Обговоримо ваші вимоги до периметра та даних — повернемося з оцінкою та планом.
Як відбувається впровадження: етапи робіт
Впровадження SSO — це не встановлення продукту, а перебудова всіх точок входу в системи. Тому починаємо з інвентаризації, а не з розгортання: поки не видно повної картини, будь-яке налаштування політик робиться навмання.
Як влаштований процес
- Аудит входів. Збираємо всі системи, куди логіняться співробітники та зовнішні користувачі: внутрішні сервіси, адмін-панелі, партнерські кабінети. Фіксуємо, де зберігаються облікові записи, які протоколи підтримуються, чи є локальні бази паролів і сервісні акаунти зі спільними credentials.
- Схема інтеграції. Визначаємо, які застосунки підключаємо за сучасними протоколами, а які потребують проксі-шару або доопрацювання. Узгоджуємо модель ролей і груп, щоб права не довелося переписувати після запуску.
- Розгортання та налаштування політик. Піднімаємо кластер з реплікацією, налаштовуємо федерацію з наявним каталогом користувачів, правила паролів, багатофакторну автентифікацію та час життя сесій. Політики описуємо декларативно — конфігурація відтворювана, а не зібрана вручну.
- Перевірка сценаріїв. Проганяємо реальні шляхи: перший вхід, скидання пароля, завершення сесії, відкликання доступу при звільненні, вхід зовнішнього підрядника з обмеженими правами. Окремо перевіряємо відмовостійкість — що відбувається при недоступності одного вузла.
- Передача в експлуатацію. Віддаємо документацію, регламенти адміністрування та інструкції для служби підтримки. Навчаємо команду замовника типових операцій: додавання застосунку, видача ролі, розбір інциденту зі входом.
Що важливо на кожному кроці
Аудит і схема інтеграції займають більше часу, ніж саме налаштування, — і саме вони визначають, чи доведеться переробляти через місяць. Перевірка сценаріїв іде до передачі, а не після: інциденти зі входом паралізують роботу швидше за будь-який інший збій.
Опишіть вашу задачу — повернемося з оцінкою та планом за етапами.
Що отримує замовник після впровадження
Вхід у систему перестає бути набором локальних облікових записів: єдина точка автентифікації обслуговує внутрішні сервіси, адмін-панелі та зовнішні кабінети партнерів. Нижче — що залишається у вашої команди після здачі, щоб підтримка й розвиток не залежали від підрядника.
- Конфігурації realm і клієнтів — експортовані у файли налаштування федерації користувачів, мапінгу ролей і груп, таймаутів сесій і оновлення токенів. Розгортаються на стенді однією командою, а не збираються заново по пам'яті.
- Схеми потоків входу — діаграми для кожного сценарію: вхід співробітника за корпоративним каталогом, зовнішнього користувача за одноразовим кодом, сервіс-акаунта за машинним токеном. Видно, де спрацьовує багатофакторна перевірка і де підключається зовнішній постачальник ідентичності.
- Політики доступу — правила видачі ролей і областей видимості, обмеження за адресами й пристроями, терміни життя сесій і умови примусового виходу. Кожне правило прив'язане до конкретної групи, а не до окремої людини.
- Регламенти супроводу — порядок додавання й блокування користувачів, ротації ключів підпису, оновлення сертифікатів і реакції на інциденти входу. Із зазначенням, хто і в який термін виконує кожен крок.
- Документація — карта інтеграцій, опис ролей та їх призначення, інструкції для служби підтримки й чек-лист діагностики типових збоїв автентифікації.
- Моніторинг і журнали — вивантаження подій входу й відмов у вашу систему збору логів, набір оповіщень на сплеск невдалих спроб і недоступність провайдера.
- Скрипти резервного копіювання й відновлення — перевірений сценарій підйому конфігурації та даних на чистому контурі із заміром часу відновлення.
Усе перелічене передається у вашому репозиторії з історією змін: правки конфігурацій проходять рев'ю, а не вносяться руками в інтерфейсі. Опишіть вашу задачу — повернемося з оцінкою та планом робіт.
Кейс: єдиний вхід для внутрішніх сервісів
До: автентифікація була розмазана по сервісах. Частина систем жила на власних таблицях користувачів, частина — на LDAP-каталозі, ще кілька — на самописних токенах.
Паролі зберігалися в трьох місцях, права видавалися вручну, а при звільненні співробітника доступ відкликали за чек-лістом, де регулярно щось забували. Підключення нового сервісу займало 3-4 тижні: узгодити схему, написати інтеграцію, протестувати сценарії входу, викотити в прод.
Після: розгорнули Keycloak як єдиний провайдер ідентифікації. Налаштували федерацію з наявним каталогом, щоб не переносити облікові записи, і підключили сервіси за стандартними протоколами — OIDC для веб-застосунків, SAML для legacy-систем, які не вміють інакше.
Ролі та групи винесли в один реєстр, а провіжинінг користувачів зав'язали на каталог: звільнення в HR-системі автоматично закриває доступи в усіх підключених сервісах.
Що змінилося в цифрах
- Час підключення нового сервісу: з 3-4 тижнів до 2-3 днів — типова інтеграція зводиться до реєстрації клієнта та налаштування редиректів.
- Звернення до підтримки щодо паролів і доступів: мінус 70% за перший квартал — скидання пароля та видача прав перейшли в самообслуговування.
- Відкликання доступу при звільненні: з кількох годин ручної роботи до автоматичного спрацювання за хвилини.
- Кількість місць зберігання паролів: з трьох до одного, з єдиною політикою складності та обов'язковою двофакторною автентифікацією для адміністративних ролей.
Чому це спрацювало
Ключове — не сам продукт, а приведена до єдиного вигляду модель доступу: одне джерело правди щодо користувачів, передбачувані ролі, стандартні протоколи замість самописних рішень.
Далі кожен новий сервіс підключається за відпрацьованим шаблоном, а не винаходить автентифікацію заново. Ми тримаємо конфігурацію в репозиторії та розкочуємо зміни через автоматизацію — стенди відтворюються один в один, включно з налаштуваннями федерації та політик.
Чим відрізняється Keycloak від саморобного входу?
Саморобний вхід майже завжди починається однаково: форма логіна, таблиця користувачів, хеш пароля, сесія в cookie.
Через півроку до цього додаються скидання пароля, підтвердження пошти, блокування після серії невдалих спроб, ролі та права, а ще вхід через корпоративний каталог і другий фактор.
Кожен пункт — окрема задача з крайовими випадками, і саме на них іде основний час, а не на саму форму входу.
Готове рішення закриває цей набір з коробки: протоколи федерації, брокеринг зовнішніх провайдерів, політики паролів, журнал подій входу, тонке налаштування прав за ролями та групами.
Наші інженери розгортають його у відмовостійкій конфігурації, підключають до вашого каталогу користувачів і налаштовують випуск та оновлення токенів. Вам не потрібно проєктувати схему зберігання секретів і продумувати, що станеться при недоступності вузла автентифікації.
Вартість підтримки — головний аргумент. Саморобний вхід непомітно обростає залежностями: зміна бібліотеки, оновлення через уразливість, доопрацювання під новий сервіс. Кожну зміну робить одна людина, і її відхід перетворює систему на чорну скриньку.
У готового рішення є спільнота, документація та передбачуваний цикл оновлень безпеки — оновлення версії не вимагає переписувати логіку входу.
Швидкість змін теж різна. Підключити новий сервіс до готового рішення — це налаштування клієнта та прав, години роботи. У саморобній схемі це правка коду, тести та викладка. Коли бізнес просить єдиний вхід для нового продукту, різниця вимірюється днями проти тижнів.
Безпека — не лише про хеші. Готове рішення роками проходить перевірки спільнотою та пентестами, а саморобний вхід уразливий рівно настільки, наскільки уважним був його автор у момент написання.
Ми не стверджуємо, що власна розробка безглузда — іноді вона виправдана вузькими вимогами. Але якщо задача — надійний вхід без постійного супроводу, готове рішення виграє за сукупною вартістю володіння.
Часті технічні сумніви
Сумніви щодо Keycloak зазвичай зводяться до чотирьох тем: сумісність із наявними застосунками, перенесення користувачів із поточної системи, поведінка під навантаженням та інтеграція з уже працюючими сервісами. Нижче — розбір кожної, з інженерного боку.
Сумісність: чи доведеться переписувати застосунки?
У більшості випадків ні. Keycloak працює за стандартними протоколами федерації ідентичності — OIDC і SAML, тому застосунки, які вже вміють автентифікацію через зовнішнього провайдера, підключаються зміною параметрів підключення, без правок коду.
Для legacy-систем без підтримки цих протоколів налаштовуємо проксі-автентифікацію або адаптер. Окремо перевіряємо сценарії: єдиний вхід, вихід з усіх сесій, оновлення токена, ролі та групи.
Міграція: як перенести наявних користувачів?
Переносимо облікові записи, хеші паролів і зв'язки ролей із поточного сховища — Active Directory, LDAP або власної бази.
Якщо формат хешів сумісний, користувачі продовжують входити зі старими паролями; якщо ні — налаштовуємо примусову зміну при першому вході, щоб не скидати всіх одразу.
Міграцію робимо поетапно: спочатку синхронізація, потім перемикання трафіку, з можливістю відкату на попередню систему до моменту повного переходу.
Навантаження: чи витримає вхід усієї компанії одночасно?
Keycloak горизонтально масштабується: кілька екземплярів за балансувальником, спільна база та розподілений кеш сесій. Ранковий пік, коли сотні співробітників входять протягом кількох хвилин, для такої схеми — штатний режим.
Кластер розносимо по зонах доступності, щоб відмова одного вузла не переривала вхід. Перед введенням в експлуатацію проганяємо навантажувальний тест на реальному профілі входів і фіксуємо запас за кількістю одночасних сесій.
Інтеграція: що з корпоративними сервісами та доступами?
Підключаємо корпоративний каталог як джерело користувачів, налаштовуємо синхронізацію груп і автоматичне відключення доступу при звільненні. Ролі з каталогу проєктуються на застосунки, тому права змінюються в одному місці.
Для зовнішніх підрядників заводимо окремий контур з обмеженим набором сервісів і строком дії облікового запису.
Опишіть ваш ландшафт — які застосунки, каталог і профіль навантаження — повернемося з оцінкою та планом міграції.
Обговоримо ваше завдання ідентифікації
Розгортання Keycloak під ключ починається з розмови, а не зі встановлення.
Нам важливо зрозуміти вашу поточну схему ідентифікації: де зберігаються облікові записи, які застосунки та сервіси потрібно підключити, чи є зовнішні підрядники та партнерські системи, яким потрібен доступ.
Від цього залежить архітектура федерації, вибір протоколів і те, як буде влаштовано відкат, якщо щось піде не за планом.
Опишіть завдання у вільній формі — повернемося з оцінкою та планом робіт. На першому дзвінку уточнимо:
- які застосунки та сервіси підключаємо і за якими протоколами (SAML, OIDC) вони вміють працювати;
- звідки мігруємо облікові записи і як переносимо паролі та групи без масового скидання;
- чи потрібна федерація із зовнішніми каталогами та корпоративними доменами;
- які вимоги до багатофакторної автентифікації та політик паролів;
- як влаштовані ролі та права: хто і до чого отримує доступ;
- чи потрібна інтеграція з наявними системами моніторингу та журналювання;
- які сценарії відмовостійкості критичні: резервний вузол, відновлення, планові оновлення;
- хто з боку замовника приймає результат і за якими критеріями.
Після дзвінка ви отримаєте план робіт з етапами, термінами та зонами відповідальності, а також схему цільової архітектури. Ми працюємо віддалено і підключаємося до вашої інфраструктури так, як зручно вашій команді безпеки. Обговоримо завдання — і повернемося з конкретною оцінкою.
