Какие ошибки превращают пароли из защиты в слабое место бизнеса
Введение
Несмотря на развитие технологий аутентификации, внедрение MFA и продвижение концепции zero trust, пароль по‑прежнему остается ключевым механизмом защиты учетных записей (УЗ). Инфраструктуры на базе Active Directory изначально завязаны на него как на универсальный идентификатор. Поэтому пароли становятся слабым звеном, уязвимым не только для словарного подбора, но и для мисконфигураций, связанных с хранением, ротацией и применением политик. Достаточно одного «вечного» сервисного пароля или нескольких слабых пользовательских комбинаций, чтобы превратить всю инфраструктуру в легкую цель.
Более того, в последние годы слабые пароли используются атакующими не только для проникновения, но и как инструмент публичного давления. Информация о том, что для критически важных УЗ годами не меняли пароли, наносит компаниям не меньший репутационный ущерб, чем сам инцидент. Это усиливает резонанс вокруг атаки, что особенно опасно в условиях высокой конкуренции и медийной прозрачности.
Управление паролями в крупных организациях редко соответствует рекомендациям Microsoft или CIS. Поэтому компрометация учетных данных стала одним из самых дешевых и быстрых способов проникнуть в корпоративную сеть, а также источником дополнительного PR‑ущерба. Частая причина компрометации — мисконфигурации, которые копятся в компаниях годами. Рассмотрим наиболее распространенные из них.
Простые или предсказуемые пароли
Это одна из самых распространенных и опасных мисконфигураций. Несмотря на развитие политик безопасности и существующие стандарты (CIS, Microsoft Baseline, NIST), в корпоративных сетях до сих пор встречаются такие пароли:
- Короткие комбинации с минимальной сложностью: 123456, Qwerty123, 1qaz@WSX.
- Сезонные вариации: Summer2024, Password2025.
- Личные или связанные с компанией данные: даты рождения, номера телефонов или названия организаций (например, CompanyName1!).
Подобные пароли используются в доменных и локальных УЗ, включая привилегированные аккаунты администраторов и сервисные учетные записи. Даже формально соответствующие требованиям (например, 8 символов, буквы и цифры), они могут быть взломаны с помощью атаки password spraying
Эту мисконфигурацию могут использовать на любом этапе атаки:
- Получение первоначального доступа. Подбор слабых паролей на периметре (например, на VPN‑шлюзе, общедоступном SSH-/RDP‑сервисе) дает прямой доступ в инфраструктуру.
- Продвижение по сети и повышение привилегий. Слабый пароль на локальной учетной записи администратора, особенно если он переиспользуется, становится «золотым билетом» для перемещения по сети или распространения шифровальщиков.
Согласно данным BI.ZONE TDR, для 2% локальных учетных записей используются слабые пароли. Для доменных УЗ этот показатель достигает в среднем 5% — столько защищены паролями, которые легко подбираются с использованием стандартных словарей. Кроме того, статистика BI.ZONE Digital Risk Protection показывает, что каждая 15‑я корпоративная УЗ хотя бы один раз оказывалась в утечках. В сочетании с недостатками парольной политики (отсутствие требований к длине, сложности, уникальности) это формирует ситуацию, когда базовые механизмы защиты могут быть скомпрометированы с минимальными усилиями.
Рекомендации
Технические меры
- Придерживайтесь политики сложности: минимальная длина — 12–14 символов, запрет на использование имени пользователя, названия компании и типовых последовательностей.
- Проверяйте новые пароли на наличие в утекших базах.
- Внедрите обязательную двухфакторную аутентификацию для всех пользователей.
- Внедрите корпоративный менеджер паролей.
Организационные меры
- Проводите регулярный аудит и отключайте неиспользуемые УЗ сотрудников и сервисов.
- Не допускайте повторного использования паролей в разных системах.
- Обучайте сотрудников работать с менеджерами паролей.
Мониторинг и аудит
- Внедрите автоматизированную проверку паролей: выявляйте слабые, предсказуемые или повторяющиеся.
Слишком длинный срок действия паролей
Хотя частая смена паролей снижает их качество (пользователи придумывают простые схемы), редкая смена не менее опасна. Распространенной мисконфигурацией является излишне длинный срок действия пароля, в том числе установка опции PasswordNeverExpires («никогда не истекает»), особенно для сервисных аккаунтов и администраторов. Это означает, что пароли не меняются годами, даже десятилетиями. Хотя современные рекомендации (NIST, Microsoft) отходят от принудительной ротации в пользу гибких подходов, полный отказ от нее без компенсирующих мер создает серьезную уязвимость.
Долгоживущие пароли увеличивают риски безопасности:
- Расширяется окно для эксплуатации утечки. Если пароль переиспользовался в сторонних сервисах и был скомпрометирован, злоумышленник может использовать его в любой момент.
- Повышается уязвимость к методам подбора. Без ротации у злоумышленников больше времени на брутфорс или перебор по словарю.
Команда BI.ZONE TDR проанализировала данные более 150 организаций: в 34% из них обнаружены более 1000 УЗ с атрибутом PasswordNeverExpires и лишь в 8% — менее 50. В среднем 22,3% учетных записей в домене имеют этот атрибут.
Хотя большинство паролей в компаниях моложе трех месяцев, почти 2% аккаунтов используют пароли старше 10 лет.
Рекомендации
- Исключите использование атрибута PasswordNeverExpires.
- Для сервисных УЗ перейдите на групповые управляемые сервисные аккаунты (gMSA), которые обеспечивают автоматическую и безопасную ротацию без ручного вмешательства. Внедрение gMSA снимает необходимость в «вечных» паролях и снижает риск эксплуатации таких аккаунтов злоумышленниками. Где переход на gMSA невозможен — внедрите контролируемые процессы принудительной ротации паролей.
- Контролируйте выполнение политики через регулярные аудиты Active Directory.
Неиспользуемые учетные записи
Учетные записи уволившихся сотрудников, временных подрядчиков, тестовые или устаревшие сервисные аккаунты могут оставаться активными месяцами или годами. Такие аккаунты сохраняют доступ к ресурсам, включая критически важные системы, и зачастую имеют слабые, неизменяемые пароли. Их существование — следствие отсутствия регулярного аудита, несовершенных процессов деактивации (например, при увольнении) и накопления легаси‑данных в инфраструктуре.
На первый взгляд такие УЗ безвредны: пользователь давно не появляется в сети, а система работает как обычно. Но для атакующего это находка по следующим причинам:
- Атаки могут начинаться именно с забытых УЗ: за ними никто не следит, и они не вызывают подозрений.
- Пароли к таким аккаунтам зачастую не менялись годами, могут быть небезопасными или уже скомпрометированными в ходе предыдущих атак и пентестов.
- К «заброшенным» УЗ редко применяются современные меры защиты, включая MFA.
Выявление неиспользуемых учетных записей в Active Directory осложняется отсутствием явных признаков их неактивности. Такие аккаунты могут использоваться в прикладном ПО или на устройствах под управлением Linux, из‑за чего параметр LastLogonDate (последний вход пользователя в домен) становится ненадежным индикатором. Тем не менее он остается полезным для первичного поиска потенциально неактивных УЗ.
По данным BI.ZONE TDR, около 5% доменных УЗ не использовались более трех лет. Это указывает на масштаб проблемы и значительное количество устаревших аккаунтов в инфраструктуре.
Подобная мисконфигурация встречается и среди привилегированных УЗ, включая группы Domain Admins и Enterprise Admins. Хотя такие случаи менее распространены, высокий уровень прав доступа этих пользователей требует особого контроля.
Рекомендации
- Регулярно проводите аудит Active Directory. Используйте скрипты и специализированные утилиты для поиска учетных записей, не входивших в систему более 90 дней. Особого внимания требуют аккаунты, которые никогда не использовались.
- Процесс увольнения сотрудника должен включать автоматическую деактивацию всех его учетных записей. Для временных сотрудников и подрядчиков необходимо заранее устанавливать срок действия УЗ.
- Контролируйте привилегированные аккаунты. Проверяйте, что уволенным администраторам заблокировали не только обычную УЗ, но и привилегированную (например, с суффиксом *‑admin).
- Поддерживайте CMDB и привяжите технические УЗ к сервисам и владельцам. Чтобы процесс отключения таких аккаунтов при выводе сервиса из эксплуатации был прозрачным, необходимо четко понимать, к кому обратиться за согласованием.
Слабые политики сложности и длины
Формальные требования вроде «минимум 8 символов» уже устарели. В 2026 году минимальная длина пароля должна составлять 12–14 символов, а уровень сложности предполагает комбинацию прописных и строчных букв, цифр и специальных символов. При этом должны быть исключены предсказуемые шаблоны (например, Summer2025!).
Без современных политик и проверки на совпадение с утекшими базами пользователи выбирают комбинации, взламываемые за минуты. Эта мисконфигурация часто возникает из‑за некорректных настроек Group Policy.
Сравним текущие средние параметры с рекомендуемыми:
| Параметр | Значение по умолчанию (Microsoft) | Среднее значение (данные BI.ZONE TDR) | Рекомендуемое значение | Комментарий |
|---|---|---|---|---|
| Минимальная длина пароля (MinPasswordLength) |
7 |
9 (у некоторых компаний 6) |
12–14 |
Требование 6–9 символов критически устарело и увеличивает уязвимость к взлому |
| Количество запоминаемых паролей (PasswordHistoryLength) |
24 |
14 |
24 |
Средний показатель ниже рекомендуемого, что позволяет чаще повторно использовать старые пароли |
| Максимальный срок действия пароля (MaxPasswordAge) |
42 дня |
133 дня (18% клиентов — навсегда) |
Зависит от парольной политики компании |
Бессрочное или длительное действие пароля повышают риски, особенно без MFA |
| Минимальный срок действия пароля (MinPasswordAge) |
1 день |
2 дня |
1–2 дня |
Стандартное значение предотвращает частую смену паролей |
| Порог блокировки (LockoutThreshold) |
0 (отключено) |
9 |
5–10 |
Значение ниже 5 может блокировать легитимных пользователей |
| Длительность блокировки (LockoutDuration) |
30 минут |
26 минут |
15–30 минут |
Временной промежуток чуть короче 30 минут удобнее для пользователей |
Пример: перебор 8‑значного числового пароля, защищенного bcrypt
Рекомендации
- Установите строгую парольную политику, используя указанные выше параметры.
- Внедрите MFA для всех аккаунтов, особенно привилегированных (например, с помощью PAM‑решения, такого как BI.ZONE PAM).
- Обучайте сотрудников созданию надежных паролей и основам кибербезопасности. Специализированные платформы помогут сделать такую работу систематической (например, платформа BI.ZONE Security Fitness).
Одинаковые пароли
Использование одних и тех же паролей для пользовательских и административных УЗ — распространенная и опасная мисконфигурация. Для работы с критическими сервисами, как правило, создаются отдельные УЗ, исключительно для выполнения специфических задач. Однако администраторы нередко задают для таких аккаунтов пароли, совпадающие с паролями их пользовательских УЗ. При этом данные аккаунты часто обладают широкими правами доступа к критическим системам и данным. Совпадение паролей создает уязвимость: скомпрометировав один аккаунт, злоумышленник с высокой вероятностью получает доступ к другим, что ставит под угрозу безопасность всей инфраструктуры.
Рекомендации
- Строго разграничьте пароли. Администраторы должны использовать выделенные УЗ для административных задач. Пароли сервисных аккаунтов должны быть уникальными.
- Используйте gMSA: пароли будут меняться автоматически, а извлечь их в открытом виде станет невозможно.
- Регулярно проверяйте пароли на дублирование. При выявлении совпадений между сервисными и пользовательскими УЗ незамедлительно меняйте пароли.
В 2026 году корпоративная безопасность по-прежнему во многом зависит от пароля — механизма, который все чаще становится источником уязвимости. Проблема в том, что инфраструктуры на базе Active Directory завязаны на пароле как основном идентификаторе. Именно это делает ошибки в управлении паролями критичными: достаточно одной неотключенной УЗ с устаревшим паролем или совпадения сервисных и административных комбинаций, чтобы открыть злоумышленникам доступ вглубь сети.
К технической стороне проблемы добавляется и медийный аспект. Публичная демонстрация слабых мест компании (например, элементарных комбинаций у топ‑менеджмента) подрывает доверие клиентов и усугубляет последствия утечек.
В итоге одна слабая комбинация может стоить бизнесу миллионы. Если компании не начнут системно пересматривать подходы к управлению паролями — усиливать требования к сложности и длине, внедрять gMSA, избавляться от вечных паролей и контролировать устаревшие УЗ, — любые инвестиции в безопасность останутся декларацией. А реальную защиту будут подрывать пароли, ломающиеся за считанные минуты.