В корпоративной инфраструктуре доступ к системам редко устроен одинаково: где-то требуется MFA, где-то – только пароль; часть сервисов работает через IdP, часть – через локальную авторизацию; политики сессий тоже различаются. В такой среде злоумышленник идет по самому простому пути, и достаточно одной более слабой системы, чтобы она стала точкой входа.
Автор: Дмитрий Грудинин, владелец продуктовой линейки решений Avanpost Access
Компрометация учетной записи – один из самых частых сценариев проникновения в инфраструктуру. Даже при наличии базовых мер, включая централизованный каталог, MFA для удаленного доступа и контроль VPN, доступ остается фрагментированным: MFA работает не во всех системах, часть приложений аутентифицируется через IdP, часть – локально, повторная проверка применяется не везде, а политики сессий различаются.
После входа через один из таких сценариев пользователь получает доступ к другим системам без дополнительной проверки. Например, после подключения к VPN многие сервисы доверяют самому факту нахождения устройства в сети. Доступ в результате контролируется не централизованно, а через набор независимых механизмов.
Гетерогенность как структурный дефект
На первый взгляд проблему решает SSO: централизованный вход, MFA через IdP, единые правила доступа. Но на практике он охватывает только часть систем. Это либо современные веб-приложения (порталы, CRM, HR, облака), которые можно подключить через SAML или OIDC, либо корпоративные приложения, работающие через доменную инфраструктуру (например, Kerberos) – но только внутри сети.
Но значительная часть корпоративного ландшафта в этот контур не попадает. Это толстые клиенты (например, бухгалтерские или производственные системы), устаревшие бизнес-приложения (которые нельзя доработать), внутренние сервисы с собственной логикой авторизации, а также административные интерфейсы инфраструктурных систем (например, панели управления гипервизорами, системами мониторинга или сетевым оборудованием). Такие системы могут либо не поддерживать современные протоколы, либо делают это формально – без полноценного контроля сессий и повторной аутентификации. В результате даже после внедрения SSO в инфраструктуре остаются разные механизмы входа: часть систем работает через IdP, часть – аутентифицирует пользователя самостоятельно. Из-за этого требования к MFA, повторной проверке и времени жизни сессии применяются только к части ресурсов.
Практически это проявляется в двух вещах. Во-первых, доступ нельзя централизованно отозвать во всей инфраструктуре: отключение пользователя в IdP не закрывает вход в системы с локальной аутентификацией или активные сессии вне SSO-контура. Во-вторых, поведение сессии зависит от конкретного приложения: где-то она управляется централизованно, где-то живет до технического тайм-аута без дополнительной проверки.
Unified SSO: единая сессия и единая политика
Классические подходы к SSO, которые используются в корпоративной среде, на практике не образуют единой технологии. Под этим термином обычно понимают набор разрозненных механизмов – централизованную аутентификацию через IdP, доменную аутентификацию, интеграции по SAML или OIDC. Каждый из них решает свою задачу, и только в пределах своей технологической зоны. В результате в инфраструктуре формируется не единая модель доступа, а комбинация разных механизмов, которые внешне выглядят как SSO, но не дают единого контроля над входом и сессиями. А бизнесу нужна как раз единая модель доступа.
Подход Unified SSO строится вокруг этой идеи: доступ к системам должен идти через единую управляемую SSO-сессию пользователя, которая возникает в момент, когда он начинает работу на своем устройстве. Такой момент легко определить на практике: пользователь вошел в операционную систему, разблокировал рабочую станцию, подключился к корпоративной среде. С этого момента единая SSO-сессия взаимодействует со всеми ресурсами. При обращении к любому сервису система опирается на параметры этой сессии: как и где пользователь вошел, с какого устройства работает, не изменились ли условия доступа. В рамках этой единой управляемой сессии и принимаются решения о доступе.
Другими словами, функции контроля больше не зависят от конкретного приложения. Например:
- при доступе к новому ресурсу система может запросить повторное подтверждение входа на своей стороне и только после этого передать пользователя в приложение;
- при смене пользовательского устройства или условий доступа система автоматически требует дополнительное подтверждение;
- время жизни сессии задается централизованно и не зависит от настроек отдельных систем;
- в случае инцидента можно сразу завершить все активные сессии пользователя.
Любое приложение в схеме с Unified SSO не должно решать, достаточно ли пользователь аутентифицирован, – оно получает уже проверенную сессию и работает с ней. Для систем, которые нельзя подключить к IdP напрямую, используются промежуточные компоненты – агенты, прокси или интеграционные модули. Они выполняют аутентификацию и передают в приложение уже установленный доступ. В результате вход в системы происходит в рамках уже существующей SSO-сессии и подчиняется общим правилам.
Ключевой аспект в подходе Unified SSO заключается в том, что проверка пользователя, управление сессией и отзыв доступа выполняются централизованно. И это позволяет применять дополнительные проверки и управлять доступом одинаково для всех ресурсов – независимо от того, как конкретное приложение реализует вход.
Важно, что такая модель упрощает работу пользователя. Ему не нужно повторно вводить учетные данные в разных системах или проходить разные сценарии аутентификации. Все проверки выполняются в рамках одной сессии и по единым правилам. И это не просто удобство ради удобства. В корпоративной среде сложные и неоднородные механизмы входа почти всегда приводят к исключениям: ослаблению требований, появлению временных обходов, локальных настроек. В результате безопасность начинает работать выборочно. Единая модель сессии, напротив, позволяет применять политики последовательно, без необходимости адаптировать их под каждую систему.
Avanpost Unified SSO
Теоретическая модель единой точки контроля выглядит убедительно, а в качестве иллюстрации можно рассмотреть Avanpost Unified SSO [1] – решение, ориентированное именно на гетерогенный корпоративный ландшафт. Его архитектура строится вокруг идеи единой сессии и централизованного Policy Engine, который распространяет правила аутентификации и управления доступом на разные типы ресурсов.
Во-первых, речь идет о кросс-протокольном охвате. Помимо поддержки стандартных механизмов федерации для веб-приложений, система ориентирована на интеграцию с инфраструктурными сервисами и корпоративной средой в целом. Это позволяет включать в единый контур как современные веб-системы, так и приложения, требующие более традиционных механизмов аутентификации. Таким образом устраняется разрыв между федеративной частью ландшафта и теми системами, которые исторически существовали вне нее.
Во-вторых, существенное внимание уделяется управлению сессией. Модель единой аутентификации предполагает, что после первичного входа пользователь получает доступ к различным ресурсам в рамках контролируемой сессии, а при необходимости возможен централизованный отзыв и завершение доступа. Для эксплуатации это означает не только удобство, но и более предсказуемую реакцию на инцидент: при компрометации учетной записи или устройства администратор может прервать доступ не точечно, а на уровне всей сессии.
Третий аспект – масштабирование многофакторной аутентификации. В Avanpost Unified SSO MFA не является надстройкой над отдельным сервисом, а встроена в общий контур входа. Дополнительные факторы могут применяться в зависимости от политики и контекста – будь то тип ресурса, роль пользователя или параметры среды. Это позволяет избежать ситуации, когда усиленная аутентификация работает только на внешнем доступе, но не распространяется на внутренние сервисы.
Отдельного внимания заслуживает механизм усиленной аутентификации E-Passport [2], который привязывает сессию к конкретному пользовательскому устройству. После аутентификации на устройстве формируется криптографический идентификатор, который используется при каждом обращении к ресурсам. Это означает, что одного знания учетных данных недостаточно: попытка использовать их с другого устройства не приведет к доступу без дополнительной проверки. В результате сессия перестает быть переносимой, а риск ее перехвата и повторного использования существенно снижается.
Наконец, решение Avanpost Unified SSO изначально ориентировано на интеграцию с существующей доменной и каталоговой инфраструктурой, а не на ее замену. Это позволяет внедрять единый контур аутентификации без радикальной перестройки ИТ-ландшафта – сильный фактор для крупных организаций, где изменения архитектуры неизбежно затрагивают бизнес-процессы.
Unified SSO в подобной реализации выступает не как изолированный компонент, а как слой контроля, накрывающий разнородную среду. Он не устраняет все риски, связанные с учетными данными, но делает их управляемыми: снижает число независимых точек входа, выравнивает политики аутентификации и позволяет централизованно реагировать на инциденты. Давайте рассмотрим примеры сценариев из практики.
Сценарий 1. VPN с MFA не контролирует вход в приложения
MFA на VPN закрывает только первичную аутентификацию на сетевом уровне: после подключения пользователь получает доступ к ресурсам, которые аутентифицируются локально или доверяют внутреннему сегменту. Unified SSO переносит контроль на уровень приложений и сервисов: первичный вход формирует единую корпоративную SSO-сессию, а доступ к ресурсам выдается через единый Policy Engine с обязательной проверкой политики (MFA/контекст) и сессионных условий. При компрометации учетной записи выполняется централизованный отзыв SSO-сессии и Single Logout, что прекращает доступ к ресурсам независимо от факта наличия активного VPN-подключения.
Сценарий 2. Аутентификация в легаси-системы
Даже при наличии SSO для OIDC-/SAML-приложений в инфраструктуре почти всегда остается слой легаси: например, внутренние порталы, которые не поддерживают федерацию. Unified SSO закрывает этот класс ресурсов не модернизацией приложений, а подключением через Enterprise-механизмы (агенты/прокси/адаптеры), которые используют единую SSO-сессию и централизованную аутентификацию вместо самостоятельной формы логина в приложении. В результате доступ к легаси-ресурсу становится производным от SSO-сессии и политик, а не отдельным входом с собственными правилами.
Сценарий 3. Перехват сессии при долгоживущих токенах
В классических схемах c SSO усиленная аутентификация часто является одноразовой: после входа сессия живет длительное время, токены не переоцениваются по контексту, а компрометация куки или токена дает доступ без повторной проверки. Unified SSO вводит централизованное управление жизненным циклом сессии: задается время жизни, условия принудительной реаутентификации, правила контекстной повторной аутентификации для чувствительных действий, а также возможность мгновенного отзыва сессии и токенов. При необходимости сессия привязывается к устройству и контексту, что снижает применимость перехваченных данных аутентификации вне исходной среды.
Заключение
Unified SSO – это не только про удобство администрирования, но и про сокращение поверхности атаки. Пока в инфраструктуре сосуществуют разные механизмы аутентификации, безопасность определяется самым слабым из них. В отличие от классического веб-SSO, Unified SSO позволяет централизовать контроль входа, масштабировать MFA и управлять сессиями как единым контуром.
Дополнительную роль играет механизм E-Passport, который привязывает доступ к конкретному устройству и тем самым снижает риск использования скомпрометированных учетных данных вне исходной среды.
Такой подход по сути реализует принципы Zero Trust на уровне доступа. Факт нахождения пользовательского устройства в сети, наличие активной VPN-сессии или ранее пройденная аутентификация не считаются достаточными. Каждый доступ к ресурсу проверяется отдельно на основе текущей сессии, условий входа и требований политики.
Все описанные технические меры не отменяют необходимости других уровней защиты, но делают проникновение через учетные данные существенно более сложным и менее предсказуемым для атакующего.
Реклама: ООО «Аванпост». ИНН 7722778473. Erid: 2SDnjcbF52J