Что такое парольная политика организации?

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

Парольная политика — это не технические настройки Active Directory и не разовый инструктаж для персонала. Это комплексный организационно-технический документ, который регулирует весь цикл аутентификационных данных: от генерации пароля до его отзыва.

Для операторов государственных информационных систем (ГИС), информационных систем персональных данных (ИСПДн) и субъектов критической информационной инфраструктуры (КИИ) её наличие — требование регулятора.

Зачем нужна парольная политика: риски и статистика

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

• Устанавливает единые стандарты — все сотрудники создают пароли по одним правилам, а не по собственному усмотрению.
• Ограничивает срок жизни скомпрометированных учётных данных — регулярная ротация сужает окно возможной атаки.
• Защищает от перебора — требования к длине и сложности повышают энтропию пароля, блокировка учётной записи останавливает брутфорс.
• Разграничивает ответственность — фиксирует, кто и за что отвечает при инциденте.
• Закрывает требования регуляторов — для ГИС, ИСПДн и КИИ наличие политики обязательно по Приказам ФСТЭК №117, №21, №239.

Компрометация учётных данных — один из главных векторов атак на корпоративную инфраструктуру. Масштаб проблемы растёт: по данным ЭАЦ ГК InfoWatch, за три года (с 2023 по 2025 год) в мире было скомпрометировано более 100 млрд записей персональных данных, из них 4,5 млрд пришлось на Россию. Каждый инцидент становится крупнее: в 2025 году в среднем за одну утечку утекало 3,27 млн записей — на 44% больше, чем в 2023-м. Тогда же была зафиксирована одна из крупнейших утечек в истории — 16 млрд учётных записей (РБК, 2025).

Но вот парадокс: по данным Specops Breached Password Report 2024, 83% скомпрометированных паролей соответствовали требованиям длины и сложности корпоративной политики. Правила были — пароли им отвечали. Тем не менее аккаунты взламывали. Это означает, что проблема не в самих требованиях, а в том, как они соблюдаются на практике.

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

Основные элементы парольной политики

Длина и сложность пароля

Минимальная длина пароля по российским стандартам: 8 символов для базового уровня защиты, 12 — для усиленного (ГОСТ Р 57580.1-2017). NIST SP 800-63B рекомендует ориентироваться на 15+ символов и делать упор на длину, а не на замену букв цифрами.

Причина проста: надёжность пароля определяется энтропией, а энтропия растёт с длиной. Парольная фраза 3Электрика!Варят#Винегрет несравнимо устойчивее к перебору, чем P@r0l, — при том что запомнить её проще. Классические требования «хотя бы одна заглавная, одна цифра, один спецсимвол» при длине 8 символов дают ложное ощущение защиты: такие пароли давно покрыты словарями атак.

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

Срок действия и история паролей

Стандартный срок ротации по требованиям ФСТЭК России — 90 дней для большинства классов систем, 60 дней для ГИС 1-го класса и КИИ категорий 1–2. ГОСТ Р 57580.1-2017 также устанавливает смену не реже раза в 90 дней.

NIST SP 800-63B занимает принципиально иную позицию: принудительная периодическая смена паролей контрпродуктивна, если пароль не был скомпрометирован. Регулярная ротация вынуждает пользователей создавать предсказуемые вариации (Март2026 → Апрель2026), что снижает реальную безопасность. Смену следует инициировать по факту компрометации или при наличии признаков угрозы.

Для российских организаций приоритет — требования ФСТЭК. Рекомендации NIST можно использовать как методологическое дополнение при разработке политики.

Запрет на повторное использование паролей — обязательный элемент: история должна хранить не менее 5–10 предыдущих значений.

Блокировка учётных записей

Блокировка после нескольких неудачных попыток входа — базовая защита от брутфорса. Типичные параметры:

Для привилегированных учётных записей порог лучше снизить до 3–5 попыток с обязательным уведомлением администратора.

Сервисные учётные записи: слепая зона парольной политики

Большинство парольных политик регулируют только пользовательские учётные записи, оставляя в стороне сервисные (технические) учётные записи — аккаунты служб Windows, SQL-серверов, приложений, резервного копирования и других автоматизированных процессов. Это системная уязвимость: пароли таких учёток часто не менялись годами, их знают несколько человек, включая уволившихся сотрудников. Компрометация сервисной записи даёт злоумышленнику постоянный доступ к критичным системам.

Требования для сервисных учётных записей:

