Контроль повторного использования паролей в компании: политика, мониторинг и отчётность без лишней бюрократии

Содержание

1. Краткое содержание
2. Введение
3. Что такое контроль повторного использования паролей
4. Почему повторное использование паролей остаётся проблемой
5. Основные понятия
6. Как работает контроль повторного использования паролей
7. Архитектура контроля в корпоративной сети
8. Политика контроля повторного использования паролей
9. Технический мониторинг: что реально проверять
10. Российский контекст: персональные данные, ГИС и КИИ
11. Практические примеры внедрения
12. Типичные ошибки
13. Сравнение подходов
14. Отчётность: что показывать руководству
15. Лучшие практики
16. Чек-лист внедрения контроля повторного использования паролей
17. Контроль в разных средах: AD, Linux, SaaS и DevOps
18. Пример внутреннего регламента: что в нём должно быть
19. Отраслевые особенности
20. Как построить отчёт для руководства
21. Минимальная дорожная карта на 90 дней
22. FAQ
23. Основные выводы
24. Источники

Краткое содержание

Контроль повторного использования паролей — это не только настройка параметра «запомнить N последних паролей» в домене. Зрелый подход включает четыре слоя: понятную парольную политику, техническое ограничение повторного использования паролей, мониторинг признаков компрометации и регулярную отчётность для ИБ, ИТ и руководства. Главная цель — не заставить сотрудников каждые 30 дней придумывать всё более предсказуемые пароли, а снизить риск захвата учётных записей через credential stuffing, password spraying, утечки внешних сервисов и повторное использование корпоративного пароля в личных аккаунтах.

Современные рекомендации NIST делают акцент на длине пароля, проверке новых паролей по спискам известных, ожидаемых и скомпрометированных значений, а также на многофакторной аутентификации. Microsoft отдельно подчёркивает: сотрудникам нельзя повторно использовать корпоративный пароль на внешних сайтах, потому что компрометация стороннего сервиса повышает вероятность взлома рабочих аккаунтов. Для России это особенно важно в системах с персональными данными, ГИС, КИИ и критичными бизнес-сервисами, где требуется управление доступом, регистрация событий безопасности и реагирование на инциденты.

Введение

Повторное использование паролей кажется мелкой бытовой проблемой. Сотрудник использует один и тот же пароль для корпоративной почты, личного маркетплейса, старого форума и облачного сервиса. Удобно? Да. Опасно? Очень.

На практике злоумышленнику не всегда нужно ломать периметр, эксплуатировать сложную уязвимость или писать эксплойт. Иногда достаточно купить или скачать базу утёкших логинов и паролей, найти там корпоративный email сотрудника и попробовать этот же пароль в VPN, почте, CRM, Git, RDP-шлюзе или облачном кабинете. Этот сценарий называется credential stuffing — автоматизированная проверка утёкших пар «логин-пароль» на других сервисах. MITRE ATT&CK прямо описывает его как подтип brute force: атакующие используют опубликованные после взломов учётные данные, рассчитывая на привычку людей применять один пароль в нескольких местах MITRE ATT&CK T1110.004.

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

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

Что такое контроль повторного использования паролей

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

Важно разделять несколько разных сценариев:

Почему это важно

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

Какие риски возникают

Главные риски — захват учётной записи, lateral movement, компрометация привилегированных доступов, утечка данных и невозможность точно понять, где ещё применялся тот же пароль.

Типичные ошибки

Компании часто ограничиваются только настройкой history в Active Directory и считают, что проблема решена. Но password history защищает только от повторного использования старого пароля в рамках одной учётной записи. Она не видит повтор между разными аккаунтами и не понимает, использовал ли сотрудник этот пароль на стороннем сайте.

Как поступают зрелые компании

Зрелые компании комбинируют password history, запрет слабых и скомпрометированных паролей, MFA, SSO, PAM, мониторинг утечек, SIEM-корреляции и обучение сотрудников. То есть работают не только с паролем как строкой, а с риском компрометации учётной записи целиком.

Почему повторное использование паролей остаётся проблемой

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

Если каждые 30 дней заставлять сотрудника менять пароль и одновременно требовать заглавные буквы, цифры, спецсимволы и запрет похожести на прошлые значения, он начинает использовать предсказуемые схемы: Company2025!, потом Company2026!, потом Company2026!!. Формально политика выполнена. По факту пароль угадываем.

