Как мгновенно отозвать доступ к 1С без доступа к серверу

от

«Базовая защита 1С часто сводится к закрытию рта через права, но это бесполезно, когда сотрудник уже уволен и его учётная запись отключена. Настоящая задача — защитить данные от него самого, пока он ещё в штате, и подготовить систему к моменту ‘х’ таким образом, чтобы действия администратора по его отключению не требовали героизма и гарантированно сработали за пару часов. Я обошёлся без спецсредств и доступа к серверу.»

Проблема не в учётных записях, а в данных и сеансах

Типичный сценарий: системному администратору или ответственному за 1С приходит служебная записка с списком ФИО на увольнение. Задача — не дать этим людям получить или повредить данные после уведомления. Стандартный протокол — отключить пользователя в Active Directory или в самой 1С (для встроенной аутентификации). Это работает, но с задержкой и рисками.

Задержка возникает из-за кэширования сеансов. Если сотрудник уже запустил 1С, отключение его учётной записи в домене может не разорвать его текущий сеанс работы с базой данных мгновенно. Он продолжит работу, пока не совершит действие, требующее повторной аутентификации (например, переход по определённым разделам) или пока не истечёт время жизни сессии на сервере 1С. Это «окно уязвимости», которое может длиться от нескольких минут до часов.

Основные риски, которые не устраняет простое отключение учётной записи:

  • Скачивание отчётов и выгрузок: Уволенный сотрудник может за несколько минут выгрузить в Excel критичные отчёты по клиентам, закупочным ценам, финансовым планам.
  • Порча или изменение данных: Внесение сумм «на память», изменение реквизитов контрагентов, создание фиктивных документов в последний день.
  • Использование сохранившихся автоматизированных сценариев: Многие пользователи создают для себя обработки или используют стандартные механизмы выгрузки, которые можно запустить массово.

защита на уровне входа в систему — необходимая, но недостаточная мера. Нужен контроль на уровне бизнес-логики и данных.

Защита доступа: стандартные инструменты 1С и их недостатки

Платформа 1С предлагает два основных механизма разграничения прав: роли и профили безопасности (в версиях платформы 8.3 и выше).

  • Роли определяют, какие действия (чтение, запись, добавление, изменение, проведение) пользователь может выполнять с конкретными объектами метаданных (справочники, документы, отчёты).
  • Профили безопасности позволяют ограничивать доступ к данным на уровне записей (например, видеть только документы своего подразделения или склада).

Проблема в том, что эти настройки статичны. Для точечного отключения сотрудника от какой-либо функции, сохранив ему доступ к остальному, администратору придётся либо создавать уникальную роль под этого человека, либо вручную редактировать его набор ролей, что требует времени, доступа к конфигуратору и несёт риск ошибки.

Кроме того, отзыв роли вступает в силу только при следующем запуске 1С или начале нового сеанса. Если сотрудник уже работает в системе, он сохранит старые права до перезахода. Это делает стандартные роли плохим инструментом для оперативного реагирования.

Скрытая угроза: сеансовые данные и внешние обработки

Даже при идеально настроенных ролях остаётся вектор атаки через механизмы, которые часто остаются без внимания:

  • Внешние обработки и отчёты: Пользователь может иметь локальные файлы (.epf, .erf) или доступ к общей сетевой папке с обработками. Многие из них запускаются с правами текущего пользователя и могут обходить ограничения интерфейса, напрямую обращаясь к данным.
  • Конструкторы запросов и выгрузок: Такие инструменты, как «Конструктор запросов» или «Анализ данных», могут быть использованы для создания произвольных выборок, если на них не наложены отдельные ограничения в ролях.

Стратегия защиты «в один день»: три слоя

Моя задача была в том, чтобы создать механизм, который позволит за час-два гарантированно и безопасно отключить любого пользователя от критичных данных, не имея в этот момент доступа к серверу 1С или AD. Решение строится на трёх независимых слоях.

Слой 1: «Теневой» список доступа на уровне конфигурации

В основу конфигурации добавлен простой, но эффективный механизм. В справочнике «Пользователи» или в отдельном регистре сведений создаётся дополнительный реквизит – флаг «ДоступОграничен». По умолчанию он установлен в «Ложь».

Далее, в критичные формы, документы и отчёты, в их процедуры-обработчики события «ПриОткрытии» или «ПередЗаписью», встраивается проверка:

Если Объект.Метаданные().Имя = "Справочник.Контрагенты" ИЛИ 
   Объект.Метаданные().Имя = "Отчет.ФинансоваяОтчетность" Тогда
    
    ТекущийПользователь = ПользователиИнформационнойБазы.ТекущийПользователь();
    // Поиск записи о пользователе в нашем «теневом» справочнике
    ЗаписьОграничения = Справочники.СлужебныеПользователи.НайтиПоРеквизиту("ОсновнойПользователь", ТекущийПользователь);
    
    Если ЗаписьОграничения  Неопределено И ЗаписьОграничения.ДоступОграничен Тогда
        // Вариант 1: Строгое закрытие
        ВызватьИсключение "Доступ к данному объекту для вашей учётной записи временно ограничен. Обратитесь к администратору.";
        
        // Вариант 2: Мягкое скрытие данных (для отчётов)
        // Обнулить основные наборы данных, вывести уведомление
    КонецЕсли;
