Настройка политик паролей в Windows через GPO
Дисклеймер
Материал предназначен для специалистов по информационной безопасности, системных администраторов и разработчиков. Рассматриваются исключительно технологии и методики — принципы работы, архитектура, способы обнаружения и нейтрализации угроз. Статья носит образовательный характер, не содержит инструкций по созданию или распространению вредоносного ПО и не призывает к нарушению законодательства РФ. Ответственность за применение описанных методов лежит на читателе в рамках действующего законодательства.
Большинство инструкций по настройке парольных политик написаны для однородной среды: только Windows, только Active Directory, только современные системы. На практике инфраструктура выглядит иначе: рядом с контроллером домена работают Linux-серверы, СУБД с собственной аутентификацией, унаследованные приложения на NTLM и сканеры безопасности, которые не поддерживают длинные пароли. Одинаково сложный пароль на всех системах — это иллюзия: у каждой платформы своя реализация политики, и «слабое звено» определяется самым мягким из них. https://seberd.ru/2105
Часть I. Windows и Active Directory
Где живёт политика паролей и почему GPO не всесилен
Доменная политика паролей применяется только на уровне объекта домена — не OU, не сайта. GPO, привязанное к подразделению «Бухгалтерия», будет применяться ко всему остальному содержимому этого OU, но настройки Password Policy в нём будут проигнорированы. Применяется единственная политика, связанная с корнем домена с наименьшим значением Link Order.
Это ограничение — не баг, а архитектурное решение, существующее с момента появления Active Directory. Его обход — Fine-Grained Password Policies (FGPP), появившиеся в Windows Server 2008.
Путь к настройкам базовой политики: Конфигурация компьютера → Параметры Windows → Параметры безопасности → Политики учётных записей → Политика паролей
Локальные политики безопасности на машинах в домене перекрываются доменной политикой в части Password Policy. Настройка локальных политик имеет смысл только для автономных машин или серверов с изолированной ролью.
Параметры Password Policy: механика и граничные случаи
Минимальная длина. Значение ниже 12 символов в 2026 году не является обоснованным ни с технической, ни с регуляторной точки зрения. Современные GPU на hashcat перебирают пространство 8-символьных паролей с NTLM-хэшами за несколько часов. При длине 12 символов со смешанным регистром и цифрами время атаки переходит в диапазон лет.
Увеличение длины сверх 16 символов без параллельного отключения требований сложности создаёт парадоксальный эффект: пользователи создают длинные, но предсказуемые фразы — «КомпанияЗима2025!», «РаботаМоскваОфис». Такие пароли словарная атака с правилами мутации вскрывает за минуты.
Windows Server 2022 при функциональном уровне домена 2016 принимает пароли до 128 символов. Это актуально для паролей-фраз (passphrase) — подхода, который NIST рекомендует как альтернативу сложным коротким паролям.
Требования сложности. Встроенный механизм проверяет структуру (три из четырёх категорий: A–Z, a–z, 0–9, спецсимволы), но не проверяет предсказуемость. P@ssw0rd, Qwerty123! и Summer2024! проходят проверку сложности и одновременно входят в первые строки любого современного словаря атак. Встроенная проверка сложности — необходимое, но недостаточное условие.
Дополнительный барьер — Microsoft Entra Password Protection для on-prem (ранее Azure AD Password Protection). DC Agent перехватывает запрос на смену пароля через Password Filter DLL и проверяет его по глобальному списку запрещённых паролей и корпоративному словарю. Алгоритм нормализует варианты: P@ssw0rd, P4ssword и passw0RD считаются одним и тем же запрещённым словом.
Максимальный срок действия. NIST SP 800-63B с 2017 года рекомендует отказаться от периодической принудительной смены в пользу реакции на инциденты. Логика: при ежеквартальной смене пользователи переходят к инкрементным паролям — Qwerty2024Q1, Qwerty2024Q2. Хэши разные, история соблюдена формально, реальная стойкость не выросла.
Российские регуляторы (ФСТЭК, ЦБ РФ для финансовых организаций) требуют периодической смены. Разумный компромисс — 90 дней при длине 14+ символов. При более длинных паролях (16+) смену можно увеличить до 180 дней — это согласуется с логикой нового методдокумента к приказу №117 (смотри раздел для руководителей).
Минимальный срок действия. Значение 0 позволяет пользователю немедленно после принудительной смены изменить пароль ещё несколько раз и вернуться к старому. Установка 1–2 дней закрывает этот вектор обхода истории.
История паролей. Максимум — 24 записи. При истории 6 и нулевом минимальном сроке пользователь меняет пароль шесть раз за один вечер и возвращается к исходному. Связка «история 12 + минимальный срок 2 дня» создаёт реальный барьер в 24 дня.
Fine-Grained Password Policies: дифференциация без мифов
FGPP хранятся в контейнере CN=Password Settings Container,CN=System,DC=domain,DC=com как объекты класса msDS-PasswordSettings. Они применяются к группам безопасности или конкретным учётным записям — но не к OU. Это ограничение обходится через nested-группы.
При конфликте (пользователь входит в несколько групп с разными PSO) применяется политика с наименьшим значением Precedence. Если пользователю назначена PSO напрямую, она имеет приоритет над PSO, назначенной группе — вне зависимости от значения Precedence.
# Создание PSO для привилегированных учётных записей New-ADFineGrainedPasswordPolicy ` -Name "PrivilegedAccounts-PSO" ` -Precedence 10 ` -MinPasswordLength 16 ` -PasswordHistoryCount 24 ` -MinPasswordAge "1.00:00:00" ` -MaxPasswordAge "60.00:00:00" ` -LockoutThreshold 3 ` -LockoutDuration "00:30:00" ` -LockoutObservationWindow "00:30:00" ` -ComplexityEnabled $true ` -ReversibleEncryptionEnabled $false # Привязка к группе Add-ADFineGrainedPasswordPolicySubject ` -Identity "PrivilegedAccounts-PSO" ` -Subjects "Domain Admins", "Tier0-Admins" # Какая политика реально применяется к конкретному пользователю Get-ADUserResultantPasswordPolicy -Identity "j.smith" # Все PSO с их субъектами — сводная картина Get-ADFineGrainedPasswordPolicy -Filter * | ForEach-Object { $pso = $_ $subjects = Get-ADFineGrainedPasswordPolicySubject -Identity $pso.Name [PSCustomObject]@{ Policy = $pso.Name Priority = $pso.Precedence MinLen = $pso.MinPasswordLength MaxAge = $pso.MaxPasswordAge.Days Lockout = $pso.LockoutThreshold AppliedTo = ($subjects.Name -join ', ') } } | Format-Table -AutoSize
Типичные категории для разных PSO: Domain Admins и Tier 0 (строжайшая политика, 16+ символов, блокировка через 3 попытки), Service Desk и Tier 1 (усиленная, 14 символов), рядовые пользователи (базовая, покрывается доменной политикой).
Политика блокировки: точки отказа и диагностика
Агрессивная блокировка при наличии служб с устаревшими учётными данными — один из самых распространённых источников инцидентов. Сценарий типичный: пароль сервисного аккаунта сменили, но не обновили в планировщике задач, службе мониторинга и конфигурационном файле приложения. Через три минуты учётная запись заблокирована на весь домен — в том числе на рабочей станции пользователя, которому она не нужна вообще.
Диагностика источника блокировок:
# Найти DC, зафиксировавший блокировку, и компьютер-источник function Find-LockoutSource { param([string]$Username) $PDC = (Get-ADDomain).PDCEmulator $Events = Get-WinEvent -ComputerName $PDC -FilterHashtable @{ LogName = 'Security' Id = 4740 } -MaxEvents 1000 -ErrorAction SilentlyContinue $Events | Where-Object { $_.Properties[0].Value -eq $Username } | Select-Object TimeCreated, @{N='Account'; E={$_.Properties[0].Value}}, @{N='CallerComputer';E={$_.Properties[1].Value}}, @{N='DC'; E={$PDC}} } Find-LockoutSource -Username "j.smith"
Коды причины в событии 4625 (поле Sub Status):
gMSA: когда паролем управляет сам AD
Group Managed Service Accounts — архитектурное решение проблемы сервисных учётных записей. Пароль генерируется и ротируется контроллером домена каждые 30 дней (настраивается). Он никогда не вводится вручную и никогда не хранится в открытом виде в конфигурационных файлах или скриптах. Компрометация через keylogger или фишинг физически невозможна.
# Шаг 1: корневой ключ KDS (один раз на домен) Add-KdsRootKey -EffectiveTime (Get-Date).AddHours(-10) # Шаг 2: создание gMSA New-ADServiceAccount ` -Name "svc-webapp01" ` -DNSHostName "webapp01.corp.local" ` -PrincipalsAllowedToRetrieveManagedPassword "WebApp-Servers" ` -ManagedPasswordIntervalInDays 30 # Шаг 3: установка на целевом сервере Install-ADServiceAccount -Identity "svc-webapp01" Test-ADServiceAccount -Identity "svc-webapp01"
В конфигурации службы или пула приложений IIS указывается DOMAIN\svc-webapp01$ без пароля — Windows запрашивает его у DC автоматически. Парольная политика домена на gMSA не распространяется.
Перевод сервисных учётных записей на gMSA — не дополнительная опция, а базовая гигиена. Список учётных записей с флагом PasswordNeverExpires, которые не являются gMSA, — это техдолг с измеримым риском:
Get-ADUser -Filter { Enabled -eq $true -and PasswordNeverExpires -eq $true } -Properties PasswordLastSet, LastLogonDate, Description | Where-Object { $_.ObjectClass -ne 'msDS-GroupManagedServiceAccount' } | Select-Object Name, PasswordLastSet, LastLogonDate, Description | Sort-Object PasswordLastSet | Export-Csv "never_expires_accounts.csv" -Encoding UTF8 -NoTypeInformation
Скрытые взаимосвязи: где политика ломается в реальной эксплуатации
Windows Credential Manager. После смены пароля сохранённые учётные данные в диспетчере продолжают использовать старый пароль. Планировщик задач, OneDrive, почтовый клиент генерируют счётчик неудачных попыток. Пользователь успешно сменил пароль, а через 10 минут аккаунт заблокирован — потому что фоновые процессы об этом не знают.
Кэшированные учётные данные на ноутбуках. При работе вне домена Windows использует кэшированные хэши (по умолчанию — последние 10 входов). После смены пароля в домене кэш на ноутбуке не обновляется до следующего подключения к корпоративной сети или VPN. Пользователь входит на ноутбук по старому паролю — он работает локально, но не работает на ресурсах домена.
Репликация между DC. Смена пароля применяется на PDC Emulator немедленно, но репликация на другие DC занимает время: внутри сайта — секунды, между сайтами — от 15 минут при стандартных настройках ISTG. Пользователь в удалённом офисе получает отказ в аутентификации сразу после смены, пока изменение не реплицировалось.
LM-хэши. Если в инфраструктуре не отключено хранение LM-хэшей, пароли длиннее 14 символов разбиваются на блоки по 7 символов — что катастрофически снижает стойкость. Отключение через GPO: Сетевая безопасность: не хранить хеш-значения LAN Manager при следующей смене пароля.
Аудит событий — обязательная часть политики:
Часть II. Linux: PAM и интеграция с Active Directory
Архитектура аутентификации в Linux
На Linux аутентификация управляется через PAM — Pluggable Authentication Modules. Это стек модулей, каждый из которых отвечает за отдельный аспект: проверку пароля, его качество, блокировку, хранение. Конфигурация находится в /etc/pam.d/ — отдельный файл для каждого сервиса (sshd, login, sudo) и общие профили (common-auth, common-password на Debian/Ubuntu; system-auth, password-auth на RHEL/AlmaLinux).
Базовые настройки жизненного цикла пароля — в /etc/login.defs:
# /etc/login.defs — применяется к локальным учётным записям PASS_MAX_DAYS 90 # Максимальный срок действия PASS_MIN_DAYS 2 # Минимальный срок действия PASS_MIN_LEN 12 # Минимальная длина (устаревший параметр, pam_pwquality приоритетнее) PASS_WARN_AGE 14 # Предупреждение за N дней до истечения
Эти значения применяются только при создании новых учётных записей. Для изменения параметров существующих пользователей используется chage:
# Посмотреть текущие настройки chage -l username # Установить максимальный срок 90 дней, минимальный 2 дня, предупреждение за 14 chage -M 90 -m 2 -W 14 username # Принудить пользователя сменить пароль при следующем входе chage -d 0 username # Массово установить параметры для всех активных локальных пользователей for user in $(awk -F: '$3 >= 1000 && $7 !~ /nologin|false/ {print $1}' /etc/passwd); do chage -M 90 -m 2 -W 14 "$user" done
pam_pwquality: контроль качества паролей
Модуль pam_pwquality (пришедший на смену устаревшему pam_cracklib) проверяет качество пароля при его смене. Он значительно мощнее встроенной Windows-проверки: понимает словарные слова через libcrack, проверяет сходство с именем пользователя и старым паролем, учитывает классы символов с гибкими весами.
Конфигурация /etc/security/pwquality.conf:
# Минимальная длина minlen = 12 # Минимальное количество классов символов (из 4: строчные, прописные, цифры, спец) minclass = 3 # Максимум одинаковых символов подряд (aaaa — запрещено при maxrepeat = 3) maxrepeat = 3 # Максимум символов одного класса подряд (1234 — запрещено при maxclassrepeat = 4) maxclassrepeat = 4 # Минимум цифр (0 — не требовать явно, контролируется через minclass) dcredit = -1 # Минимум прописных букв ucredit = -1 # Минимум строчных букв lcredit = -1 # Минимум специальных символов ocredit = -1 # Проверка по словарю (требует установленного cracklib-dicts) dictcheck = 1 # Запрет пароля, содержащего имя пользователя usercheck = 1 # Насколько новый пароль должен отличаться от старого (количество изменённых символов) difok = 5 # Число попыток ввода пароля при смене до ошибки retry = 3
Привязка модуля в /etc/pam.d/common-password (Debian/Ubuntu):
password requisite pam_pwquality.so retry=3 password [success=1 default=ignore] pam_unix.so obscure use_authtok try_first_pass yescrypt
На RHEL/AlmaLinux/Rocky Linux (в /etc/pam.d/system-auth):
password requisite pam_pwquality.so try_first_pass local_users_only password sufficient pam_unix.so sha512 shadow nullok try_first_pass use_authtok
Алгоритм хранения паролей указывается явно: sha512 — минимум для современных систем. Более безопасная альтернатива на современных дистрибутивах — yescrypt (RHEL 9+, Ubuntu 22.04+): это memory-hard алгоритм, резко снижающий скорость брутфорса даже на GPU.
pam_faillock: блокировка по числу попыток
pam_faillock заменил устаревший pam_tally2. Он отслеживает неудачные попытки аутентификации и блокирует учётную запись при превышении порога.
Конфигурация /etc/security/faillock.conf:
# Число попыток до блокировки deny = 5 # Окно наблюдения в секундах (30 минут) fail_interval = 1800 # Время автоматической разблокировки (30 минут; 0 = до ручной разблокировки) unlock_time = 1800 # Блокировать даже root (осторожно: можно заблокировать себя) # even_deny_root # Аудит: логировать попытки audit
В PAM-стеке (/etc/pam.d/system-auth или common-auth):
auth required pam_faillock.so preauth audit silent auth sufficient pam_unix.so try_first_pass nullok auth [default=die] pam_faillock.so authfail audit
Управление блокировками:
# Статус конкретного пользователя faillock --user username # Разблокировать учётную запись faillock --user username --reset # Статус всех заблокированных faillock | grep -B1 'V '
История паролей в Linux
PAM хранит историю хэшей паролей в /etc/security/opasswd. Модуль pam_unix с параметром remember проверяет новый пароль против N предыдущих:
# В /etc/pam.d/common-password password required pam_unix.so use_authtok sha512 shadow remember=12
Файл /etc/security/opasswd должен быть доступен только root:
chmod 600 /etc/security/opasswd chown root:root /etc/security/opasswd
Интеграция Linux с Active Directory: SSSD и Winbind
Для организаций с AD в качестве центральной точки управления идентификацией Linux-системы подключаются к домену — тогда парольная политика применяется централизованно через SSSD (System Security Services Daemon) или Winbind.
SSSD + realmd — предпочтительный подход на современных дистрибутивах:
# Установка зависимостей (RHEL/AlmaLinux) dnf install realmd sssd oddjob oddjob-mkhomedir adcli samba-common-tools -y # Обнаружение домена realm discover corp.local # Ввод в домен realm join -U administrator corp.local # Проверка членства realm list id administrator@corp.local
Конфигурация /etc/sssd/sssd.conf:
[sssd] domains = corp.local config_file_version = 2 services = nss, pam
[domain/corp.local]
ad_domain = corp.local krb5_realm = CORP.LOCAL realmd_tags = manages-system joined-with-adcli cache_credentials = True id_provider = ad auth_provider = ad access_provider = ad chpass_provider = ad # Ограничение входа по группе AD ad_access_filter = memberOf=CN=Linux-Servers-Access,OU=Groups,DC=corp,DC=local # Не требовать FQDN при входе (user вместо user@corp.local) use_fully_qualified_names = False # Кэш учётных данных для работы без связи с DC krb5_store_password_if_offline = True
При такой конфигурации политика паролей для доменных пользователей берётся с AD — включая FGPP, если она назначена на группу. Смена пароля через passwd на Linux выполняет изменение в Active Directory через Kerberos.
Локальная политика PAM при AD-интеграции. SSSD применяет парольную политику AD для доменных учётных записей. Локальная политика PAM (pwquality, faillock) применяется только к локальным учётным записям (/etc/passwd). Оба механизма работают параллельно и не конфликтуют.
Проверка применяемой политики для доменного пользователя с Linux-хоста:
# Политика домена (требует пакета adcli) adcli info corp.local # Kerberos-тикет пользователя klist -e # К какому DC подключён SSSD sssctl domain-status corp.local
Часть III. Legacy-системы: когда политика и реальность расходятся
Что считать Legacy в контексте парольных политик
Legacy в данном контексте — не только старые ОС. Это любая система с одним из следующих ограничений: максимальная длина пароля меньше 14 символов; поддержка только NTLM без Kerberos; хранение паролей в обратимо-зашифрованном или открытом виде; невозможность принять спецсимволы в паролях; аутентификация через hardcoded-учётные данные в конфигурационных файлах.
Типичные представители: промышленные SCADA-системы 2005–2015 годов выпуска, унаследованные бухгалтерские и ERP-решения на основе Clipper/FoxPro/Delphi, сетевое оборудование с устаревшей прошивкой, сканеры и принтеры с веб-интерфейсом, старые версии СУБД с собственной аутентификацией (Oracle 9i–10g, MS SQL 2000).
NTLM: когда Kerberos недоступен
NTLM используется как fallback при недоступности Kerberos — обращение по IP-адресу вместо DNS-имени, недоступность DC, некоторые сценарии со смешанными доверительными отношениями. Для Legacy-систем NTLM нередко является единственным вариантом.
Уязвимость NTLM: передача хэша (pass-the-hash), NTLM relay-атаки, относительно быстрый брутфорс NTLM-хэшей. При вынужденном сохранении NTLM минимизация риска выглядит так: отключить NTLMv1 и NTLMv2 везде, где это технически возможно, оставив только NTLMv2; сегментировать Legacy-системы в отдельный VLAN с ограниченной маршрутизацией; настроить мониторинг событий 4776 (NTLM-аутентификация) для обнаружения аномалий.
GPO для ограничения NTLM: Конфигурация компьютера → Параметры Windows → Параметры безопасности → Локальные политики → Параметры безопасности → Сетевая безопасность: уровень проверки подлинности LAN Manager
Значение: Отправлять только NTLMv2-ответы. Отказывать LM и NTLM.
Системы с ограничением длины пароля
Некоторые Legacy-системы принимают пароль, но молча обрезают его до 8 или 14 символов. Пользователь устанавливает пароль MySecure2024! длиной 14 символов, а система хранит только MySecure. При следующем входе система принимает как MySecure2024!, так и MySecure — и пользователь об этом не знает.
Диагностика: проверить, принимает ли система разные суффиксы одного и того же «длинного» пароля. Если принимает — длина усекается.
Стратегия работы с такими системами:
- Выявить все системы с ограничением длины и задокументировать фактический лимит.
- Для таких систем создать отдельную PSO с максимальной длиной, равной лимиту системы, и усиленными требованиями сложности.
- Изолировать системы сетевым сегментированием — чтобы компрометация короткого пароля не давала доступа к другим ресурсам.
- Запланировать замену или обновление. Система с лимитом пароля 8 символов не может быть защищена на уровне, требуемом современными стандартами.
Обратимое шифрование: когда оно всё ещё включено
Параметр Хранить пароли, используя обратимое шифрование должен быть отключён везде. Он хранит пароль в форме, которая может быть расшифрована — фактически в открытом виде с дополнительным шагом. Включение этого параметра требуется только для CHAP-аутентификации (устаревший протокол) и некоторых Legacy-приложений, использующих аутентификацию через открытый текст.
Проверить, у кого включён этот флаг:
Get-ADUser -Filter {AllowReversiblePasswordEncryption -eq $true} ` -Properties AllowReversiblePasswordEncryption | Select-Object Name, SamAccountName, Enabled
Если список непустой — каждая запись требует анализа: почему включено, можно ли перевести приложение на другой метод аутентификации.
LAPS: управление паролями локальных администраторов
Windows LAPS (Local Administrator Password Solution) решает проблему одинакового пароля локального администратора на всех машинах домена. При компрометации одной машины атакующий получает доступ ко всем — это называется lateral movement через pass-the-hash.
LAPS (в версии Microsoft LAPS, встроенной в Windows Server 2019+) автоматически генерирует уникальный пароль для учётной записи локального администратора на каждой машине, хранит его в атрибуте AD-объекта компьютера и ротирует по расписанию.
# Настройка LAPS через PowerShell (Windows LAPS, встроен в Server 2019+) # Обновление схемы AD Update-LapsADSchema # Настройка разрешений на чтение паролей для группы Service Desk Set-LapsADComputerSelfPermission -Identity "OU=Workstations,DC=corp,DC=local" # GPO: Computer Configuration → Administrative Templates → System → LAPS # Backup directory: Active Directory # Password age: 30 days # Password length: 20 # Password complexity: Large letters + small letters + numbers + specials # Получить текущий пароль машины (для Service Desk) Get-LapsADPassword -Identity "PC-001" -AsPlainText
Интеграция Legacy в общую политику: практический подход
Не все Legacy-системы можно модернизировать немедленно. Практическая стратегия управления рисками в гетерогенной среде:
Инвентаризация и классификация. Каждая система, участвующая в аутентификации — даже периферийная, — вносится в реестр с указанием протокола аутентификации, ограничений на пароль и уровня риска. Без этого шага невозможно оценить реальную поверхность атаки.
Сегментация. Legacy-системы с ослабленными требованиями к паролям изолируются в отдельный сетевой сегмент с ограниченным доступом. Это не устраняет проблему, но локализует последствия компрометации.
Компенсирующие меры. Для систем, где невозможно применить современную парольную политику: дополнительный слой аутентификации перед доступом к системе (jump host, PAM-решение), усиленный мониторинг событий входа, ограничение источников подключения по IP.
Дорожная карта замены. Legacy-система без возможности модернизации входит в план замены с обоснованием риска. Риск формулируется в бизнес-терминах: «система хранит учётные данные в открытом виде, что при компрометации даёт атакующему…» — и далее конкретные последствия для конкретной организации.
Часть IV. Блок для руководителей
Приказ ФСТЭК №117 (утверждён 11 апреля 2025 года, вступил в силу 1 марта 2026 года) полностью заменил приказ №17, действовавший с 2013 года. Область применения расширена: помимо ГИС, требования распространяются на иные информационные системы государственных органов, ГУП и государственных учреждений, а также на подрядчиков, получающих данные из ГИС.
Главное концептуальное изменение — переход от разовой аттестации к непрерывному процессу. Вместо документа о соответствии, выданного раз в три года, — числовые показатели Кзи (коэффициент защищённости информации) и Пзи, которые рассчитываются и отчитываются регулярно. Действующие аттестаты по приказу №17 сохраняют силу до истечения срока, но ФСТЭК рекомендует начать разработку плана перехода (информационное сообщение №240/22/1492 от 12 марта 2026 года).
В части парольных требований методдокумент 2026 года к приказу №117 устанавливает конкретные значения: минимальная длина — 12 символов, буквы верхнего и нижнего регистра, специальные символы, отсутствие персонифицированных данных (имён, дат рождения, телефонов) в составе пароля. Для привилегированного доступа — обязательная строгая аутентификация или многофакторная, если техническое ограничение не позволяет реализовать строгую.
Приказ ФСТЭК №21 (ИСПДн, персональные данные) и Приказ №239 (КИИ) сохраняют силу. Требования к парольным политикам в них формулированы через меры группы ИАФ (идентификация и аутентификация) — конкретные значения параметров зависят от уровня защищённости (УЗ) и класса защищённости соответственно.
Регуляторные требования к параметрам пароля
Таблица отражает минимальные пороги регуляторов. Внутренняя политика организации может быть строже.
Как политика паролей влияет на стоимость инцидента
Компрометация учётных данных присутствует в 49% взломов корпоративных сетей по данным DBIR 2024. Среднее время обнаружения атаки через скомпрометированные учётные данные в российских компаниях составляло около 197 дней по данным Solar JSOC за 2023 год — почти полгода незамеченного присутствия в инфраструктуре.
При этом чрезмерно жёсткая парольная политика генерирует измеримые прямые расходы. Каждый сброс пароля через Service Desk — это от 10 до 30 минут рабочего времени специалиста плюс простой пользователя. При 500 пользователях, ежемесячной смене и 5% обращений в поддержку — 25 тикетов ежемесячно только по паролям. Умноженное на год и среднюю стоимость тикета, это сумма, которую можно сравнить с годовой подпиской на MFA-решение.
Три метрики для контроля эффективности
Количество сбросов пароля через Service Desk в месяц. Базовое значение устанавливается за первые три месяца после внедрения политики. Рост метрики после ужесточения требований — прямой индикатор пользовательского трения, которое рано или поздно приведёт к обходным паттернам.
Количество событий 4740 (блокировка) в неделю. Нормальный фоновый уровень определяется за период покоя без активных атак. Аномальный рост — сигнал либо атаки перебором (требует расследования источника), либо проблем с кэшированными учётными данными (требует инвентаризации сервисных аккаунтов).
Доля учётных записей с PasswordNeverExpires вне gMSA. Целевое значение — 0% для пользовательских учётных записей. Любое ненулевое значение — это учётная запись, выведенная из-под контроля парольной политики с явным или неявным обоснованием.
Что запросить у ИТ-команды как приоритет
Если политики паролей не пересматривались более двух лет, достаточно четырёх документов для принятия обоснованного решения о приоритетах:
- Выгрузка текущих настроек GPO и всех FGPP через PowerShell.
- Список учётных записей с PasswordNeverExpires = true, не являющихся gMSA.
- Анализ событий 4740 за последние 30 дней с разбивкой по источникам блокировок.
- Реестр Legacy-систем с ограничениями на парольную политику.
Эти четыре позиции дают полную картину фактического состояния без необходимости глубокого технического погружения.
Сводные конфигурации
Windows AD: три профиля
Linux PAM: минимальная безопасная конфигурация
# /etc/security/pwquality.conf minlen = 12 minclass = 3 maxrepeat = 3 dcredit = -1 ucredit = -1 lcredit = -1 ocredit = -1 dictcheck = 1 usercheck = 1 difok = 5 # /etc/security/faillock.conf deny = 5 fail_interval = 1800 unlock_time = 1800 audit # /etc/login.defs PASS_MAX_DAYS 90 PASS_MIN_DAYS 2 PASS_WARN_AGE 14
Диагностические команды — быстрый справочник
# Текущая политика домена Get-ADDefaultDomainPasswordPolicy # Политика, применяемая к конкретному пользователю Get-ADUserResultantPasswordPolicy -Identity "username" # Учётные записи с паролем старше 180 дней $cutoff = (Get-Date).AddDays(-180) Get-ADUser -Filter {Enabled -eq $true} -Properties PasswordLastSet | Where-Object {$_.PasswordLastSet -lt $cutoff} | Select-Object Name, PasswordLastSet | Sort-Object PasswordLastSet # Источник блокировки Get-WinEvent -ComputerName (Get-ADDomain).PDCEmulator ` -FilterHashtable @{LogName='Security'; Id=4740} -MaxEvents 100 | Select-Object TimeCreated, @{N='Account'; E={$_.Properties[0].Value}}, @{N='Source'; E={$_.Properties[1].Value}} # Linux: статус пользователя chage -l username faillock --user username # Проверка PAM-политики grep -r "pam_pwquality\|pam_faillock" /etc/pam.d/ # Подключение к домену realm list sssctl domain-status corp.local
Парольная политика — это не набор переключателей в одном GPO, а система, охватывающая несколько платформ, несколько уровней хранения учётных данных и несколько слоёв пользовательского поведения. Windows GPO покрывает доменные учётные записи, но не локальные администраторы без LAPS, не сервисные аккаунты без gMSA, не Linux-системы без SSSD, не Legacy с ограничениями на длину пароля.
Каждый непокрытый слой — это потенциальная точка входа, которая сводит на нет инвестиции в остальные уровни защиты. Инвентаризация всех точек аутентификации в инфраструктуре, дифференцированные политики через FGPP, замена сервисных аккаунтов на gMSA и честная работа с Legacy-ограничениями — это не дополнительные улучшения, а базовый уровень, без которого парольная политика остаётся декларацией на бумаге.