NIST SP 800-63B рекомендует при установке или смене пароля сравнивать новый пароль со списками общеупотребимых, ожидаемых и скомпрометированных значений, а не полагаться только на требования сложности NIST SP 800-63B. OWASP также указывает, что современные парольные требования должны избегать избыточных правил состава и уделять больше внимания длине, блокировке известных слабых паролей, защите от credential stuffing и MFA OWASP Authentication Cheat Sheet.

Microsoft в рекомендациях по парольной политике для Microsoft 365 отдельно подчёркивает: один из самых важных сигналов для пользователей — не использовать корпоративный пароль где-либо ещё, потому что применение рабочего пароля на внешних сайтах резко повышает вероятность компрометации Microsoft Password Policy Recommendations.

Почему это важно

Если политика неудобна, сотрудники начинают обходить её. В итоге формально требования есть, но реальная безопасность падает.

Какие риски возникают

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

Типичные ошибки

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

Как избежать ошибок

Нужно строить политику вокруг рисков: длинные пароли или парольные фразы, запрет скомпрометированных значений, MFA, парольные менеджеры, SSO и технический контроль.

Основные понятия

Password reuse

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

Credential stuffing

Автоматизированная атака, при которой злоумышленник проверяет утёкшие пары «логин-пароль» на других сервисах. MITRE ATT&CK описывает credential stuffing как отдельную технику T1110.004 MITRE ATT&CK T1110.004.

Password spraying

Атака, при которой один слабый пароль проверяется сразу на множестве учётных записей. Например, Winter2026! или Company123!. Это позволяет избежать блокировки конкретного аккаунта после большого числа попыток.

Password history

Механизм, который не позволяет пользователю вернуть один из предыдущих паролей. В Active Directory это настраивается через доменную политику. Но важно понимать ограничение: password history не защищает от повторного использования пароля в других системах.

Password blocklist / banned password list

Список запрещённых паролей: общеупотребимые, ожидаемые, корпоративные шаблоны, пароли из утечек, названия компании, брендов, продуктов, городов, сезонов и годов. Microsoft Entra Password Protection применяет глобальный список запрещённых паролей и позволяет создавать пользовательский список для организации Microsoft Entra Password Protection.

MFA

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

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

Контроль строится на нескольких уровнях. Один механизм не решает всё.

1. Политика паролей

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

Хорошая политика написана понятным языком. Не «пользователь обязан обеспечить конфиденциальность аутентификационной информации», а: «нельзя использовать рабочий пароль в личной почте, соцсетях, маркетплейсах, тестовых сервисах и у подрядчиков».

2. Техническая блокировка слабых и повторяющихся паролей

Технические меры должны не только описывать правила, но и не позволять их нарушить. Примеры:

• password history в Active Directory;
• custom banned password list в Microsoft Entra ID;
• password filter на контроллерах домена;
• проверка новых паролей по внутреннему списку запрещённых слов;
• запрет использования названия компании, домена, продукта, фамилии пользователя;
• применение PAM для администраторов и сервисных аккаунтов.

3. Мониторинг признаков повторного использования

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

• серия входов в разные сервисы с одного внешнего IP;
• неуспешные попытки входа по многим аккаунтам;
• входы с необычных геолокаций или ASN;
• попытки входа в VPN, почту и облако с одинаковым набором учётных данных;
• обнаружение корпоративных email в утёкших базах;
• использование одного локального администратора на нескольких машинах;
• одинаковые сервисные секреты в конфигурациях.

MITRE рекомендует мониторить множественные неуспешные попытки аутентификации по разным аккаунтам как возможный признак password spraying MITRE ATT&CK T1110.

4. Отчётность и управление риском

Отчётность нужна не «для галочки». Она показывает руководству, где риск накапливается: у каких подразделений больше исключений, где нет MFA, какие критичные системы не подключены к мониторингу, сколько сотрудников попали в утечки.

Архитектура контроля в корпоративной сети

В зрелой компании контроль повторного использования паролей обычно выглядит так:

Практический комментарий

Если в компании есть SSO, это не отменяет контроль повторного использования паролей. Наоборот, SSO делает один пароль более критичным. Если он скомпрометирован, злоумышленник получает доступ сразу ко многим сервисам. Поэтому SSO должен сочетаться с MFA, conditional access, device compliance, блокировкой слабых паролей и мониторингом входов.

