Контроль доступа к документам в 1С:Предприятие — критически важная задача для безопасности бизнес-процессов. Неправильно настроенные права могут привести к утечке конфиденциальных данных, ошибкам в учете или даже мошенничеству. В этой статье разберем все способы ограничения доступа: от стандартных ролей до сложных механизмов RLS (Record Level Security) и прав на уровне записей.

Вы узнаете, как запретить пользователям просматривать чужие заказы, редактировать проведенные документы или видеть финансовую отчетность. Все инструкции актуальны для 1С 8.3 (включая последние релиза) и адаптированы под типовые конфигурации: Бухгалтерия 3.0, Управление торговлей 11, Зарплата и управление персоналом 3.1. Для программистов приведены примеры кода на встроенном языке.

Особое внимание уделим типичным ошибкам администрирования, которые приводят к "дырам" в безопасности. Например, почему настройка прав только через роли недостаточна для крупных компаний, и когда требуется комбинация RLS + права на уровне записей + групповые политики Active Directory.

📊 Какую конфигурацию 1С вы администрируете?
Бухгалтерия 3.0
Управление торговлей 11
Зарплата и управление персоналом
ERP 2.5
Другую типовую
Самописную конфигурацию

1. Базовые принципы прав доступа в 1С

В 1С:Предприятие права доступа строятся на трех китах:

  • 🔑 Роли — наборы прав, которые назначаются пользователям. Например, роль "Кассир" может разрешать создание кассовых ордеров, но запрещать доступ к банковским выпискам.
  • 📄 Права на уровне объектов — разрешения на работу с конкретными справочниками, документами или отчетами (чтение, добавление, изменение, удаление).
  • 🔍 RLS (Record Level Security) — ограничение доступа к отдельным записям (например, менеджер видит только свои заказы).

Важно понимать, что роли действуют глобально: если пользователю назначена роль с правом редактирования документов "Реализация товаров", он сможет изменять все такие документы в базе. Для более тонкой настройки потребуются дополнительные механизмы.

В типовых конфигурациях уже предустановлены стандартные роли (например, "Полные права", "Бухгалтер", "Кладовщик"), но их часто требуется дорабатывать. Например, в Управлении торговлей 11 роль "Менеджер по продажам" по умолчанию позволяет видеть все заказы клиентов, что не всегда уместно.

⚠️ Внимание: Назначение пользователю роли "Полные права" отключает все остальные ограничения, включая RLS. Это эквивалент административного доступа в Windows — используйте только для технических учетных записей.

2. Настройка прав через стандартные роли

Самый простой способ ограничить доступ — отредактировать существующие роли или создать новые. Рассмотрим процесс на примере 1С:Бухгалтерия 3.0:

  1. Откройте конфигуратор (Файл → Конфигуратор).
  2. Перейдите в Администрирование → Пользователи и права → Роли.
  3. Выберите роль для редактирования (например, "Бухгалтер") или создайте новую кнопкой Добавить.
  4. Вкладка Права — здесь настраиваются разрешения для объектов метаданных (документы, справочники, отчеты).

Для ограничения доступа к документу "Платежное поручение":

  1. Найдите в дереве объектов раздел Документы → ПлатежноеПоручение.
  2. Снимите флажки напротив ненужных прав (например, Добавление, Изменение).
  3. Для запрета просмотра чужих документов используйте вкладку Ограничение доступа к данным (RLS).

Пример настройки роли "Кассир" для работы только с кассовыми ордерами:

Объект метаданных Чтение Добавление Изменение Удаление
Документ "ПриходныйКассовыйОрдер" ✅ ✅ ✅ ❌
Документ "РасходныйКассовыйОрдер" ✅ ✅ ✅ ❌
Документ "ПлатежноеПоручение" ❌ ❌ ❌ ❌
Справочник "Контрагенты" ✅ ❌ ❌ ❌
⚠️ Внимание: После изменения ролей обязательно обновите права пользователей в Администрирование → Пользователи. В противном случае изменения не вступят в силу.

Создана новая роль с уникальным именем|Права назначены только на необходимые объекты|Запрещены лишние действия (удаление, изменение проведенных документов)|Проверена работа RLS (если используется)|Обновлены права пользователей в базе-->

3. Ограничение доступа на уровне записей (RLS)

RLS (Record Level Security) позволяет ограничить доступ пользователя к конкретным записям в базе. Например, менеджер по продажам будет видеть только свои заказы, а руководитель отдела — заказы всех подчиненных.

Настройка RLS состоит из двух этапов:

  1. Создание ограничения в конфигураторе (Администрирование → Ограничение доступа к данным).
  2. Привязка ограничения к роли на вкладке Ограничение доступа к данным (RLS).

