Навіщо захищати пароль, якщо можна від нього відмовитися?

Проблема, яку ми звикли вважати нормою

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

Ми настільки звикли до цієї конструкції, що майже перестали запитувати себе: а чи обов’язково все має працювати саме так?

Коли в тебе один сайт, проблема не здається суттєвою. Створив складний пароль, увімкнув двофакторну автентифікацію, налаштував обмеження кількості спроб входу — і працюєш.

Але що відбувається, коли проєктів стає десять, двадцять чи тридцять?

У моєму випадку йдеться про екосистему DigiMeld, що об’єднує понад тридцять самостійних програмних проєктів. Кожен має власну архітектуру, серверну логіку та адміністративний інтерфейс.

Відповідно, кожному потрібен механізм адміністративного доступу.

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

Це працювало.

Але в якийсь момент я замислився: чому я взагалі маю зберігати стільки адміністративних паролів? Чому мені доводиться захищати не лише сервери, а й самі засоби отримання доступу до них?

І чи можна відмовитися від цієї потреби?

Я дійшов думки, яка згодом стала основою мого рішення:

Можливо, варто захищати не постійний вхід, а саме право тимчасово отримати доступ.

А що, як звичної сторінки входу взагалі не буде?

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

Не просто сховати форму логіна.

Не перейменувати адресу.

Не замінити пароль ще складнішим паролем.

А усунути саму потребу в постійному вході за паролем.

Звісно, адміністративні інтерфейси нікуди не зникли. Вони й далі потрібні для керування застосунками.

Змінився спосіб отримання доступу до них.

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

Натомість я використовую власну систему ідентифікації та керування доступом MeldID.

Суть доволі проста: адміністративний доступ надається лише тоді, коли він справді потрібен, конкретному користувачеві та до конкретного проєкту.

Причому сам факт наявності облікового запису ще не означає права відкрити адміністративну панель.

Таке право потрібно надати окремо.

Доступ, якого не існувало хвилину тому

Мабуть, це найцікавіша частина всієї концепції.

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

Я вирішив змінити цей принцип.

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

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

Але навіть наявність такого тимчасового посилання сама собою не означає отримання доступу.

Це принциповий момент.

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

У моїй моделі посилання лише дає змогу розпочати процедуру підтвердження.

Щоб продовжити, потрібен окремий дозвіл через довірений мобільний пристрій MeldID.

Без відповідного підтвердження адміністративна сесія не створюється.

Саме тому я розглядаю тимчасове посилання не як заміну пароля, а як один з елементів процедури надання доступу.

Знати, куди звернутися, і мати право увійти — зовсім різні речі.

Телефон стає інструментом керування доступом

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

Він використовується для підтвердження дій, пов’язаних з адміністративним доступом.

Коли я хочу відкрити адміністративну панель, система запитує підтвердження через MeldID.

Я бачу відповідний запит на довіреному пристрої та підтверджую дію.

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

При цьому підтвердження пов’язане з конкретною дією, а не просто з фактом розблокування телефона.

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

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

І тут з’являється ще одна перевага: довіреними пристроями можна керувати.

Якщо пристрій більше не має використовуватися для підтвердження доступу, його статус довіреного можна відкликати.

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

Одна система — безліч незалежних проєктів

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

Я не хотів об’єднувати всі адміністративні панелі в один величезний застосунок.

Кожен сервіс DigiMeld і надалі має керувати власною логікою, налаштуваннями, користувачами й даними.

Тому я розділив два завдання.

MeldID відповідає за ідентифікацію та надання адміністративного допуску.

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

У результаті вийшла централізована модель керування доступом без потреби централізувати самі застосунки.

Крім того, права надаються окремо.

Адміністратор одного проєкту не отримує автоматично доступ до решти лише тому, що має обліковий запис MeldID.

Для кожного адміністративного напрямку можна визначити власне коло допущених користувачів.

При цьому права звичайних користувачів та адміністративні повноваження існують окремо.

Для екосистеми з десятків сервісів це виявилося особливо зручним.

Чому тимчасовий доступ подобається мені більше за постійний

Є ще один принцип, який я свідомо заклав у систему.

Адміністративний доступ не має зберігатися безстроково.

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

Щоб продовжити роботу після завершення строку, потрібна нова процедура підтвердження.

Це дає змогу не перетворювати одноразову авторизацію на постійне право.

Але самого обмеження в часі недостатньо.

Важливо мати змогу достроково припинити вже наданий доступ.

Тому в MeldID передбачене централізоване відкликання адміністративних дозволів.

Коли дозвіл відкликають, підключені проєкти отримують відповідну подію та анулюють пов’язані адміністративні сесії.

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

