Пункт 3.5 приложения 3 к ПТКЗИ: контроль правил генерации и смены паролей

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

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

На практике это означает, что парольная политика не должна существовать только как общая фраза в документе. Должны быть определены требования к генерации паролей, их сложности или стойкости, запрету очевидных значений, порядку первичной выдачи, смены, восстановления, блокировки при компрометации и контролю фактического применения этих правил в ИС. Если правила есть в ЛПА, но технически не применяются, требование исполнено формально. Если настройки есть в системе, но не закреплены документально, проверяющему будет сложно оценить, почему именно такой режим считается установленным владельцем ИС.

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

Приложение 3 к Положению о порядке технической и криптографической защиты информации в информационных системах, предназначенных для обработки информации, распространение и (или) предоставление которой ограничено, утверждённому приказом Оперативно-аналитического центра при Президенте Республики Беларусь от 20 февраля 2020 г. № 66, в редакции приказа от 10 декабря 2024 г. № 259, с учётом изменений, внесённых приказом от 27 мая 2026 г. № 98 (далее – Приложение 3 к ПТКЗИ), раздел «Требования по обеспечению идентификации и аутентификации», пункт 3.5: «обеспечение контроля за соблюдением правил генерации и смены паролей пользователей информационной системы».

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

По таблице приложения 3 требование пункта 3.5 является обязательным для всех классов типовых ИС: 4-ин, 4-спец, 4-бг, 4-юл, 4-дсп, 3-ин, 3-спец, 3-бг, 3-юл, 3-дсп. Рекомендательный режим применения для данного требования не предусмотрен.

Приказ № 66 не устанавливает единую длину пароля, обязательный набор символов или одну периодичность смены для всех ИС. Конкретные правила определяет собственник (владелец) с учётом архитектуры, категорий пользователей и рисков. В рекомендациях НЦКБ для объектов информационной инфраструктуры также предлагается закреплять требования к паролям и частоте их смены в локальных правовых актах; эту рекомендацию можно использовать как практический ориентир, но она не заменяет требования, установленные для конкретной ИС.

Что должно быть определено владельцем ИС

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

• Правила генерации паролей. Следует определить минимальные требования к стойкости пароля: длину, недопустимость очевидных значений, запрет совпадения с именем пользователя, использование словарных и типовых значений, при необходимости – требования к составу символов.
• Порядок первичной выдачи. Должно быть понятно, как пользователь получает первичный пароль, обязан ли он сменить его при первом входе, кто имеет доступ к первичному значению и как исключается его повторное использование.
• Правила смены паролей. Следует установить случаи плановой и внеплановой смены: по истечении срока, при подозрении на компрометацию, после восстановления доступа, после временной передачи реквизитов либо при изменении режима доступа.
• Разные категории пользователей. Для обычных пользователей, администраторов, внешних специалистов, сервисных и технических учётных записей могут применяться разные требования. Особенно это важно для привилегированных и сервисных записей.
• Контроль соблюдения. Необходимо определить, как владелец ИС убеждается, что установленные правила реально применяются: через технические политики, периодические проверки, выгрузки настроек, отчёты или сверку с утверждёнными параметрами.

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

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

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

• закреплены ли правила генерации и смены паролей в ЛПА, регламенте управления учётными записями, политике ИБ, инструкции администратора или ином ОРД;
• определены ли требования к длине, стойкости, недопустимым значениям и повторному использованию паролей;
• установлена ли периодичность или условия смены паролей, включая внеплановую смену при подозрении на компрометацию;
• различаются ли требования для обычных, административных, сервисных и временных учётных записей;
• реализованы ли правила технически в доменной политике, приложении, СУБД, СЗИ, VPN, сетевом оборудовании или иных компонентах ИС;
• можно ли показать фактические настройки парольной политики, выгрузки параметров, отчёты или иные подтверждения;
• не используются ли бессрочные, слабые, одинаковые, общие или передаваемые пароли;
• контролируется ли смена первичных паролей и блокируется ли использование очевидных или скомпрометированных значений, если такая возможность реализована технически.

Особое внимание обычно уделяется расхождению между документами и настройками. Если в ЛПА указана одна периодичность смены, а фактические политики позволяют бессрочное использование паролей, требование нельзя считать исполненным надлежащим образом. То же относится к ситуации, когда парольная политика есть только в домене, но не охватывает приложения, СУБД, СЗИ и локальные административные интерфейсы.

Варианты реализации

Организационный вариант.

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

Технический вариант.

Правила реализуются средствами ОС, домена, приложения, СУБД, каталога, VPN, СЗИ или иной платформы. Настраиваются минимальная длина, история паролей, срок действия, запрет повторного использования, блокировка после неуспешных попыток, принудительная смена при первом входе или после сброса. Такой вариант даёт сильную фактическую реализацию, но без ЛПА остаётся недостаточно обоснованным с точки зрения установленного владельцем порядка.

Комбинированный вариант.

