Парольная политика ИБ: требования ФСТЭК, структура документа и шаблон

Парольная политика — один из обязательных документов для организаций, работающих с ГИС, ИСПДн или объектами КИИ. Требования ФСТЭК (Приказы №117, №21, №239) прямо указывают на необходимость регламентации идентификации и аутентификации. На практике же парольная политика часто сводится к формальному документу, скопированному из интернета, который не соответствует ни классу защищённости системы, ни реальным настройкам Active Directory. В этой статье — конкретные требования регуляторов, структура документа, параметры по классам защищённости и рекомендации по технической реализации.

Что такое парольная политика и зачем она нужна

Парольная политика как элемент СУИБ

Парольная политика — внутренний нормативный документ организации, определяющий правила создания, использования, хранения и смены паролей. В иерархии документов ИБ парольная политика относится к 3-му уровню (стандарты) или оформляется как раздел политики управления доступом.

Место парольной политики в системе документов:

• Политика ИБ (2-й уровень) — определяет принципы управления доступом
• Парольная политика (3-й уровень) — конкретизирует требования к паролям
• Инструкция пользователя (5-й уровень) — содержит правила работы с паролями для сотрудников
• Настройки GPO (техническая реализация) — обеспечивают принудительное соблюдение требований

Нормативные основания: ФСТЭК, ФСБ, ГОСТ

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

Последствия отсутствия парольной политики

Отсутствие утверждённой парольной политики влечёт:

• Замечание при проверке ФСТЭК — невыполнение мер ИАФ квалифицируется как несоответствие
• Проблемы при аттестации — аттестация ГИС или ИСПДн невозможна без комплекта ОРД
• Инциденты — без формализованных требований пользователи используют простые пароли, один пароль на все системы, записывают пароли на стикерах
• Отсутствие ответственности — без документа невозможно привлечь сотрудника к дисциплинарной ответственности за нарушение правил

💡 Совет: парольная политика — один из ~20 обязательных документов ИБ. Модуль документов КиберОснова генерирует весь комплект под ваши системы за минуты и следит за актуальностью при смене требований — посмотрите на демо, как это выглядит.

Требования к паролям по нормативным документам

Требования ФСТЭК (Приказы №117, №21, №239)

ФСТЭК устанавливает требования через блок мер ИАФ (идентификация и аутентификация). Конкретные параметры зависят от класса защищённости / уровня защищённости информационной системы.

Группа ИАФ в методдоке от 12.04.2026 содержит четыре меры, и парольные требования лежат ровно в одной из них:

Мера ИАФ.3 задаёт параметры простой (парольной) аутентификации: длина не менее 12 символов, алфавит не менее 70 символов, не более 5 неуспешных попыток до блокировки, блокировка на 15 минут, смена не более чем через 90 дней, повторное использование пароля запрещено.

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

Частая ошибка в пересказах: приписать парольные требования мере ИАФ.1. Она про идентификацию, то есть про распознавание пользователя, а не про проверку его подлинности.

ГОСТ Р 57580.1-2017 для финансовых организаций

ГОСТ 57580.1 задаёт парольные требования отдельными мерами группы РД, и они применяются на всех трёх уровнях защиты информации (усиленном, стандартном, минимальном):

• РД.21 — пароли пользователей длиной не менее восьми символов
• РД.22 — пароли эксплуатационного персонала длиной не менее шестнадцати символов
• РД.19 — смена паролей пользователей не реже одного раза в год
• РД.20 — смена паролей эксплуатационного персонала не реже одного раза в квартал
• РД.23 — буквы верхнего и нижнего регистров и цифры при формировании паролей
• РД.11 — временная блокировка учётной записи после серии неуспешных попыток аутентификации

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

Рекомендации NIST и ISO 27002

Международные стандарты расходятся с российскими требованиями в ряде позиций:

