Управление паролями пользователей: политики Windows и Linux, хранение секретов и сброс

Зачем управлять паролями пользователей централизованно

Управление паролями пользователей складывается из трех частей: политика (сложность, срок действия, история, блокировка после неудачных попыток), хранение (менеджеры секретов и хранилища вроде HashiCorp Vault или KeePass) и процессы сброса (самостоятельный сброс через SSPR либо обращение в поддержку). Порядок работ такой: сначала единая политика и одна точка хранения привилегированных паролей, затем автоматизация сброса. Обратная последовательность дает пользователям удобный сброс пароля, который приходится менять через месяц, потому что требования к паролям так и не определены.

Локальные настройки расходятся быстро. На одном сервере минимальная длина пароля 8 символов, на другом 12, в третьей системе после установки нет ни истории, ни блокировки. Привилегированные пароли живут в заметках, в переписке и в файлах .env внутри репозиториев. Итог: на вопрос, в каких системах у уволившегося сотрудника остался доступ, никто не отвечает без отдельного аудита.

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

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

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

Дальше приведены параметры конфигураций по документации Microsoft, Red Hat и HashiCorp. Перед раскаткой в продакшене сверяйте набор опций с версией вашей ОС: имена модулей PAM и доступные ключи отличаются между релизами дистрибутивов.

Парольная политика Windows через Group Policy

В домене Active Directory требования к паролям задаются через Group Policy Management Console (оснастка gpmc.msc). Путь к настройкам: Computer Configuration → Policies → Windows Settings → Security Settings → Account Policies. Внутри два узла: Password Policy и Account Lockout Policy.

Политику применяют к Default Domain Policy или к отдельному GPO, привязанному к конкретному подразделению. Первый вариант затрагивает всех пользователей домена сразу, второй позволяет обкатать значения на тестовом OU. Для групп с особыми требованиями, например администраторов домена или сервисных учетных записей, работают Fine-Grained Password Policies на базе объектов PSO, доступные в доменах с функциональным уровнем Windows Server 2008 и выше.

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

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

Срок смены в 30 дней выглядит строго, но на практике ведет к предсказуемым инкрементам вида Password1 → Password2. Компромисс 60-90 дней дает пользователю время придумать новую фразу, а компании сохраняет ограничение на срок жизни утёкшего пароля. Minimum password age в 1 день закрывает обход истории: без него сотрудник меняет пароль несколько раз подряд и возвращается к исходному значению.

История паролей хранится в доменной базе NTDS.dit на контроллерах. Смена пароля самим пользователем и сброс пароля администратором обрабатываются по-разному, поэтому поведение истории перед раскаткой проверяют на тестовом домене: предсказуемость здесь важнее скорости.

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

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

Доменная политика блокировки не распространяется на локальные учетные записи компьютеров вне домена, там настройки задают локально. Контроль ведут по журналу безопасности: событие 4740 фиксирует блокировку учетной записи, 4625 - неудачный вход. Оба события стоит вывести в систему мониторинга, иначе о волне подбора паролей администратор узнает от пользователей.

Применение и проверка выполняются стандартными средствами: gpupdate /force обновляет политику на клиенте, gpresult /r показывает примененные объекты, rsop.msc строит итоговый набор параметров. Привязка политики к Default Domain Policy затрагивает всех, поэтому тестовый OU обязателен.

Настройка парольной политики в Linux: pam_pwquality и pam_cracklib

В Linux требования к паролям проверяет стек PAM. Модуль pam_cracklib исторически использовался в RHEL и Debian, сейчас его вытеснил pam_pwquality: он совместим по большинству параметров и умеет сверять пароль со словарем. Если в конфигурации вы видите pam_cracklib, переход на pam_pwquality не требует переписывать все ключи, но сами параметры стоит сверить с документацией вашего дистрибутива.

Настройки pam_pwquality лежат в /etc/security/pwquality.conf и в каталоге /etc/security/pwquality.conf.d/, параметры pam_cracklib - в /etc/security/pam_cracklib.conf. Подключение модуля выполняется в /etc/pam.d/common-password в Debian и Ubuntu либо в /etc/pam.d/system-auth в RHEL, CentOS, Rocky Linux, AlmaLinux:

password requisite pam_pwquality.so retry=3 local_users_only

Разбор связки PAM с SSH и sudo, включая безопасное отключение парольного входа, собран в отдельном руководстве по аутентификации и безопасному доступу в Linux.

Параметры pwquality.conf с примерами

Рабочий набор значений для сервера общего назначения:

minlen = 12
dcredit = -1
ucredit = -1
lcredit = -1
ocredit = -1
retry = 3
difok = 3
maxrepeat = 3
maxclassrepeat = 4
gecoscheck = 1
dictcheck = 1