Политика контроля повторного использования паролей

Ниже пример структуры политики. Это не юридический шаблон, а практический каркас, который можно адаптировать.

1. Область действия

Политика распространяется на сотрудников, подрядчиков, временные учётные записи, сервисные аккаунты, администраторов, учётные записи приложений и доступы к облачным системам.

2. Основные запреты

• запрещено использовать корпоративный пароль в личных сервисах;
• запрещено использовать один пароль для разных корпоративных учётных записей, если они не объединены через SSO;
• запрещено использовать одинаковые пароли для обычного и привилегированного аккаунта;
• запрещено использовать пароли из утечек, словарные пароли и корпоративные шаблоны;
• запрещено передавать пароль коллегам, подрядчикам или службе поддержки;
• запрещено хранить пароль в открытом виде в файлах, тикетах, чатах, скриптах.

3. Минимальные требования

• длинные пароли или парольные фразы;
• проверка новых паролей по спискам известных слабых и скомпрометированных значений;
• MFA для удалённого доступа, почты, администраторов, облачных сервисов;
• password history для доменных учётных записей;
• отдельные учётные записи для административных действий;
• PAM или vault для привилегированных доступов;
• LAPS/Windows LAPS для локальных администраторов;
• обязательная смена пароля при подозрении на компрометацию.

4. Исключения

Исключения должны быть редкими, временными и согласованными. Например, если старая система не поддерживает MFA или современные требования к паролю, это фиксируется как риск с планом устранения.

5. Ответственность

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

Технический мониторинг: что реально проверять

Active Directory

Для AD нужно проверять:

• включена ли история паролей;
• минимальная длина и запрет слабых значений;
• используются ли fine-grained password policies для разных групп;
• есть ли отдельные политики для администраторов;
• настроены ли блокировки при подборе;
• есть ли локальные администраторы с одинаковыми паролями;
• применяются ли LAPS/Windows LAPS;
• не используются ли устаревшие протоколы аутентификации.

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

Microsoft Entra ID и облачные сервисы

Для облачной среды важно:

• включить MFA, желательно фишинг-устойчивую для критичных ролей;
• использовать Microsoft Entra Password Protection;
• настроить custom banned password list с названиями компании, продуктов, городов, сезонов, типовых шаблонов;
• включить риск-ориентированные политики входа;
• контролировать legacy authentication;
• анализировать входы из необычных мест;
• проверять аккаунты с отключенным MFA.

Microsoft Entra Password Protection использует глобальный список запрещённых паролей и позволяет добавить пользовательские запрещённые значения, характерные для конкретной организации Microsoft Entra Password Protection.

SIEM-корреляции

Примеры правил корреляции:

Мониторинг утечек

Компания может использовать:

• сервисы мониторинга утечек корпоративных доменов;
• threat intelligence;
• проверку корпоративных email в утёкших базах;
• проверку утёкших секретов в Git-репозиториях;
• контроль публикации конфигураций, токенов, API-ключей.

Verizon DBIR 2025 отмечает, что в инцидентах встречались случаи повторного использования учётных данных у третьих сторон, а медианное время устранения утёкших секретов в GitHub составляло 94 дня Verizon DBIR 2025 Executive Summary.

Российский контекст: персональные данные, ГИС и КИИ

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

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

Для КИИ и ГИС требования могут быть строже: нужны сертифицированные СЗИ, регламентированный контроль доступа, журналы событий, внутренний контроль и готовность показать регулятору, что политика не просто написана, а реально применяется.

Почему это важно

При проверке регулятор смотрит не только на наличие документа, но и на фактическое исполнение. Если в политике написано «пароли не должны повторяться», а в SIEM нет контроля, в AD нет ограничений, у локальных администраторов одинаковые пароли, это будет восприниматься как слабость процесса.

Типичные ошибки

• политика есть, технических настроек нет;
• AD настроен, облачные сервисы забыты;
• MFA включена только для части пользователей;
• администраторы используют тот же пароль, что и в обычной учётке;
• сервисные аккаунты годами не меняются;
• отчётность строится вручную и нерегулярно.

Практические примеры внедрения

