Аудит парольной безопасности: чек-лист системного администратора

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

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

Главное об аудите парольной безопасности

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

1. Инвентаризация учётных записей — разделить обычные, привилегированные и сервисные, найти забытые и «мёртвые» учётки.
2. Проверка качества и уникальности паролей — длина, случайность, совпадения между системами.
3. Аудит парольной политики и настроек блокировки — сверить регламент с реальными настройками в системах.
4. Проверка многофакторной аутентификации — покрытие MFA и устойчивость метода к фишингу.
5. Проверка журнала аудита и подозрительной активности — нетипичные входы, подбор пароля, повторяющиеся сессии.
6. Приоритизация находок и отчёт — сроки реагирования и документ для руководства.

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

Зачем и когда проводить аудит парольной безопасности

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

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

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

Шаг 1. Инвентаризация учётных записей

Инвентаризация — это полная карта учётных записей компании с делением на три категории: обычные пользовательские, привилегированные (администраторы домена, серверов, баз данных) и сервисные (для приложений, скриптов, интеграций). Без этого разделения аудит может превратиться в проверку личных паролей сотрудников, а зона максимального риска останется нетронутой.

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

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

С привилегированными и сервисными учётными записями сложнее: часто данных просто нет, потому что их не заводили по единому процессу. По данным BI.ZONE, почти 40% таких записей используют одинаковые или похожие пароли, а больше половины никогда не истекают. На одного ИТ-специалиста в среднем приходится 3–7 привилегированных учётных записей, и часто он сам не может назвать их точное число без выгрузки.

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

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

Ещё одна категория риска в инвентаризации — учётные записи бывших сотрудников и подрядчиков, доступ которых не отозвали. По данным ГК «Солар», на одну крупную российскую организацию в среднем приходится более 600 утекших уникальных корпоративных учётных записей, и больше половины из них — с паролями в открытом виде. Если такая запись не деактивирована вовремя, утёкший пароль остаётся рабочим ключом от системы.

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

Шаг 2. Проверка качества и уникальности паролей

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

Оцените среднюю и минимальную длину паролей

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

Не считайте спецсимволы признаком надёжности

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

Сверьте принятую в компании ротацию паролей с применимым стандартом

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

ФСТЭК России, напротив, рекомендует смену пароля не реже одного раза в 90 дней. Если организация подпадает под требования регулятора, ориентируйтесь на этот срок, если нет — ориентируйтесь на внутреннюю политику безопасности и меняйте пароль точечно, при подозрении на компрометацию.

Сопоставьте пароли между учётными записями

Проверьте пароли на совпадения и повторы. По данным исследования ГК «Солар», 47% опрошенных используют один и тот же пароль для разных учётных записей. Каждое найденное совпадение — повод для точечной смены конкретного пароля.

Если дефолтные и повторяющиеся пароли — не единичные случаи, а массовое явление

Значит проблема не в дисциплине сотрудников, а в самой парольной политике: минимальная длина занижена, ротация идёт по календарю, уникальность не проверяется техническими средствами. Точечная смена паролей снимает симптом, причину устраняет пересмотр политики. Этому посвящён шаг 4 статьи и статья «Что такое парольная политика».

Рекомендации

Шаг 3. Аудит парольной политики и настроек блокировки

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

Проверьте минимальную длину и требования к алфавиту пароля

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

Проверьте глубину истории паролей

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

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

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

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

Сверьте настройки между всеми системами компании

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

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

Шаг 4. Проверка многофакторной аутентификации

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

Задача этого шага: не зафиксировать факт наличия MFA в компании, а проверить её покрытие: у кого она включена и где остались исключения.

Чек-лист проверки MFA:

• Включена ли MFA для всех привилегированных учётных записей без исключений
• Есть ли обходные пути входа без второго фактора: старые интеграции, сервисные API, устаревшие протоколы
• Какой метод MFA используется: SMS-код, приложение-аутентификатор или аппаратный ключ
• Покрывает ли MFA доступ к самим системам управления паролями и секретами, а не только к рабочей почте

Оцените метод MFA на устойчивость к фишингу

SMS-код и одноразовый пароль из приложения — рабочий минимум, но не предел. SMS остаётся уязвимым к перехвату и подмене SIM-карты, поэтому для привилегированных учётных записей его стоит считать временной мерой. Более зрелый уровень защиты — аппаратные ключи (FIDO2) и ключи доступа (passkeys), которые не передают код по каналу связи и поэтому не перехватываются тем же способом.

Проверьте, защищена ли MFA сама система управления паролями и секретами

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

Сверьте, как MFA сочетается с единым входом (SSO)

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

Шаг 5. Проверка журнала аудита и подозрительной активности

Журнал аудита фиксирует, кто и когда входил в систему. Без его регулярного просмотра администратор узнаёт о компрометации только после инцидента, а не до него.

На что смотреть в первую очередь:

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

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

Команда зрелого уровня не проверяет журналы вручную каждый раз, а настраивает экспорт логов в SIEM или Syslog и получает уведомления по заданным правилам.

