Парольная политика NIST и ФСТЭК: сравнение 2026

На аттестации ГИС территориального ведомства в марте 2026 года проверяющий открыл оснастку Active Directory, посмотрел Default Domain Policy - Maximum Password Age = 0. Несоответствие мере ИАФ.3 зафиксировано за четыре минуты. Команда ИБ ссылалась на NIST SP 800-63B Rev 4, где периодическая смена паролей прямо запрещена с середины 2025 года. Аттестатор кивнул сочувственно - и записал замечание.

По документам NIST - нельзя ротировать. По методдоку ФСТЭК (от 12 апреля 2026 года; дата и содержание требуют проверки по официальному источнику) - обязательно каждые 90 дней. На проверке работает ФСТЭК, и точка.

Ниже - детальное сравнение парольных политик NIST и ФСТЭК, матрица применимости по типам организаций, detection-чеклист для SIEM и конфигурации GPO/PAM, которые закрывают оба стандарта одновременно.

NIST SP 800-63B Rev 4: длина вместо ротации​

NIST опубликовал SP 800-63B Revision 4 (по имеющимся данным, финализирован в 2025 году; статус и точную дату стоит сверить на сайте NIST). Формально документ обязателен только для федеральных систем США, но де-факто на него ссылаются все: PCI DSS 4.0.1, SOC 2, ISO/IEC 27002:2022 (контроль 5.17).

Главное изменение Rev 4: в разделе 3.1.1.2 формулировка SHALL NOT вместо прежнего SHOULD NOT для принудительной смены - "Verifiers and CSPs SHALL NOT require subscribers to change passwords periodically""Проверяющие стороны и поставщики услуг (CSP) не должны требовать от абонентов периодической смены паролей." (цитата по вторичным источникам, стоит сверить с финальным текстом). Ротация допускается только при подтверждённой или подозреваемой компрометации. Не "рекомендуем не менять", а "запрещено менять без повода".

Остальные требования NIST к паролям:

• Минимум 8 символов при MFA, 15 - если пароль единственный фактор (по данным Netwrix и Enzoic, это повышение с прежних 8 для всех случаев). Системы обязаны принимать до 64 символов минимум.
• Правила сложности запрещены (SHALL NOT). "Хотя бы одна заглавная, одна цифра, один спецсимвол" - официально в прошлом. По мнению NIST, такие правила порождают предсказуемые паттерны подстановки без реального прироста энтропии. И они правы: P@ssw0rd1 формально проходит complexity, но в любом словаре стоит на первой странице.
• Блоклист-скрининг обязателен (SHALL). Каждый новый пароль проверяется по базам утечек, словарным словам, последовательностям вроде 12345 и контекстным терминам (имя организации, логин пользователя).
• Подсказки и контрольные вопросы запрещены (SHALL NOT). Knowledge-Based Authentication полностью выкинули из Rev 4.
• Rate-limiting обязателен, NIST допускает до 100 неудачных попыток.
• Хранение: salted hash с memory-hard KDF - Argon2id (предпочтительно), bcrypt, PBKDF2. Голый SHA-256 не годится: слишком быстрый, GPU перебирает миллиарды хешей в секунду.
• SMS OTP больше не соответствует AAL2 из-за рисков SIM-swap и перехвата. Для систем с чувствительными данными - FIDO2/WebAuthn или аппаратные токены.

По данным Verizon DBIR, значительная часть атак на веб-приложения связана с украденными учётными данными (точный процент варьируется от года к году). Логика NIST понятна: длинные уникальные пароли + скрининг по утечкам + phishing-resistant MFA дают больше, чем ротация, превращающая пароли в Vesna2026! на стикере под монитором.

ФСТЭК 2026: три документа и обязательная ротация​

Требование о смене паролей у ФСТЭК размазано по трём документам. Проверять по одному - гарантированно получить неполную картину.

Приказ №117 (по имеющимся данным, действует с 1 марта 2026; стоит сверить по официальному источнику ФСТЭК). Слова "пароль" не содержит вообще. Задаёт мероприятия и группы мер, а конкретику отдаёт методическим документам. Пункт 68 обязывает реализовывать меры "с использованием методических документов ФСТЭК" - отсылка обязывающая, не рекомендательная.

Методика оценки показателя Кзи (11 ноября 2025). Показатель k23 проверяет отсутствие паролей по умолчанию у сервисных УЗ. Сроков смены методика не устанавливает, но требует, чтобы парольная политика содержала требования к периодичности. А конкретные 90 дней приходят из следующего документа.

Методический документ "Состав и содержание мер" (12 апреля 2026). Отменил методичку 2014 года. Мера ИАФ.3 для парольной аутентификации задаёт параметры жёстко:

• Длина - не менее 12 символов
• Алфавит - не менее 70 символов
• Максимум 5 неуспешных попыток до блокировки
• Блокировка на 15 минут
• Смена паролей не более чем через 90 дней
• Запрет повторного использования