Пример 1. Средняя компания на Active Directory

Исходная ситуация: 500 сотрудников, домен AD, VPN, почта, 1С, файловые ресурсы. Пользователи часто повторяют пароли. Локальные администраторы на рабочих станциях имеют одинаковый пароль.

Что сделать:

1. Настроить password history и минимальную длину.
2. Внедрить LAPS/Windows LAPS для локальных администраторов.
3. Добавить запрет корпоративных слов и типовых шаблонов.
4. Включить MFA для VPN и почты.
5. Подключить события AD, VPN, почты и EDR в SIEM.
6. Настроить корреляции для password spraying и входов из необычных источников.
7. Провести аудит сервисных аккаунтов.
8. Подготовить ежемесячный отчёт для ИБ и ИТ.

Пример 2. Компания с Microsoft 365 и Entra ID

Исходная ситуация: сотрудники используют Microsoft 365, часть сервисов в облаке, часть в локальной сети. Есть SSO, но MFA включена не для всех.

Что сделать:

1. Включить Microsoft Entra Password Protection.
2. Настроить custom banned password list.
3. Включить MFA для всех пользователей, приоритет — администраторы и удалённый доступ.
4. Запретить legacy authentication.
5. Настроить conditional access.
6. Анализировать Sign-in logs.
7. Отслеживать пользователей с повышенным риском.
8. Проверять корпоративные email в утечках.

Пример 3. Организация с подрядчиками

Исходная ситуация: подрядчики получают доступ к Jira, Git, VPN и тестовым стендам. Некоторые аккаунты создаются вручную, после завершения работ не отключаются.

Что сделать:

1. Ввести отдельный процесс жизненного цикла подрядчиков.
2. Запретить общие учётные записи.
3. Ограничить сроки действия аккаунтов.
4. Использовать SSO/MFA там, где возможно.
5. Запретить повтор паролей через password filter или banned list.
6. Мониторить входы подрядчиков отдельно.
7. Формировать отчёт по активным внешним доступам.

Типичные ошибки

Ошибка 1. Хранить пароли в таблицах

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

Ошибка 2. Проверять пароли вручную

Ручная проверка приводит к утечкам и нарушениям конфиденциальности. Нужно использовать безопасные механизмы: хеши, password filters, встроенные средства IdP, аудит без раскрытия пароля.

Ошибка 3. Доверять только сложности пароля

P@ssw0rd2026! формально сложный, но по сути предсказуемый. Лучше длинная парольная фраза плюс blocklist и MFA.

Ошибка 4. Игнорировать локальных администраторов

Одинаковый пароль локального администратора на 300 рабочих станциях — это подарок для lateral movement.

Ошибка 5. Не контролировать сервисные аккаунты

Сервисные пароли часто живут годами, используются в скриптах, конфигурациях и планировщиках. Их нужно переводить на gMSA, vault или PAM.

Ошибка 6. Не учитывать внешние утечки

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

Сравнение подходов

Отчётность: что показывать руководству

Хороший отчёт должен быть коротким, понятным и полезным.

Ежемесячные метрики

• доля пользователей с MFA;
• количество аккаунтов без MFA;
• число попыток password spraying;
• число найденных корпоративных email в утечках;
• количество сброшенных паролей по риску;
• число сервисных аккаунтов без владельца;
• количество локальных администраторов без LAPS;
• доля критичных систем, подключённых к SIEM;
• количество исключений из политики;
• срок устранения нарушений.

Пример отчёта

Почему это важно

Руководству не нужны сотни строк логов. Ему нужен ответ: риск растёт или снижается, что уже сделано, где нужна помощь, какой ущерб предотвращён.

Лучшие практики

1. Используйте длинные пароли и парольные фразы.
2. Проверяйте новые пароли по blocklist.
3. Не заставляйте менять пароли слишком часто без причины.
4. Включайте MFA, особенно для удалённого доступа и администраторов.
5. Запрещайте повтор корпоративного пароля на внешних сервисах.
6. Используйте менеджер паролей.
7. Разделяйте обычные и привилегированные учётные записи.
8. Внедряйте PAM для админов и сервисных секретов.
9. Используйте LAPS/Windows LAPS для локальных администраторов.
10. Подключайте события аутентификации в SIEM.
11. Мониторьте внешние утечки.
12. Готовьте регулярные отчёты.
13. Обучайте сотрудников на конкретных сценариях, а не сухими лекциями.

