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

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

Что регулирует корпоративный стандарт

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

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

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

Основные цели регламента:

• Установить единые требования к учетным данным.
• Разделить правила по категориям пользователей и критичности систем.
• Запретить небезопасное хранение и передачу паролей.
• Определить порядок аудита и реагирования на отклонения.

Длина, сложность и срок действия

Чем длиннее пароль, тем сложнее его подобрать. Рекомендации NIST SP 800-63B-4рекомендации Национального института стандартов и технологий США по аутентификации и управлению средствами подтверждения личности устанавливают минимум 15 символов, если пароль остается единственным способом входа. При многофакторной аутентификации допустимый минимум составляет восемь символов. NIST также рекомендует поддерживать длину пароля не менее 64 символов.

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

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

Скачать памятку

Где и как настраиваются правила

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

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

В доменной инфраструктуре служба каталогов Active Directory Domain Services, или AD DS, позволяет задавать базовые параметры через групповые политики. Fine-Grained Password Policies назначают разные требования группам и отдельным пользователям одного домена, например усиливают правила для привилегированных аккаунтов. Итоговую политику, примененную к конкретному пользователю, можно проверить административными средствами Windows Server.

Последовательность работ:

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

Защита от перебора и повторного использования

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

Защита от подбора включает несколько уровней:

• Ограничение числа неудачных попыток входа за установленный период.
• Увеличение задержки между повторными попытками.
• Временная блокировка учетной записи.
• Оповещение ответственных сотрудников о подозрительной активности.
• Дополнительное подтверждение для критичных операций и привилегированных аккаунтов.

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

Практические меры защиты:

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

152-ФЗ и переход от приказа № 17 к приказу № 117

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

Приказ ФСТЭК России № 17 регулировал защиту информации в государственных информационных системах, но с 1 марта 2026 года утратил силу. Его заменил приказ № 117 для государственных информационных систем и других систем государственных органов, государственных унитарных предприятий и учреждений. С 1 сентября 2026 года применяются изменения, внесенные приказом ФСТЭК России № 137.

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

Понятные требования работают лучше

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

Эксперты Solar inRights

Корпоративные правила и ручной контроль

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

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

Типовые признаки проблемы:

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

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

Наведите порядок в учетных записях

Возьмите пользовательские и технические аккаунты, их владельцев, пароли и полномочия под централизованный контроль с помощью Solar inRights .

Попробовать бесплатно

Как IGA автоматизирует контроль

IGA (Identity Governance and Administration)класс систем для управления жизненным циклом учетных записей, правами, политиками, согласованиями и контролем доступа связывает жизненный цикл учетных записей и прав с корпоративными политиками. При наличии соответствующей интеграции может также централизовать управление отдельными параметрами учетных данных. Автоматизация снижает риск забытых прав и активных учетных записей после увольнения, а контроль парольных требований входит в оценку зрелости управления доступом.

В Solar inRights можно:

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

Технические учетные записи должны иметь владельца, понятное назначение и управляемый жизненный цикл. Если подключенная система поддерживает нужный сценарий, Solar inRightsроссийская IGA-платформа для централизованного управления учетными записями, правами доступа и связанными с ними процессами может автоматически инициировать сброс или смену пароля. Ответственные сотрудники получают уведомления, а информация об операции сохраняется в истории.

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

MFA (Multi-Factor Authentication)многофакторная аутентификация, при которой для входа используются не менее двух независимых факторов дополняет пароль вторым независимым фактором — например, подтверждением владения устройством / аппаратным ключом или биометрическим фактором. Такой подход важен для удаленного доступа, администраторов и критических приложений, поскольку пароль может быть похищен с помощью фишинга.

Обеспечьте единое выполнение правил

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

Запросить демонстрацию

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

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

Основные этапы внедрения:

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

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

Управляйте паролями централизованно

Надежная защита начинается с понимания, какие учетные записи существуют, кому они принадлежат и к каким ресурсам открывают доступ. Solar inRights собирает эти сведения в едином контуре и помогает управлять всем жизненным циклом аккаунтов — от создания до блокировки или удаления. Система помогает выявлять неактуальные и несогласованные УЗ и права в подключенном контуре.

Платформа позволяет:

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

Solar inRights интегрируется с корпоративной инфраструктурой через примерно 40 готовых коннекторов, а для нестандартных систем предусмотрен универсальный механизм REST + JSON. Это позволяет постепенно расширять охват по мере подключения новых приложений, подразделений и категорий учетных записей. Платформа сертифицирована ФСТЭК России по четвертому уровню доверия и включена в Единый реестр российского ПО, что позволяет использовать ее в проектах с учетом требований конкретной ИС.

В результате компания получает не просто инструмент для смены паролей, а единый центр управления учетными записями, правами и связанными с ними рисками. Solar inRights делает установленные требования исполнимыми, контроль — постоянным, а процессы доступа — прозрачными для ИБ, ИТ и владельцев информационных систем.

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