Создание реестра служебных учетных записей

Реальные проблемы из-за отсутствия реестра

• «Зомби-аккаунты» — доступ остаётся активным после остановки сервиса, миграции системы или увольнения команды, его создавшей.
• Нарушение аудита — в журналах безопасности фигурирует svc_backup, но невозможно установить, какое приложение или процесс за ним стоит, что сводит расследование инцидента на нет.
• Статические секреты — пароли или ключи не меняются годами, упрощая атаки перебора или их использование при утечке старых резервных копий.
• Эскалация привилегий — аккаунт, созданный для чтения логов, со временем получает права на запись или удаление данных из-за изменений в политиках групп.

Ответственный владелец

Конкретная роль (например, «Руководитель отдела аналитики») или должностное лицо, которое подтверждает необходимость аккаунта и его привилегий. Ответственность не может быть коллективной («ИТ-отдел»). При смене владельца требуется обязательная переаттестация аккаунта.

Четкое назначение

Однозначное описание бизнес-функции, которую выполняет аккаунт. Следует избегать общих формулировок вроде «для работы системы». Пример правильного описания: «Автоматический ежедневный экспорт данных о продажах из SAP BW в систему отчётности QlikView для формирования дашбордов». Такая детализация позволяет оценить актуальность аккаунта при изменении бизнес-процессов.

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

Способ аутентификации (пароль, сертификат X.509, Managed Service Identity), срок действия секрета, ограничения по IP-адресам или времени доступа (например, только в рабочее время). Цель — уйти от вечных паролей к управляемым идентификаторам с ограниченным временем жизни.

График пересмотра

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

Уровень критичности

Классификация (Высокий/Средний/Низкий) на основе потенциального ущерба при компрометации. Определяет не только частоту проверок, но и строгость контроля (например, обязательное использование многофакторной аутентификации для «Высокого» уровня). Оценка основывается на категориях обрабатываемых данных и доступных для аккаунта операциях.

Связанные системы

Список приложений, серверов, баз данных или сетевых ресурсов, где используется аккаунт. Позволяет быстро оценить масштаб воздействия при инциденте безопасности. Идеально, если эта информация синхронизируется с CMDB (Configuration Management Database).

Шаг 1. Инвентаризация и обнаружение

Первый шаг — найти все служебные аккаунты в инфраструктуре. Необходимо комбинировать методы:

• Автоматическое сканирование Active Directory или другого каталога по шаблонам имён (svc_, app_, adm_), а также по атрибутам вроде PasswordNeverExpires.
• Анализ журналов событий (Windows Event Log, журналы приложений) на предмет нечеловеческих паттернов входа: систематические действия в ночное время, входы с IP-адресов серверов, отсутствие интерактивных сессий.
• Ручной опрос администраторов и разработчиков: «Какие технические учётные записи использует ваше приложение или служба для взаимодействия с другими системами?»

Пример поиска в Active Directory с помощью PowerShell:

Get-ADUser -Filter * -Properties Description, PasswordNeverExpires, LastLogonDate |
Where-Object {$_.SamAccountName -like 'svc_*' -or $_.Description -like '*service*' -or $_.PasswordNeverExpires -eq $true} |
Select-Object Name, SamAccountName, Enabled, PasswordNeverExpires, LastLogonDate, Description |
Export-Csv -Path 'C:tempdiscovered_service_accounts.csv' -NoTypeInformation -Encoding UTF8

Шаг 2. Создание и заполнение реестра

На начальном этапе можно использовать простую таблицу (Excel, Google Таблицы) или задачу в ITSM-системе. Главное — начать фиксировать данные. Ключевые действия: для каждого найденного аккаунта назначить ответственного владельца (через согласование с руководством подразделений) и присвоить уровень критичности.

Шаг 3. Внедрение цикла переаттестации

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

1. Автоматическое напоминание. За 2-3 недели до даты плановой проверки система создаёт тикет или отправляет письмо ответственному владельцу со ссылкой на запись в реестре.
2. Подтверждение актуальности. Владелец обязан дать ответ: «Аккаунт необходим, права соответствуют назначению», «Требуется изменить права» или «Аккаунт можно отозвать».
3. Выполнение действий. На основе решения владельца выполняются действия: обновление атрибутов в реестре, смена пароля/сертификата, корректировка прав или полное отключение аккаунта.
4. Фиксация для аудита. Каждое решение и действие логируется. Эти журналы являются доказательством для внутренних проверок и аудиторов ФСТЭК по требованиям 152-ФЗ и документов ФСТЭК.

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