Шаг 6. Приоритизация находок и отчёт

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

Шкала критичности находок (3 уровня)

Разнесите каждую находку по трём уровням. От этого зависит срок реагирования, а не от того, на каком шаге чек-листа она обнаружена:

Заметьте закономерность: находки шага 1 (забытые учётные записи, сервисные аккаунты) и шага 4 (пробелы в MFA) чаще попадают в Критично и Важно, а формальные отклонения из шага 2 (длина пароля на пару символов ниже нормы) — почти всегда в Можно отложить. Это не правило: решает не то, на каком шаге найдена проблема, а то, что она открывает злоумышленнику.

Минимальная структура отчёта

Готовый отчёт отвечает на пять вопросов, и каждый прямо опирается на данные, собранные на шагах 1–5:

1. Дата и охват аудита. Какие системы и учётные записи проверены — тот же периметр, что вы зафиксировали на шаге 1.
2. Сводка по категориям. Сколько обычных, привилегированных и сервисных учётных записей проверено и сколько находок пришлось на каждую категорию — разбивка наследует категории из шага 1.
3. Находки по уровню приоритета. Таблица выше, но с конкретными системами и учётными записями, а не абстрактными формулировками вида «пароли недостаточно сложные».
4. Рекомендации и сроки. Что сделать, до какой даты и кто отвечает — для «Критично» и «Важно» это конкретный исполнитель, не абстрактный «ИБ-отдел».
5. Дата следующего аудита. Плановая дата для обычных учётных записей и отдельная, более частая — для привилегированных и сервисных, в соответствии с циклами из раздела «Зачем и когда проводить аудит».

Как Пассворк закрывает находки аудита

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

Привилегированные и сервисные учётные записи

Для машинных секретов (API-ключей, токенов доступа к базам данных, учётных данных CI/CD) в Пассворке есть отдельный механизм сервисных аккаунтов: несколько scoped-токенов на одну систему, каждый можно отозвать или заменить без остановки пайплайна. Это закрывает главную находку большинства аудитов: сервисные аккаунты с пожизненным паролем, который никто не менял с момента настройки интеграции.

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

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

Многофакторная аутентификация

Пассворк поддерживает TOTP, ключи доступа (passkeys/WebAuthn) и приложение «Пассворк 2ФА». Администратор может настроить обязательную MFA для конкретных ролей — в первую очередь для тех, у кого доступ к привилегированным сейфам.

Права доступа и их пересмотр

Ролевая модель построена на ролях и группах: встроенные роли Владелец, Администратор и сотрудник, а также неограниченное количество настраиваемых ролей для гибкого управления системой. Группы синхронизируются с AD/LDAP — при увольнении сотрудника или его переводе в другой отдел доступ отзывается один раз, а не вручную по каждому сейфу. Для входа доступны SAML SSO и OAuth.

Журнал использования прав

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

Заключение

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

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

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

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

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

Как часто нужно проводить аудит парольной безопасности?

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

Чем аудит паролей отличается от парольной политики?

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

Нужно ли менять все пароли по графику при аудите?

По умолчанию — нет. Массовая смена паролей по расписанию без разбора создаёт видимость работы, но не устраняет причину: скомпрометированный или повторяющийся пароль останется таким же слабым после ротации. Меняйте точечно, там, где аудит нашёл конкретную проблему. Исключение — системы, подпадающие под требования ФСТЭК (ГИС, КИИ): там периодическая смена паролей может быть прямым требованием регулятора и обязательна независимо от результатов аудита.

Что делать с найденными «мёртвыми аккаунтами» — учётными записями без владельца?

«Мёртвые учётные записи» — записи без установленного владельца, чаще всего оставшиеся после увольнения сотрудника или завершения работы с подрядчиком. Порядок действий: заблокировать доступ немедленно, зафиксировать находку в отчёте как критическую, разобраться, к каким ресурсам был доступ, и только после этого удалить запись. Синхронизация групп с Active Directory снижает число таких находок в будущих циклах аудита, но не убирает уже накопленные: их нужно закрыть вручную один раз.

Внедрение менеджера паролей: пошаговое руководство

Сисадмин пересылает SSH-ключи в мессенджере. Уволенный сотрудник до сих пор получает рассылку с данными клиентов. Стажёр с правами администратора. Знакомо? Рассмотрим, как ИТ-отделу взять доступы под контроль — от первого аудита до работающей системы.

Блог ПассворкаАнастасия Лебедева

Как создать надёжный пароль в 2026: новые требования, правила и примеры

73% российских компаний до сих пор пользуются паролем по умолчанию — притом что одна лишняя буква длины часто защищает больше, чем весь набор спецсимволов. Разбираем, что на этот счёт думают ФСТЭК, NIST и OWASP, и как быстро собрать пароль, который устроит всех.

Блог ПассворкаИлья Шелыгин

Управление паролями в компании: система, угрозы, внедрение

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

Блог ПассворкаИлья Шелыгин