ФСТЭК ужесточила контроль привилегированных учетных записей

Приказ ФСТЭК России № 117 изменил правила работы с учетными записями администраторов и других сотрудников с повышенными правами. Для такого доступа теперь нужно создавать отдельные привилегированные учетные записи, ограничивать их полномочия необходимым минимумом, разделять административные роли, регистрировать действия пользователей и применять строгую либо усиленную многофакторную аутентификацию.

Документ вступил в силу 1 марта 2026 года и заменил приказ ФСТЭК № 17 от 2013 года. С 1 сентября действует редакция с изменениями, внесенными приказом № 137 от 8 мая 2026 года. Сам приказ № 117 распространяется на государственные информационные системы, другие информационные системы государственных органов, государственных унитарных предприятий и государственных учреждений. Для муниципальных информационных систем эти требования также применяются, если законодательством не установлено иное.

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

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

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

Апрельский методический документ ФСТЭК раскрывает эти правила подробнее. Все привилегированные учетные записи должны быть закреплены за конкретными работниками. Групповые записи допустимы, если организация может однозначно установить, кто именно использовал их в конкретный момент. Для автоматического взаимодействия программ и систем предусмотрены отдельные неперсонифицированные технологические записи, но и они должны учитываться, контролироваться и быть закреплены за ответственными сотрудниками.

Таким образом, привычная ситуация, когда несколько администраторов работают под одним общим admin и по журналам невозможно понять, кто выполнил конкретную команду, требованиям уже не соответствует.

ФСТЭК запрещает объединять в одной привилегированной учетной записи или группе сразу несколько типов ролей: системное администрирование, разработку и тестирование программных и программно-аппаратных средств, а также функции администратора безопасности.

На практике разработчик, системный администратор и специалист, контролирующий безопасность, не должны получать общий набор полномочий через одну учетную запись.

Такое разделение ограничивает последствия компрометации. Захват учетных данных системного администратора не должен автоматически давать доступ к функциям администратора безопасности или контуру разработки.

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

Эти понятия различаются. ГОСТ Р 58833-2020 определяет строгую аутентификацию как многофакторную взаимную аутентификацию с применением криптографических протоколов. Упрощенно: свою подлинность должен подтвердить пользователь, а используемый механизм должен позволять проверить и другую сторону взаимодействия.

Методический документ ФСТЭК описывает технический вариант такой схемы. Для строгой аутентификации предусмотрено физическое устройство с поддержкой криптографии и неизвлекаемым закрытым ключом, цифровой сертификат и секрет, например ПИН-код устройства. В системе с доменной архитектурой предусматриваются корпоративный центр выпуска и проверки сертификатов и централизованное управление их жизненным циклом. В качестве примеров криптографических протоколов указаны Kerberos и TLS.

Обычная комбинация пароля и одноразового кода относится к многофакторной аутентификации, но сама по себе не равна строгой аутентификации в терминологии ФСТЭК.

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

Для внутренних пользователей в этом случае допускается усиленная аутентификация с компенсирующими мерами, которые сильнее связывают пользователя с физическим средством аутентификации. ФСТЭК приводит в качестве примеров биометрию или мобильный телефон со средством генерации одноразовых паролей, SMS либо push-подтверждениями.

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

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

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

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

Методический документ запрещает системным администраторам и администраторам безопасности использовать мобильные устройства для привилегированного доступа.

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

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

Для удаленной работы требования могут усиливаться. В частности, документ предусматривает строгую аутентификацию внутреннего привилегированного пользователя при удаленном доступе в рамках соответствующего усиления меры ИАФ.3.

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

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

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

В исследовании BI.ZONE за январь–сентябрь 2025 года использование или компрометация привилегированных учетных записей фигурировали в 39% инцидентов, зафиксированных командой BI.ZONE TDR. В 57% рассмотренных эпизодов атакующие использовали действующие учетные данные, а манипуляции с учетными записями встречались в 40% случаев. Эти показатели относятся к выборке самой компании, а не ко всем киберинцидентам в России.

Эксперты компании также оценивали число привилегированных записей на одного ИТ-сотрудника в три–семь. В разных системах 30–40% таких записей могли использовать одинаковые или похожие пароли.

Приказ № 117 вступил в силу 1 марта 2026 года. Выданные до этой даты аттестаты соответствия информационных систем сохраняют действие.

8 мая ФСТЭК подписала приказ № 137 с изменениями в требования. Минюст зарегистрировал его 10 августа, а основная часть поправок вступила в силу 1 сентября 2026 года. Отдельное изменение пункта 32 начнет действовать 1 марта 2027 года.

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

Вопросы и ответы

Что считается привилегированной учетной записью?

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

Можно ли нескольким администраторам использовать одну учетную запись?

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

Нужно ли менять пароли привилегированных учетных записей?

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

Сколько времени есть на блокировку доступа у отстраненного администратора?

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

Можно ли администрировать систему с телефона?

Системным администраторам и администраторам безопасности использовать мобильные устройства для привилегированного доступа запрещено.