Утечка базы 1С: какие меры реально мешают унести данные

Защитить базу 1С от копирования можно только снаружи программы: убрать у пользователей доступ к файлу базы и серверу СУБД, перевести файловую базу в клиент-серверный режим или на терминал, а внутри 1С урезать права на вывод данных, внешние обработки и внешнее соединение. Частое заблуждение — что хватит пароля на вход или HASP-ключа. Ни то ни другое не мешает унести файл 1Cv8.1CD на флешку.

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

Откуда на самом деле уносят базы 1С

Прежде чем закрывать что-то, оцените, через какие каналы данные покидают компанию. На практике их пять.

• 📁 Файл базы. В файловом варианте вся база — один файл 1Cv8.1CD в общей папке. У каждого, кто работает с базой, есть права на запись в эту папку, иначе 1С не откроется. Скопировать файл может любой из них.
• 💾 Выгрузка .dt. Конфигуратор выгружает базу целиком одним файлом. Это доступно пользователю с административными правами.
• 🗄️ Резервные копии. Архивы лежат на сетевых дисках, в облаке, у подрядчика. Часто без пароля.
• 🔌 Внешнее соединение и обработки. Через COM-соединение или внешнюю обработку можно вытащить справочники и документы программно, не трогая файл.
• 📋 Вывод на экран. Отчёты сохраняются в Excel, списки копируются в буфер обмена. Это медленнее, но клиентскую базу так выносят чаще всего.

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

Права и роли: что закрыть внутри 1С

Внутри программы защищаем не файл, а пути, по которым данные выходят наружу через интерфейс. В типовых конфигурациях права настраиваются через профили групп доступа: Администрирование → Настройки пользователей и прав → Профили групп доступа. Если профиль нужен свой, скопируйте типовой и уберите из него лишние роли.

Что проверить у рядовых пользователей:

Ограничение права «Вывод» — сильная мера, но неудобная. Бухгалтер перестанет печатать и сохранять отчёты. Её разумно применять к ролям вроде «оператор склада» или «менеджер по продажам», где выгрузка не нужна.

💡 Для защиты отдельных справочников, например клиентской базы, подойдёт ограничение доступа на уровне записей (RLS). Менеджер видит только своих контрагентов, и выгрузка списка уже не даёт всей базы.

Профили безопасности для внешнего кода

В клиент-серверном варианте в консоли кластера настраиваются профили безопасности. Они запрещают внешним обработкам и расширениям обращаться к файловой системе, COM-объектам и интернету. В типовых конфигурациях на БСП использование профилей включается в разделе Администрирование, в настройках защиты. Внешняя обработка без нужных разрешений просто не сможет записать файл на диск.

Начиная с платформы 8.3.9 работает и защита от опасных действий: при открытии внешней обработки платформа предупреждает пользователя. Не отключайте её в свойствах пользователя без причины.

Блокировка запуска копии: код при старте и его пределы

Популярная идея — встроить в базу проверку: если база открыта не на «своём» сервере, программа закрывается. Это действительно отсекает случайного сотрудника, который скопировал файл домой.

Проверку пишут в расширении, чтобы не снимать типовую конфигурацию с поддержки. В модуле управляемого приложения расширения:

&После("ПриНачалеРаботыСистемы")
Процедура ЗащитаКопии_ПриНачалеРаботыСистемы()
	Строка = НРег(СтрокаСоединенияИнформационнойБазы());
	Если СтрНайти(Строка, "srvr=""srv1c""") = 0 Тогда
		ЗавершитьРаботуСистемы(Ложь);
	КонецЕсли;
КонецПроцедуры

Здесь srv1c — имя вашего сервера 1С в нижнем регистре. Для файловой базы вместо srvr проверяют путь file= к каталогу.

Слабые места у такой защиты серьёзные:

• 🔓 Пользователь с административными правами откроет Конфигуратор, отключит или удалит расширение.
• 🔓 Внешнее соединение и Конфигуратор не выполняют клиентский обработчик ПриНачалеРаботыСистемы.
• 🔓 Данные в .1CD или в базе СУБД всё равно читаются без запуска 1С.

Код при запуске — это замок от честных людей, а не защита данных. Рассматривайте его как дополнение к ограничению доступа к файлу, но не вместо него.

Поставка без исходных текстов: что скрывает, а что нет

Технологическая поддержка и режим поставки решают другую задачу — защиту кода, а не данных. Это вопрос разработчика, который продаёт отраслевое решение и не хочет, чтобы его модули читали.

