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

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

Российские требования и зарубежные рекомендации не всегда совпадают. Методический документ ФСТЭК России от 12 апреля 2026 года устанавливает параметры простой парольной аутентификации, включая минимальную длину пароля 12 символов и его смену не более чем через 90 дней. В NIST SP 800-63B-4 подход другой: если пароль используется как единственный фактор, он должен содержать не менее 15 символов, но требовать его периодической смены без признаков компрометации нельзя. NIST также не рекомендует навязывать пользователям обязательные комбинации разных типов символов.

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

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

Сначала о статусе документов

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

Методический документ «Состав и содержание мероприятий и мер по защите информации, содержащейся в информационных системах», утверждённый 12 апреля 2026 года, определяет подходы к защите информации в предусмотренных им информационных системах, автоматизированных системах управления и информационно-телекоммуникационных сетях государственных органов, государственных унитарных предприятий, государственных учреждений и организаций, включая субъектов критической информационной инфраструктуры. Следовательно, сначала необходимо установить, относится ли конкретная система и организация к области применения документа и какие положения для неё актуальны.

Для простой парольной аутентификации документ устанавливает следующие параметры:

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

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

NIST – Национальный институт стандартов и технологий США. Документы серии SP 800 широко используются как ориентир при проектировании систем цифровой идентификации и аутентификации, но сами по себе не устанавливают обязательных требований для российских организаций.

ФСТЭК и NIST: что именно отличается

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

Параметр парольной политики	Методический документ ФСТЭК России, 2026 год	NIST SP 800-63B-4
Минимальная длина пароля	При простой парольной аутентификации – не менее 12 символов	Не менее 15 символов, если пароль является единственным фактором; не менее 8 символов, если используется в составе многофакторной аутентификации
Требования к набору символов	Алфавит пароля – не менее 70 символов	Нельзя вводить обязательные правила вроде «заглавная буква + цифра + специальный знак»
Плановая смена пароля	Не более чем через 90 дней в рамках указанной меры	Нельзя требовать периодическую смену без признаков компрометации
Проверка при создании пароля	В рассматриваемом фрагменте используются требования к длине и алфавиту	Новый пароль сравнивается со списками распространённых, ожидаемых и скомпрометированных значений
Менеджеры паролей	В рассматриваемой мере нет отдельного универсального требования об их использовании	Использование менеджеров паролей и автозаполнение должны быть разрешены

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

Почему NIST отказался от смены пароля по календарю

Логика старой парольной политики была понятна: если пользователь регулярно меняет пароль, украденный секрет со временем перестанет работать. Поэтому организации устанавливали срок действия пароля в 30, 60 или 90 дней.

Однако такая практика создавала побочный эффект. Когда человек вынужден часто менять секрет, который должен помнить, он нередко выбирает предсказуемое изменение предыдущего пароля. Например, Password1! превращается в Password2!, а затем в Password3!. Другой распространённый вариант – добавление обозначения месяца или года.

NIST учитывает такое поведение пользователей. В SP 800-63B-4 запрещено требовать периодическую смену пароля без признаков компрометации. Если же появились основания считать пароль скомпрометированным, его необходимо сменить.

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

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

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

Сложный пароль или длинный пароль

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

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

Например, password превращается в Password1, а при требовании специального символа – в Password1!.

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

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

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

Отсюда появляются менеджеры паролей

В NIST SP 800-63B-4 есть прямые требования разрешать использование менеджеров паролей и автозаполнение. Если автоматическое заполнение недоступно, рекомендуется не блокировать вставку пароля.

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

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

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

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

Для привилегированных учётных записей могут потребоваться отдельная архитектура и специализированные средства управления привилегированным доступом – PAM (Privileged Access Management).

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

Ещё одно важное изменение состоит в том, что пароль постепенно теряет центральную роль в архитектуре аутентификации.

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

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

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

Технических мер недостаточно без работы с поведением сотрудников

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

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

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

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

Как с этим работать российской компании

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

Если российский регулятор установил обязательные параметры парольной аутентификации для соответствующего контура, организация должна их выполнять независимо от зарубежных рекомендаций. В случае методического документа ФСТЭК от 12 апреля 2026 года необходимо дополнительно установить его применимость к системе, учесть её класс защищённости, типы пользователей и сценарии доступа, а также предусмотренные документом меры усиления.

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

При разработке политики ИБ-службе стоит ответить как минимум на следующие вопросы:

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

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

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

Зарубежный опыт полезен именно как опыт

NIST интересен российским специалистам не как замена национальным требованиям, а как пример пересмотра подходов к парольной безопасности.

В SP 800-63B-4 закреплены положения, которые заметно отличаются от привычной корпоративной практики: отказ от обязательной периодической смены паролей без признаков компрометации, отказ от обязательных комбинаций типов символов, разрешение менеджеров паролей и автозаполнения.

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

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

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

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