Журнал "Information Security/ Информационная безопасность" #1, 2026

Компрометация учетной записи – один из самых частых сценариев проникно- вения в инфраструктуру. Даже при нали- чии базовых мер, включая централизо- ванный каталог, 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-сессия взаимо- действует со всеми ресурсами. При обращении к любому сервису система опирается на параметры этой сессии: как и где пользователь вошел, с какого устройства работает, не изменились ли условия доступа. В рамках этой единой управляемой сессии и принимаются решения о доступе. Другими словами, функции контроля больше не зависят от конкретного при- ложения. Например: l при доступе к новому ресурсу система может запросить повторное подтвер- ждение входа на своей стороне и только после этого передать пользователя в приложение; l при смене пользовательского устрой- ства или условий доступа система авто- матически требует дополнительное под- тверждение; l время жизни сессии задается центра- лизованно и не зависит от настроек отдельных систем; l в случае инцидента можно сразу завершить все активные сессии пользо- вателя. Любое приложение в схеме с Unified SSO не должно решать, достаточно ли пользователь аутентифицирован, – оно получает уже проверенную сессию и работает с ней. Для систем, которые нельзя подключить к IdP напрямую, используются промежуточные компо- ненты – агенты, прокси или интегра- ционные модули. Они выполняют аутен- тификацию и передают в приложение уже установленный доступ. В результате вход в системы происходит в рамках уже существующей SSO-сессии и под- чиняется общим правилам. Ключевой аспект в подходе Unified SSO заключается в том, что проверка пользователя, управление сессией и отзыв доступа выполняются централи- зованно. И это позволяет применять дополнительные проверки и управлять доступом одинаково для всех ресурсов – независимо от того, как конкретное приложение реализует вход. 48 • ТЕХНОЛОГИИ Avanpost Unified SSO против лоскутной аутентификации корпоративной инфраструктуре доступ к системам редко устроен одинаково: где-то требуется MFA, где-то – только пароль; часть сервисов работает через IdP, часть – через локальную авториза- цию; политики сессий тоже различаются. В такой среде зло- умышленник идет по самому простому пути, и достаточно одной более слабой системы, чтобы она стала точкой входа. В Дмитрий Грудинин, владелец продуктовой линейки решений Avanpost Access Фото: Аванпост