Чек-лист внедрения контроля повторного использования паролей

Этап 1. Инвентаризация

• Список всех систем аутентификации.
• Список доменов, IdP, VPN, облачных сервисов.
• Список привилегированных аккаунтов.
• Список сервисных аккаунтов.
• Список систем с персональными данными.

Этап 2. Политика

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

Этап 3. Технические меры

• Настроена password history.
• Включена MFA.
• Включены banned password lists.
• Внедрён LAPS/Windows LAPS.
• Сервисные аккаунты переведены под контроль.
• Логи аутентификации подключены к SIEM.

Этап 4. Мониторинг

• Правила password spraying.
• Правила credential stuffing.
• Проверка входов из необычных источников.
• Мониторинг корпоративных email в утечках.
• Отчёты по MFA и исключениям.

Этап 5. Контроль и развитие

• Ежемесячный отчёт.
• Квартальный аудит привилегий.
• Проверка сервисных аккаунтов.
• Обучение сотрудников.
• Пересмотр политики не реже одного раза в год.

Контроль в разных средах: AD, Linux, SaaS и DevOps

Active Directory и Microsoft Entra ID

В российских компаниях Active Directory всё ещё остаётся основным каталогом пользователей. Поэтому именно с него чаще всего начинается контроль повторного использования паролей. Базовая настройка — Enforce password history, минимальная длина пароля, запрет слабых значений и MFA для критичных входов. Но доменная политика не должна жить отдельно от реальности. Если у компании есть локальные учётки на серверах, отдельные пароли в сетевом оборудовании, админки в облаках и аккаунты в SaaS-сервисах, то AD покрывает только часть периметра.

Что обычно делают на первом этапе:

• проверяют Default Domain Policy и Fine-Grained Password Policies;
• выделяют группы повышенного риска: администраторы, бухгалтерия, HR, DevOps, сотрудники с доступом к клиентским базам;
• включают MFA для VPN, почты, IdP и административных порталов;
• добавляют в banned password list контекстные слова организации;
• подключают события входа и смены паролей в SIEM;
• проводят ревизию локальных администраторов и legacy-систем.

Пример управленческой логики: у обычных пользователей пароль может быть длинным и уникальным без частой принудительной смены, а у администраторов доступ должен идти через PAM, MFA и персональные учётные записи. Это не противоречие. Это разные уровни риска.

Linux-серверы и Unix-подобные системы

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

Что проверить:

• отключён ли вход root по SSH;
• используются ли ключи SSH вместо пароля там, где это оправдано;
• есть ли централизованная аутентификация через LDAP/FreeIPA/AD;
• настроена ли история паролей через PAM, если локальные пароли всё ещё используются;
• где хранятся секреты приложений;
• есть ли одинаковые пароли между dev, test и prod.

Особенно внимательно нужно относиться к сервисным аккаунтам. У них часто нет интерактивного входа, но при этом они имеют широкий доступ к БД, очередям сообщений, файловым хранилищам или API. Для таких учёток важнее не «длина пароля по стандарту», а учёт владельца, минимальные привилегии, ротация и хранение в vault.

SaaS и облачные сервисы

Сервисы вроде CRM, helpdesk, корпоративной почты, облачного хранилища, систем аналитики и проектного управления могут быть подключены к SSO, а могут жить отдельно. Второй вариант почти всегда увеличивает риск повторного использования паролей.

Зрелая схема выглядит так:

• всё, что поддерживает SAML/OIDC, подключается к SSO;
• для входа включается MFA;
• локальные пароли в SaaS отключаются или ограничиваются;
• при увольнении сотрудника доступ отзывается централизованно;
• события входа отправляются в SIEM или хотя бы выгружаются в журнал аудита;
• внешние подрядчики получают временные и ограниченные учётные записи.

Слабое место SaaS — «теневые» аккаунты. Например, отдел маркетинга самостоятельно заводит сервис для рассылок, сотрудники регистрируются по корпоративной почте и ставят знакомые пароли. Формально сервис «не в периметре ИТ», фактически там лежат клиентские данные. Поэтому контроль password reuse должен быть связан с процессом закупки и согласования новых сервисов.