Наиболее правильный подход. Владелец ИС определяет парольные правила в ЛПА и ОРД, реализует их технически в доступных механизмах, а затем периодически проверяет соответствие фактических настроек утверждённым требованиям. Для большинства ИС именно эта модель является оптимальной: она сочетает юридическую определённость и техническую принудительность.

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

Приложение 3 к Положению содержит перечень требований, подлежащих включению в техническое задание на создание системы защиты информации. Поэтому в ТЗ необходимо зафиксировать требуемый результат и границы его применения, а в ЛПА и ОРД – порядок эксплуатации, роли, ответственность и подтверждающие процедуры.

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

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

Техническая реализация и инструменты

Техническая реализация пункта 3.5 зависит от платформы, в которой создаются и используются учётные записи. Требование редко закрывается одним механизмом, если ИС состоит из домена, приложений, СУБД, СЗИ и сетевого оборудования. Важно определить, где парольные правила применяются централизованно, а где требуют отдельной настройки.

• Active Directory и групповые политики Windows. Позволяют централизованно задавать минимальную длину пароля, сложность, срок действия, историю паролей, блокировку после неуспешных попыток и принудительную смену при определённых условиях.
• Fine-Grained Password Policies в Active Directory. Применимы, когда для разных групп пользователей нужны разные парольные правила: например, отдельные требования для администраторов, сервисных записей или привилегированных групп.
• Linux PAM, pam_pwquality, pam_faillock. Используются в Linux-среде для задания требований к качеству пароля, контроля неуспешных попыток, блокировки и иных параметров аутентификации.
• FreeIPA и LDAP-каталоги. Позволяют централизованно управлять парольными правилами в Linux/Unix-инфраструктуре и применять единые параметры к группам пользователей.
• Keycloak, Microsoft Entra ID, ADFS и иные IAM/SSO-решения. Применимы для централизованного управления аутентификацией в приложениях и веб-сервисах, включая политики паролей и дополнительные механизмы защиты входа.
• Встроенные политики приложений и СУБД. Используются там, где приложение или база данных имеют собственную модель пользователей. Важно, чтобы локальные правила не были слабее утверждённых требований владельца ИС.
• Password manager / корпоративное хранилище секретов. Уместны для генерации и безопасного хранения сложных паролей сервисных и административных учётных записей. Не заменяют парольную политику, но помогают выполнять её на практике.
• Средства аудита конфигураций и скрипты проверки. PowerShell, Bash, Ansible и иные средства могут использоваться для выгрузки фактических параметров парольных политик и сверки их с ЛПА.

При выборе инструментов необходимо учитывать границы ИС. Если парольная политика настроена только в домене, но приложение, СУБД или СЗИ используют локальные слабые пароли, требование не реализовано полноценно. Контроль должен охватывать все значимые точки, где применяются пароли пользователей ИС.

Когда технический контроль невозможен

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

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

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

Раздельные документы для разных ролей

Единая парольная политика может оставаться основным внутренним документом, но доводить её целиком до каждого работника не обязательно и нередко нежелательно. Пункт 13 ПТКЗИ требует доводить ЛПА и ОРД до работников в части, их касающейся. Поэтому практичнее разделить требования по ролям и не раскрывать обычным пользователям детали обращения с административными и сервисными секретами.

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

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

Физические ограничения устаревших и специализированных активов

Требование ЛПА должно быть выполнимым на конкретном активе. Если BIOS, промышленный контроллер, сетевое устройство или устаревшая ОС принимает не более семи символов, нельзя одновременно установить в документе обязательную минимальную длину двенадцать символов и считать требование выполненным. Такое расхождение обнаруживается простой проверкой настроек.

Для каждого исключения следует оформить карточку технического ограничения:

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

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

Что показать проверяющему

Для подтверждения контроля полезно заранее подготовить связанный комплект доказательств:

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

Типичные ошибки при реализации

• в документах указаны парольные правила, но технические политики им не соответствуют;
• парольная политика настроена только для доменных пользователей, но не применяется к приложениям, СУБД, СЗИ и сетевому оборудованию;
• для всех категорий пользователей действуют одинаковые слабые требования, включая администраторов и сервисные записи;
• первичные пароли не подлежат обязательной смене после выдачи;
• сервисные пароли не меняются годами и известны нескольким лицам без учёта;
• не контролируется повторное использование старых паролей;
• в системе допускаются очевидные пароли, связанные с именем пользователя, организацией, сезоном, годом или названием системы;
• сброс пароля выполняется без подтверждения личности пользователя и без фиксации основания;
• нет периодической проверки фактических настроек парольных политик;
• пароли хранятся в открытых файлах, таблицах, письмах или мессенджерах.

Вывод

Пункт 3.5 следует рассматривать как требование к управляемой парольной политике, а не как формальное указание “установить сложные пароли”. Владелец ИС должен сам определить правила генерации и смены паролей, закрепить их в ЛПА и обеспечить контроль их исполнения техническими и организационными средствами.

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

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

• Идентификация и аутентификация
• Управление учётными записями
• Блокировка доступа при неактивности