«Защита данных после ухода сотрудника, это не просто блокировка учётки в домене. Основная угроза часто сохраняется внутри 1С и не требует прав на сервер для её нейтрализации. Вы можете перекрыть все каналы влияния, используя только возможности самой платформы, если знаете, где искать.»
Почему стандартного отзыва прав в домене недостаточно
В российской IT-среде закрытие доступа к рабочему месту и VPN считается стандартной процедурой. Однако информационная база 1С живёт по своим правилам. Её кластер серверов управляется независимо от корпоративного домена Active Directory. Активная учётная запись сотрудника может остаться внутри системы по несколь причинам: забывчивость администратора, отсутствие интеграции с кадровыми системами или сохранённый доступ через тонкий клиент извне.
Но даже формальное удаление пользователя из списка в консоли кластера не закрывает всех рисков. Реальная угроза состоит в «наследственных» механизмах, созданных за время работы:
- Учётные данные, вшитые в код обработок для интеграций или внешних соединений.
- Неотозванные права «Все права» (Полные), выданные для решения разовых задач.
- Регламентные и фоновые задания, запрограммированные на выполнение от имени сотрудника, потенциально содержащие скрытую логику.
- В файловых базах — доступ к общим сеансам через компрометацию данных другого пользователя.
- Запуск обработок с именами, похожими на служебные, но не входящими в поставку (например, «ОчисткаТест» или «ВыгрузкаРезервная»).
- Многократные ошибки «Недостаточно прав» на объекты, к которым у пользователя теоретически не должно быть доступа, это может указывать на попытки выполнения скрипта, проверяющего границы полномочий.
- События изменения конфигурации, если соответствующие права были выданы. Их часто пропускают, фокусируясь только на данных.
- Немедленно остановите задание, сняв флажок «Включено».
- Изучите выполняемый метод. Откройте свойства задания. Если в качестве метода указан вызов внешней обработки (
ВнешняяОбработка.Создать()) или неочевидный общий модуль, это требует детального анализа кода в Конфигураторе. - Перепривяжите задание. Если функционал необходим, назначьте его на отдельную служебную учётную запись (например, «ФоновыеЗадания») или действующего ответственного сотрудника.
- Планы обмена. Проверьте настройки узлов, указанные адреса и учётные данные.
- Настройки HTTP-сервисов и веб-сервисов. Убедитесь, что в точках входа не используются личные аккаунты.
- Константы и регистры сведений для хранения токенов или паролей к внешним API.
- Дату и время увольнения и получения уведомления в IT.
- Список отключённых регламентных заданий с указанием их методов.
- Выводы по анализу журнала регистрации (ключевые подозрительные события).
- Факт смены ролей на нулевые.
- Перечень внешних систем, для которых изменены учётные данные.
- Подпись исполнителя.
- В консоли администрирования кластера 1С:Предприятие для каждой информационной базы найти и принудительно завершить все активные сессии пользователя [ФИО].
- Удалить учётную запись пользователя [ФИО] из списка пользователей кластера.
- Предоставить скриншоты, подтверждающие выполнение пунктов 1 и 2.
- Принцип минимальных привилегий. Роль «Полные права» не должна быть постоянной ни у кого. Используйте её только для установки обновлений с последующей деактивацией.
- Служебные учётные записи для автоматизации. Все регламентные и фоновые задания должны выполняться от имени специально созданных сервисных аккаунтов (например, «Job_Reconciliation»), а не персональных учёток сотрудников.
- Автоматизация аудита. Настройте ежеквартальный запуск отчёта по пользователям и их правам с последующей сверкой с актуальным штатным расписанием. «Мёртвые» учётки подлежат безусловному удалению.
- Интеграция с кадровыми системами. Стремитесь к настройке автоматического уведомления IT-службы об изменении статуса сотрудника (увольнение, перевод) за 1-2 рабочих дня.
задача смещается с блокировки входа на полную ликвидацию цифрового следа и инструментов влияния внутри конфигурации.
Подготовка: сбор контекста изнутри базы
Отсутствие доступа к серверу — не оправдание. Первый шаг — диагностика. Используйте встроенные возможности 1С для сбора полной картины активности пользователя.
Начните с отчёта «Анализ пользователей», доступного через меню «Все функции» в типовых конфигурациях. Он покажет последний сеанс, назначенные роли и общую активность. Но это лишь поверхностный слой.
Ключевой инструмент — «Журнал регистрации» («Сервис» → «Журнал регистрации»). Настройте отбор по имени пользователя за последние 1–3 месяца. Обращайте внимание на аномалии в событиях, которые редко появляются в учебных материалах по безопасности:
Дополните картину отчётом «История изменений данных», чтобы выявить подозрительные массовые правки в документах или справочниках, сделанные накануне увольнения.
Этап 1: Мгновенная изоляция через ролевую модель
Самый быстрый способ обезвредить аккаунт — оставить ему нулевой уровень привилегий. Если прямое удаление из кластера невозможно, измените его профиль внутри базы.
Перейдите в «Администрирование» → «Настройки пользователей и прав». Создайте новую роль с именем вроде «Z_Заблокирован». В её настройках не включайте ни одного права, даже на просмотр. Снимите с пользователя все существующие роли и назначьте только эту пустую.
После сохранения пользователь при следующем обращении к системе или при попытке выполнить любое действие в активной сессии столкнётся с полным отсутствием интерфейса или ошибками доступа. Это создаёт временный буфер для глубокой проверки.
Этап 2: Контроль над автоматическими процессами
Блокировка интерфейса бессильна против фоновых заданий. Их необходимо найти и обезвредить.
В разделе администрирования регламентных заданий («Администрирование» → «Поддержка и обслуживание» → «Регламентные задания») выполните отбор или сортировку по полю «Пользователь». Для каждого задания, связанного с уволенным сотрудником, выполните последовательность действий. Простой отключки недостаточно.
Этап 3: Поиск преднамеренных модификаций в конфигурации
Это наиболее сложный, но критичный этап. Сотрудник с правами разработчика мог внести код, активируемый по событию или временной метке.
Получите выгрузку конфигурации в файлы через Конфигуратор. Для поиска используйте любой редактор с функцией поиска по нескольким файлам. Ищите не только прямой логин, но и косвенные указатели.
Фокусные точки для аудита:
| Где искать | На что обратить внимание | Потенциальная угроза |
|---|---|---|
| Общие модули, особенно серверные | Условия с проверкой ТекущийПользователь() или сравнениями дат (ТекущаяДата() >= '20241001') |
Логика с отложенным запуском, активируемая после ухода |
Обработчики событий ПриНачалеРаботыСистемы(), ПередЗавершениемРаботыСистемы() |
Вызовы методов отправки почты, HTTP-запросов, массового удаления данных | Немедленный или фоновый экспорт данных, саботаж |
| Внешние обработки и отчёты в общих каталогах | Файлы, изменённые незадолго до увольнения. Код с функциями работы с файловой системой (Новый Файл, ЗаписатьТекст) |
Создание скрытых дампов информации |
Особенно опасны конструкции, где проверка пользователя вынесена в сложное условие или спрятана за вызовом другой функции.
Этап 4: Зачистка пользовательских данных и настроек
В системе накапливаются персональные данные сотрудника: сохранённые отборы в отчётах, настройки форм, элементы избранного. Они могут содержать чувствительные фильтры или служить инструментом для социальной инженерии.
Данные обычно хранятся в регистрах сведений с названиями вида «ПользовательскиеНастройкиНаборовДанных». Для их удаления потребуется выполнить код с повышенными привилегиями. Можно создать одноразовую обработку со следующим алгоритмом:
Создать объект менеджера соответствующего регистра, организовать выборку записей по измерению «Пользователь», равному уволенному сотруднику, и выполнить их удаление в цикле. После выполнения обработку следует удалить.
Проверьте также внутренний справочник «Пользователи», если он используется, и установите флаг «Неактивен» или удалите запись.
Этап 5: Ревизия внешних интеграций и соединений
В настройках обмена с CRM, маркетплейсами, CMS часто хранятся логины и пароли. Сотрудник мог подменить их на свои или знать действующие.
Проведите инвентаризацию:
Пароли и токены доступа ко всем интегрированным системам должны быть сброшены в обязательном порядке, это требование часто упускают из виду, фокусируясь только на 1С.
Этап 6: Фиксация действий для отчётности
Документирование — не бюрократия, а доказательство выполнения требований 152-ФЗ о соблюдении мер защиты персональных данных и due diligence в случае инцидента.
Сформируйте справку или акт, включив в него:
Этот документ станет частью истории изменений и аудиторским доказательством.
Когда без прав администратора кластера не обойтись
Описанный план покрывает большинство сценариев. Однако для полной очистки, особенно в кластерных версиях, могут потребоваться действия на уровне сервера.
В этом случае ваша задача — составить для администратора предельно конкретное техническое задание, а не устную просьбу. Пример:
Профилактика как системный подход
Чтобы не действовать в авральном режиме, внедрите превентивные меры в регулярные процессы:
Безопасность 1С после увольнения сотрудника, это управляемый процесс, а не хаотичная реакция. Описанная методика позволяет взять его под контроль, даже имея ограниченный круг полномочий, и превратить потенциальный инцидент в рядовую операцию.