Идеальная система аутентификации создает максимум препятствий для злоумышленников и минимум — для легитимных пользователей. Но на практике приходится искать компромисс между надежностью и удобством, например, устанавливать требования к паролям по длине и сложности. Классические технологии единого входа (SSO), среди которых SAML, OIDC и Kerberos закрывают часть этих вопросов: упрощают доступ для сотрудников и централизуют аутентификацию в определенные системы, однако имеют собственные недостатки — в первую очередь, они связаны многообразием систем, используемых в реальных enterprise-инфраструктурах, длительностью сессии и других аспектах, о которых мы поговорим в статье. Меня зовут Дмитрий Грудинин, я владелец линейки продуктов Avanpost Access, и сегодня я на примере нашей технологии Avanpost Unified SSO расскажу, как решить эти проблемы.

Немного цифр
В этом году команда крупного американского телекома изучила более 22 тыс. утечек, произошедших в компаниях из 139 стран. Информацию о киберинцидентах собирали по внутренним и открытым источникам, а также от партнеров — например, судебных экспертов и брокеров, занимающихся киберстрахованием. Анализ показал, что при атаках на инфраструктуру злоумышленники чаще всего выбирали путь наименьшего сопротивления, и их главной целью становились учетные данные. Так, согласно отчету, 88% атак на веб-приложения осуществлялись с использованием украденных логинов и паролей. При этом значительная часть скомпрометированных комбинаций не отвечала даже минимальным требованиям к сложности [неудивительно, что количество успешных брутфорс-атак с перебором паролей выросло втрое по сравнению с прошлым годом].

Параллельно увеличиваются и объемы утечек учетных данных. По оценкам израильской компании Cyberint, специализирующейся на анализе киберугроз, в 2025 году их количество увеличилось на 160%. Базы с логинами и паролями появляются в сети с пугающей регулярностью. Буквально в прошлом году в открытый доступ выложили набор из 16 млрд логинов, паролей, сессионных кук и токенов, собранных разного рода инфостилерами. И даже если учесть, что в нее попали данные не первой свежести, масштабы утечки довольно внушительные.


Это всё сухие факты. Сами по себе учётные данные – это ещё не всё, потому что у многих на сегодня конечно же есть как минимум двухфакторка на критичных системах, не правда ли? Поэтому вроде бы проблема утечек выглядит не такой пугающей. Но есть нюанс.

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

Много приложений

Корпорации — активные потребители приложений, а куча приложений означает и множество учетных записей. По оценкам американской компании Okta, которая развивает облачную платформу для управления идентификацией и доступом, организации со штатом более 2 тыс. сотрудников используют порядка 230 приложений. Даже компании меньшего размера в среднем работают с 72 приложениями [а для технологических стартапов эта цифра равна 50]. Всего в Okta проанализировали анонимизированную статистику более 18 тыс. клиентов и пришли к выводу, что среднее число приложений для бизнесов всех размеров превышает 90 штук. Однако эти оценки варьируются — например, исследование Forrester показывает, что в организациях с численностью от 20 тыс. сотрудников число приложений в среднем составляет 367, а по мнению специалистов Salesforce, среднестатистическая корпорация вообще использует больше тысячи приложений.


Для закрытия всех «точек доступа» при таком количестве приложений централизованно контролируемой многофакторной аутентификацией необходимо проделать большую работу. При этом также требуется учесть, что все приложения поддерживают различные протоколы и методы интеграции, которые сильно варьирются – от локального логина и пароля и до поддержки OpenID Connect. По причине организационно-технической сложности интеграции приложений в систему аутентификации до сих пор не потеряли актуально классические атаки с украденными учётными данными.

