Защо да защитаваме паролата, ако можем да се откажем от нея?

Проблемът, който сме свикнали да приемаме за нормален

Почти всяко уеб приложение има административен панел. А административният панел обикновено има адрес за вход, форма за удостоверяване, потребителско име и парола.

Толкова сме свикнали с тази конструкция, че почти спряхме да се питаме: задължително ли е всичко да работи точно така?

Когато имаш един сайт, проблемът не изглежда съществен. Създаваш сложна парола, включваш двуфакторно удостоверяване, настройваш ограничение на опитите за вход — и работиш.

Но какво се случва, когато проектите станат десет, двадесет или тридесет?

В моя случай става дума за екосистемата 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 за мен.