Отрицательное значение dcredit, ucredit, lcredit, ocredit задает минимум символов соответствующего класса: цифры, заглавные буквы, строчные буквы, прочие символы. Положительное значение задает максимум таких символов в пароле. minlen задает минимальную длину, retry - количество попыток ввода при смене пароля, difok - сколько символов должно отличаться от предыдущего пароля. maxrepeat и maxclassrepeat ограничивают повторы одного символа и одного класса символов. gecoscheck запрещает использовать данные из поля GECOS (имя, телефон), dictcheck сверяет пароль со словарем.

Историю паролей контролирует отдельный модуль pam_pwhistory и его параметр remember: именно он не дает повторно использовать последние N паролей. В pwquality.conf параметра remember нет, и прописанная там строка не даст эффекта. Настройки pam_pwhistory лежат в /etc/security/pwhistory.conf, подключение выполняется в том же файле PAM строкой password requisite pam_pwhistory.so remember=5.

Проверить пароль до его применения можно утилитой pwscore:

echo 'Zx7#kLm2Qw9p' | pwscore

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

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

Неудачные попытки входа в Linux ограничивает pam_faillock. Параметры задаются в /etc/security/faillock.conf:

deny = 5
unlock_time = 900
fail_interval = 900
even_deny_root
audit

deny задает число неудачных попыток до блокировки, fail_interval - окно в секундах, в котором они подсчитываются, unlock_time - длительность блокировки. Опция even_deny_root распространяет правило на root: включайте ее осознанно, поскольку она открывает путь к блокировке привилегированной учетной записи. Модуль подключают тремя строками в /etc/pam.d/system-auth и /etc/pam.d/password-auth:

auth required pam_faillock.so preauth
auth [default=die] pam_faillock.so authfail
account required pam_faillock.so

В RHEL 8 и новее правки PAM удобнее делать через authselect: команда authselect enable-feature with-faillock включает профиль блокировки без ручного редактирования файлов. Состояние блокировок смотрят командой faillock --user имя_пользователя, сброс выполняют через faillock --reset.

Правка файлов в /etc/pam.d/ способна заблокировать вход в систему. Держите открытую root-сессию во втором терминале или консоль гипервизора до проверки нового входа и сохраните копии изменяемых файлов.

Хранение паролей и секретов: Vault и KeePass

Парольная политика определяет форму пароля, но не отвечает на вопрос, где он хранится. Два подхода закрывают разные задачи. HashiCorp Vault работает как серверное хранилище секретов с API, аудитом и выдачей динамических учетных данных. KeePass и KeePassXC остаются локальным менеджером с зашифрованной базой KDBX, которому не нужна серверная инфраструктура.

Vault отдает секреты по API и создает их на лету: secret engine для баз данных генерирует временную учетную запись с заданным TTL и удаляет ее по истечении срока. Движки KV, database, AWS, PKI подключаются как отдельные точки выдачи, аудит пишется в отдельные устройства логирования, а интеграция с Kubernetes выполняется через Vault Agent Injector или Secrets Store CSI driver, поэтому секрет попадает в под без ручного копирования в манифесты. Плата за это - сервер, TLS-сертификаты, процедура unseal и резервные копии storage backend. Развернуть Vault можно на VDS с отдельным диском, например на облачном сервере Timeweb Cloud.

KeePassXC хранит базу в формате KDBX с шифрованием AES-256 или ChaCha20 и ключевой функцией Argon2. Для небольшой команды достаточно базы на общем сетевом ресурсе, но такая схема требует дисциплины: конфликты синхронизации и одновременное редактирование приводят к потере записей. Мастер-пароль восстановить нельзя, и забытый пароль означает потерю доступа ко всей базе.

Секреты бывают разного происхождения: пароли к базам данных, токены CI, ключи внешних API. Если команда пользуется сторонними сервисами, например агрегатором моделей AiTunnel, ключи к нему тоже стоит хранить в Vault и ротировать, а не держать в .env внутри репозитория.

Когда выбирать Vault, а когда KeePass

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

Практический пример: пять администраторов с общими паролями от панелей управления закрывают задачу базой KeePass на защищенном сетевом ресурсе с key-файлом на отдельном носителе. Когда в инфраструктуре больше пятидесяти микросервисов с доступом к базе данных, выбор смещается в сторону Vault с database secret engine и коротким TTL, чтобы пароли не жили в конфигурациях.

Классы решений и их различия по модели доверия разобраны в статье об обзоре систем хранения паролей, а критерии для команды DevOps - в материале о том, как выбрать корпоративное хранилище паролей.

Базовые правила хранения мастер-паролей и ключей

Доступ к хранилищу восстанавливают заранее, а не в момент инцидента. В Vault ключи unseal делят по схеме Шамира: например, на пять частей с порогом три. Части хранят у разных ответственных, в разных физических местах, в запечатанных конвертах или сейфах. Для автоматического unseal используют облачный KMS или HSM: ручная процедура исчезает, но появляется зависимость от внешнего сервиса.

