Нормативный источник: пункт 3.7 Приложения 3 к Положению о порядке технической и криптографической защиты информации в информационных системах, предназначенных для обработки информации, распространение и (или) предоставление которой ограничено, утверждённому приказом Оперативно-аналитического центра при Президенте Республики Беларусь от 20 февраля 2020 г. № 66, в редакции приказа от 10 декабря 2024 г. № 259, с учётом изменений, внесённых приказом от 27 мая 2026 г. № 98 (далее – Приложение 3 к ПТКЗИ).
Смысл требования
Пункт 3.7 приложения 3 к ПТКЗИ – практический разбор требования «блокировка сеансов». Пункт 3.7 устанавливает требование к автоматическому и ручному прекращению открытого пользовательского сеанса при отсутствии активности либо по инициативе самого пользователя. Его смысл состоит в том, что доступ к активам информационной системы и средствам защиты информации не должен оставаться открытым, если пользователь фактически перестал работать с системой, отошёл от рабочего места, оставил активную сессию удалённого доступа или завершил выполнение задачи без выхода из системы.
Практически требование направлено на снижение риска использования уже открытого сеанса посторонним лицом. Даже корректная идентификация и аутентификация теряют защитный смысл, если после входа пользователь может оставить активную сессию без ограничений. Поэтому владелец ИС должен установить время неактивности, после которого доступ блокируется, а также обеспечить возможность блокировки по запросу пользователя: например, через блокировку рабочей станции, выход из приложения, завершение сессии или блокировку административного интерфейса.
Формулировка требования
Приложение 3 к Положению о порядке технической и криптографической защиты информации в информационных системах, предназначенных для обработки информации, распространение и (или) предоставление которой ограничено, утверждённому приказом Оперативно-аналитического центра при Президенте Республики Беларусь от 20 февраля 2020 г. № 66, в редакции приказа от 10 декабря 2024 г. № 259, с учётом изменений, внесённых приказом от 27 мая 2026 г. № 98 (далее – Приложение 3 к ПТКЗИ), раздел «Требования по обеспечению идентификации и аутентификации», пункт 3.7: «обеспечение блокировки доступа к активам информационной системы, средствам защиты информации после истечения установленного времени бездействия (неактивности) пользователя информационной системы или по его запросу».
Обязательность применения
По таблице приложения 3 требование пункта 3.7 является обязательным для всех классов типовых ИС: 4-ин, 4-спец, 4-бг, 4-юл, 4-дсп, 3-ин, 3-спец, 3-бг, 3-юл, 3-дсп. Рекомендательного режима применения для данного требования не предусмотрено.
Приказ не устанавливает единое значение времени неактивности. Это означает, что конкретный интервал должен быть определён владельцем ИС самостоятельно с учётом характера системы, условий эксплуатации, категорий пользователей, удалённого доступа, административных функций и рисков несанкционированного использования открытого сеанса. Важно не просто выбрать число, а закрепить его в документах и реализовать технически в соответствующих точках доступа.
Что именно должно блокироваться
Распространённая ошибка – считать, что пункт 3.7 закрывается только блокировкой экрана Windows. Это лишь один из возможных элементов реализации. Формулировка требования шире: блокироваться должен доступ к активам ИС и средствам защиты информации. Следовательно, необходимо учитывать все значимые точки, где пользовательская или административная сессия может остаться активной.
- Рабочие станции и административные АРМ. Должна быть настроена автоматическая блокировка экрана или сеанса после установленного периода бездействия.
- Серверные и терминальные сессии. RDP, SSH, VDI и терминальный доступ должны иметь ограничения по неактивности, особенно для административных подключений.
- Прикладные системы. Веб-приложения, клиент-серверные приложения и административные панели должны завершать или блокировать пользовательскую сессию после установленного периода бездействия.
- VPN и удалённый доступ. Должны применяться тайм-ауты неактивности и ограничения длительности сессии, если это поддерживается используемыми средствами.
- СЗИ и административные консоли. Консоли межсетевых экранов, антивирусных систем, SIEM, СЗИ от НСД, средств резервного копирования и иных защитных компонентов должны иметь собственные настройки блокировки или завершения сессии.
- Сетевое и телекоммуникационное оборудование. Консольный, SSH, web и иной административный доступ к оборудованию должен завершаться либо блокироваться при неактивности администратора.
Практический критерий простой: если пользователь или администратор может оставить активную сессию, через которую можно получить доступ к данным, настройкам, сервисам или СЗИ, для такой сессии должен быть установлен и технически реализован механизм блокировки или завершения при неактивности.
Что следует подтвердить при проверке
При проверке пункта 3.7 оценивается наличие установленного и фактически реализованного режима блокировки доступа. Проверяющий смотрит, определил ли владелец ИС допустимое время неактивности, в каких документах оно закреплено, для каких категорий пользователей и систем оно применяется, а также можно ли подтвердить фактическую настройку на рабочих станциях, серверах, приложениях, СЗИ и средствах удалённого доступа.
- закреплено ли время неактивности в ЛПА, регламенте управления доступом, инструкции пользователя, инструкции администратора или эксплуатационном регламенте;
- определён ли порядок блокировки по запросу пользователя, а не только автоматическая блокировка;
- охвачены ли требованием рабочие станции, административные АРМ, удалённые подключения, приложения, СЗИ и сетевое оборудование;
- различаются ли интервалы неактивности для обычного пользовательского доступа, административного доступа и удалённого доступа, если это необходимо;
- реализованы ли настройки технически: через политики ОС, параметры приложений, настройки VPN, RDP, SSH, web-консолей и СЗИ;
- можно ли показать фактические параметры тайм-аутов, групповые политики, конфигурации приложений, настройки оборудования или скриншоты административных интерфейсов;
- не существуют ли исключения, при которых сессии остаются открытыми бессрочно без обоснования и контроля.
Слабой реализацией будет ситуация, когда блокировка настроена только на рабочих станциях пользователей, но административные сессии к серверам, СЗИ, сетевому оборудованию и приложениям остаются активными без ограничения. Именно такие исключения часто создают основной риск.
Варианты реализации
Организационный вариант.
Владелец ИС утверждает правило блокировки доступа после установленного времени бездействия и обязанность пользователя самостоятельно блокировать сеанс при оставлении рабочего места или завершении работы. Такой вариант необходим как нормативная основа, но сам по себе не является достаточным для полноценного исполнения требования, если не поддержан техническими настройками. Пользовательская дисциплина не должна быть единственным механизмом защиты активной сессии.
Технический вариант.
Блокировка или завершение сессий реализуются средствами ОС, приложений, VPN, RDP, SSH, сетевого оборудования и СЗИ. В этом варианте задаются тайм-ауты неактивности, автоматическая блокировка экрана, завершение терминальных подключений, истечение web-сессии, idle timeout для VPN и administrative timeout для сетевого оборудования. Такой подход даёт фактический результат, но должен быть согласован с документально установленным режимом.
Комбинированный вариант.
Наиболее правильный подход. Владелец ИС устанавливает в ЛПА и ОРД интервалы неактивности и порядок ручной блокировки, затем реализует соответствующие параметры технически в разных слоях системы и периодически проверяет их соблюдение. Для большинства ИС именно комбинированная модель является оптимальной, поскольку соединяет юридическую определённость, пользовательскую обязанность и техническую принудительность.
Что закрепить в ТЗ, ЛПА и ОРД
Приложение 3 к Положению содержит перечень требований, подлежащих включению в техническое задание на создание системы защиты информации. Поэтому в ТЗ необходимо зафиксировать требуемый результат и границы его применения, а в ЛПА и ОРД – порядок эксплуатации, роли, ответственность и подтверждающие процедуры.
- установленное время бездействия для автоматической блокировки или завершения сеанса;
- различные интервалы для пользовательских, административных, удалённых и прикладных сессий, если это необходимо;
- обязанность пользователя блокировать доступ по собственному запросу при оставлении рабочего места или завершении работы;
- перечень точек доступа, где должна применяться блокировка: рабочие станции, серверы, приложения, VPN, СЗИ, сетевое оборудование;
- порядок настройки и проверки параметров блокировки администраторами;
- порядок оформления исключений, если отдельный технологический процесс не допускает стандартной блокировки;
- порядок действий при выявлении активных незаблокированных сеансов или нарушении пользователем установленного режима;
- форму подтверждения выполнения требования: скриншоты настроек, выгрузки политик, конфигурации приложений, результаты проверки.
Для административного доступа желательно устанавливать более строгие параметры, чем для обычных пользовательских сессий, поскольку открытая административная сессия создаёт более высокий риск. Особенно это касается удалённого доступа, консолей СЗИ и сетевого оборудования.
Техническая реализация и инструменты
Техническая реализация пункта 3.7 обычно выполняется штатными средствами используемых платформ. Отдельный продукт нужен редко; важнее охватить все точки доступа, а не только рабочие станции пользователей.
- Групповые политики Windows. Позволяют централизованно настроить блокировку экрана, параметры заставки, требования к возобновлению работы после блокировки, а также ограничения для RDP-сессий.
- Параметры RDP и Remote Desktop Services. Используются для ограничения времени неактивных и отключённых сессий, особенно на терминальных серверах и административных подключениях.
- Linux PAM, systemd-logind, shell timeout и настройки SSH. Позволяют ограничивать неактивные консольные и SSH-сессии, а также управлять временем жизни пользовательских подключений.
- Настройки веб-приложений. В прикладных системах должны быть реализованы idle timeout, истечение web-сессии и необходимость повторной аутентификации после длительного бездействия.
- VPN-шлюзы и средства удалённого доступа. Обычно поддерживают idle timeout, session timeout и принудительное завершение неактивных подключений.
- Сетевое оборудование. Маршрутизаторы, коммутаторы, межсетевые экраны и иные устройства обычно имеют параметры exec-timeout, session timeout или аналогичные настройки для административных сессий.
- Консоли СЗИ. Антивирусные системы, SIEM, межсетевые экраны, СЗИ от НСД, средства резервного копирования и иные защитные платформы должны использовать собственные настройки автоматического выхода или блокировки административной сессии.
- MDM / EMM-платформы. Применимы для мобильных устройств, ноутбуков и корпоративных планшетов, где требуется централизованно задать блокировку экрана и параметры неактивности.
При выборе способа реализации важно не подменять требование одной настройкой. Если в домене настроена блокировка экрана, но web-приложение, VPN, SSH, RDP и консоли СЗИ не имеют тайм-аутов, требование выполнено только частично.
Типичные ошибки при реализации
- в документах указана обязанность блокировать рабочее место, но не определено установленное время неактивности;
- автоматическая блокировка настроена только на рабочих станциях, но не на серверах, приложениях, VPN и СЗИ;
- административные сессии остаются активными бессрочно;
- web-приложение не завершает сессию после длительного бездействия;
- пользователь может оставить открытый удалённый доступ без ограничения времени;
- на сетевом оборудовании не настроены тайм-ауты административных сессий;
- исключения из правила неактивности не оформлены и не обоснованы;
- фактические настройки не совпадают с параметрами, указанными в ЛПА;
- блокировка есть, но повторный доступ после неё не требует аутентификации;
- нет подтверждающих материалов: выгрузок политик, скриншотов настроек, конфигураций или результатов проверки.
Вывод
Пункт 3.7 следует рассматривать как требование к управлению активными сеансами доступа. Его нельзя закрыть только инструкцией пользователю или только одной групповой политикой для рабочих станций. Необходимо определить допустимое время неактивности, закрепить обязанность ручной блокировки по запросу пользователя и реализовать технические тайм-ауты во всех значимых точках доступа.
Для небольшой ИС может быть достаточно блокировки рабочих станций, тайм-аутов в приложении и документально закреплённого порядка. Для распределённой ИС с удалённым доступом, административными интерфейсами и СЗИ требуется более широкий подход: отдельные параметры для RDP, SSH, VPN, web-приложений, сетевого оборудования и консолей средств защиты. Требование считается исполненным тогда, когда владелец ИС может показать, что открытые пользовательские и административные сеансы не остаются доступными бессрочно, а блокируются или завершаются по установленному и технически обеспеченному правилу.