При создании файлов поставки в Конфигураторе (Конфигурация → Поставка конфигурации → Настройка поставки) для модулей можно выбрать вариант поставки без исходных текстов. Клиент получит работающую конфигурацию, но не увидит алгоритм. Для более жёсткой защиты разработчики используют систему лицензирования и защиты конфигураций (СЛК) — она привязывает работу решения к своему ключу.

Чего это не даёт:

1. Данные бухгалтерии, клиенты и цены остаются в базе в открытом виде.
2. Пользователь с правами может выгрузить базу в .dt и поднять её где угодно.
3. Закрытые модули мешают вашим же доработкам: обновить или исправить такой код может только автор.

Если цель — не дать унести клиентскую базу, поставка без исходников не поможет. Если цель — защитить собственную разработку от тиражирования, это правильный инструмент.

Шифрование данных 1С на диске, в СУБД и в копиях

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

Шифрование не мешает тому, у кого есть легальный доступ. Сотрудник, открывший 1С под своим пользователем, видит данные в расшифрованном виде. Поэтому этот слой закрывает физическую кражу, а не инсайдера.

💡 Резервные копии — самый недооценённый канал утечки. Проверьте, кто имеет доступ к папке с бэкапами и к облачному хранилищу. Часто это шире, чем доступ к самой базе.

HASP-ключи и лицензии: почему они не защищают данные

Аппаратный ключ HASP и программная лицензия 1С — это защита фирмы 1С от нелегального использования платформы. Ваши данные они не охраняют.

Как это выглядит на практике:

• 🔑 Ключ или программная лицензия позволяет запускать платформу на определённом числе рабочих мест.
• 📦 Сама база к ключу не привязана. Файл 1Cv8.1CD или выгрузку .dt можно открыть на любом компьютере с собственной лицензией.
• 🖥️ Без лицензии платформа базу не запустит (кроме учебной версии), но для злоумышленника это лишь вопрос покупки своей лицензии.

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

Ограничение доступа к базе 1С на уровне сети и файлов

Это главный слой защиты. Задача — чтобы пользователь вообще не имел доступа к файлам базы, а работал с ней только через программу.

Перевод на клиент-серверный вариант или терминал

В клиент-серверном варианте данные лежат в СУБД на сервере. У пользователя нет пути к файлу: клиент обращается к агенту сервера 1С (порт 1540), затем к менеджеру кластера (1541) и рабочим процессам (диапазон портов задаётся в свойствах рабочего сервера, по умолчанию 1560-1591).

Для небольшой файловой базы есть два варианта без перехода на СУБД:

1. Терминальный сервер . База лежит на сервере, пользователи работают через RDP. Общей папки нет вообще.
2. Публикация на веб-сервере. Пользователи открывают базу через тонкий клиент или браузер по HTTPS, файл им недоступен.

Правила сети и файловой системы

Что настроить администратору:

1. Закрыть папку с файловой базой от всех, кроме службы веб-сервера или терминальных пользователей, если база перенесена на терминал.
2. Закрыть порт СУБД (1433 для MS SQL, 5432 для PostgreSQL) на межсетевом экране для рабочих станций. Подключаться к СУБД должен только сервер 1С.
3. Назначить администраторов кластера и центрального сервера в консоли кластера. Без них любой, кто дотянется до порта 1540, может управлять кластером.
4. На терминальном сервере отключить перенаправление дисков и буфера обмена в групповых политиках, если сотрудникам это не нужно по работе.
5. Ограничить запись на USB-накопители групповой политикой на рабочих станциях.
6. Учётную запись СУБД, под которой работает 1С, не давать пользователям и подрядчикам.

Журнал регистрации как контроль

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

Частые ошибки при защите базы 1С

• ❌ Пароль на вход считают защитой данных. Пароль защищает интерфейс. Файл базы читается и без него.
• ❌ Общий пользователь на всех. Если десять человек входят под одним именем, журнал регистрации бесполезен, а права не разграничены.
• ❌ Подрядчику дают полные права и выгрузку. Для доработок дают копию базы с обезличенными данными, а не рабочую базу.
• ❌ Бэкап лежит рядом с базой. Копия в той же папке доступна всем, у кого есть доступ к базе, — и пропадёт вместе с ней при сбое диска.
• ❌ Защита только техническая. Без оформленного режима коммерческой тайны уволившегося сотрудника, унёсшего клиентскую базу, сложно привлечь к ответственности.

Частые вопросы