Нормативный источник: пункт 3.1 Приложения 3 к Положению о порядке технической и криптографической защиты информации в информационных системах, предназначенных для обработки информации, распространение и (или) предоставление которой ограничено, утверждённому приказом Оперативно-аналитического центра при Президенте Республики Беларусь от 20 февраля 2020 г. № 66, в редакции приказа от 10 декабря 2024 г. № 259, с учётом изменений, внесённых приказом от 27 мая 2026 г. № 98 (далее – Приложение 3 к ПТКЗИ).
Смысл требования
Пункт 3.1 приложения 3 к ПТКЗИ – практический разбор требования «разграничение доступа». Пункт 3.1 устанавливает базовое требование к управлению доступом в информационной системе. Его смысл состоит в том, что пользователь не должен получать одинаковый или неограниченный доступ ко всем техническим и программным компонентам ИС. Доступ должен быть разделён по ролям, полномочиям, зонам ответственности и фактической необходимости выполнения служебных задач.
В практическом применении это требование охватывает не только прикладное программное обеспечение, где обычно есть роли пользователей, но и более широкий технический контур: рабочие станции, серверы, телекоммуникационное оборудование, системное программное обеспечение, административные интерфейсы и средства защиты информации. Если доступ к этим компонентам не разграничен, владелец ИС не может обоснованно утверждать, что пользователи действуют только в пределах предоставленных полномочий.
Формулировка требования
Приложение 3 к Положению о порядке технической и криптографической защиты информации в информационных системах, предназначенных для обработки информации, распространение и (или) предоставление которой ограничено, утверждённому приказом Оперативно-аналитического центра при Президенте Республики Беларусь от 20 февраля 2020 г. № 66, в редакции приказа от 10 декабря 2024 г. № 259, с учётом изменений, внесённых приказом от 27 мая 2026 г. № 98 (далее – Приложение 3 к ПТКЗИ), раздел «Требования по обеспечению идентификации и аутентификации», пункт 3.1: «обеспечение разграничения доступа пользователей к средствам вычислительной техники, телекоммуникационному оборудованию, системному и прикладному программному обеспечению и средствам защиты информации».
Обязательность применения
По таблице приложения 3 требование пункта 3.1 является обязательным для всех классов типовых ИС: 4-ин, 4-спец, 4-бг, 4-юл, 4-дсп, 3-ин, 3-спец, 3-бг, 3-юл, 3-дсп. Рекомендательный режим для данного требования не предусмотрен.
Это означает, что владелец ИС обязан реализовать разграничение доступа независимо от масштаба системы и состава обрабатываемой информации. Отличаться может только глубина реализации. Для небольшой ИС это может быть простая ролевая модель и локальные ограничения. Для распределённой инфраструктуры требуется более формализованная модель доступа с централизованным управлением, разделением административных ролей и контролем привилегий.
Что именно следует разграничивать
Ошибка в реализации пункта 3.1 часто возникает из-за слишком узкого понимания доступа. Владелец ИС настраивает роли в прикладной системе, но оставляет без должного внимания серверы, сетевое оборудование, консоли СЗИ, административные интерфейсы и системное программное обеспечение. Такое исполнение неполно, поскольку формулировка требования прямо охватывает несколько разных классов объектов.
- Средства вычислительной техники. Рабочие станции, серверы, виртуальные машины, терминальные серверы, административные рабочие места и иные вычислительные узлы, входящие в контур ИС.
- Телекоммуникационное оборудование. Коммутаторы, маршрутизаторы, межсетевые экраны, VPN-шлюзы, точки доступа, контроллеры и иные сетевые устройства, через которые проходит взаимодействие ИС.
- Системное программное обеспечение. Операционные системы, системные службы, доменная инфраструктура, гипервизоры, сервисы каталогов, системные консоли и административные инструменты.
- Прикладное программное обеспечение. Бизнес-приложения, веб-системы, СУБД, интерфейсы пользователей, административные панели и сервисные модули.
- Средства защиты информации. СЗИ от НСД, межсетевые экраны, средства криптографической защиты, антивирусные решения, IDS/IPS, системы журналирования, средства контроля целостности и иные защитные компоненты.
Практический критерий простой: если пользователь или администратор может войти в компонент, изменить его параметры, получить доступ к данным, управлять сервисом или влиять на защитный режим ИС, доступ к такому компоненту должен быть разграничен и управляем.
Что следует подтвердить при проверке
При проверке пункта 3.1 оценивается не только наличие учётных записей и паролей. Проверяющий смотрит, существует ли у владельца ИС понятная модель разграничения доступа и соответствует ли она фактической настройке активов. Иными словами, должны совпадать три слоя: документированная модель доступа, техническая реализация и реальные полномочия пользователей.
- закреплён ли порядок разграничения доступа в ЛПА, регламенте управления доступом, матрице доступа, инструкции администратора или ином ОРД;
- определены ли роли пользователей, администраторов, операторов, аудиторов, сервисных учётных записей и иных категорий субъектов доступа;
- существует ли матрица доступа либо иной документ, показывающий, кому и к каким объектам доступ разрешён;
- реализованы ли технические ограничения на уровне ОС, приложений, сетевого оборудования, СЗИ и административных интерфейсов;
- исключены ли общие учётные записи и неформальная передача административных полномочий;
- ограничен ли доступ к средствам защиты информации и их административным функциям;
- проводится ли пересмотр прав при изменении должности, увольнении, завершении проекта или изменении состава ИС;
- можно ли показать фактические настройки групп, ролей, ACL, профилей доступа, политик и журналов изменения прав.
Наиболее слабый вариант – когда в документах указано разграничение доступа, но в реальной системе большинство пользователей или администраторов имеет избыточные права. Не менее проблемная ситуация – когда доступ фактически ограничен, но порядок его предоставления, изменения и отзыва нигде не закреплён.
Варианты реализации
Организационный вариант.
Владелец ИС утверждает порядок управления доступом, матрицу доступа, перечень ролей и правила предоставления, изменения, временного расширения и отзыва прав. Такой вариант необходим как правовая и управленческая основа, но сам по себе не обеспечивает фактическое разграничение. Он должен быть подкреплён настройками в ОС, приложениях, сетевом оборудовании и СЗИ.
Технический вариант.
Разграничение доступа реализуется непосредственно средствами платформ: группами безопасности, ролями приложений, профилями пользователей, ACL, политиками ОС, настройками СЗИ, локальными ролями сетевого оборудования и правами в административных консолях. Такой вариант обеспечивает техническое ограничение, но без утверждённой модели доступа быстро превращается в набор отдельных настроек, которые трудно обосновать на проверке.
Комбинированный вариант.
Наиболее устойчивый подход. Сначала владелец ИС определяет роли и допустимые полномочия, затем реализует их технически, после чего периодически сверяет фактические права с утверждённой моделью. Именно такой вариант лучше всего соответствует смыслу пункта 3.1, поскольку объединяет юридически оформленное решение и проверяемую техническую реализацию.
Что закрепить в ТЗ, ЛПА и ОРД
Приложение 3 к Положению содержит перечень требований, подлежащих включению в техническое задание на создание системы защиты информации. Поэтому в ТЗ необходимо зафиксировать требуемый результат и границы его применения, а в ЛПА и ОРД – порядок эксплуатации, роли, ответственность и подтверждающие процедуры.
- перечень категорий пользователей и администраторов ИС;
- перечень объектов доступа: СВТ, телекоммуникационное оборудование, системное ПО, прикладное ПО, СЗИ;
- матрицу доступа либо иной документ, определяющий допустимые полномочия;
- порядок предоставления, изменения, временного расширения и отзыва доступа;
- порядок согласования административных и привилегированных прав;
- правила использования сервисных учётных записей;
- периодичность пересмотра прав доступа;
- порядок фиксации изменений прав и действий администраторов;
- действия при выявлении избыточных, ошибочных или несанкционированных прав.
На практике желательно, чтобы матрица доступа была не декоративным приложением, а рабочим документом, с которым сверяются фактические группы, роли и полномочия в системе.
Техническая реализация и инструменты
Техническая реализация пункта 3.1 зависит от того, какие платформы входят в состав ИС. Универсального инструмента, который сам по себе закрывает весь пункт, обычно нет. Требование реализуется совокупностью настроек доступа в разных слоях инфраструктуры.
- Active Directory / LDAP / FreeIPA. Используются для централизованного управления группами, ролями и правами доступа в доменной или каталоговой инфраструктуре. Позволяют строить доступ через группы, а не через индивидуальные исключения.
- Групповые политики Windows (GPO). Применяются для разграничения локальных прав, ограничения административных полномочий, управления доступом к рабочим станциям, серверам и системным функциям.
- RBAC в прикладных системах. Ролевая модель приложений позволяет разделять полномочия пользователей по функциям: просмотр, ввод, изменение, утверждение, администрирование, аудит.
- ACL и права файловых систем. Используются для ограничения доступа к каталогам, конфигурационным файлам, журналам, резервным копиям и служебным ресурсам.
- AAA, RADIUS, TACACS+. Применимы для сетевого оборудования и административного доступа к телекоммуникационным устройствам. Позволяют централизовать аутентификацию и разграничить команды или уровни полномочий.
- Ролевые модели в СЗИ. Консоли межсетевых экранов, антивирусных систем, SIEM, СЗИ от НСД и иных средств защиты обычно позволяют разделять роли администратора, оператора, аудитора и пользователя просмотра.
- PAM-системы. Уместны в зрелой инфраструктуре для контроля привилегированного доступа к серверам, сетевым устройствам, СЗИ и административным консолям.
- IAM / IGA-системы. Применимы в крупных организациях, где требуется централизованное управление жизненным циклом доступа, согласование заявок и регулярная аттестация прав.
При выборе инструментов важно не подменять требование продуктом. Наличие Active Directory, PAM или IAM не означает автоматического исполнения пункта 3.1. Значимым является соответствие фактических прав утверждённой модели доступа и возможность это подтвердить документально и технически.
Типичные ошибки при реализации
- разграничение доступа настроено только в прикладной системе, но не охватывает серверы, СЗИ и сетевое оборудование;
- права предоставляются персонально и вручную, без групп и ролей;
- административные полномочия выданы шире, чем требуется для выполнения служебных задач;
- используются общие учётные записи для администрирования или сопровождения;
- матрица доступа существует, но не соответствует фактическим настройкам;
- не проводится регулярный пересмотр прав после изменения должностей, увольнений и завершения проектов;
- сервисные учётные записи используются как обычные административные;
- доступ к СЗИ не разделён по ролям администратора, оператора и аудитора;
- нет журналирования изменений прав доступа и административных действий.
Вывод
Пункт 3.1 следует рассматривать как требование к управляемой модели доступа, а не как разовую настройку прав в одном приложении. Его предмет охватывает весь технический контур ИС: вычислительные средства, сетевое оборудование, системное и прикладное ПО, а также средства защиты информации.
Для небольшой ИС допустима простая ролевая модель с документально закреплёнными правами и периодическим пересмотром. Для сложной инфраструктуры необходим комбинированный подход: матрица доступа, группы и роли, техническое разграничение по слоям, контроль привилегий и регулярная сверка фактических прав с утверждённой моделью. Требование считается исполненным только тогда, когда владелец ИС способен показать не декларацию о разграничении доступа, а реальное соответствие между документами, настройками и фактическими полномочиями пользователей.