DevOps, CI/CD и секреты

В DevOps-среде пароль часто заменяется токеном, API-ключом или секретом. Но суть остаётся той же: один и тот же секрет нельзя повторно использовать в нескольких средах и проектах. Разделение dev/test/prod должно быть не только на бумаге, но и в секретах.

Минимальный набор правил:

• разные секреты для dev, stage и production;
• запрет хранения секретов в Git;
• secret scanning в репозиториях и CI/CD;
• автоматическая ротация при обнаружении секрета в коммите;
• доступ приложений к секретам через vault, а не через .env на общем диске;
• отдельные сервисные учётки под каждую интеграцию;
• журналирование использования секретов.

Повторное использование секретов в DevOps опасно тем, что компрометация тестовой среды может дать доступ к production. Такое случается не потому, что команда «плохая», а потому что секреты часто создаются вручную и копируются по принципу «чтобы быстрее заработало».

Пример внутреннего регламента: что в нём должно быть

Хороший регламент парольной защиты не должен быть на 40 страниц. Его задача — дать понятные правила и связать их с техническим контролем.

Структура может быть такой:

1. Область действия. На какие системы и пользователей распространяется документ: сотрудники, администраторы, подрядчики, сервисные учётные записи, SaaS, удалённый доступ.
2. Роли и ответственность. Кто утверждает политику, кто внедряет настройки, кто расследует нарушения, кто согласует исключения.
3. Требования к паролям. Минимальная длина, запрет повторного использования, запрет утёкших и контекстных значений, требования к хранению.
4. Требования к MFA. Где MFA обязательна: VPN, почта, IdP, админ-панели, облака, Git.
5. Требования к привилегированным учётным записям. PAM, персональные admin-аккаунты, запрет shared admin, ротация.
6. Требования к сервисным учёткам. Владелец, назначение, срок действия, запрет интерактивного входа, минимальные права, ротация.
7. Мониторинг и реагирование. Какие события попадают в SIEM, какие сценарии считаются инцидентом, как быстро меняются скомпрометированные пароли.
8. Отчётность. Метрики, периодичность, ответственные за предоставление отчётов.
9. Исключения. Как оформляются, кто утверждает, на какой срок и какими компенсирующими мерами закрываются.
10. Пересмотр политики. Не реже одного раза в год или при изменении инфраструктуры/инциденте.

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

Отраслевые особенности

Финансовые организации

Для банков, МФО, страховых и платёжных сервисов парольная защита критична из-за высокой стоимости компрометации аккаунтов. Здесь нужен строгий контроль администраторов, MFA для всех критичных систем, PAM, SIEM-корреляции и регулярная проверка учётных данных в утечках. Особое внимание — подрядчикам и интеграциям с внешними сервисами.

Производственные компании

На производстве часто есть АСУ ТП, legacy-системы и рабочие станции, где невозможно быстро внедрить современные IdP. Поэтому важно не ломать технологический процесс, а строить защиту слоями: сегментация, уникальные локальные пароли, jump-серверы, PAM, запрет shared accounts, мониторинг входов и фиксация исключений.

Ритейл и e-commerce

Основной риск — доступ к CRM, личным кабинетам, заказам, платёжной информации и административным панелям сайта. Здесь важны защита админок, MFA, блокировка credential stuffing, контроль подрядчиков, мониторинг входов из новых регионов и запрет повторного использования паролей между CMS, CRM и почтой.

IT и разработка ПО

Для IT-команд пароль — только часть картины. Нужно контролировать токены, SSH-ключи, API-ключи, секреты в Git и доступы в CI/CD. Парольная политика должна быть связана с secret management и безопасной разработкой.

Малый и средний бизнес

МСБ часто считает, что контроль паролей — это «для банков». На деле самые быстрые улучшения доступны без сложных проектов: MFA на почту и VPN, менеджер паролей, запрет общих admin-паролей, инвентаризация локальных учёток и ежемесячный отчёт по утёкшим корпоративным адресам.

Как построить отчёт для руководства

Отчёт должен быть коротким. Руководителю не нужно знать, сколько раз сработал фильтр LDAP. Ему важно понимать, снижается ли риск.

Пример структуры ежемесячного отчёта:

Такой отчёт показывает зрелость процесса. Он не обвиняет пользователей, а показывает, где компания снижает риски.

