Когда сессию похищают, недостаточно проверить только токен; нужно проверить и контекст сессии.
Session hijacking — классическая, но всё ещё критическая проблема. Когда сессионный cookie пользователя перехвачен, злоумышленник пытается перехватить сессию с тем же токеном. Если система смотрит только на наличие токена, она не проверяет, в каком контексте IP, устройства, браузера или пользователя был сгенерирован этот токен. В этом случае идентификатор сессии в одиночку становится границей безопасности.
Забытые флаги безопасности cookie — тоже распространённая слабость. Без HttpOnly клиентские скрипты могут получить доступ к cookie; без Secure ослабляется транспортный слой; без SameSite кросс-сайтовые запросы становятся более рискованными. Ожидать, что каждая команда приложения будет последовательно применять эти настройки, в крупных организациях нереалистично.
Управление timeout тоже зачастую настраивается неполно. Idle timeout определяет, как долго сессия остаётся открытой после последней активности; absolute timeout же ограничивает максимальную продолжительность жизни с момента входа, даже если пользователь активен. Особенно в финансовых, медицинских и корпоративных порталах эти два лимита должны управляться по отдельности.
Контроль одновременных сессий не решается сам собой стандартной системой cookie. Решения вроде того, со скольких устройств может входить пользователь, должен ли новый вход сбрасывать старую сессию или новый вход должен быть отклонён, требуют централизованного session store и отслеживания активных сессий. В многоузловых структурах это становится ещё более критичным.
TR7 Защита сессий объединяет эту потребность под единым policy graph: генерация session ID, флаги безопасности cookie, binding IP / IP+UA / composite, idle и absolute timeout, максимум одновременных сессий и опциональное шифрование cookie сходятся в одной модели управления.
Наш подход
TR7 применяет защиту сессий не как единственную настройку cookie, а как многослойную политику, простирающуюся от генерации к проверке и от обновления к завершению.
Слой SAM управляет генерацией cookie и session ID
SAM совместно управляет session affinity, именем cookie, источником cookie, форматом сессии и флагами безопасности. TR7 может генерировать session ID или работать с cookie, сгенерированным backend; могут использоваться форматы UUID, IP+timestamp+random, IP+random или custom.
Session binding улавливает смену контекста после входа
После открытия сессии может применяться один из режимов binding: IP, IP+UA, composite или none. При обнаружении смены контекста помечается session mismatch, и приложение может запросить повторную проверку или дополнительный контроль.
Опциональное шифрование cookie снижает риск tampering и replay
При включённом шифровании cookie на базе AES-256-CBC выбранные cookie становятся нечитаемыми на стороне клиента. Благодаря дополнительной привязке, производной из контекста IP+UA, повторное использование токена на другом клиенте затрудняется.
Атомарный session refresh на базе Redis безопасно управляет timeout
Операция session refresh выполняется атомарно с помощью Lua-функций Redis. Idle timeout может обновляться при каждой активности; absolute timeout остаётся привязан к времени входа. Контроль максимума одновременных сессий также может применяться через централизованное session state.
Возможности
Защита сессий предлагает готовые профили, опции binding, управление timeout и безопасность cookie для разных потребностей безопасности и пользовательского опыта.
Четыре встроенных policy preset обеспечивают разные профили безопасности сессий
Профиль default спроектирован для корпоративного стандартного использования с IP binding, idle timeout 8 часов и absolute timeout 7 дней. Профиль session_strict обеспечивает более строгую безопасность с IP+UA binding, idle 30 минут, absolute timeout 8 часов и одной одновременной сессией. Профиль session_relaxed подходит для длительных SaaS-сессий без binding с idle 7 дней и absolute timeout 90 дней. Профиль session_singleDevice используется в приложениях, требующих ограничения по лицензии или устройству, с IP binding и политикой одной одновременной сессии.
Формат session ID выбирается по потребности приложения и безопасности
TR7 не навязывает session ID единую фиксированную модель. Формат ipTimestampRandom обеспечивает сильный формат по умолчанию из комбинации IP, времени и random-значения; формат uuid генерирует непрозрачное значение без IP. Формат ipRandom использует IP и random-значение; формат custom позволяет оператору создать ключ сессии из заголовков, cookie или кастомных переменных. Эта гибкость обеспечивает адаптацию к разным архитектурам приложений.
Флаги безопасности cookie применяются и стандартизируются централизованно
На слое SAM HttpOnly может быть настроен как минимальный флаг безопасности. На уровне политики могут добавляться и дополнительные флаги, такие как Secure, SameSite=Strict или SameSite=Lax. Значение Max-Age cookie может быть связано с absolute timeout. Так не ожидается, что каждая команда приложения будет безошибочно делать настройки безопасности cookie по отдельности.
Источник cookie может быть выбран как TR7 или backend
Когда значение samCookieSource равно TR7, session cookie генерируется на слое ADC. Если backend продолжит генерировать собственный cookie, может использоваться cookie, исходящий от backend. В гибридной модели, если у backend есть cookie, продолжение идёт с этим значением, иначе TR7 может создать новое session-значение. Этот подход обеспечивает адаптацию и к новым приложениям, и к старым системам.
Четыре режима binding устанавливают разные балансы безопасности и мобильности
Режим ip binding сохраняет контекст исходного IP, с которого пользователь вошёл; он силён в сценариях корпоративного офиса или VPN. Режим ip+ua binding обеспечивает более строгий контроль, оценивая пару IP и User-Agent вместе. Режим composite binding может быть расширен дополнительными компонентами, такими как Accept-Language, кастомный заголовок или TLS fingerprint. Режим none ведёт себя более гибко при длительных сессиях и частой смене сети в SaaS-использовании.
Шифрование cookie AES-256-CBC работает opt-in для выбранных cookie
Шифрование cookie не считается включённым по умолчанию; это опциональная защита, активируемая для выбранных cookie. При активации применяется поток cookie_encrypt на стороне response и cookie_decrypt на стороне request. С использованием salt, padding и base64-форматирования для каждого cookie значение на стороне клиента становится бессмысленным. При неудачном decryption значение не рассматривается как доверенные данные сессии, и приложение может принять решение о повторной проверке или отклонении.
Idle и absolute timeout управляются по отдельности
sessionIdleTimeout определяет, как долго сессия остаётся действительной после последней активности. sessionAbsoluteTimeout же ограничивает максимальную продолжительность жизни сессии с момента входа и не продлевается постоянно активностью. Это разделение особенно критично в банковских, корпоративных и содержащих чувствительные данные приложениях. Пользовательский опыт и граница безопасности балансируются в одной политике.
Максимум одновременных сессий может быть ограничен на пользователя
Значением maxConcurrentSessions определяется, сколько активных сессий пользователь может иметь одновременно. При превышении лимита с помощью logout_oldest может быть сброшена самая старая сессия, или с помощью deny_new новый вход может быть отклонён. Эта структура может использоваться для лицензии одного устройства, банковской безопасности или корпоративного контроля доступа. Список активных сессий отслеживается в централизованном session state.
События жизненного цикла сессии отслеживаются как create, refresh, mismatch и logout
При входе сессия создаётся, при каждом request может выполняться idle refresh, при binding mismatch сессия помечается как подозрительная, а при logout сессия аннулируется. Этот жизненный цикл обеспечивает управление сессией не только в начале, но на протяжении всего времени использования. Потоки SIEM и audit могут генерировать сигнал безопасности из этих событий. Особенно при расследованиях захвата учётных записей история сессии важна.
В многоузловых структурах непрерывность сессии сохраняется через peer sync и Redis
Для сохранения session state на нескольких узлах TR7 могут совместно использоваться peer-синхронизация и централизованный store на базе Redis. В сценариях failover или rolling restart дизайн обеспечивает сохранение непрерывности сессии. С опциями replication и персистентности на стороне Redis устойчивость session state может быть повышена. Эта структура не позволяет защите сессий зависеть от одного узла.
Операционная глубина
Защита сессий эксплуатируется вместе с именем cookie, генерацией attribute, composite binding, audit-категориями, session store и поведением fallback timeout.
Настраиваемое имя cookie
Имя cookie по умолчанию может использоваться как TR7SID. Для каждого pool с помощью samCookieName может быть определено другое имя. Это используется для соответствия бренду, стандарту приложения или совместимости с существующей архитектурой cookie.
Генерация attribute cookie во время выполнения
При создании значения cookie attribute, такие как HttpOnly, Secure, SameSite и Max-Age, добавляются согласно настройкам политики. Эти attribute могут устанавливаться только при генерации новой сессии. Так безопасность cookie стандартизируется централизованной политикой.
Компоненты composite binding
Composite binding по умолчанию может строиться из компонентов, таких как исходный IP и User-Agent. Оператор может включить дополнительные компоненты, такие как Accept-Language, Accept-Encoding, кастомный заголовок или TLS fingerprint. Это вычисление должно выполняться на поздней стадии, после того как соответствующие переменные сгенерированы.
Audit-категории
События сессии и доступа могут логироваться с категориями, такими как whitelisted, authorized или unauthorized. Эта информация облегчает на стороне SIEM расследования захвата учётных записей, злоупотребления и несанкционированного доступа. Для каждого request контекст пользователя и сессии становится более видимым.
Redis session store
Session state AAM может храниться в Redis, а операции session refresh выполняются атомарно с помощью Lua-функций. Эта модель убирает классическую задержку базы данных из пути контроля сессии. С помощью функций Redis, таких как AOF и replication, персистентность и устойчивость могут быть повышены.
Безопасные значения fallback
Если конфигурация idle timeout отсутствует, может использоваться fallback 1 час. Если отсутствует absolute timeout, может применяться fallback-значение 24 часа. Эти значения обеспечивают безопасные предположения, предотвращающие создание бессрочной сессии при отсутствии конфигурации.
В каких сценариях применяется
Строгий binding и сессия одного устройства в банкинге
Банковское приложение может хотеть удерживать пользователя на одном устройстве и закрывать сессию при 30 минутах неактивности. Профиль session_strict применяется с политикой IP+UA binding, idle 30 минут, absolute timeout 8 часов и одной одновременной сессией. Если похищенная сессия используется в другом контексте, генерируется сигнал mismatch.
Длительная гибкая сессия в SaaS-приложении
Пользователи B2B SaaS могут хотеть доступ к одной учётной записи с ноутбука, телефона и планшета. Профиль session_relaxed сохраняет пользовательский опыт без binding с длинными значениями idle и absolute timeout. Смена IP или разнообразие устройств не порождают лишней повторной проверки.
IP binding и сессия рабочего дня в корпоративном портале
В портале сотрудника пользователь входит через сеть офиса или VPN и работает в течение рабочего дня без повторного входа. Профиль default может применяться с IP binding, idle timeout 8 часов и absolute timeout 7 дней. Если контекст IP меняется, приложение может запросить повторную проверку.
Лимит одновременных сессий для лицензии одного устройства
Премиум-приложение или лицензированный сервис может хотеть, чтобы учётная запись использовалась одновременно только на одном устройстве. Профиль session_singleDevice сбрасывает старую сессию при новом входе с max 1 concurrent session и поведением logout_oldest. Совместное использование лицензии и неконтролируемое множественное использование затрудняются.
Часто задаваемые вопросы
Что происходит при обнаружении session binding mismatch?
В чём разница между idle timeout и absolute timeout?
Включено ли шифрование cookie AES-256-CBC по умолчанию?
Входят ли защита CSRF и JWT в область этой страницы?
Что происходит при превышении лимита максимума одновременных сессий?
Как обеспечивается непрерывность сессии в многоузловой установке TR7?
Выведите безопасность сессий из кода приложения
Генерация session ID, флаги безопасности cookie, IP+UA binding, политика timeout и лимит одновременных сессий под единым policy graph. Проведём вас по живой установке с вашими собственными сервисами.