Зачем защищать пароль, если можно отказаться от него?

Проблема, которую мы привыкли считать нормой

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

Мы настолько привыкли к этой конструкции, что практически перестали задаваться вопросом: а обязательно ли всё должно работать именно так?

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

Но что происходит, когда проектов становится десять, двадцать или тридцать?

В моём случае речь идёт об экосистеме DigiMeld, объединяющей более тридцати самостоятельных программных проектов. У каждого собственная архитектура, серверная логика и административный интерфейс.

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

Долгое время я использовал вполне привычный подход: отдельные административные учётные данные, сложные пароли и их сохранение в браузере.

Это работало.

Но в какой-то момент я задумался: почему я вообще должен хранить столько административных паролей? Почему мне приходится защищать не только серверы, но и сами средства получения доступа к ним?

И нельзя ли отказаться от этой необходимости?

Сложный пароль не устраняет саму проблему

Современные средства позволяют создавать пароли с очень высокой энтропией. Правильно сгенерированный длинный случайный пароль практически невозможно подобрать прямым перебором.

Но каким бы сложным ни был пароль, его необходимо где-то хранить, а затем использовать.

Можно применять менеджеры паролей, аппаратные ключи, многофакторную аутентификацию и дополнительные ограничения. И всё это действительно повышает безопасность.

Однако остаётся сама архитектурная конструкция: существует определённый интерфейс, через который пользователь предъявляет свои учётные данные.

На него можно отправлять запросы. Его можно сканировать. Он может становиться объектом автоматизированных атак.

Можно скрыть адрес административной панели, заменить стандартный путь длинной случайной последовательностью символов или ограничить доступ по IP.

Но тогда появляется новый вопрос: где хранить этот адрес и как им пользоваться?

И самое главное — зачем сохранять постоянную точку входа, если административный доступ нужен только в определённые моменты?

Я пришёл к мысли, которая впоследствии стала основой моего решения:

Возможно, стоит защищать не постоянный вход, а само право временно получить доступ.

А что, если привычной страницы входа вообще не будет?

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

Не просто спрятать форму логина.

Не переименовать адрес.

Не заменить пароль ещё более сложным паролем.

А убрать саму необходимость постоянно существующего парольного входа.

Разумеется, административные интерфейсы никуда не исчезли. Они по-прежнему необходимы для управления приложениями.

Изменился способ получения доступа к ним.

Теперь для входа в административные панели подключённых проектов не требуется вводить сохранённый логин и пароль.

Вместо этого я использую собственную систему идентификации и управления доступом 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.