Минимальная дорожная карта на 90 дней

Первые 30 дней

• Собрать список критичных систем.
• Проверить MFA на почте, VPN, IdP.
• Включить или проверить password history.
• Найти локальные admin-аккаунты.
• Проверить corporate email в утечках.
• Подготовить проект парольной политики.

31–60 дней

• Настроить banned password list.
• Внедрить password manager для ИТ и ИБ.
• Подключить события аутентификации в SIEM.
• Настроить корреляции password spraying и невозможных перемещений.
• Описать порядок реагирования на утёкшие пароли.
• Начать учёт сервисных учётных записей.

61–90 дней

• Запустить PAM-пилот для администраторов.
• Настроить регулярную отчётность.
• Убрать или оформить исключения для legacy-систем.
• Провести обучение сотрудников.
• Проверить secret scanning в Git/CI.
• Утвердить план перехода на passwordless/passkeys для подходящих сервисов.

FAQ

Можно ли полностью запретить повторное использование паролей?

Внутри одной системы — да, через password history и запрещённые списки. Между всеми внутренними и внешними сервисами — полностью нет, потому что компания не видит личные аккаунты сотрудников. Но можно сильно снизить риск через SSO, MFA, менеджер паролей, обучение и мониторинг утечек.

Нужно ли принудительно менять пароли каждые 30 дней?

Не всегда. Современные рекомендации NIST и OWASP смещают фокус с частой ротации на длину, blocklist, MFA и смену при признаках компрометации. Частая смена без причины часто приводит к предсказуемым шаблонам.

Можно ли проверять пароли сотрудников на совпадение?

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

Что делать, если корпоративный email найден в утечке?

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

Что важнее: сложный пароль или MFA?

Нужно и то, и другое, но MFA значительно снижает риск использования украденного пароля. CISA рекомендует использовать MFA, желательно фишинг-устойчивую, особенно для критичных аккаунтов CISA MFA.

Как контролировать пароли сервисных аккаунтов?

Назначить владельцев, убрать пароли из конфигов и скриптов, использовать gMSA, vault или PAM, включить ротацию по регламенту и мониторить использование.

Основные выводы

• Контроль повторного использования паролей — это не только настройка password history.
• Нельзя хранить или сравнивать пароли сотрудников в открытом виде.
• Основные риски связаны с credential stuffing, password spraying и повтором корпоративного пароля на внешних сайтах.
• Современный подход — длинные пароли, blocklist, MFA, SSO, PAM, LAPS и мониторинг утечек.
• В российских ИСПДн, ГИС и КИИ контроль паролей связан с управлением доступом, регистрацией событий безопасности и реагированием на инциденты.
• Регулярная отчётность нужна не для формальности, а для управления риском.
• Зрелая компания контролирует не только пользователей, но и администраторов, сервисные аккаунты, подрядчиков и облачные сервисы.

Источники

1. NIST SP 800-63B Digital Identity Guidelines: https://pages.nist.gov/800-63-4/sp800-63b.html
2. Microsoft Password Policy Recommendations: https://learn.microsoft.com/en-us/microsoft-365/admin/misc/password-policy-recommendations
3. Microsoft Entra Password Protection: https://learn.microsoft.com/en-us/entra/identity/authentication/concept-password-ban-bad
4. CISA MFA Guidance: https://www.cisa.gov/MFA
5. OWASP Authentication Cheat Sheet: https://cheatsheetseries.owasp.org/cheatsheets/Authentication_Cheat_Sheet.html
6. OWASP Credential Stuffing Prevention Cheat Sheet: https://cheatsheetseries.owasp.org/cheatsheets/Credential_Stuffing_Prevention_Cheat_Sheet.html
7. MITRE ATT&CK T1110 Brute Force: https://attack.mitre.org/techniques/T1110/
8. MITRE ATT&CK T1110.004 Credential Stuffing: https://attack.mitre.org/techniques/T1110/004/
9. Verizon DBIR 2025 Executive Summary: https://www.verizon.com/business/resources/reports/2025-dbir-executive-summary.pdf
10. Постановление Правительства РФ №1119: https://government.ru/docs/all/84743/
11. Приказ ФСТЭК России №21: https://legalacts.ru/doc/prikaz-fstek-rossii-ot-18022013-n-21/