Мера ЗМУ.1 для мобильных устройств: пароль от 6 символов (10 для К1 и К2), смена не более чем через 30 дней, запрет повторного использования 12 последних паролей. Обязательно для всех классов: К1, К2, К3.

Финансовый контекст: по неофициальным оценкам (в частности, BearPass), штрафы по новой редакции КоАП могут составлять от нескольких миллионов рублей для юрлиц, при повторном нарушении - значительно больше (точные суммы сверяйте по актуальному тексту КоАП РФ). Показатель Кзи считается раз в полгода и отправляется во ФСТЭК. Если k21 провален дважды за 12 месяцев - весовой коэффициент всей группы "Защита пользователей" (вес 0,25) обнуляется по пункту 35 методики. Ещё жёстче: если при пентесте первоначальный доступ получен через учётные записи, группе присваивается ноль сразу, без второго шанса.

Сводная таблица: парольная политика NIST и ФСТЭК сравнение​

Прямое столкновение - ровно в одном пункте: периодическая ротация. Как отмечает разбор на Хабре, философии у стандартов разные. NIST оптимизирует поведение живого человека, у которого принудительная смена порождает Password2026!. ФСТЭК оптимизирует проверяемость - срок смены легко измерить и спросить одинаково у тысяч операторов.

При этом NIST по длине строже: 15 символов для single-factor против 12 у ФСТЭК. По блокировке наоборот - ФСТЭК жёстче: 5 попыток вместо 100. Каждый стандарт закрывает свой вектор: NIST делает пароль длиннее и уникальнее, ФСТЭК быстрее отсекает перебор.

Кого касаются требования ФСТЭК, а кому хватит NIST​

Граница прописана в пункте 1.2 методдока. Внутри контура - ГИС, госучреждения, ГУП, субъекты КИИ, значимые объекты КИИ. Для них 90 дней ротации - нормативная данность, и аргументы NIST на аттестации не работают.


Нюанс для финансов: ГОСТ Р 57580.1-2017 задаёт свои сроки - РД.19 (смена раз в год), РД.20 (эксплуатационный персонал - раз в квартал), РД.21 (длина 8 символов), РД.22 (16 символов для персонала). Если организация попадает под оба документа (госучреждение + финансы) - выполняется более строгое требование.

Detection и hardening: практическая реализация​

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

Для Linux (RHEL/Debian, FreeIPA) парольная политика реализуется через PAM. В /etc/security/pwquality.conf: minlen = 12, minclass = 3, dcredit = -1, ucredit = -1, lcredit = -1, ocredit = -1. В /etc/login.defs: PASS_MAX_DAYS 90, PASS_MIN_DAYS 1, PASS_WARN_AGE 14. Для существующих пользователей - через chage -M 90 -m 1 username.

Блоклист-скрининг: что стоит взять у NIST всем​

NIST обязывает проверять новые пароли по базам утечек. ФСТЭК этого не требует, но внедрение блоклиста не противоречит методдоку и закрывает реальный вектор. Пароль Zima2025! формально проходит complexity requirements ФСТЭК, но находится в первой тысяче при password spray.

В Active Directory блоклист реализуется через Azure AD Password Protection (гибридные среды с облачным сервисом) или Lithnet Password Protection - open-source решение, проверяющее пароли по Have I Been Pwned при каждой смене через password filter DLL. Для GNU/Linux - PAM-модуль pam-pwned или проверка по локально загруженной базе хешей.

Блоклист-скрининг - единственная мера, которая одновременно закрывает обязательное требование NIST и усиливает парольную политику ФСТЭК. Если организация работает в международном контуре (PCI DSS 4.0.1, SOC 2), внедрение блоклиста закрывает оба стандарта одним контролем. Из всего, что можно сделать за день, - это даёт максимальную отдачу.

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

90 дней без блоклист-скрининга и MFA - фикция безопасности. Пользователь меняет Zima2025! на Vesna2026!, формально проходит k21, аттестатор доволен, SIEM молчит, а пароль по-прежнему в первой сотне при credential stuffing. NIST запретил ротацию не потому что она "бесполезна", а потому что она работает только в связке с контролями, которых у большинства организаций нет. ФСТЭК оставил ротацию не потому что "отстал", а потому что 90 дней - единственный параметр, который можно проверить на тысячах операторов без глубокого технического аудита каждого.

Практический вывод для тех, кто прямо сейчас пишет парольную политику: ставьте 90 дней, если под ФСТЭК (вариантов нет), но параллельно внедряйте блоклист-скрининг и phishing-resistant MFA. Это не "выбор между NIST и ФСТЭК" - это сумма обоих подходов, где каждый закрывает слепые зоны другого. Если ваша команда настраивает парольный мониторинг и нужен обмен опытом - на codeby.net есть тред с разбором парольного аудита и примерами корреляционных правил для разных SIEM-платформ.