Пример для документа "Заказ клиента" в Управлении торговлей 11:

  1. Создайте новое ограничение с именем "Только свои заказы".
  2. В поле Таблица выберите Документ.ЗаказКлиента.
  3. В поле Параметр укажите условие: 
    Ответственный = &ТекущийПользователь

    где &ТекущийПользователь — стандартный параметр, возвращающий текущего пользователя системы.

  4. На вкладке Права отметьте Чтение, Добавление, Изменение.
  5. Сохраните ограничение и привяжите его к роли "Менеджер по продажам".

Для более сложных сценариев можно использовать параметры сеанса. Например, ограничить доступ по подразделению:

Подразделение В ОБЪЕКТЕ(Документ.ЗаказКлиента.Ответственный) = &ТекущееПодразделение
⚠️ Внимание: RLS не работает для полнотекстового поиска (ПоискПоНоменуклатуре и аналогичные механизмы). Пользователь может найти документ через поиск, даже если у него нет прав на просмотр.
Как проверить, применяется ли RLS к пользователю?

Чтобы убедиться, что ограничения RLS работают:

1. Зайдите в базу под тестовым пользователем с назначенной ролью.

2. Откройте список документов, к которым применено RLS (например, "Заказы клиентов").

3. Если видно только часть записей — RLS работает корректно.

4. Для диагностики используйте отладчик в конфигураторе: установите точку останова на событие ПриОткрытии формы списка и проверьте, какие данные возвращает запрос к базе с учетом RLS.

4. Права на уровне записей (без RLS)

Если RLS кажется слишком сложным, можно использовать права на уровне записей — альтернативный механизм, доступный в большинстве типовых конфигураций. Он позволяет назначать права не на весь документ, а на отдельные его экземпляры.

Пример настройки для документа "Счет на оплату" в Бухгалтерии 3.0:

  1. Откройте документ "Счет на оплату" в режиме предприятия.
  2. Выделите нужный счет и нажмите Ещё → Настройка прав доступа (или Действия → Права доступа, в зависимости от конфигурации).
  3. Добавьте пользователя или роль, которой хотите разрешить доступ.
  4. Назначьте права: Чтение, Изменение или Полный доступ.

Преимущества этого метода:

  • ✅ Не требует изменений в конфигураторе (настраивается в пользовательском режиме).
  • ✅ Гибкость: можно назначать права на каждый документ индивидуально.
  • ✅ Визуальный контроль: в списке документов отображается иконка 🔒 для записей с ограниченным доступом.

Недостатки:

  • ❌ Трудоемко при большом количестве документов (назначать права приходится вручную).
  • ❌ Нет автоматизации (например, нельзя автоматически давать доступ менеджеру ко всем его заказам).
💡

Для массового назначения прав на документы используйте обработку "Групповая обработка справочников и документов" (доступна в типовых конфигурациях). С ее помощью можно выбрать несколько документов и назначить одинаковые права доступа за один раз.

5. Комбинация RLS и прав на уровне записей

В сложных сценариях (например, в ERP 2.5 или крупных самописных конфигурациях) часто требуется комбинировать оба подхода. Типичный пример:

  • 🔹 RLS ограничивает доступ менеджера к заказам своего отдела (Подразделение = &ТекущееПодразделение).
  • 🔹 Права на уровне записей используются для исключений: руководитель отдела может вручную открыть доступ к конкретному заказу другому менеджеру.

Алгоритм настройки:

  1. Сначала настройте RLS в конфигураторе (как описано в разделе 3).
  2. Затем в пользовательском режиме назначьте дополнительные права на уровне записей для исключительных случаев.
  3. Проверьте, что RLS не конфликтует с правами на уровне записей. Для этого используйте тестового пользователя с минимальными правами.

Пример кода для программной проверки доступа (встроенный язык 1С):

Если НЕ ЗначениеЗаполнено(ПраваДоступа.ПроверкаДоступа(

"Документ.ЗаказКлиента",


Объект.Ссылка,


"Чтение")) Тогда


Сообщить("Доступ запрещен!");


Возврат Ложь;


КонецЕсли;

⚠️ Внимание: При комбинации RLS и прав на уровне записей приоритет имеют более строгие ограничения. Если RLS запрещает доступ, а права на уровне записей разрешают — доступ будет запрещен.

6. Дополнительные механизмы безопасности