• Минимальная длина: 16 символов (в два раза больше, чем для обычных пользователей).
• Генерация: Криптографически стойким генератором, без ручного придумывания.
• Хранение: Исключительно в защищённом хранилище.
• Ротация: Обязательная смена при увольнении любого сотрудника, имевшего доступ к паролю.
• Доступ: Ограничен только теми, кому это необходимо для работы. Все обращения логируются.

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

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

По требованиям ФСТЭК, MFA обязательна для ГИС 1-го класса, ИСПДн УЗ-1, КИИ категорий 1–2, а также при удалённом доступе по ГОСТ Р 57580.1-2017.

Сравнение методов многофакторной аутентификации
Не все методы МФА одинаково надёжны. Выбор зависит от класса системы, сценария использования и уровня требуемой защиты.

Ключевые замечания

• SMS-коды уязвимы к атакам на протокол SS7 и перехвату SIM-карты. Для систем высокого класса защищённости ФСТЭК рекомендует аппаратные токены, сертифицированные ФСБ.
• Программные OTP (Google Authenticator, Microsoft Authenticator) обеспечивают хороший баланс между безопасностью и удобством для большинства корпоративных сценариев.
• Аппаратные токены — стандарт для привилегированного доступа и критичных систем, но требуют логистики распределения и восстановления.

Нормативные требования в России: ФСТЭК, ГОСТ и 152-ФЗ

Для операторов ГИС, ИСПДн и субъектов КИИ парольная политика — законодательное требование. Приказы ФСТЭК России №117 (ГИС), №21 (ИСПДн) и №239 (КИИ) обязывают реализовывать меры группы ИАФ (идентификация и аутентификация), включая ИАФ.1–ИАФ.6. Федеральный закон №152-ФЗ «О персональных данных» устанавливает обязанность оператора обеспечить защиту ИСПДн, конкретные технические меры для которой определяет Приказ ФСТЭК №21.

Сводная таблица требований по классам ИС

Источники: Приказ ФСТЭК №117, Приказ ФСТЭК №21, Приказ ФСТЭК №239, ГОСТ Р 57580.1-2017.

ФСТЭК vs NIST: ключевые различия подходов

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

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

Как внедрить парольную политику в организации

Внедрение парольной политики — это последовательный процесс, а не разовая настройка групповых политик (GPO) в Active Directory.

1. Разработать и утвердить нормативный документ. Положение о парольной защите должно охватывать все классы систем, роли пользователей (рядовые сотрудники, администраторы, привилегированные учётные записи) и процедуры реагирования на инциденты. Документ утверждается руководством и вводится приказом.
2. Реализовать технически. Для Windows-инфраструктуры — через групповые политики (GPO) в Active Directory: Fine-Grained Password Policy позволяет задавать разные требования для разных групп пользователей. Для Linux-окружения — через PAM (Pluggable Authentication Modules) и модуль pam_pwquality.
3. Обучить сотрудников. Технические ограничения без понимания причин порождают обходные манёвры. Объясните, почему Лето2025! — плохой пароль, даже если он формально соответствует политике. Кибергигиена работает только тогда, когда люди понимают логику требований.
4. Внедрить инструменты. Менеджер паролей и MFA — не опции, а обязательные компоненты работающей политики. Без них сотрудники физически не способны соблюдать требования к уникальности и сложности паролей для десятков систем.
5. Проверка соответствия документа и реализации. После утверждения политики и настройки GPO/PAM проведите аудит соответствия: каждому пункту документа должна соответствовать техническая настройка. Создайте матрицу соответствия «Требование политики ↔ Параметр GPO ↔ Ответственный», чтобы избежать пробелов. Это особенно важно для сервисных учётных записей и привилегированных групп.
6. Проводить регулярный аудит. Политика без контроля исполнения — декларация. Аудит должен включать проверку соответствия паролей требованиям, анализ журналов блокировок и попыток входа, а также периодическую проверку паролей по базам скомпрометированных учётных данных.

Типичные ошибки при внедрении парольной политики

Парольная политика часто внедряется неправильно, что сводит её эффективность к нулю. Пять типичных ошибок и способы их исправления:

Ошибка 1: Политика существует только на бумаге

• Сценарий: Документ утверждён, но групповые политики (GPO) не настроены. Пользователи устанавливают пароль 123456, и никто это не контролирует.
• Последствие: Требования не соблюдаются, система остаётся уязвимой.
• Как исправить: Каждый пункт документа должен иметь соответствующую техническую настройку в Active Directory, PAM или менеджере паролей.

