Нормативный источник: пункт 3.6 Приложения 3 к Положению о порядке технической и криптографической защиты информации в информационных системах, предназначенных для обработки информации, распространение и (или) предоставление которой ограничено, утверждённому приказом Оперативно-аналитического центра при Президенте Республики Беларусь от 20 февраля 2020 г. № 66, в редакции приказа от 10 декабря 2024 г. № 259, с учётом изменений, внесённых приказом от 27 мая 2026 г. № 98 (далее – Приложение 3 к ПТКЗИ).
Смысл требования
Пункт 3.6 приложения 3 к ПТКЗИ – практический разбор требования «централизованный учёт пользователей». Пункт 3.6 требует не просто наличия учётных записей и не только установленного порядка их создания или блокировки. Его предметом является централизация управления учётными записями пользователей информационной системы. Это означает, что владелец ИС должен стремиться к такой модели, при которой управление пользователями, их статусами, группами, ролями и базовыми параметрами доступа осуществляется из единой управляемой точки либо по единому централизованному процессу.
Практический смысл требования состоит в снижении хаоса в управлении доступом. Если учётные записи создаются отдельно в операционных системах, отдельно в прикладных системах, отдельно в СУБД, отдельно на сетевом оборудовании и отдельно в СЗИ, владелец ИС быстро теряет целостное представление о том, кто имеет доступ к системе и в каком объёме. Централизованное управление позволяет связать жизненный цикл учётной записи, назначение прав, блокировку, пересмотр и контроль с единой моделью, а не с набором разрозненных ручных действий.
Формулировка требования
Приложение 3 к Положению о порядке технической и криптографической защиты информации в информационных системах, предназначенных для обработки информации, распространение и (или) предоставление которой ограничено, утверждённому приказом Оперативно-аналитического центра при Президенте Республики Беларусь от 20 февраля 2020 г. № 66, в редакции приказа от 10 декабря 2024 г. № 259, с учётом изменений, внесённых приказом от 27 мая 2026 г. № 98 (далее – Приложение 3 к ПТКЗИ), раздел «Требования по обеспечению идентификации и аутентификации», пункт 3.6: «обеспечение централизованного управления учетными записями пользователей информационной системы».
Обязательность применения
По таблице приложения 3 требование пункта 3.6 является рекомендуемым для классов 4-ин, 4-спец, 4-бг, 4-юл, 4-дсп, 3-ин и 3-спец и обязательным для классов 3-бг, 3-юл и 3-дсп. Такое распределение следует читать непосредственно по восьми колонкам таблицы: классы 4-ин и 4-спец объединены в одну колонку, как и классы 3-ин и 3-спец.
Для классов, где стоит отметка «+/–», решение о применении централизованного управления должно быть принято при проектировании и отражено в ТЗ. Если требование включено в ТЗ, его фактическая реализация проверяется при аттестации. Для классов 3-бг, 3-юл и 3-дсп требование должно быть включено и реализовано обязательно.
Чем пункт 3.6 отличается от пункта 3.4
Пункт 3.4 и пункт 3.6 часто смешивают, хотя они решают разные задачи. Пункт 3.4 требует полномочного управления жизненным циклом учётных записей: создание, активация, блокировка и уничтожение должны выполняться по установленному основанию и уполномоченными лицами. Пункт 3.6 добавляет другое требование – централизованность такого управления.
Проще говоря, пункт 3.4 отвечает на вопрос, по какому полномочному порядку управляются учётные записи. Пункт 3.6 отвечает на вопрос, насколько централизованно это управление реализовано. Можно иметь регламент создания и блокировки пользователей, но при этом вести их вручную в десятке несвязанных систем. В таком случае пункт 3.4 может быть частично закрыт, но централизованная модель по пункту 3.6 фактически отсутствует.
Что следует считать централизованным управлением
Централизованное управление не обязательно означает наличие дорогой IAM-платформы. В малой или средней инфраструктуре таким центром может быть домен, каталог, единая система заявок, единый регламент и назначенный администратор, если фактическое управление пользователями действительно не распадается на множество независимых и неучтённых локальных практик. Однако чем сложнее ИС, тем выше требования к технической централизации.
В полноценной модели централизованного управления владелец ИС должен понимать, где создаётся пользователь, как его учётная запись распространяется или используется в связанных системах, как назначаются роли, как блокируется доступ, как удаляются или выводятся из эксплуатации записи, как ведётся учёт сервисных и административных записей, и как проверяется актуальность всего перечня.
- Единый источник учётных записей. Пользователи управляются через каталог, домен, IAM, SSO или иной установленный центр управления.
- Единая логика ролей и групп. Права назначаются не произвольными локальными исключениями, а через группы, роли, профили или утверждённые шаблоны доступа.
- Единый жизненный цикл. Создание, активация, блокировка и вывод из эксплуатации выполняются по общему порядку и отражаются в одном управляемом процессе.
- Единая точка контроля. Владелец ИС может получить актуальный перечень пользователей, групп, статусов и связанных прав без ручного обхода всех компонентов.
- Управляемость исключений. Локальные, сервисные, технические и встроенные учётные записи допускаются только при наличии обоснования, владельца, ограничений и порядка пересмотра.
Если значительная часть пользователей создаётся и блокируется локально в отдельных приложениях, на серверах, в сетевом оборудовании и СЗИ без общей точки контроля, говорить о полноценном централизованном управлении нельзя.
Что следует подтвердить при проверке
При проверке пункта 3.6 оценивается, существует ли у владельца ИС управляемая централизованная модель учётных записей и соответствует ли ей фактическая настройка системы. Проверяющий будет смотреть не только на наличие домена или каталога, но и на то, действительно ли через него управляется доступ пользователей к активам ИС, приложениям и средствам защиты, либо каталог существует формально, а значимая часть доступа живёт отдельно.
- закреплена ли модель централизованного управления учётными записями в ЛПА, регламенте управления доступом, ТЗ, инструкции администратора или ином ОРД;
- определён ли основной источник учётных записей: домен, каталог, IAM, SSO, система заявок или иной установленный механизм;
- охватывает ли централизованное управление основные активы ИС, прикладные системы, административные интерфейсы и СЗИ;
- понятно ли, какие учётные записи остаются локальными и почему;
- есть ли перечень исключений: встроенные, сервисные, аварийные, локальные и технические записи;
- можно ли быстро выгрузить актуальный перечень пользователей, групп, ролей и статусов;
- связаны ли операции создания, блокировки и удаления с заявками, кадровыми событиями или иными полномочными основаниями;
- проводится ли периодическая сверка локальных учётных записей с централизованной моделью.
Слабая позиция при проверке – наличие домена только для рабочих станций, при том что приложения, СУБД, сетевое оборудование, СЗИ и административные консоли имеют собственные несогласованные списки пользователей. В такой ситуации централизованность управления носит частичный характер и должна быть либо устранена, либо честно описана с обоснованием и компенсирующими мерами.
Варианты реализации
Организационная централизация.
Владелец ИС устанавливает единый порядок управления учётными записями, единый журнал заявок, единый перечень пользователей и единых ответственных лиц. Фактическое создание записей может выполняться вручную в отдельных системах, но только на основании единого процесса. Такой подход допустим для небольшой ИС или для случаев, когда техническая интеграция невозможна, но он требует дисциплины и регулярной сверки. Для классов 3-* такая модель без технической централизации обычно будет выглядеть слабее и потребует более серьёзного обоснования.
Техническая централизация через каталог или домен.
Учётные записи управляются через Active Directory, LDAP, FreeIPA или иной каталог, а приложения и сервисы по возможности используют этот источник для аутентификации и назначения групп. Это наиболее распространённый вариант для корпоративной инфраструктуры. Его преимущество – понятность, управляемость и простота проверки. Ограничение – не все приложения, СЗИ и устройства поддерживают интеграцию с каталогом, поэтому остающиеся локальные записи необходимо учитывать отдельно.
Централизация через IAM/SSO.
Для нескольких приложений, веб-сервисов и распределённых сред целесообразно использовать IAM или SSO-платформу. Она позволяет унифицировать вход, управление пользователями, роли, группы, интеграцию с каталогом и дополнительные механизмы защиты. Такой вариант особенно полезен, если в ИС много прикладных компонентов и пользователей с разными ролями.
Комбинированная модель.
Наиболее реалистичный вариант для большинства организаций. Основная масса пользователей управляется через домен, каталог или IAM, приложения интегрируются с централизованной моделью по возможности, а локальные и сервисные записи выделяются в отдельный реестр исключений. Эта модель признаёт технические ограничения, но не допускает неучтённого локального хаоса.
Что закрепить в ТЗ, ЛПА и ОРД
Приложение 3 к Положению содержит перечень требований, подлежащих включению в техническое задание на создание системы защиты информации. Поэтому в ТЗ необходимо зафиксировать требуемый результат и границы его применения, а в ЛПА и ОРД – порядок эксплуатации, роли, ответственность и подтверждающие процедуры.
- основной источник управления учётными записями пользователей ИС;
- перечень систем, приложений и средств защиты, интегрированных с централизованной моделью;
- порядок создания, изменения, блокировки и удаления пользователей в централизованной системе;
- правила назначения групп, ролей и профилей доступа;
- перечень допустимых локальных, сервисных, встроенных и аварийных учётных записей;
- порядок согласования и учёта исключений из централизованной модели;
- периодичность сверки локальных учётных записей с централизованным перечнем;
- порядок выгрузки и хранения перечня активных пользователей и групп;
- ответственных лиц за сопровождение централизованной модели;
- порядок действий при выявлении неучтённых или неактуальных записей.
Отдельно желательно описать границы применимости централизованной модели. Если часть СЗИ, сетевого оборудования или приложений технически не поддерживает интеграцию с каталогом или IAM, это не нужно скрывать. Такие случаи следует оформлять как исключения с отдельным порядком контроля.
Техническая реализация и инструменты
Техническая реализация пункта 3.6 зависит от состава ИС, числа пользователей, прикладной архитектуры и наличия интеграции между компонентами. В отличие от пунктов, где достаточно локальной настройки, здесь важен именно центр управления или единый управляемый процесс.
- Active Directory. Наиболее распространённая основа централизованного управления учётными записями в Windows-инфраструктуре. Позволяет управлять пользователями, группами, политиками, блокировкой и жизненным циклом доступа.
- LDAP / OpenLDAP / FreeIPA. Используются в Linux/Unix-средах и смешанной инфраструктуре. Позволяют централизовать идентификацию, группы и базовые параметры пользователей.
- Microsoft Entra ID. Подходит для облачных и гибридных сред, где требуется централизованное управление пользователями, приложениями, группами и политиками доступа.
- Keycloak. Практичный вариант для централизованной аутентификации и управления пользователями веб-приложений, особенно в средах с собственной разработкой и несколькими сервисами.
- IAM/IGA-платформы. Применяются в крупных организациях для управления жизненным циклом пользователей, согласования заявок, аттестации прав и интеграции с кадровыми системами.
- RADIUS / TACACS+. Используются для подключения сетевого оборудования, VPN, Wi-Fi и административного доступа к централизованной модели аутентификации и управления.
- ITSM / Helpdesk-системы. Не являются каталогом, но помогают централизовать процесс заявок на создание, изменение, блокировку и удаление учётных записей, особенно если часть операций остаётся ручной.
- HR-интеграция. Связка с кадровыми событиями позволяет автоматизировать создание, изменение и блокировку пользователей при приёме, переводе и увольнении.
- Скрипты и средства автоматизации. PowerShell, Bash, Ansible и аналогичные средства позволяют выгружать перечни пользователей, выявлять локальные исключения и сверять фактическое состояние с централизованной моделью.
Наличие одного из этих инструментов само по себе не означает исполнения требования. Централизованное управление подтверждается не названием продукта, а тем, что учётные записи действительно создаются, изменяются, блокируются и контролируются через единый центр либо через единый воспроизводимый процесс.
Типичные ошибки при реализации
- наличие домена ошибочно считается достаточным, хотя приложения, СУБД и СЗИ используют отдельные локальные списки пользователей;
- локальные учётные записи на серверах и сетевом оборудовании не учтены и не пересматриваются;
- сервисные и технические учётные записи не включены в общую модель управления;
- пользователи создаются централизованно, но права назначаются вручную и несогласованно в каждом приложении;
- отсутствует перечень исключений из централизованной модели;
- блокировка пользователя в домене не приводит к прекращению доступа в отдельных приложениях;
- не проводится сверка локальных пользователей с централизованным каталогом;
- централизованное управление описано в документах, но фактическая эксплуатация продолжает выполняться по неформальным просьбам;
- администраторы имеют возможность создавать локальные учётные записи без согласования и последующего контроля.
Вывод
Пункт 3.6 следует рассматривать как требование к архитектуре управления учётными записями. Его нельзя закрыть одной фразой о наличии администратора или тем, что пользователи заведены в домене. Важно показать, что управление действительно централизовано: есть основной источник пользователей, единая логика ролей и групп, порядок исключений, контроль локальных записей и возможность получить актуальное состояние учётных записей ИС.
Для небольшой изолированной ИС, где требование носит рекомендательный характер, допустима организационная централизация с единым реестром и строгим регламентом. Для ИС классов 3-* предпочтительна техническая или комбинированная модель на основе каталога, домена, IAM/SSO или иной централизованной платформы. Требование считается исполненным тогда, когда владелец ИС способен доказать, что учётные записи пользователей управляются не разрозненно, а через установленный и контролируемый центр управления либо единый полномочный процесс.