Пункт 7.4 приложения 3 к ПТКЗИ: работа под пользовательскими учетными записями

Смысл требования

Пункт 7.4 приложения 3 к ПТКЗИ – практический разбор требования «разделение учётных записей». Пункт 7.4 закрепляет принцип минимальных привилегий в повседневной работе.

Административные полномочия применяются только для управления активами или при документированной технической необходимости.

Если сотрудник постоянно работает с административными правами, любая запущенная им программа получает те же возможности. Ошибка, вредоносное вложение или уязвимость браузера могут привести к изменению системных настроек и отключению защиты.

Разделение записей не мешает администрированию. Оно отделяет почту, браузер и документы от операций, которые действительно изменяют конфигурацию серверов, рабочих станций и средств защиты.

Формулировка требования

Приложение 3 к Положению о порядке технической и криптографической защиты информации, пункт 7.4: «использование активов информационной системы под пользовательскими учетными записями (использование учетных записей, имеющих административные привилегии, только в случае управления активами информационной системы или наличия особенностей функционирования активов информационной системы)».

Нормативная формулировка обычно короче, чем реальный процесс её выполнения. Поэтому при внедрении её следует разложить на понятные действия: определить объект контроля, назначить ответственных, установить технические правила и подготовить доказательства фактической реализации.

Обязательность применения

Требование обязательно для всех классов типовых ИС: 4-ин, 4-спец, 4-бг, 4-юл, 4-дсп, 3-ин, 3-спец, 3-бг, 3-юл и 3-дсп.

Требование распространяется на пользовательские и административные сценарии. Исключения из-за особенностей функционирования должны быть обоснованы и контролироваться.

Если специализированное приложение требует повышенных прав, необходимо проверить возможность точечной настройки разрешений. Удобство пользователя или привычка администратора сами по себе не являются технической особенностью функционирования.

Разделение учётных записей

• обычная именная запись для повседневной работы;
• отдельная именная административная запись;
• локальные аварийные записи;
• служебные записи без интерактивной работы;
• выделенное административное рабочее место;
• контролируемое повышение привилегий;
• журналирование административных сессий.

Конкретная технология не предписана. Решение должно соответствовать архитектуре ИС и обеспечивать заявленный результат.

Типовая схема предполагает обычную именную запись для повседневной работы и отдельную административную – для управления. Критичные операции желательно выполнять с выделенного административного рабочего места или через контролируемый механизм повышения привилегий.

Например, администратор читает почту под обычной записью, а консоль управления доменом открывает под отдельной. Компрометация браузера в таком случае не даёт злоумышленнику доменные привилегии автоматически.

Именная административная запись должна принадлежать конкретному сотруднику. Общие записи вроде administrator-team затрудняют расследование и не позволяют связать действие с человеком. Исключение возможно только для аварийных сценариев с отдельным контролем использования.

Для особо критичных систем полезно выдавать привилегии на ограниченное время. Администратор получает доступ после согласования, выполняет работу, а затем полномочия автоматически отзываются. Это уменьшает число постоянно активных административных записей.

Технические исключения

• описать конкретное приложение и актив;
• зафиксировать техническую причину;
• проверить возможность точечного изменения прав;
• ограничить область полномочий;
• установить срок исключения;
• усилить мониторинг;
• пересмотреть решение после обновления.

Каждое исключение должно относиться к конкретному приложению и активу. Следует зафиксировать техническую причину, ограничить область полномочий, установить срок пересмотра и усилить мониторинг.

Часто вместо полного локального администратора достаточно разрешить запись в определённый каталог, управление одной службой или доступ к конкретной ветви реестра.

Если приложение запускается только с повышенными правами, следует проверить его поведение с помощью мониторинга доступа к файлам, реестру и службам. Нередко причина состоит в одном каталоге с неправильно настроенными разрешениями, а не в реальной необходимости полного администратора.

Компенсирующие меры должны снижать конкретный риск. Например, для изолированного АРМ без интернета можно допустить более широкие локальные права, но при этом ограничить установку программ, съёмные носители и сетевые подключения.

Что следует подтвердить при проверке

• раздельные пользовательские и административные записи;
• группы с привилегиями;
• отсутствие постоянных прав у обычных пользователей;
• порядок повышения привилегий;
• журналы административных входов;
• перечень исключений;
• ограничение интерактивного использования служебных записей;
• периодический пересмотр прав.