Один из механизмов для защиты инфраструктуры — это модель нулевого доверия (Zero Trust). Ее основополагающий принцип: «Никогда не доверяй, всегда проверяй». Каждый запрос к приложению или ресурсу проходит проверку подлинности независимо от того, где находится пользователь: в офисной сети, дома или в кафе. Однако на практике получается так, что про Zero Trust слышали все, но никто не видел, поскольку с реализацией подхода возникают некоторые сложности. Во-первых, он может приводить к «избыточной аутентификации». Пользователь вынужден проходить повторные проверки при работе с операционной системой, корпоративной почтой, веб-порталами — например, Jira, Confluence, GitLab и так далее. Во-вторых, фрагментация процессов аутентификации влияет на уровень безопасности. При этом сотрудники, стремясь упростить себе жизнь, нередко используют одинаковые пароли для разных сервисов или хранят токены в небезопасных местах. В результате увеличивается количество инцидентов, возрастает нагрузка на внутренние службы поддержки и СБ.

Чтобы упростить управление доступами, сократить число точек входа и снизить риск компрометации учетных записей, бизнес использует SSO. Но здесь перед энтерпрайзом встает вопрос: на чем строить технологию единого входа? Кажется, что разработка собственной системы на базе OIDC, Kerberos и чего-нибудь ещё позволяет получить полный контроль и минимизировать зависимости — но на практике есть нюансы.

Такой разный SSO

Первая проблема, связанная с построением SSO в энтерпрайзе, касается разрозненных технологий и инфраструктурных протоколов. Например, Kerberos и NTLM [хотя здесь стоит отметить, что в Microsoft решили отключить NTLM в новых версиях Windows] используют для Windows-окружений и доменной авторизации, RADIUS (несмотря на отсутствие в протоколе понятия сессии) — для работы с сетевым оборудованием, а SAML и OpenID Connect — для подключения к веб-сервисам. Каждый протокол имеет собственную модель доверия, жизненный цикл сессии и требования к конфигурации.

Инфраструктурный SSO на базе Kerberos или NTLM эффективно работает только внутри корпоративной сети с доступным контроллером домена и не покрывает дистанционные, мобильные и гибридные рабочие сценарии.
LDAP‑аутентификация — как антипаттер — не только для SSO, но и как антипаттерн в принципе для аутентификации (читайте об этом в статье) — в целом не является SSO и создаёт при использовании обширное число точек компрометации учётных данных.
Веб‑SSO (OIDC, SAML) облегчает аутентификацию веб‑приложений, но не охватывает десктопные приложения, мобильные клиенты и SaaS‑системы вне браузера.

Также помимо «протокольных» историй нужно помнить, что в любых компаниях есть целый парк систем с локальной внутренней аутентификацией как в веб-исполнении, так и в варианте десктопного клиента, которые никакими протоколами не подключить к SSO. И там де-факто в качестве SSO выступает сам пользователь, который использует свой любимый браузер с плагинами вида: «скачать видео вк/ютуб» и «бесплатный VPN без регистрации и SMS» в связке со встроенным браузерным менеджером паролей с синхронизацией в облако.

Интеграция этих систем, как правило, оказывается за рамками классического SSO. В итоге получается, что корпоративный ландшафт как бы «сшит из лоскутов», к тому же плохо стыкуемых друг с другом. В то же время множество приложений и устройств — например, мобильные почтовые клиенты, удаленные ПК, специализированные десктопные приложения — находятся в «серой зоне» и не попадают под единое управление аутентификацией, остаются без централизованного контроля, что повышает риск утечек.

В то же время пользователи классических SSO сталкиваются с раздражением и фрустрацией. При аутентификации через TOTP, телефонные звонки или SMS коды приходится вводить вручную, что тормозит рабочие процессы. Ситуацию усугубляет проблема с доставкой push-уведомлений на Android и iOS — сообщения могут приходить с задержкой или не доходить вовсе.

Помимо разнородности приложений и «лоскутного» ИТ-ландшафта, нужно учитывать, что в корпоративных ландшафтах много legacy-приложений и систем. Один из способов связать все эти решения в единую инфраструктуру, раз уж мы пошли в «глубокую кастомизацию» — реализовать весь «кастом» на чём-то хотя бы частично готовом. И поскольку речь идет о внутренней реализации, многие в первую очередь рассматривают open source-решения — в таком случае на ум, как правило, сразу приходит KeyCloak.

Но разработка SSO на базе открытых решений требует определенной экспертизы, которой обладает далеко не каждая компания. Начиная строить корпоративную систему аутентификации на KeyCloak, мало кто задумывается о реальных затратах на эту инициативу. Как же «бесплатно» и «все же используют» может оказаться в итоге «дорого» и «долго»?

