«Неактивная учётка — это как незакрытая дверь в дом, из которого выехали. Забытый аккаунт не означает забвение для злоумышленника. Это прямой риск с юридическими последствиями.»
Уязвимость по умолчанию: почему неактивные учётные записи опасны
Учётная запись сотрудника, уволившегося полгода назад, или служебный аккаунт от старого проекта часто продолжают числиться в системах. Они редко попадают в фокус внимания, пароли к ним давно не менялись, а права доступа могут быть шире необходимых. Эти «сироты» инфраструктуры — не просто цифровой мусор, а законные объекты для атаки. Внутренний нарушитель или внешний злоумышленник, получивший к ним доступ, действует от лица легального пользователя, что затрудняет обнаружение.
Типичный путь компрометации: увольнение сотрудника → учётная запись остаётся активной → спустя месяцы злоумышленник подбирает или находит старый пароль → получает доступ к внутренним ресурсам или данным. Период между утечкой и её обнаружением может растягиваться на сотни дней.
Классификация рисков и приоритеты отключения
Не все неактивные учётные записи одинаково опасны. Их критичность определяется комбинацией трёх факторов: уровень привилегий, чувствительность данных, к которым есть доступ, и потенциальный ущерб для бизнес-процессов.
| Уровень риска | Тип учётной записи | Рекомендуемый срок неактивности до блокировки | Ключевые меры контроля |
|---|---|---|---|
| Критический | Учётные записи администраторов домена, привилегированные сервисные аккаунты (например, для служб каталогов или резервного копирования). | 15–30 дней | Обязательная многофакторная аутентификация (MFA), выделенный мониторинг сессий и действий, ручное подтверждение необходимости продления. |
| Высокий | Сотрудники с доступом к финансовым системам, базам персональных данных (ПДн), системам управления персоналом. | 30 дней | Регулярный аудит активности (не реже раза в неделю), автоматические алёрты службе безопасности, обязательное уведомление руководителя. |
| Средний | Стандартные пользователи (офисные сотрудники) без доступа к критическим данным. | 45–60 дней | Автоматическая блокировка по истечении срока, система самообслуживания для разблокировки, массовые уведомления перед отключением. |
| Низкий | Временные (гостевые) и тестовые учётные записи, аккаунты для внешних подрядчиков. | 90 дней (или сразу по истечении срока проекта/договора) | Жёстко ограниченный срок жизни при создании, минимальные права, автоматическое удаление. |
Алгоритм внедрения процесса управления неактивными аккаунтами
Эффективный процесс — это не разовая чистка, а цикличная процедура, интегрированная в эксплуатацию ИТ-инфраструктуры.
1. Инвентаризация и базовая классификация
Начните с составления полного реестра. Нельзя управлять тем, что не учтено. Используйте средства вашей системы (Active Directory, централизованные службы аутентификации) для выгрузки списка всех учётных записей. Сразу отсеките встроенные и системные аккаунты (например, Administrator, Guest, krbtgt), но не забывайте про них позже — они требуют отдельного подхода. Для каждой записи определите: владельца (или ответственного), уровень привилегий, последнюю дату входа, срок действия пароля. Первичная классификация по таблице рисков выше — основа для дальнейших действий.
2. Установка политики «неактивности»
Определите, что считается неактивностью. Чаще всего это отсутствие успешного входа в систему (логина) за определённый период. Однако для некоторых сервисных аккаунтов логины могут не происходить — их активность определяется по запуску служб, запросам к API или другим событиям. Политика должна быть закреплена во внутреннем документе — «Политике управления учётными записями». Укажите в ней:
- Сроки неактивности для каждой категории пользователей.
- Процедуру уведомления (за сколько дней и кого).
- Порядок эскалации (если на первое уведомление не отреагировали).
- Действия по истечении срока (блокировка, отключение, перемещение в отдельное подразделение).
- Механизм восстановления доступа в случае ошибки.
3. Автоматизация обнаружения и уведомлений
Ручной поиск неэффективен и подвержен ошибкам. Автоматизируйте процесс с помощью скриптов или специализированных систем управления идентификацией и доступом (IAM).
Для Windows Active Directory можно использовать PowerShell. Скрипт не просто находит неактивные аккаунты, но и формирует список для ответственных лиц.
# Поиск включенных пользовательских учётных записей, не логинившихся более 45 дней
$InactiveDate = (Get-Date).AddDays(-45)
Get-ADUser -Filter {Enabled -eq $true -and LastLogonDate -lt $InactiveDate -and LastLogonDate -ne $NULL} -Properties LastLogonDate |
Select-Object Name, SamAccountName, LastLogonDate |
Export-CSV "C:ReportsInactiveUsers_$(Get-Date -Format 'yyyyMMdd').csv" -NoTypeInformation -Encoding UTF8
Важный нюанс: атрибут LastLogonDate не реплицируется между контроллерами домена. Для точной картины необходимо опрашивать все контроллеры и выбирать самое свежее значение. Готовые решения IAM решают эту задачу из коробки.
Для Linux-систем логика похожа, но данные берутся из /var/log/wtmp, lastlog или системных журналов. Настройка модуля pam_lastlog в PAM (Pluggable Authentication Modules) позволяет блокировать вход для пользователей, не активных заданный период.
# Пример строки в /etc/pam.d/system-auth или /etc/pam.d/common-auth
account required pam_lastlog.so inactive=45
4. Процедура блокировки, а не удаления
Отключайте (disable) учётные записи, а не удаляйте их сразу. Отключённая запись сохраняет свою уникальную идентификатор (SID в AD, UID в Linux), что предотвращает конфликты при возможном восстановлении сотрудника или пересоздании аккаунта. Данные, принадлежавшие пользователю, остаются на месте. Удаление — финальный этап, который можно проводить, например, раз в год после подтверждения ненадобности всеми заинтересованными подразделениями (кадры, руководитель, ИТ).
5. Регулярный аудит и отчётность
Процесс нужно постоянно проверять. Раз в квартал проводите выборочный аудит: сверяйте список активных учётных записей с актуальным штатным расписанием. Анализируйте логи отключений — нет ли аномалий, массовых блокировок. Эти отчёты — прямое доказательство выполнения требований регуляторов в области защиты информации.
Соответствие требованиям 152-ФЗ и ФСТЭК
Управление учётными записями — не просто рекомендация, а прямое требование российского законодательства.
- 152-ФЗ «О персональных данных» (ст. 18.1, 19) обязывает оператора ПДн принимать меры по защите, включая контроль доступа. Непрослеживаемые, «брошенные» учётные записи с доступом к ПДн — прямое нарушение принципа актуальности и контроля прав доступа.
- Требования ФСТЭК России, особенно для государственных информационных систем (ГИС) и критической информационной инфраструктуры (КИИ), жёстко регламентируют жизненный цикл учётных записей. Например, необходимость регулярной (не реже раза в квартал) проверки актуальности списков пользователей и их прав.
- Отраслевые стандарты (например, СТО БР ИББС для банков) также содержат детальные указания по управлению доступом, включая своевременное отключение уволившихся сотрудников.
Документально процесс должен быть оформлен в виде Регламента управления учётными записями. В случае проверки именно этот документ и журналы автоматического отключения будут главными доказательствами вашей добросовестности.
Обработка исключений: длительный отпуск, больничные, командировки
Жёсткие автоматические правила требуют гибкости. Сотрудник может уйти в трёхмесячный отпуск или длительную командировку. Полная блокировка его учётной записи нарушит бизнес-процессы (например, доступ к корпоративному порталу для оформления документов). Решение — не отключать правило, а создавать легальные, контролируемые исключения.
Механизм может выглядеть так: сотрудник или его руководитель подаёт заявку на сохранение активности аккаунта на определённый срок. Заявка согласуется со службой безопасности. Учётная запись помечается специальным атрибутом (например, в AD добавляется в группу «Исключения_Неактивность»), что временно исключает её из автоматических скриптов блокировки. На время исключения для аккаунта могут быть усилены другие меры: обязательство сменить пароль после возвращения, временное ограничение круга доступных систем. Все такие исключения должны документироваться и иметь чёткий срок действия.
Заброшенная учётная запись — это больше, чем технический долг. Это готовый вектор для атаки, который может свести на нет усилия по защите периметра. Системный подход к их ликвидации снижает поверхность атаки изнутри и является обязательным элементом зрелой модели информационной безопасности, отвечающей как бизнес-логике, так и жёстким требованиям регуляторов.