Российские организации обязаны соблюдать требования ФСТЭК, даже если международные рекомендации (NIST) предлагают иной подход. Несоблюдение российских нормативных требований — основание для предписания при проверке. Рекомендации NIST можно использовать как дополнение, но не замену.

Три документа ФСТЭК 2025–2026: где именно живёт требование о смене пароля

Вопрос «требует ли ФСТЭК плановую смену пароля» в 2026 году решается не одним документом, а тремя, и отвечают они по-разному.

Приказ №117 (действует с 1 марта 2026 года) слова «пароль» не содержит ни разу. Он перечисляет мероприятия и группы мер, а конкретику отдаёт методическим документам: пункт 68 обязывает реализовывать меры с использованием методических документов ФСТЭК.

Методика оценки показателя защищённости Кзи (11 ноября 2025 года) пароль видит, но только его сложность. Частный показатель k21 проверяет, что нет учётных записей с паролем слабее парольной политики, а в перечне подтверждающих материалов описана сама политика: не менее 12 символов, буквы обоих регистров, специальные символы, без персонифицированной информации. Показатель k23 проверяет отсутствие паролей по умолчанию у сервисных учётных записей и учётных записей разработчиков. Собственного срока смены методика не устанавливает, но требует, чтобы организационно-распорядительный документ по парольной политике содержал требования к периодичности смены, — а конкретные 90 дней приходят из методического документа ниже. При повторном за 12 месяцев невыполнении меры вес всей группы «Защита пользователей» обнуляется (пункт 35).

Методический документ «Состав и содержание мероприятий и мер по защите информации» (12 апреля 2026 года) отменил методичку 2014 года о мерах в ГИС и задаёт содержание мер, на которые ссылается приказ №117. Мера ИАФ.3 для простой парольной аутентификации: длина не менее 12 символов, алфавит не менее 70 символов, не более 5 неудачных попыток до блокировки, блокировка на 15 минут, смена паролей не более чем через 90 дней, запрет повторного использования пароля. Мера ЗМУ.1 для мобильных устройств: пароль от 6 символов (усиление ЗМУ.1 для К1 и К2 — не менее 10), смена не более чем через 30 дней, запрет повторного использования 12 последних паролей. Область документа (пункт 1.2): информационные системы государственных органов, ГУП и госучреждений, организаций, включая субъектов КИИ.

Итог: для ГИС, госучреждений и субъектов КИИ плановая смена пароля обязательна, 90 дней в системе и 30 дней на мобильном устройстве, и эти сроки должны стоять в тексте парольной политики, на которую смотрит показатель k21. Коммерческая организация вне этого контура выбирает параметры сама, по модели угроз, и там аргументы NIST против принудительной смены остаются в силе. Сравнение трёх документов ФСТЭК с NIST SP 800-63B, где периодическая смена с 2025 года прямо запрещена, разобрано в статье Василия Сеничева на Хабре.

Сводная таблица требований

Сложно отслеживать соответствие парольной политики требованиям для разных информационных систем? Модуль документов ИБ в КиберОснова автоматически контролирует актуальность всех политик и связывает их с конкретными системами и мерами защиты.

Структура документа «Парольная политика»

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

Вводный раздел определяет:

• Назначение документа — установление требований к парольной аутентификации
• Область применения — перечень информационных систем, на которые распространяется политика (все ИС организации или конкретные: ГИС, ИСПДн, КИИ)
• Нормативные основания — ссылки на приказы ФСТЭК, ФСБ, ГОСТы
• Термины и определения — пароль, аутентификация, учётная запись, привилегированный доступ
• Ответственность — кто отвечает за реализацию и контроль

Требования к длине и сложности паролей

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

• ГИС, госучреждения, субъекты КИИ — мера ИАФ.3 методического документа ФСТЭК от 12.04.2026: не менее 12 символов, алфавит не менее 70. Значение одинаково для К1, К2 и К3.
• Финансовые организации по ГОСТ Р 57580.1 — требования разделены по типу субъекта: пользователи не менее 8 символов (РД.21), эксплуатационный персонал не менее 16 (РД.22).
• ИСПДн вне этих контуров — числа задаёт оператор, приказ №21 требует контроля правил генерации и смены (мера АНЗ.5), но длину не называет.
• Организация вне контуров — по модели угроз.

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

