В дискуссиях об identity security много внимания уделяется аутентификации.

MFA, passwordless, Conditional Access, биометрия, FIDO2.

Всё это необходимо. Но я вижу управленческую ошибку: успешный контроль входа часто воспринимается как контроль доступа в целом.

На практике после аутентификации начинается отдельный жизненный цикл.

Приложение выдаёт session cookie или токен. Браузер сохраняет его. Сотрудник продолжает работать без повторного ввода пароля и MFA.

Если токен украден, атакующему уже не обязательно проходить вход самостоятельно. Система может принять его действия за продолжение ранее разрешённой сессии.

Именно поэтому infostealers представляют собой не просто endpoint-угрозу.

Они связывают заражённую рабочую станцию с последующим доступом к облачным приложениям, почте, CRM, системам разработки и административным интерфейсам. По данным Mandiant, украденные credentials стали вторым по частоте initial infection vector и встречались в 16% расследований M-Trends 2025. (Google Cloud)esponse-процесс нередко

выглядит так:

Изолировали устройство.

Удалили malware.

Сбросили пароль.

Закрыли инцидент.

Но смена пароля и завершение всех активных сессий — не одно и то же.

У пользователя могут оставаться access tokens, refresh tokens, cookies identity provider, независимые сессии SaaS-приложений, мобильные сессии и OAuth-разрешения.

Microsoft отдельно указывает: если приложение выпустило собственный session token, identity provider не всегда может отозвать его напрямую. Сессия может действовать до своего истечения или до повторной проверки пользователя приложением. (Microsoft Learn)что browser session должна стать самостоятельным объектом cyber risk management.

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

Отдельная тема — разделение рабочих и личных браузерных профилей.

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

Она проходит между соседними вкладками.

Поэтому browser policy должна быть частью identity architecture, а не второстепенным приложением к endpoint hardening.

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

Моя позиция:

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

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

Есть ли у вашей компании единая процедура завершения всех browser sessions после обнаружения infostealer — или каждая система будет отключаться отдельно?