КонецЕсли;

Преимущество: это управляется из самого клиента 1С с правами, например, «Редактирование служебных данных». В день увольнения ответственное лицо (руководитель отдела кадров, начальник IT) заходит в 1С, находит пользователя в этом служебном справочнике и ставит галочку «ДоступОграничен». Изменение вступает в силу немедленно для всех новых действий этого пользователя. Ему необязательно даже перезапускать 1С — при попытке открыть защищённый справочник или запустить отчёт он получит сообщение об ошибке.

Слой 2: Динамическая фильтрация данных через общий модуль

Для более тонкого контроля, например, чтобы сотрудник видел документы, но только за прошлые периоды, используется динамическая подстановка фильтров. Создаётся общий модуль «КонтрольДоступаПриУвольнении» с экспортной функцией, возвращающей условия отбора.

Эта функция считывает состояние флага из «теневого» списка (Слой 1) и, если доступ ограничен, возвращает жёсткое условие для запросов. Например:

// В отчёте или обработке, при формировании запроса:
УсловиеОграничения = КонтрольДоступаПриУвольнении.ПолучитьОграниченияНаПериод();
Если НЕ ПустаяСтрока(УсловиеОграничения) Тогда
    ТекстЗапроса = ТекстЗапроса + " ГДЕ " + УсловиеОграничения;
КонецЕсли;

Условием может быть «Дата < '20240101'» (чтобы видеть только старые данные) или «Подразделение = Неопределено» (чтобы скрыть все привязанные к подразделениям записи). Это позволяет не блокировать работу сотрудника полностью (он может завершить технические операции), но лишает его доступа к актуальным коммерческим данным.

Слой 3: Проактивный мониторинг активности потенциально увольняемых

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

В тот же общий модуль добавляется логирование запуска критичных операций (открытие ключевых отчётов, массовая печать, выгрузка в файл) для пользователей с установленным флагом «Внимание» (второй реквизит в «теневом» списке). Записи пишутся в отдельный регистр сведений или даже во внешний текстовый лог.

// При запуске критичного отчёта:
Если КонтрольДоступаПриУвольнении.ТребуетЛогирования(ТекущийПользователь) Тогда
    Запись = Новый Структура("Пользователь, Объект, Время, Параметры", 
               ТекущийПользователь.Имя, 
               ЭтотОбъект.Метаданные().ПолноеИмя(),
               ТекущаяДата(),
               СтандартныеПараметрыОтчёта);
    // Запись в регистр или файл
    ЗаписатьЖурналКонтроля(Запись);
КонецЕсли;

Это не предотвращает инцидент, но создаёт доказательную базу и позволяет увидеть подозрительную активность до наступления дня «X».

Порядок действий в день увольнения

С этим механизмом процесс занимает считанные минуты:

  1. Получение списка: От кадровой службы поступает список сотрудников.
  2. Включение ограничения: Ответственный сотрудник заходит в 1С под своей учётной записью, открывает служебный справочник «Контроль увольнений», находит пользователей и устанавливает флаг «ДоступОграничен». Никакого конфигуратора, никаких серверных настроек.
  3. Реакция системы: С этого момента для указанных пользователей:
    • Блокируется доступ к справочникам «Контрагенты», «Номенклатура», «Сотрудники» (по настройке).
    • Финансовые отчёты либо не открываются, либо показывают только архивные данные.
    • Массовые выгрузки и обработки завершаются с ошибкой.
  4. Стандартные процедуры: Параллельно или после этого системный администратор отключает учётные записи в AD и в 1С для полного запрета входа.

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

Ограничения и важные условия внедрения

Этот подход не панацея и требует выполнения условий:

  • Доработка конфигурации: Требуются минимальные, но ответственные правки в коде типовых или собственных конфигураций. Желательно поручить это опытному разработчику 1С.
  • Обходы: Механизм работает на уровне логики приложения. Прямой доступ к базе данных SQL (если он есть) или доступ через другое, недекларированное клиентское приложение могут его обойти. Это подчёркивает необходимость комплексной защиты.
  • Юридический аспект: Внедрение такого скрытого механизма контроля должно быть регламентировано внутренними политиками безопасности и доведено до сведения сотрудников в общем виде (что деятельность в информационных системах контролируется).
  • Производительность: Добавление проверок в частые операции может негативно сказаться на скорости. Необходимо тщательно выбирать точки для встраивания проверок, избегая циклов и частых вызовов.

Итог: защита как процесс, а не разовая акция

Защита от внутренних угроз, особенно в момент перехода статуса сотрудника,, это не про установку одного «волшебного» переключателя. Это про создание архитектуры, в которой такие переключатели логично встроены в бизнес-процесс и позволяют управлять рисками пропорционально.

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

Оставьте комментарий