Обычные пользователи:

• Минимальная длина — 12 символов в контуре ФСТЭК (ИАФ.3), 8 символов — нижняя граница ГОСТ Р 57580.1 для финансового контура
• Обязательно: буквы верхнего и нижнего регистра, цифры
• Рекомендуется: спецсимволы (!@#$%^&*)
• Запрещается: имя пользователя, название организации, словарные слова, последовательности (123456, qwerty)

Привилегированные учётные записи (администраторы):

• Минимальная длина — 16 символов: в контуре ГОСТ Р 57580.1 это норма для эксплуатационного персонала (РД.22), в контуре ФСТЭК — практика сверх минимума ИАФ.3
• Обязательно: буквы обоих регистров, цифры, спецсимволы
• Запрещается: совпадение с паролем обычной УЗ того же пользователя
• Рекомендуется: использование парольных фраз (passphrase)

Сервисные учётные записи:

• Минимальная длина — 16 символов, генерация криптографически стойким генератором
• Хранение в защищённом хранилище (vault)
• Смена при увольнении знающего пароль сотрудника

Периодичность и правила смены паролей

Норма для ГИС, госучреждений и субъектов КИИ одна: смена не более чем через 90 дней (ИАФ.3), на мобильных устройствах — 30 дней (ЗМУ.1). Ниже — практика сверх нормы, которую организации закрепляют в политике:

• Обычные УЗ — смена не реже чем раз в 90 дней
• Привилегированные УЗ — чаще (типично 60 дней) и обязательно с многофакторной аутентификацией
• Сервисные УЗ — по регламенту (типично 180 дней) и при увольнении знающего пароль сотрудника
• Внеплановая смена — при подозрении на компрометацию (немедленно)
• Запрет повторного использования — мера ИАФ.3 запрещает повторное использование пароля, не называя числа; на практике настраивают 10–12, для мобильных устройств по ЗМУ.1 — 12 последних
• Минимальный срок жизни пароля — 1 день (защита от быстрой «прокрутки» истории)

Хранение и передача паролей

• Запрещается: записывать на бумаге, хранить в текстовых файлах, отправлять по email
• Допускается: использование корпоративного менеджера паролей (KeePass, Bitwarden)
• Первичный пароль при создании УЗ — одноразовый, со сменой при первом входе
• Передача паролей — только через защищённый канал, запрет устной передачи по телефону

Многофакторная аутентификация

Определите, для каких систем и ролей МФА обязательна:

Допустимые виды второго фактора:

• Аппаратный токен (Рутокен, eToken, YubiKey)
• Программный OTP-генератор (Google Authenticator, FreeOTP)
• Push-уведомление на корпоративное мобильное устройство
• SMS-код (минимально допустимый уровень, не рекомендуется для высоких классов)

Сервисные и привилегированные учётные записи

Отдельный раздел необходим для учётных записей с повышенными привилегиями:

• Администраторы домена — МФА обязательна, пароль 12+ символов, смена каждые 60 дней (внутренний норматив; методдок ФСТЭК требует не более 90)
• root / локальный администратор — пароль 16+ символов, хранение в vault, доступ по запросу
• Сервисные УЗ (SQL, приложения, бэкапы) — генерированные пароли 16+ символов, хранение в vault
• Учётные записи подрядчиков — временные, с ограниченным сроком действия, МФА обязательна

Ответственность за нарушение

Раздел фиксирует:

• Виды нарушений (передача пароля, использование простого пароля, запись на бумаге)
• Меры ответственности (предупреждение, выговор, увольнение)
• Порядок расследования инцидентов, связанных с компрометацией паролей
• Обязанность сотрудника немедленно сообщить о подозрении на компрометацию

Параметры парольной политики по классам защищённости

Конкретные параметры определяются классом защищённости ГИС (Приказ №117), уровнем защищённости ИСПДн (Приказ №21) или категорией значимости КИИ (Приказ №239). Используйте сводную таблицу из раздела выше для определения параметров вашей системы. Ниже — ключевые ориентиры для настройки.

Параметры по нормативным документам:

• ГИС любого класса, госучреждения, субъекты КИИ — единые значения меры ИАФ.3 методдока от 12.04.2026: длина от 12 символов, алфавит от 70, 5 попыток и блокировка на 15 минут, смена не более чем через 90 дней, запрет повторного использования; для мобильных устройств (ЗМУ.1) — от 6 символов, смена не более чем через 30 дней, запрет 12 последних паролей.
• ИСПДн (приказ №21) — числовых параметров приказ не задаёт; оператор фиксирует их в парольной политике, а мера АНЗ.5 требует контролировать правила генерации и смены паролей. На практике операторы берут значения ИАФ.3 как ориентир.
• Коммерческая организация вне контура ГИС и КИИ — параметры по модели угроз с обоснованием в парольной политике: отсутствие плановой смены при наличии МФА и контроля утечек — допустимая позиция, если она задокументирована.

Настройка парольной политики в Active Directory

GPO: минимальные параметры по требованиям ФСТЭК

Парольная политика на бумаге бесполезна без технической реализации. В среде Microsoft Active Directory параметры задаются через Group Policy Object (GPO).

Путь: Computer Configuration > Policies > Windows Settings > Security Settings > Account Policies > Password Policy

Путь: Account Policies > Account Lockout Policy

Fine-Grained Password Policies для привилегированных УЗ

Стандартная доменная политика паролей применяется ко всем пользователям одинаково. Для привилегированных УЗ необходимы усиленные требования через Fine-Grained Password Policies (FGPP):

• Создайте Password Settings Object (PSO) для группы администраторов
• Установите минимальную длину 12 символов
• Установите период смены 60 дней для привилегированных (норма для остальных — не более 90 дней по ИАФ.3)
• Установите блокировку после 5 попыток
• Установите историю 12 паролей
• Примените PSO к группе Domain Admins и другим привилегированным группам

Типичные ошибки настройки

Ошибка 1: политика не применена. Документ утверждён, но GPO не настроена. Пользователи ставят пароль «123456» и никто не контролирует.

Ошибка 2: одна политика на всех. Администраторы и обычные пользователи подчиняются одним правилам. Привилегированные УЗ должны иметь усиленные требования.

Ошибка 3: слишком частая смена. Смена каждые 30 дней приводит к тому, что пользователи записывают пароли на стикерах или используют предсказуемые шаблоны (Password1!, Password2!, Password3!).

Ошибка 4: нет блокировки. Без ограничения количества попыток входа система уязвима к brute-force-атакам.

Ошибка 5: забытые сервисные УЗ. Пароль сервисной учётной записи SQL-сервера не менялся 5 лет, его знают три уволившихся сотрудника.

Многофакторная аутентификация: когда обязательна

Требования регуляторов к МФА

Многофакторная аутентификация (МФА) — использование двух или более факторов аутентификации из разных категорий:

• Знание — пароль, PIN-код
• Владение — токен, смартфон, смарт-карта
• Биометрия — отпечаток пальца, распознавание лица

Где усиленная (двухфакторная) аутентификация обязательна по методдоку 12.04.2026, мера ИАФ.3:

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

Удалённый доступ привилегированных пользователей с личных мобильных устройств не допускается вовсе. Для ИСПДн и значимых объектов КИИ необходимость МФА определяется приказами №21 и №239, уровнем защищённости или категорией и моделью угроз.

Варианты второго фактора

Для систем с высоким классом защищённости ФСТЭК рекомендует аппаратные токены, сертифицированные ФСБ.

Особенности МФА для удалённого доступа

При организации удалённого доступа (VPN, RDP, VDI) МФА обязательна вне зависимости от класса системы — это базовая мера, рекомендованная ФСТЭК и закреплённая в ГОСТ Р 57580.1. Рекомендуемая конфигурация: VPN — сертификат на токене + пароль; RDP через шлюз — пароль + OTP; веб-приложения — пароль + push-уведомление; административный доступ — сертификат + пароль + одобрение второго администратора (PAM).

Шаблон парольной политики ИБ

Адаптация шаблона под свою организацию

При разработке парольной политики на основе шаблона необходимо адаптировать:

1. Область применения — перечислить конкретные информационные системы организации
2. Параметры — установить значения в соответствии с классом / уровнем защищённости ваших систем (см. таблицы выше)
3. Роли — указать конкретные должности (администратор ИБ, системный администратор, руководитель ИТ)
4. Ответственность — привести в соответствие с локальными нормативными актами организации
5. МФА — определить список систем и ролей, для которых МФА обязательна

Структура оглавления шаблона:

1. Общие положения
2. Область применения
3. Термины и определения
4. Требования к паролям пользователей
5. Требования к паролям привилегированных УЗ
6. Требования к паролям сервисных УЗ
7. Многофакторная аутентификация
8. Хранение и передача паролей
9. Порядок восстановления доступа
10. Ответственность за нарушение
11. Порядок пересмотра и актуализации
12. Приложения (таблица параметров по системам)

Согласование и утверждение документа

Порядок ввода в действие: разработка подразделением ИБ, согласование с ИТ (техническая реализуемость), юристами (ответственность) и HR (ознакомление), утверждение руководителем, ввод приказом, ознакомление сотрудников под подпись, настройка GPO/FGPP в соответствии с утверждённым документом.

Автоматизация управления парольными политиками в SGRC

Контроль соответствия требованиям

Организация с несколькими информационными системами разных классов защищённости сталкивается с проблемой: для ГИС 1-го класса нужны одни параметры, для ИСПДн УЗ-3 — другие, для объекта КИИ — третьи. Отслеживать соответствие требованиям вручную — ресурсоёмкая задача.

SGRC-платформа решает эту задачу, связывая:

• Информационную систему с её классом / уровнем защищённости
• Класс с набором обязательных мер (для паролей это ИАФ.3)
• Меры с конкретными параметрами парольной политики
• Параметры с фактическими настройками (данные из AD через интеграцию)

Версионирование и актуализация документов

Парольная политика — живой документ, который пересматривается при изменении нормативных требований, ИТ-инфраструктуры, по результатам инцидентов и аудитов. Модуль документов ИБ в КиберОснова ведёт автоматическое версионирование, уведомления о пересмотре, контроль ознакомления сотрудников и связь документа с мерами защиты.

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

Заключение

Парольная политика — не формальность, а рабочий документ, определяющий параметры одного из базовых механизмов защиты. Ключевое правило: документ должен соответствовать и требованиям регулятора (ФСТЭК, ГОСТ), и реальным техническим настройкам (GPO, LDAP). Парольная политика на бумаге без настроенной GPO бесполезна. Настроенная GPO без утверждённого документа — нарушение при проверке.

Ключевые рекомендации:

• Определите параметры в соответствии с классом / уровнем защищённости каждой системы
• Разделяйте требования для обычных, привилегированных и сервисных учётных записей
• Обеспечьте техническую реализацию через GPO и FGPP — документ без принудительного исполнения не работает
• Внедрите МФА как минимум для удалённого доступа и привилегированных УЗ
• Настройте регулярный пересмотр документа и контроль соответствия

Запросите демо КиберОснова и посмотрите, как SGRC-платформа помогает разрабатывать, согласовывать и поддерживать в актуальном состоянии парольные политики и весь комплект документов ИБ.