Доказательства должны подтверждать фактическое состояние всей заявленной области, а не единичный пример.

Проверка должна показывать связь между документами и реальной конфигурацией. Схема, реестр, настройка и журнал изменений должны описывать один и тот же объект, а не разные состояния системы.

Лучше готовить не отдельные случайные скриншоты, а связанный набор доказательств: утверждённое правило, техническую реализацию, результат контроля и пример обработки выявленного отклонения.

Выборочная проверка должна показывать, что обычные учётные записи администраторов не входят в привилегированные группы. Также полезно подтвердить, что административные записи не используются для почты, web-доступа и других повседневных задач.

Журналы должны позволять определить не только факт входа, но и характер административной активности. Для критичных систем это может быть запись сессий, команд или изменений конфигурации.

Полезно проверить сценарий с начала до конца: сотрудник входит под обычной записью, инициирует административную операцию, проходит установленное повышение полномочий, выполняет действие и завершает привилегированную сессию. Такая демонстрация лучше отдельных списков групп показывает, как правило работает в повседневной эксплуатации.

При увольнении, переводе или длительном отсутствии сотрудника административные записи должны блокироваться так же управляемо, как обычные. Отдельное имя привилегированной записи не должно приводить к тому, что она забывается при изменении кадрового статуса владельца.

Что закрепить в ТЗ, ЛПА и ОРД

• принцип работы под обычной записью;
• виды административных записей;
• порядок выдачи и отзыва прав;
• способы повышения привилегий;
• требования к административным АРМ;
• порядок исключений;
• журналирование и контроль.

Документы не должны переписывать интерфейс конкретного продукта. Их задача – установить устойчивые правила: кто принимает решение, что именно контролируется, когда выполняется проверка и какие действия предпринимаются при нарушении.

Такая формулировка остаётся применимой после замены оборудования или программного обеспечения и не требует полностью переписывать ЛПА при каждом техническом обновлении.

Следует определить порядок действий при временной необходимости расширенных прав. Например, аварийная работа оформляется заявкой постфактум в установленный срок, а применение резервной записи автоматически создаёт уведомление ответственному за ИБ.

Политику паролей и многофакторную аутентификацию для административных записей желательно делать строже, чем для обычных пользователей. Это оправдано более высоким ущербом при компрометации. При этом секреты не должны храниться в общих файлах, браузерах или сценариях автоматизации без защищённого механизма управления.

Типичные ошибки

• администратор постоянно работает под Domain Admin;
• обычные пользователи состоят в локальных администраторах;
• административная запись используется для почты;
• одна общая запись используется всем подразделением;
• служебная запись допускает интерактивный вход;
• исключения не имеют срока;
• аварийная запись используется ежедневно.

Большинство перечисленных ошибок возникает, когда мера существует только в документах либо реализована на части активов. Исправление следует начинать с определения фактического охвата, а затем устранять разрыв между требованиями, настройками и эксплуатационными действиями.

Иногда организация создаёт две записи, но обе имеют одинаково широкие права. Формальное разделение имён без разделения полномочий не уменьшает риск и не соответствует смыслу требования.

Связанные материалы

• Пункт 3.1: разграничение доступа.
• Пункт 3.4: управление учётными записями.
• Пункт 3.6: централизованное управление учётными записями.

Вывод

Пункт 7.4 требует отделить повседневную работу от администрирования.

Качественная реализация использует раздельные именные записи, контролируемое повышение прав и ограниченные исключения.

Такой подход снижает последствия фишинга, вредоносного ПО и случайных действий. Даже если обычная пользовательская сессия будет скомпрометирована, административные полномочия останутся в отдельном контролируемом контексте.

Принцип можно сформулировать просто: административные права должны включаться как инструмент для конкретной работы, а не быть постоянным фоном всей пользовательской деятельности.

Нормативная основа

• Приказ ОАЦ № 66 от 20.02.2020 в редакции приказа ОАЦ № 259 от 10.12.2024 – приложение 3, пункт 7.4. Официальный источник.
• Положение о порядке технической и криптографической защиты информации – требования к ТЗ, ЛПА и эксплуатации. Официальный источник.

При применении материала необходимо использовать актуальную редакцию нормативного акта и учитывать класс конкретной ИС, её границы и решения, закреплённые в техническом задании.