Попытка «взять KeyCloak и допилить» быстро упирается в тот факт, что KeyCloak — это IdP общего назначения, заточенный под протокол OpenID Connect. Он вполне достойно показывает себя в клиентских сервисах и внутренних решениях для разработки. Но если говорить про корпоративное использование, то по факту оказывается, что ~80% типичных enterprise-сценариев команда разработки «собственного SSO» вынуждена реализовывать с нуля. Подобные доработки обходятся значительно дороже и оказываются куда сложнее в поддержке на «долгосрок», чем покупка готового коробочного решения для корпоративной аутентификации. Передача проекта на аутсорс, на первый взгляд, частично решает проблему, но порождает другую: можно попасть в зависимость от команды, которая будет заниматься разработкой. При этом любые правки или интеграции станут затратным процессом без специалистов, строивших систему изначально.

Наконец, еще одна проблема классических SSO-решений связана с так называемыми «долгоиграющими сессиями». Ожидаемо, что многофакторная аутентификация усложняет вход не только для злоумышленников, но и для легитимных пользователей. И некоторые компании идут на компромисс с безопасностью, искусственно увеличивая срок жизни сессий. Однако злоумышленники, украв токены через XSS-атаки или с помощью вредоносного ПО, могут использовать долгоиграющую сессию в приложении и системе аутентификации для компрометации инфраструктуры. Кроме того, перехват сессий, cookies и обход механизмов MFA — это тренд, который набирал обороты весь прошлый год, и, скорее всего, продолжит усиливаться в 2026-м.

Решение

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

Unified SSO реализует адаптивные политики многофакторной аутентификации, которые корректируются в зависимости от контекста — локации, устройства, риск-параметров. Например, при входе на рабочую станцию включена строгая 2FA, а при попытке получить доступ к финансовым или административным сервисам понадобится дополнительное подтверждение — например, биометрия или аппаратный токен. Если Unified SSO обнаруживает аномалии, то автоматически завершает все сессии пользователя, блокирует доступ ко всем системам, включая удаленные рабочие столы, локализуя угрозу. При этом пользовательская сессия может завершаться как по тайм-ауту, так и при возникновении инцидента, зафиксированного внешней системой.

Классическая сессия Unified SSO от Avanpost может выглядеть следующим образом:

  • В начале рабочего дня на устройстве сотрудника выполняется полный цикл проверки MFA в соответствии с заданными политиками.

  • Далее, в приложении-аутентификаторе Avanpost Authenticator Desktop или Avanpost Authenticator Mobile создается защищенная сессия Unified SSO, которая выступает в качестве источника доверия для доступа к остальным корпоративным ресурсам.

  • При запуске десктопных или веб-приложений аутентификация осуществляется в рамках непрерывной сессии. При необходимости Unified SSO проводит дополнительную верификацию или сбрасывает текущую сессию.

  • Если сотрудник подключит в процессе аутентификации на своем устройстве E-passport — технологию установления доверия в рамках Unified SSO — то все взаимодействия будут осуществляться с использованием криптографически устойчивой двусторонней проверки доверия (подобно тому, как это реализовано в Mutual-TLS), а уровень доверия к сессии и устройству сотрудника ощутимо повысится, что позволит ускорить прохождение MFA.

  • В конце рабочего дня выполняется централизованное завершение сессий сотрудника (OpenID Connect, SAML, сеанс операционной системы, сеансы в облачных веб-приложениях и SaaS-сервисах).

Сессия имеет ограничение по времени действия, которое определяет системный администратор.

На сегодняшний день уровень зрелости российских решений по аутентификации позволяет развивать перспективные и технологичные истории. Но несмотря на кажущуюся простоту и очевидность SSO — это достаточно многогранный и разрозненный набор технологий, который требует существенной «доработки напильником» и приведения к общему знаменателю для полноценного и безопасного использования в реальных корпоративных инфраструктурах. При этом мы в компании Avanpost уже провели все необходимые RnD, проработали архитектуру и реализовали готовое решение — Unified SSO.

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