“Бывший сотрудник, уволившийся полгода назад, всё ещё может иметь доступ к вашим критическим данным — бухгалтерским, персональным, коммерческим. Это не вопрос злого умысла, а системная уязвимость. Большинство организаций видят процедуру увольнения как кадровый процесс, забывая, что это в первую очередь информационная безопасность. Сейчас вы узнаете, в каких именно системах и журналах оседают следы таких «фантомных» пользователей, и как построить практические проверки, а не полагаться на заверения службы персонала.”
Призраки в системе: почему доступ остаётся после увольнения
Формально процесс увольнения выглядит просто: приказ, запись в трудовой книжке, расчёт. Однако цифровая тень сотрудника в информационных системах компании гораздо живучее. В крупных организациях с десятками сервисов — от 1С и CRM до корпоративной почты, систем документооборота и специализированных бухгалтерских баз — учётные записи создаются в разных подсистемах и в разное время. Единый каталог пользователей (например, на базе Active Directory) упрощает управление, но не гарантирует синхронизацию со всеми периферийными системами. Зачастую доступы в них выдаются вручную, по запросу руководителя, а процесс их отзыва никто формально не прописывает.
Отдел кадров отчитывается о прекращении трудовых отношений. IT-служба, получив уведомление, отключает доменную учётную запись и корпоративную почту. Но учётная запись в конфигурации 1С:Бухгалтерия, где сотрудник был пользователем с правами на проведение документов, может «зависнуть». Особенно если её создание и удаление — прерогатива главного бухгалтера, а не системного администратора. Аналогичная ситуация с доступом к облачным сервисам отчётности, банк-клиентам или к внутренней wiki-базе знаний. В результате формируется «цифровой труп» — неактуальная учётная запись, сохраняющая права доступа к конфиденциальной информации.
Где искать следы фантомного доступа
Обнаружение подобных уязвимостей — задача для последовательного аудита, а не для разовых проверок. Нужно проверять не только факт наличия учётной записи, но и её активность. Вот ключевые точки контроля.
1. Журналы безопасности и аудита в 1С
Платформа 1С предоставляет встроенные механизмы регистрации событий. Их необходимо активировать и правильно настроить. В журнале регистрации (меню «Сервис» — «Журнал регистрации» в конфигураторе или в тонком клиенте) фиксируются входы пользователей, запуск сеансов, критичные операции. Ищите события с кодом «UC» (User Connection) для вашей базы данных. Фильтрация по имени пользователя и дате позволит увидеть, заходил ли «уволенный» бухгалтер после своей даты увольнения.
Стоит помнить: журнал регистрации может быть отключён или иметь короткий период хранения. Проверьте его настройки. Также активность может маскироваться, если бывший сотрудник знал пароли других коллег и использовал их учётные записи. В этом случае косвенным признаком будет аномальная активность учетной записи действующего сотрудника вне рабочего времени или с необычных IP-адресов.
2. Отчёты и журналы в СУБД
Если 1С работает в клиент-серверном варианте (на базе PostgreSQL, Microsoft SQL Server, IBM DB2), следы операций остаются в журналах транзакций самой СУБД. Запросы к журналу аудита базы данных могут показать все операции SELECT, INSERT, UPDATE, выполненные от имени конкретного пользователя базы данных, который привязан к учётной записи 1С.
Пример запроса для поиска подключений в PostgreSQL (упрощённо):
SELECT usename, client_addr, backend_start, query_start, state
FROM pg_stat_activity
WHERE usename = 'имя_пользователя_бд';
Это даст картину текущих и недавних сеансов. Для исторического анализа потребуется изучать log-файлы СУБД, если включено логирование подключений.
3. Система контроля доступа (Active Directory, FreeIPA) и корпоративный VPN
Журналы событий безопасности Windows (Event Log) на контроллере домена хранят записи о успешных и неуспешных попытках входа (события с ID 4624, 4625). Фильтрация по имени учётной записи бывшего сотрудника покажет, пытался ли он аутентифицироваться в домене после увольнения. Это важный индикатор, даже если доступ к 1С был через веб-клиент или тонкий клиент, не требующий доменной аутентификации для самого приложения — вход на рабочий компьютер или VPN мог происходить под его старыми кредами.
Аналогично нужно проверять логи сервера VPN (например, на основе OpenVPN или WireGuard), которые фиксируют подключения с привязкой к имени пользователя и выделенному IP-адресу.
4. Косвенные системы: почта, документооборот, облачные сервисы
Бухгалтер для работы мог получить доступ не только к 1С. Проверьте:
- Корпоративную почту (Microsoft Exchange, Яндекс.Почта для бизнеса): активна ли переадресация писем на личный ящик, настроенная до увольнения. В панели администратора почтового сервиса можно посмотреть историю входов в веб-интерфейс.
- Системы электронного документооборота (СЭД) и CRM: наличие активной учётной записи, права на просмотр финансовых документов или договоров.
- Облачные сервисы (например, Контур.Эльба, СБИС, 1С-Отчётность): доступ обычно предоставляется по отдельному приглашению. Его нужно отзывать вручную в настройках администратора конкретного сервиса. Уволенный сотрудник мог остаться «полноправным представителем» организации в глазах налоговой или банка.
- Банк-клиенты: это особо критичный пункт. Даже если доступ по логину/паролю отозван, в некоторых системах остаются активными аппаратные токены (например, Рутокен), выданные на руки сотруднику. Их необходимо изымать физически или оперативно отзывать в банке по заявлению.
Общей рекомендацией является получение от каждого сервиса, где возможен учёт, отчёта о всех пользователях с правами доступа (user access review). Сверьте этот список с актуальным списком сотрудников от кадровой службы.
Как выстроить непрерывный контроль вместо разовых чисток
Ручные проверки раз в полгода — лучше, чем ничего, но недостаточно. Нужны процедуры, встроенные в цикл управления персоналом.
- Увязка процессов HR и IT. Увольнение должно инициировать автоматический тикет (через Service Desk, например, Jira Service Management или Битрикс24) на отзыв всех доступов. В тикете — чёткий чек-лист на основе роли сотрудника (бухгалтер, разработчик, менеджер), который исполнители из разных отделов (сисадмины, администраторы 1С, ответственные за CRM) отмечают по мере выполнения.
- Регламентные проверки Access Review. Каждые 1-3 месяца ответственные лица (CISO, руководители отделов) получают на подпись отчёты о списках пользователей во вверенных им системах. Задача — подтвердить, что все учётные записи актуальны, или инициировать отзыв.
- Мониторинг аномальной активности. Внедрение SIEM-системы (например, на базе Open Source решений вроде Wazuh или коммерческих российских аналогов) позволяет агрегировать логи со всех источников (1С, AD, VPN, СУБД) и настраивать алерты. Правило может звучать так: «Если учётная запись, исключённая из группы “Действующие сотрудники” в AD, обнаруживает успешную аутентификацию в любой из корпоративных систем — отправить экстренное оповещение». Это превращает реакцию из поиска по архивам в реальном времени.
- Минимализация ручного управления доступом. Используйте ролевую модель (RBAC) в 1С и других системах. Сотрудник получает не персональные права «на всё», а роль «Бухгалтер по первичке», которая централизованно назначается и снимается. Это сокращает число точек управления.
Что делать, если доступ был использован
Обнаружение факта неавторизованного входа — инцидент информационной безопасности. Действуйте по плану:
- Немедленная блокировка. Отзовите все найденные активные доступы, смените пароли для связанных сервисов, если есть подозрения в их компрометации.
- Сбор и сохранение доказательств. Сделайте скриншоты журналов, сохраните логи в неизменяемом виде. Это может понадобиться для внутреннего расследования или, в крайнем случае, для обращения в правоохранительные органы по статье 272 УК РФ (неправомерный доступ к компьютерной информации).
- Анализ масштаба. Определите, к каким именно данным был получен доступ, какие действия выполнялись (просмотр, копирование, изменение). В 1С для этого можно анализировать журнал проведения документов или использовать отчёты по изменениям данных.
- Оценка последствий и исправление. Если данные были изменены, необходимо восстановить корректность на основе резервных копий. Если произошла утечка персональных данных, возможно, нужно уведомлять Роскомнадзор в соответствии с 152-ФЗ.
- Ревизия процессов. Сам инцидент — повод для пересмотра и ужесточения процедур увольнения и регулярного контроля доступов.
Регуляторные требования ФСТЭК и 152-ФЗ прямо не предписывают искать уволенных бухгалтеров в базах, но они требуют защиты персональных данных и коммерческой тайны, внедрения системы управления инцидентами ИБ и контроля доступа. Обнаружение «фантомного» пользователя, это как раз индикатор сбоя в этих системах. Построение чёткого, перекрёстно проверяемого процесса отзыва доступов не просто защищает от мести бывшего сотрудника, это базовый гигиенический фактор цифровой безопасности любой компании, работающей с чувствительными данными. Начинать нужно не с поиска виноватых, а с аудита собственных цифровых следов и их актуальности прямо сейчас.