Сессия не может переноситься безгранично поверх доверия, выданного при входе
Многие шлюзы проверяют пользователя один раз при входе и затем предполагают, что ему можно доверять, пока сессия не истечёт. Это предположение удобно — и дорого обходится, когда оно даёт сбой.
Cookie крадутся и повторно воспроизводятся из другой страны. Браузерная сессия пользователя угоняется, пока сессия открыта. Три администратора тихо делят одну привилегированную учётную запись. Пользователь, вошедший на доверенном устройстве, отходит и оставляет сессию открытой на ноутбуке в кафе. Ни один из этих моментов не запускает новый вход; поэтому ни один из них не ловится моделью доверия, смотрящей только на момент входа.
Другая крайность — короткая, частая повторная аутентификация — наказывает легитимных пользователей, не решая проблему; ведь время между двумя challenge'ами всё ещё остаётся окном, в котором может произойти что угодно.
Доверие, заработанное при входе, должно непрерывно переоцениваться по мере продвижения сессии — тихо, пока всё выглядит нормально, и решительно в момент, когда выглядит ненормально.
Наш подход
Сессии привязываются, отслеживаются, ограничиваются и завершаются через один движок.
У каждой сессии есть отпечаток, который должен продолжать совпадать
При входе сессия привязывается к IP пользователя, его user agent и отпечатку устройства. Каждый последующий запрос проверяется по этим привязкам. Несовпадение не игнорируется тихо — запускается поток bind-anomaly; этот поток в зависимости от политики может выполнить повторную аутентификацию, ограничение или завершение сессии.
Ресинхронизация при изменении чего-либо принуждает к свежей оценке
Когда меняется политика доступа, обновляется атрибут или растёт риск внутри сессии, AAM может запустить принудительную ресинхронизацию — контекст доверия перестраивается, политика условного доступа переоценивается, и новые правила применяются, не начиная с пользователя заново со страницы входа.
Одновременные сессии ограничены, а не безграничны
Один пользователь не может иметь неограниченное число активных сессий. Лимиты настраиваются по группе пользователей и сервису. Так привилегированная учётная запись не может тихо делиться тремя операторами, а ноутбук подрядчика не может открыться десяткам параллельных входов.
Выход закрывает не одну вкладку, а каждую дверь
Выход из одного приложения очищает сессию на шлюзе и распространяется на каждый связанный сервис. Украденные токены становятся непригодными, частичные выходы не оставляют фоновые вкладки аутентифицированными, а выход в конце дня действительно закрывает день.
Возможности
Контроли сессий, превращающие единичный вход в непрерывное доверие.
Привязка сессии — IP, user agent и отпечаток устройства должны продолжать совпадать
Каждая аутентифицированная сессия привязывается к исходному IP, user agent и отпечатку устройства, вычисленному при входе. Несовпадение по любому из этих сигналов направляет в поток bind-anomaly: повторная аутентификация согласно политике условного доступа этого сервиса, ограничение до безопасных ресурсов, завершение сессии или log-and-alert.
Принудительная ресинхронизация сессии — обнови доверие, не начиная с пользователя заново
Когда меняется политика, авторизовавшая сессию, обновляется атрибут или этого требует внешний сигнал, AAM может запустить ресинхронизацию. Контекст доверия перестраивается, политика условного доступа переоценивается, и сессия продолжается — без повтора входа пользователем или потери текущей работы.
Тайм-аут сессии по бездействию и абсолютный
Сессии завершаются двумя счётчиками: тайм-аут по бездействию, работающий когда пользователь пассивен, и абсолютный тайм-аут, работающий независимо от активности. Оба настраиваются по группе сервисов; низкорисковое intranet-приложение может оставаться открытым весь день, тогда как привилегированная административная сессия завершается после короткого окна пассивности.
Лимиты одновременных сессий на пользователя и сервис
Администраторы задают максимальное число активных сессий на пользователя, группу или сервис. Когда лимит заполнен, новый вход либо отклоняется, либо заменяет самую старую сессию, либо запрашивает явное подтверждение — предотвращая тихое совместное использование учётной записи и мгновенно выводя на свет необычные всплески входов.
Комплексный single logout между связанными сервисами
Выход из одного приложения запускает чистое завершение сессии на шлюзе, затем распространяется на каждый связанный сервис. Нет осиротевшей сессии, оставшейся активной в другой вкладке, нет всё ещё действительного токена в забытом браузере и нет частичного выхода, который пользователь счёл завершённым.
Восстановление потерянной сессии без потери текущей работы
Если сессия временно теряется — короткий сбой хранилища, принудительная ресинхронизация, краткий сетевой обрыв — пользователь попадает на страницу восстановления, повторно проверяющую идентичность и восстанавливающую контекст. Поток намеренный и поддающийся аудиту, а не тихий повторный вход; вредоносная попытка восстановления не может смешаться с нормальным трафиком.
Операционная глубина
Инфраструктура, делающая непрерывную оценку надёжной, быстрой и поддающейся аудиту.
Координированные stateless pod'ы шлюза через Redis
Состояние сессии живёт в Redis; так любой pod шлюза может подхватить любую сессию на любом шаге. Проверки привязки, триггеры ресинхронизации и подсчёты одновременных сессий остаются согласованными между pod'ами в горизонтально масштабированных развёртываниях без накладных расходов на координацию.
Журнал аудита на основе событий
Каждое событие сессии — привязка, обнаружено несовпадение, принуждена ресинхронизация, сработал тайм-аут, достигнут лимит одновременности, выход — записывает структурированную запись аудита с временной меткой, исходным IP, user agent и результатом. Сессии могут быть реконструированы из лога аудита в единую временную шкалу, а поток направляется в SIEM streaming-цель платформы.
Оркестрация step-up MFA внутри сессии
Когда сессии нужно step-up — вырос риск, пользователь достиг более чувствительного ресурса, политика этого требует — оценщик доверия делегирует действию MFA внутри политики условного доступа. Пользователь лишь завершает дополнительный фактор; сама сессия продолжается без повторного входа.
Понижение до режима только-чтение для привилегированных ресурсов
Когда доверие падает, вместо прямого завершения сессии политика может понизить её до режима только-чтение — позволяя пользователю продолжать видеть свою работу, но блокируя разрушительную операцию. Пользователь видит чёткое предупреждение; команда безопасности видит решение в потоке аудита.
В каких сценариях используется
Украденный cookie сессии
Злоумышленник, утёкший cookie сессии и повторно воспроизводящий его из другой сети и браузера, ловится по несовпадению привязки в тот момент, когда первый запрос достигает шлюза — не дожидаясь следующего входа пользователя.
Смена geo или устройства внутри сессии
Привилегированный оператор, чей исходный IP меняет страну внутри сессии, повышается до дополнительной MFA перед следующим чувствительным действием; конечная точка, вышедшая из управляемого состояния, понижается до режима только-чтение, пока устройство не вернётся к соответствию.
Тихое совместное использование учётной записи
Одна привилегированная учётная запись, тихо разделяемая тремя операторами, выводится на свет лимитом одновременных сессий и временной шкалой аудита — видна из одного запроса, без необходимости кому-либо признаваться в совместном использовании.
Доказательство соответствия на каждую сессию
Аудиты PCI-DSS, HIPAA, GDPR и ISO 27001 ищут доказательства того, что привилегированные сессии ограничены, отслеживаются и завершаются чисто. Аудит на основе событий даёт единую временную шкалу для каждой сессии; аудитор воспроизводит её без ручной реконструкции.
Часто задаваемые вопросы
По каким сигналам сопоставляется привязка сессии?
Сколько одновременных сессий может иметь пользователь одновременно?
Что происходит, если доверие падает внутри сессии?
Выход завершает одну вкладку или все связанные сессии?
Держите доверие под оценкой, а не под предположением
Один движок для привязки, времени жизни, лимитов одновременности и выхода — каждое событие сессии под аудитом. Проведём вас по живой установке на ваших собственных приложениях.