Для усиления защиты данных в 1С используйте:

  • 🔐 Групповые политики Active Directory — ограничение запуска 1С только с определенных компьютеров или для конкретных пользователей домена.
  • 📡 Сеансы работы — настройка автоматического завершения сеансов после бездействия (Администрирование → Настройки программы → Сеансы работы).
  • 📋 Журнал регистрации — ведение лога действий пользователей (включается в Администрирование → Журнал регистрации).
  • 🔄 Резервное копирование — регулярное создание бэкапов перед массовыми изменениями прав.

Пример настройки групповой политики для 1С:

  1. Откройте Редактор групповой политики на сервере (gpedit.msc).
  2. Перейдите в Конфигурация пользователя → Административные шаблоны → 1С:Предприятие 8.
  3. Активируйте политику Ограничить запуск 1С:Предприятие и укажите разрешенные базы.
  4. Настройте политику Запретить сохранение файлов на локальный диск для предотвращения утечек данных.

Для аудита действий пользователей включите журнал регистрации с параметрами:

Регистрировать = Истина;

РегистрироватьПараметры = Истина;


РегистрироватьДанные = Ложь; // Во избежание перегрузки базы


УровеньДетализации = УровеньДетализацииЖурналаРегистрации.Отладка;

💡

Сочетание технических средств (RLS, права на уровне записей) и организационных мер (групповые политики, журнал регистрации) обеспечивает максимальную защиту данных в 1С.

7. Типичные ошибки и как их избежать

Ошибки при настройке прав доступа часто ведут к брешам в безопасности или невозможности работы пользователей. Рассмотрим самые распространенные:

Ошибка Последствия Как исправить
Назначение роли "Полные права" обычным пользователям Пользователь получает доступ ко всем данным, включая зарплаты и финансовую отчетность. Создайте отдельную роль с минимально необходимыми правами.
Использование только RLS без прав на уровне записей Невозможно гибко управлять исключениями (например, дать доступ к чужому документу). Комбинируйте RLS с правами на уровне записей.
Необновление прав пользователей после изменений в ролях Пользователи продолжают работать со старыми правами. После редактирования ролей обновите права в Администрирование → Пользователи.
Настройка RLS без тестирования Пользователи не видят нужные документы или видят чужие. Проверяйте RLS под тестовым пользователем с минимальными правами.

Еще одна распространенная проблема — конфликты между RLS и правами на уровне записей. Например, если:

  • RLS разрешает доступ к документу, но права на уровне записей запрещают — документ будет недоступен.
  • RLS запрещает доступ, а права на уровне записей разрешают — документ будет недоступен (приоритет у RLS).

Для диагностики таких конфликтов используйте Отладчик 1С:

  1. Установите точку останова на событие ПриОткрытии формы документа.
  2. Проверьте, какие ограничения применяются через ПраваДоступа.ПроверкаДоступа().
  3. Сравните результат с настройками RLS в конфигураторе.

FAQ: Частые вопросы по настройке прав в 1С

Как запретить пользователю редактировать проведенные документы?

В настройках роли снимите флажок Изменение для документа и оставьте только Добавление. Для типовых конфигураций (например, Бухгалтерия 3.0) также проверьте настройку Разрешить изменение проведенных документов в параметрах учета (Главное → Настройки → Параметры учета).

Можно ли ограничить доступ к документам по дате создания?

Да, через RLS. В ограничении доступа используйте условие:

Дата >= НачалоМесяца(&ТекущаяДата) И Дата <= КонецМесяца(&ТекущаяДата)

где &ТекущаяДата — параметр сеанса с текущей датой. Это позволит показывать документы только за текущий месяц.

Как дать доступ к документам только определенному кругу пользователей?

Создайте новую роль (например, "Руководители проекта") и настройте для нее RLS с условием:

Пользователь.Группа В (&ДопущенныеПользователи)

где &ДопущенныеПользователи — список пользователей, хранящийся в справочнике или параметре сеанса.

Почему пользователь не видит документы, несмотря на назначенные права?

Проверьте:

  1. Обновлены ли права пользователя после изменений в ролях.
  2. Нет ли конфликтующих RLS-ограничений (например, по подразделению и по ответственному).
  3. Не установлен ли фильтр в форме списка документов (иногда пользователи случайно сохраняют фильтры).
  4. Нет ли ошибок в коде RLS (проверьте через Отладчик).
Как массово назначить права на документы?

Используйте обработку "Групповая обработка справочников и документов":

  1. Откройте обработку (Файл → Открыть → выберите файл обработки).
  2. Укажите тип объекта (например, "Документ.ЗаказКлиента").
  3. Задайте отбор (например, по дате или ответственному).
  4. На вкладке Действия выберите Настройка прав доступа.
  5. Укажите пользователя/роль и права (Чтение, Изменение).
  6. Выполните обработку.