Ошибка 2: Единая политика для всех пользователей

• Сценарий: Администраторы и рядовые сотрудники подчиняются одним правилам.
• Последствие: Привилегированные учётные записи остаются уязвимыми.
• Исправление: Использовать подробные политики паролей (Fine-Grained Password Policies, FGPP) для привилегированных групп. Администраторы должны иметь усиленные требования: минимум 12–16 символов, смена раз в 60 дней, блокировка после 5 попыток.

Ошибка 3: Забытые сервисные учётные записи

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

Ошибка 4: Отсутствие блокировки при переборе

• Сценарий: Без ограничения количества попыток входа система открыта для брутфорс-атак. Злоумышленник может перебирать пароли неограниченное время.
• Последствие: Система уязвима к автоматизированным атакам.
• Исправление: Включить Account Lockout Policy в GPO: блокировка после 5–10 неудачных попыток, время разблокировки 15–30 минут.

Ошибка 5: Отсутствие контроля над паролями при увольнении сотрудников

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

Вывод: Часть этих ошибок устраняется корпоративным менеджером паролей — он исключает хранение паролей в незащищённых местах, обеспечивает контролируемый доступ к сервисным учётным записям и ведёт полный журнал аудита.

Почему строгая политика без правильных инструментов не работает

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

Именно это объясняет статистику Specops из начала статьи: 83% взломанных паролей соответствовали корпоративной политике. Правила были выполнены формально — реальной защиты не было. Политика создала иллюзию безопасности.

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

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

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

• Двухфакторная аутентификация (2FA, 2ФА) — метод проверки личности, при котором для входа требуются ровно два независимых фактора из разных категорий: то, что пользователь знает (пароль), и то, чем он владеет (телефон с приложением-аутентификатором, SMS-код) или чем является (биометрия).
• Ротация паролей — регламентированная процедура плановой замены паролей через установленные промежутки времени или при наступлении триггерных событий: утечки данных, увольнения сотрудника, компрометации учётной записи. Снижает окно возможной атаки, ограничивая срок жизни скомпрометированных учётных данных. Применяется прежде всего к привилегированным и сервисным аккаунтам.
• Надёжность пароля — мера устойчивости пароля к подбору или взлому. Она определяет, насколько сложно злоумышленнику угадать или вычислить пароль с помощью атак методом перебора (brute force), словарных атак или других техник.
• Менеджер паролей — программный инструмент для безопасного хранения, генерации и управления паролями. В корпоративном контексте обеспечивает централизованный контроль доступа и аудит использования учётных данных.

Заключение

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

Протестируйте Пассворк в своей инфраструктуре: менеджер паролей разворачивается на вашем сервере, поддерживает требования ФСТЭК и снимает с сотрудников когнитивную нагрузку по управлению паролями → passwork.ru

Часто задаваемые вопросы

Как часто нужно менять пароли?

По требованиям ФСТЭК России — не реже одного раза в 90 дней для большинства классов систем, раз в 60 дней — для ГИС 1-го класса и КИИ категорий 1–2. NIST SP 800-63B рекомендует менять пароль только при признаках компрометации. Для российских организаций, подпадающих под действие Приказов ФСТЭК №117, №21 или №239, требования регулятора обязательны.

Какой пароль считается надёжным?

Надёжный пароль содержит не менее 12 символов, включая заглавные и строчные буквы, цифры и спецсимволы. Ещё лучше — парольная фраза длиной от 15 символов: она обладает высокой энтропией и при этом легче запоминается. Пароли вида P@r0l или Лето2026! — предсказуемы и давно включены в словари атак.

Обязательна ли парольная политика по закону?

Да, для операторов государственных информационных систем (ГИС), информационных систем персональных данных (ИСПДн) и субъектов критической информационной инфраструктуры (КИИ). Требования установлены Приказами ФСТЭК России №117, №21 и №239 в части мер ИАФ.1–ИАФ.6. Для финансовых организаций дополнительно применяется ГОСТ Р 57580.1-2017.

Что такое парольная фраза и чем она лучше обычного пароля?

Парольная фраза — это длинная последовательность слов или символов, используемая вместо традиционного пароля. Её надёжность определяется длиной: фраза из 4–5 случайных слов с разделителями (Кедр!Облако7Рельс#Маяк) устойчивее к перебору, чем короткий сложный пароль, — и при этом значительно проще для запоминания. NIST SP 800-63B прямо рекомендует поощрять использование парольных фраз.

Как менеджер паролей помогает соблюдать парольную политику?

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