В KeePass роль второго фактора выполняет key-файл: база открывается только при наличии и мастер-пароля, и файла, который лежит на отдельном носителе. Рабочие правила выглядят так:

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

Порядок копирования и сценарии восстановления после потери мастер-пароля описаны в руководстве по резервному копированию хранилищ паролей.

Самостоятельный сброс пароля пользователем

Сброс пароля остается самой частой причиной обращений в поддержку, и именно его проще всего перевести в самообслуживание. Схема SSPR (Self-Service Password Reset) одинакова для разных платформ: пользователь подтверждает личность одним или несколькими способами, после чего система разрешает задать новый пароль. В облачных сценариях Microsoft Entra ID это встроенная функция с политикой на всю организацию. Для локального Active Directory на своих серверах нужен Microsoft Identity Manager либо сторонние продукты вроде ManageEngine ADSelfService Plus, которые публикуют веб-портал и синхронизируются с каталогом.

В Linux самостоятельный сброс строят на связке LDAP и веб-приложения, например self-service-password: пользователь вводит логин, подтверждает личность по email или SMS и задает новый пароль через тот же стек PAM, что и при обычном входе. Веб-интерфейс разворачивают на отдельном хосте, желательно в изолированном сегменте, с обязательным HTTPS.

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

Отдельный сценарий возникает при выводе из эксплуатации корпоративных мобильных устройств. Если смартфон на Android привязан к Google-аккаунту уволившегося сотрудника, после сброса настроек сработает Factory Reset Protection и устройство запросит логин и пароль от прежнего аккаунта. Механизм привязки хранится в отдельном разделе памяти и не стирается вместе с пользовательскими данными, а штатный сброс через меню на разблокированном устройстве, как правило, снимает защиту корректно, поскольку система видит, что операцию инициировал владелец (как работает FRP и когда его снимают).

Риски слабых паролей и переход к MFA

Строгие требования к паролям не закрывают основные атаки на учетные записи:

• Брутфорс: перебор по словарю и маскам, от которого защищает блокировка после N неудачных попыток.
• Credential stuffing: подстановка логинов и паролей, утёкших с других сервисов, в ваши системы. Атака работает за счет повторного использования пароля человеком.
• Фишинг: сотрудник сам вводит пароль на поддельной странице входа, и требования к сложности ему не мешают.
• Перехват кодов SMS через подмену SIM или атаку на оператора связи, из-за чего SMS остается самым слабым вторым фактором.

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

MFA снимает часть этих рисков: украденный пароль без второго фактора не дает войти в систему. Варианты второго фактора различаются по стойкости. TOTP (RFC 6238) работает в приложениях Google Authenticator, FreeOTP, Aegis и требует только синхронизации времени. Аппаратные токены FIDO2 и WebAuthn, например YubiKey, привязывают вход к домену сайта и устойчивы к фишингу, поскольку подпись проверяет сервис, а не человек. Push-уведомления удобны, но требуют защиты от усталостных атак, когда пользователю десятками приходят запросы на подтверждение входа.

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

Как внедрить политику без ошибок: чек-лист и типичные проблемы

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

1. Соберите инвентаризацию: где хранятся пароли, какие системы используют локальные учетные записи, какие сервисы аутентифицируются по LDAP или AD.
2. Разверните тестовый стенд с копией OU и конфигураций PAM, проверьте новые значения на группе из 5-10 добровольцев.
3. Предупредите пользователей за 1-2 недели: что меняется, с какой даты, куда обращаться при проблемах.
4. Применяйте поэтапно: сначала сложность и минимальная длина, через 2-3 недели срок действия и история, затем блокировка учетных записей.
5. Сохраните резервные копии GPO и изменяемых файлов в /etc/pam.d/ и /etc/security/.
6. Настройте мониторинг: события 4740 и 4625 в Windows, вывод faillock и журналы pam_unix в Linux.
7. Опишите план отката: как отключить политику, к кому обращаться, какой пароль использовать для аварийного входа.

Типичные ошибки повторяются из проекта в проект: политику применяют сразу к Default Domain Policy, не проверив ее на тестовом подразделении; выставляют срок смены 30 дней и получают предсказуемые инкременты в паролях; забывают про escrow мастер-пароля хранилища и теряют доступ к базе при уходе единственного администратора; не учитывают локальные учетные записи и сервисные аккаунты, которые не подчиняются доменной политике; не настраивают мониторинг блокировок, поэтому о волне неудачных входов узнают от пользователей.

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

Начните с двух действий, которые дают эффект в тот же день: вынесите привилегированные пароли из заметок и чатов в одно хранилище (Vault для инфраструктуры с API, KeePassXC для небольшой команды) и включите блокировку учетных записей после 5-10 неудачных попыток. Дальше последовательно настройте сложность и срок действия, добавьте самостоятельный сброс и завершите обязательным MFA для администраторов.