Нормативный источник: пункт 3.4 Приложения 3 к Положению о порядке технической и криптографической защиты информации в информационных системах, предназначенных для обработки информации, распространение и (или) предоставление которой ограничено, утверждённому приказом Оперативно-аналитического центра при Президенте Республики Беларусь от 20 февраля 2020 г. № 66, в редакции приказа от 10 декабря 2024 г. № 259, с учётом изменений, внесённых приказом от 27 мая 2026 г. № 98 (далее – Приложение 3 к ПТКЗИ).
Смысл требования
Пункт 3.4 приложения 3 к ПТКЗИ – практический разбор требования «управление учётными записями». Пункт 3.4 устанавливает требование к управляемому жизненному циклу учётных записей пользователей информационной системы. Его смысл состоит не только в том, чтобы в ИС существовали учётные записи, а в том, чтобы их создание, активация, блокировка и уничтожение выполнялись уполномоченно, по установленному порядку и с возможностью последующего подтверждения.
На практике это требование закрывает один из наиболее частых источников нарушений: учётные записи создаются по устной просьбе, не блокируются после увольнения, сохраняются “на всякий случай”, передаются между сотрудниками, используются без владельца или остаются активными после завершения проекта. При таком подходе идентификация и аутентификация формально есть, но управляемости учётных записей нет.
Формулировка требования
Приложение 3 к Положению о порядке технической и криптографической защиты информации в информационных системах, предназначенных для обработки информации, распространение и (или) предоставление которой ограничено, утверждённому приказом Оперативно-аналитического центра при Президенте Республики Беларусь от 20 февраля 2020 г. № 66, в редакции приказа от 10 декабря 2024 г. № 259, с учётом изменений, внесённых приказом от 27 мая 2026 г. № 98 (далее – Приложение 3 к ПТКЗИ), раздел «Требования по обеспечению идентификации и аутентификации», пункт 3.4: «обеспечение полномочного управления (создание, активация, блокировка и уничтожение) учетными записями пользователей информационной системы».
Обязательность применения
По таблице приложения 3 требование пункта 3.4 является обязательным для всех классов типовых ИС: 4-ин, 4-спец, 4-бг, 4-юл, 4-дсп, 3-ин, 3-спец, 3-бг, 3-юл, 3-дсп. Рекомендательный режим применения для этого требования не предусмотрен.
Это означает, что владелец ИС должен обеспечить управляемый порядок работы с учётными записями независимо от масштаба системы. В небольшой ИС такой порядок может быть реализован через регламент, журнал заявок и локальное администрирование. В более сложной инфраструктуре требуется централизованная модель, привязка к кадровым событиям, согласование заявок и регулярный пересмотр активных учётных записей.
Что означает полномочное управление
Термин «полномочное управление» следует понимать как управление учётными записями только теми лицами и только в том порядке, которые установлены владельцем ИС. Иными словами, администратор не должен самостоятельно решать, кому создать учётную запись, когда её активировать, какие права назначить и когда удалить. Эти действия должны выполняться на основании заявки, распоряжения, кадрового события, решения владельца процесса или иного предусмотренного основания.
Требование прямо перечисляет четыре операции: создание, активация, блокировка и уничтожение. На практике к ним неизбежно добавляются изменение реквизитов, изменение прав, временная приостановка доступа, восстановление доступа и пересмотр актуальности учётных записей. Эти действия не названы в пункте буквально, но без их регулирования жизненный цикл учётной записи остаётся неполным.
- Создание. Учётная запись создаётся на основании установленного основания: приёма сотрудника, назначения роли, подключения внешнего специалиста, создания сервисной функции или иной утверждённой необходимости.
- Активация. Учётная запись становится доступной для использования только после назначения владельца, первичных реквизитов, необходимых прав и выполнения предусмотренного согласования.
- Блокировка. Доступ прекращается при увольнении, переводе, окончании договора, выявлении инцидента, нарушении правил, длительном неиспользовании или иной предусмотренной причине.
- Уничтожение. Учётная запись удаляется или выводится из эксплуатации после истечения установленного периода, завершения всех проверок и при отсутствии необходимости сохранять её для истории аудита в активном состоянии.
Отдельного внимания требуют сервисные, технические и административные учётные записи. Они часто живут дольше обычных пользовательских записей, имеют повышенные привилегии и хуже привязаны к конкретным людям. Поэтому их жизненный цикл должен регулироваться не слабее, а строже.
Что следует подтвердить при проверке
При проверке пункта 3.4 оценивается не только наличие списка пользователей в системе. Проверяющий смотрит, существует ли установленный порядок управления учётными записями, кто имеет право инициировать и выполнять операции с ними, как эти действия согласуются, фиксируются и проверяются. Главное – показать связь между документами, заявками, кадровыми событиями и фактическим состоянием учётных записей в ИС.
- закреплён ли порядок управления учётными записями в ЛПА, регламенте управления доступом, инструкции администратора или ином ОРД;
- определены ли лица, уполномоченные инициировать создание, активацию, блокировку и уничтожение учётных записей;
- разделены ли роли инициатора, согласующего лица и администратора, выполняющего техническое действие;
- ведётся ли учёт заявок или распоряжений на создание, изменение, блокировку и удаление учётных записей;
- своевременно ли блокируются учётные записи уволенных, переведённых или утративших необходимость доступа пользователей;
- существует ли перечень активных учётных записей и проводится ли его периодический пересмотр;
- отдельно ли учитываются административные, сервисные, временные и внешние учётные записи;
- можно ли сопоставить фактические учётные записи в системе с действующими пользователями, ролями и основаниями доступа.
Наиболее проблемная ситуация – когда в системе есть активные записи без понятного владельца, без основания создания или без подтверждённой необходимости. Для проверяющего такие записи являются признаком неуправляемого доступа, даже если технически система требует пароль при входе.
Варианты реализации
Организационный вариант.
Владелец ИС утверждает регламент управления учётными записями, в котором определяет основания для создания, порядок согласования, сроки активации, случаи блокировки, порядок уничтожения и правила пересмотра. Операции выполняются администраторами на основании заявок, служебных записок, распоряжений или кадровых уведомлений. Такой вариант может применяться в небольшой ИС, но требует дисциплины и регулярной сверки фактического состояния учётных записей.
Технический вариант.
Управление учётными записями реализуется через каталог, доменную инфраструктуру, IAM/IGA-систему, систему заявок, автоматическую синхронизацию с кадровыми данными или встроенные механизмы приложений. Такой подход снижает долю ручных действий, но не отменяет необходимости утверждённого порядка. Без регламента автоматизация будет лишь быстрее создавать и блокировать записи, но не решит вопрос полномочности.
Комбинированный вариант.
Наиболее устойчивый подход. Владелец ИС документально устанавливает жизненный цикл учётных записей, а технически реализует его через управляемые группы, роли, заявки, каталоги, автоматическую блокировку и регулярную сверку активных записей. Для большинства реальных ИС именно такой вариант является оптимальным: он создаёт и юридическое основание, и технически проверяемый результат.
Что закрепить в ТЗ, ЛПА и ОРД
Приложение 3 к Положению содержит перечень требований, подлежащих включению в техническое задание на создание системы защиты информации. Поэтому в ТЗ необходимо зафиксировать требуемый результат и границы его применения, а в ЛПА и ОРД – порядок эксплуатации, роли, ответственность и подтверждающие процедуры.
- категории учётных записей: пользовательские, административные, сервисные, временные, внешние, технические;
- основания для создания и активации каждой категории учётных записей;
- перечень лиц, имеющих право инициировать создание и изменение учётных записей;
- порядок согласования заявок и назначения начальных прав;
- сроки блокировки при увольнении, переводе, завершении договора, инциденте или неактивности;
- порядок уничтожения, удаления или архивирования учётных записей;
- порядок ведения перечня активных учётных записей;
- периодичность пересмотра актуальности учётных записей;
- особый порядок управления сервисными и привилегированными учётными записями;
- порядок фиксации действий администратора при создании, активации, блокировке и уничтожении учётных записей.
Практически полезно привязать управление учётными записями к кадровым событиям: приём, перевод, отпуск с длительным отсутствием, увольнение, привлечение подрядчика, завершение договора. Если такой связи нет, блокировка и уничтожение записей почти всегда начинают выполняться с задержкой.
Техническая реализация и инструменты
Техническая реализация пункта 3.4 зависит от масштаба ИС и числа учётных записей. Для небольшой среды достаточно строгого регламента и ручного администрирования с журналом заявок. Для распределённой инфраструктуры желательно использовать централизованные и автоматизированные механизмы управления жизненным циклом.
- Active Directory / LDAP / FreeIPA. Базовые средства централизованного управления учётными записями, группами, блокировкой и удалением пользователей. Позволяют управлять доступом через группы и применять единые политики.
- Microsoft Entra ID, Keycloak, ADFS и иные IAM/SSO-решения. Применимы для централизованной идентификации и управления доступом к приложениям. Удобны, если ИС состоит из нескольких сервисов и требует единой точки управления пользователями.
- IGA-системы. Используются в крупных организациях для согласования заявок, периодической аттестации прав, управления жизненным циклом учётных записей и автоматизации контроля доступа.
- ITSM / Helpdesk-системы. Jira Service Management, GLPI, OTRS, Naumen, ServiceNow и аналогичные платформы позволяют фиксировать заявки на создание, изменение, блокировку и удаление учётных записей, а также хранить историю согласований.
- HR-интеграция. Связка с кадровой системой позволяет автоматизировать создание и блокировку учётных записей при приёме, переводе и увольнении сотрудников. Это снижает риск забытых активных записей.
- PowerShell, Bash, Ansible и иные средства автоматизации. Уместны для типовых операций создания, блокировки, выгрузки перечней пользователей и сверки активных записей с утверждёнными списками.
- PAM-системы. Применимы для управления привилегированными и административными учётными записями, особенно если необходимо контролировать выдачу временных прав и действия администраторов.
- Встроенные механизмы прикладных систем. Используются там, где приложение имеет собственную базу пользователей. Важно, чтобы локальная модель не противоречила общему порядку управления учётными записями.
Наличие каталога или IAM-платформы само по себе не означает исполнения пункта 3.4. Требование выполнено только тогда, когда операции с учётными записями выполняются по полномочному основанию, фиксируются, контролируются и соответствуют утверждённому жизненному циклу.
Типичные ошибки при реализации
- учётные записи создаются по устным просьбам без заявки или распоряжения;
- аккаунты уволенных сотрудников остаются активными после прекращения трудовых отношений;
- временные учётные записи подрядчиков не блокируются после завершения работ;
- сервисные учётные записи не имеют владельца и срока пересмотра;
- администраторы самостоятельно назначают права без согласования с владельцем процесса или ответственным лицом;
- учётные записи удаляются без сохранения минимально необходимой истории для аудита;
- в системе есть активные записи, которые невозможно связать с действующими пользователями или служебной функцией;
- нет регулярной сверки активных учётных записей с кадровыми и организационными данными;
- порядок управления учётными записями описан в документах, но фактические операции выполняются иначе.
Вывод
Пункт 3.4 следует рассматривать как требование к жизненному циклу учётной записи. Его нельзя закрыть только наличием пользователей в системе или возможностью администратора вручную создать аккаунт. Требуется установленный порядок, в котором понятно, кто инициирует создание, кто согласует активацию, кто выполняет блокировку, когда запись уничтожается и как всё это подтверждается.
Для небольшой ИС допустим регламентированный ручной процесс с журналом заявок и регулярной сверкой. Для сложной ИС предпочтительна централизованная модель с каталогом, заявками, HR-интеграцией, автоматизацией блокировки и отдельным порядком для сервисных и привилегированных записей. Требование считается исполненным тогда, когда каждая активная учётная запись имеет владельца, основание, назначение, актуальный статус и управляется по утверждённому порядку.