Можливість відкликати повноваження для мене не менш важлива, ніж можливість їх надати.

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

А що змінилося у повсякденній роботі?

Насамперед зникла потреба постійно звертатися до збережених адміністративних паролів.

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

Натомість я керую дозволами через єдиний механізм.

Вибираю потрібний проєкт, підтверджую доступ і працюю.

Коли адміністративний доступ більше не потрібен, його можна відкликати.

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

Достатньо підключити його до наявної моделі та визначити потрібні дозволи.

Звісно, це не означає, що всі ризики безпеки зникли.

Тимчасові дозволи, довірені пристрої, серверні сесії та центральна інфраструктура також потребують захисту.

Але мені більше не потрібно окремо вирішувати одне й те саме завдання керування адміністративними паролями для кожного застосунку.

І саме це було однією з моїх початкових цілей.

Хіба подібні технології вже не існують?

Звісно, існують.

Безпарольна автентифікація, керування привілейованим доступом, тимчасові дозволи та підтвердження через довірені пристрої давно відомі в індустрії інформаційної безпеки.

Такі підходи трапляються в системах Identity and Access Management, Privileged Access Management і концепціях Zero Trust.

Я не претендую на винайдення цих принципів.

Моє завдання було іншим.

Мені потрібно було створити власну інтегровану систему, яка розв’язує конкретні проблеми інфраструктури DigiMeld і дає змогу керувати адміністративним доступом до багатьох самостійних проєктів.

У результаті я об’єднав кілька відомих підходів в одну архітектуру, що відповідає моїм вимогам.

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

Іноді вона полягає в тому, щоб правильно сформулювати проблему й знайти відповідне рішення.

MeldID — не лише для адміністративних панелей

Тут варто зробити окреме уточнення.

MeldID створювався не виключно як інструмент для мого власного адміністративного доступу.

Він також надає розробникам SDK для інтеграції механізмів ідентифікації та підтвердження входу у власні застосунки.

Причому такий SDK доступний безкоштовно.

Наприклад, сторонній розробник може використовувати MeldID як додатковий рівень підтвердження авторизації користувача.

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

Користувачеві надходить запит на довірений мобільний пристрій, де він підтверджує або відхиляє спробу входу.

Це дає змогу знизити ризик несанкціонованого доступу в разі компрометації облікових даних.

Важливо розрізняти цю загальнодоступну можливість MeldID і розроблену мною модель адміністративного доступу для проєктів DigiMeld.

Вони використовують спільні принципи довіри та підтвердження дій, але розв’язують різні завдання.

Безпека — це не лише захист того, що вже існує

Робота над цією системою змусила мене по-іншому поглянути на звичні механізми автентифікації.

Ми часто намагаємося захистити те, що існує з історичних причин.

Додаємо нові перевірки, обмеження, додаткові паролі та захисні рівні.

Іноді це справді необхідно.

Але часом корисніше поставити інше запитання:

А чи обов’язково сам механізм, який ми захищаємо, має існувати в попередньому вигляді?

У моєму випадку відповідь була негативною.

Мені не була потрібна постійно доступна форма адміністративного входу.

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

Це два різні завдання.

І перехід від першого до другого змінив не лише технічну архітектуру, а й повсякденну роботу з проєктами.

Не остаточна крапка, а обраний напрямок

Сьогодні ця архітектура вже працює у значній частині екосистеми DigiMeld.

Решту проєктів поступово переводять на нову модель адміністративного доступу.

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

Окремі елементи інтерфейсу та правила керування сесіями ще можуть змінюватися.

Але основну ідею вже визначено.

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

Водночас я не вважаю власну реалізацію універсальним рішенням для всіх.

У різних організацій різні вимоги, інфраструктура, моделі загроз і способи адміністрування.

Те, що зручно й виправдано для екосистеми DigiMeld, не обов’язково буде оптимальним для іншого розробника.

Однак сам принцип тимчасового надання повноважень вартий уваги.

Замість висновку

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

І не тому, що хочу представити чергову систему як абсолютно захищену.

Абсолютної безпеки не існує.

Мені просто здається цікавою сама постановка питання.

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

Замість зберігання безлічі паролів — використовувати тимчасові дозволи.

Замість автоматичної довіри після першої авторизації — підтверджувати надання конкретних повноважень.

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

І, нарешті, замість окремого механізму входу в кожному проєкті — побудувати єдину систему керування адміністративним допуском, зберігши самостійність застосунків.

Я не стверджую, що такий підхід усуває можливість компрометації.

Він просто переносить акцент із захисту постійно наявних облікових даних на контрольоване надання та припинення повноважень.

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

Саме з цієї думки для мене почалася історія MeldID Admin Gateway.