Защита конфигурации 1С: права, поставка, выгрузка и бэкапы
Содержание
Чаще всего конфигурацию ломает не хакер, а свой же сотрудник с ролью «Полные права», который «просто поправил» один модуль. Второй частый сценарий: подрядчик уходит, а исходники остаются у него. Поэтому защита конфигурации 1С от изменений начинается не с паролей на модули, а с вопроса: кто вообще может открыть Конфигуратор .
Полностью закрыть конфигурацию от копирования средствами платформы нельзя. Можно сделать так, чтобы лишний человек не добрался до Конфигуратора, чтобы любая правка была видна и обратима, а потеря базы стоила часа работы, а не месяца. Ниже — слои защиты от дешёвых к дорогим.
Всё, что описано ниже, касается защиты своей базы и своих разработок. Обход защиты чужих решений и лицензий здесь не разбирается.
Сначала решите, от чего защищаете
Меры для случайной правки и для кражи разработки — разные. Определитесь, какой у вас случай, иначе потратите время на лишнее.
Таблица ниже показывает, какой слой что закрывает.
| Слой | Защищает от | Не защищает от |
|---|---|---|
| Роли и права | Правок и просмотра данных обычными пользователями | Администратора с полными правами |
| Поддержка конфигурации | Случайных изменений типовых объектов | Намеренной правки при снятии с поддержки |
| Хранилище и выгрузка в файлы | Потери истории и «тихих» правок | Утечки самих исходников |
| Резервные копии | Порчи, удаления, шифровальщиков | Кражи копии, если её не защитить |
| Защита сервера и сети | Внешнего доступа к базе и СУБД | Злоупотреблений изнутри |
| Журнал регистрации | Неподотчётности | Самих действий (он только фиксирует) |
Роли и права: кому дать Конфигуратор, а кому нет
Это самый дешёвый и самый важный слой. Любой пользователь с ролью «Полные права» может открыть Конфигуратор и изменить что угодно, в том числе включить себе всё остальное.
Минимум прав на каждого
- 👤 Обычным сотрудникам — только прикладные роли своего участка: бухгалтер, кадровик, кладовщик.
- 🔑 Роль «Полные права» — одному-двум людям. Лучше выделить отдельного пользователя-администратора, под которым никто не работает каждый день.
- 🚫 Не давайте ролей «Администратор системы» и «Полные права» по принципу «чтобы не просил каждый раз».
- 🔒 У каждого пользователя свой пароль. Общий пользователь «Бухгалтер» на пятерых лишает смысла любой аудит.
Вход в Конфигуратор определяется правом «Конфигуратор» у роли. Если его нет, пользователь не сможет запустить 1С в режиме разработки, даже зная путь к ярлыку. Проверьте у каждой роли, нужно ли это право на самом деле.
Защита от опасных действий
В карточке пользователя есть флажок «Защита от опасных действий». Он запрашивает подтверждение там, где можно необратимо потерять данные: например, при удалении или при выполнении внешнего кода. Для рядовых пользователей оставляйте его включённым.
Пароли и аутентификация
- Задайте пароль каждому пользователю, в том числе техническим учёткам обмена.
- Включите проверку сложности и срока действия пароля в параметрах пользователей.
- Уволенных не удаляйте, а отключайте вход: история действий в журнале останется привязанной к имени.
Хотите проверить права на практике — войдите под тестовым пользователем с типовой ролью и попробуйте открыть Конфигуратор и изменить ссылочные данные. Результат быстро покажет дыры.
Поддержка и поставка: защита самой конфигурации от правок
Типовая конфигурация 1С стоит «на поддержке» у фирмы-разработчика. Это не пароль, а механизм, который не даёт случайно изменить типовые объекты и позволяет автоматически накатывать обновления.
В Конфигураторе откройте меню «Конфигурация → Поддержка → Настройка поддержки». Там для всей конфигурации и для отдельных объектов выбирается режим:
- 🔐 Не редактируется — объект нельзя менять, пока не снять его с поддержки.
- ✏️ Редактируется с сохранением поддержки — правки возможны, но при обновлении платформа покажет сравнение и предложит объединить.
- 🔓 Снят с поддержки — полная свобода, но обновления придётся накатывать вручную.
Правило простое: держите конфигурацию в режиме «Не редактируется» и открывайте нужный объект только на время правки. Тогда любое изменение становится осознанным шагом.
Поставка для заказчика
Если вы разрабатываете решение для других, при подготовке поставки есть режимы, в которых исходные тексты модулей остаются закрытыми, а конфигурация передаётся без возможности редактирования. Конкретный набор параметров зависит от версии платформы, поэтому смотрите на форме создания поставки, а не копируйте чужие настройки.
Закрытый модуль нельзя восстановить из поставки. Храните исходные тексты у себя в хранилище или в выгрузке в файлы, иначе потеряете собственную разработку.
Хранилище и выгрузка в файлы: история изменений
Правка, которую никто не заметил, опаснее правки, которую сделали с ошибкой. Хранилище конфигурации и выгрузка в файлы делают изменения видимыми.
Хранилище конфигурации
Хранилище работает по схеме «взял объект — изменил — поместил». Пока объект захвачен одним разработчиком, другой его не изменит. У каждой версии есть автор, дата и комментарий, а откатиться можно к любой.
- Создайте хранилище в Конфигураторе: «Конфигурация → Хранилище конфигурации → Создать хранилище».
- Заведите пользователей хранилища и разделите права: чтение, захват объектов, помещение изменений, администрирование.
- Требуйте комментарий к каждой версии. «Правки» — не комментарий.
Выгрузка в файлы и контроль версий
Начиная с версии 8.3 конфигурацию можно выгрузить в набор каталогов и текстовых файлов: «Конфигурация → Выгрузить конфигурацию в файлы». Разработчики выкладывают такую выгрузку в Git и сравнивают версии обычным diff.
Автоматически это делается из командной строки:
"C:\Program Files\1cv8\8.3.xx.xxxx\bin\1cv8.exe" DESIGNER /F "D:\Bases\Work" /N "Админ" /P "пароль" /DumpConfigToFiles "D:\Git\work-config" /Out "D:\Git\dump.log"
Номер версии подставьте свой. Пароль в командной строке виден в списке процессов, поэтому запускайте такой скрипт под служебной учётной записью и не публикуйте его.
Что вы получаете:
- 📜 каждое изменение модуля видно построчно;
- 👁 правка «в обход» обнаруживается при очередной выгрузке: diff покажет то, чего нет в истории хранилища;
- ♻️ откат — это обычное восстановление файла из репозитория.
Репозиторий с исходниками держите на закрытом сервере. Публичный репозиторий с кодом доработок — это тоже «копирование».
Резервные копии: защита от потери и порчи
Если конфигурацию испортили, есть откат. Если испортили данные, спасает только копия. Для работы потеря базы обычно хуже потери конфигурации.
Что копировать
| Способ | Что даёт | Когда подходит |
|---|---|---|
Выгрузка информационной базы (.dt) | Данные и конфигурация в одном файле | Небольшие базы, перенос между серверами |
Копия каталога файловой базы (1Cv8.1CD) | Точная копия, но только при закрытой базе | Файловый вариант в нерабочее время |
| Бэкап СУБД | Полная копия на уровне PostgreSQL или MS SQL | Клиент-серверный вариант |
Выгрузка конфигурации (.cf) | Только конфигурация | Перед правками и обновлением |
Выгрузку базы из командной строки можно поставить в планировщик:
"C:\Program Files\1cv8\8.3.xx.xxxx\bin\1cv8.exe" DESIGNER /F "D:\Bases\Work" /N "Админ" /P "пароль" /DumpIB "E:\Backup\work.dt" /Out "E:\Backup\dump.log"
Копировать файл 1Cv8.1CD у запущенной базы нельзя: копия получится битой. Это один из самых частых способов «сделать бэкап, которым нельзя воспользоваться».
Правило 3-2-1 в масштабе небольшой фирмы
- 📦 три копии данных;
- 💽 на двух разных носителях;
- 🌍 одна копия вне офиса или в облаке.
Копия на том же диске, что и база, копией не считается: диск умер — умерло всё. Второй пункт, который забывают: шифруйте внешние копии и ограничивайте доступ, иначе бэкап станет самым уязвимым местом.
Раз в квартал разворачивайте копию на тестовой машине и проверяйте, что база открывается. Непроверенная копия — это надежда, а не защита.
Защита сервера и сети: чтобы до базы не дошли снаружи
Всё сказанное выше не поможет, если файл базы лежит в сетевой папке с доступом «для всех».
Файловая база
- 📁 Выдайте права на каталог с базой только тем пользователям, которым она нужна. Для работы нужно право изменения, а не полный контроль.
- 🖥 Не публикуйте каталог с базой в общий доступ без необходимости.
- 🔗 Если базу нужно открывать извне, используйте публикацию через веб-сервер с HTTPS, а не проброс общей папки наружу.
Клиент-серверная база
Кластер серверов 1С по умолчанию использует порты 1540 (агент), 1541 (менеджер кластера) и диапазон 1560–1591 для рабочих процессов. СУБД слушает свой порт: у PostgreSQL это 5432, у MS SQL Server — 1433.
Правила брандмауэра простые:
- Порты кластера открывайте только для адресов, где стоят клиенты или другие серверы приложений.
- Порт СУБД открывайте только для сервера 1С. Пользователю напрямую к базе данных ходить незачем.
- Учётные записи кластера и СУБД защищайте отдельными паролями и не используйте их для пользовательской работы.
- Службе сервера 1С дайте отдельного пользователя ОС без прав администратора.
Доступ к серверу СУБД эквивалентен доступу к данным в обход всех ролей 1С. Права в конфигурации ограничивают только тех, кто входит через 1С.
Лицензии и ключи
Аппаратные ключи и программные лицензии защищают от несанкционированного запуска, но не от изменения конфигурации. Если вы разрабатываете коммерческое решение, придерживайтесь лицензионного соглашения платформы и условий поставки. Учитывайте, что защитой от копирования слабой стороной остаётся человек, а не шифрование.
Журнал регистрации: кто что сделал
Журнал регистрации отвечает на вопрос «кто это изменил». Он пишет входы пользователей, ошибки, изменения данных и административные действия.
Настройка находится в Конфигураторе: «Администрирование → Журнал регистрации → Настройки». Здесь задаётся срок хранения и разбивка файлов журнала. Просмотр открывается рядом: «Администрирование → Журнал регистрации».
Что имеет смысл отслеживать:
- 🚪 вход и выход, особенно под административными пользователями и в нерабочее время;
- ⚙️ изменения прав пользователей и ролей;
- 📝 изменения конфигурации и обновление базы;
- 🧾 удаление и массовые изменения данных, если включено протоколирование на нужных объектах.
Фильтры в журнале сужают выборку по пользователю, дате и событию. Начните с отбора по административной учётке: чаще всего аномалия находится там.
Журнал занимает место. На крупной базе задайте разбивку по периодам и срок хранения, иначе он «съест» диск. Для важных событий настройте регулярную выгрузку журнала на отдельный сервер, чтобы администратор не мог стереть следы.