Как запретить вызов HTTP-сервиса из копии базы 1С

Программист 1С v8.3 (Управляемые формы) IT и автоматизация бизнеса
← На главную

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

В этой статье мы подробно разберем, как обезопасить свой контур разработки и предотвратить нежелательные вызовы HTTP-сервисов из копий баз, используя как встроенные средства платформы и БСП, так и инструменты системного администрирования.

Использование механизмов Библиотеки стандартных подсистем (БСП)

В современных типовых конфигурациях 1С, построенных на базе БСП, уже заложен мощный механизм контроля работы с внешними ресурсами. Рассмотрим, как он функционирует. При восстановлении базы из резервной копии или ее перемещении платформа определяет изменение параметров (имя сервера, имя базы) и при первом запуске выдает пользователю вопрос: «Информационная база перемещена или восстановлена из резервной копии?». Если пользователь выбирает вариант «Это копия», система устанавливает блокировку регламентных заданий и внешних ресурсов.

Для программной проверки этого состояния мы можем использовать параметры сеанса. Проанализируем пример кода, который следует вставлять перед выполнением любого HTTP-запроса:


Если ПараметрыСеанса.РаботаСВнешнимиРесурсамиЗаблокирована Тогда
    ЗаписьЖурналаРегистрации("Интеграция", УровеньЖурналаРегистрации.Предупреждение, , , "Попытка вызова сервиса из копии базы заблокирована.");
    Возврат;
КонецЕсли;

В некоторых версиях БСП рекомендуется обращаться к специализированным функциям общих модулей, чтобы код оставался универсальным. Выясним, как это сделать через модуль ОбщегоНазначения:


Если ОбщегоНазначения.ЭтоКопияИнформационнойБазы() Тогда
    // Блокируем логику вызова
    ВызватьИсключение "Выполнение внешних запросов запрещено в копии информационной базы!";
КонецЕсли;

Использование ОбщегоНазначения.ЭтоКопияИнформационнойБазы() является наиболее «чистым» методом, так как он опирается на стандартную логику БСП, которую вендор развивает и поддерживает.

Профили безопасности на уровне кластера

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

Для тестовой базы мы можем создать профиль, в котором:

  1. Будет полностью запрещено использование HTTPСоединение для определенных URL.
  2. Будут ограничены права на запуск внешних компонент и COM-объектов.
  3. Разрешен доступ только к «заглушкам» (Mock-серверам) или тестовым контурам внешних систем.

Преимущество этого метода заключается в том, что даже если разработчик забудет добавить проверку ЭтоКопия() в коде, платформа сама заблокирует попытку соединения на низком уровне и выдаст ошибку доступа. Проанализируем ситуацию: если код попытается создать HTTPСоединение с адресом, не входящим в белый список профиля, выполнение будет прервано с системной ошибкой.

Разграничение на уровне сетевой инфраструктуры (файл Hosts)

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

Когда 1С инициирует HTTP-запрос, она обращается к DNS-службе сервера для определения IP-адреса хоста. Мы можем перехватить этот процесс. В файле C:\Windows\System32\drivers\etc\hosts (для Windows) или /etc/hosts (для Linux) на тестовом сервере можно прописать следующее:


127.0.0.1   api.production-service.ru
127.0.0.1   exchange.mycompany.com

После внесения таких изменений любые запросы из 1С к рабочим адресам api.production-service.ru будут направляться на локальный адрес самого сервера (loopback). Запрос просто «не уйдет» в сеть, и рабочая база будет в безопасности. Это максимально надежный способ «защиты от дурака» на уровне инфраструктуры.

Централизованная «обертка» для HTTP-запросов

Чтобы не вставлять условия проверки в каждом месте конфигурации, где используется HTTPСоединение, мы рекомендуем создать общую процедуру или функцию в общем модуле. Рассмотрим пример создания такой «обертки» в модуле ИнтеграцияКлиентСервер:


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

Использование такой функции позволяет централизованно управлять всеми исходящими вызовами. Вы можете добавить в нее логирование всех запросов, проверку заголовков или даже подмену адреса на тестовый в зависимости от константы или переменной окружения.

Идентификация источника на стороне приемника

Проанализируем еще один интересный подход: передача информации о базе в самом запросе. Если вы контролируете обе стороны интеграции (и базу-отправитель, и базу-приемник), вы можете добавить в заголовки (Headers) HTTP-запроса уникальный идентификатор базы или ее имя.

Пример формирования запроса на стороне отправителя:


Запрос = Новый HTTPЗапрос("/hs/myapi/v1/data");
Запрос.Заголовки.Вставить("X-1C-Base-Name", СтрокаСоединенияИнформационнойБазы());

На стороне приемника (в HTTP-сервисе) мы можем проверять этот заголовок. Если имя базы не совпадает с эталонным рабочим именем, сервис может вернуть ошибку 403 Forbidden или 406 Not Acceptable. Это гарантирует, что даже если запрос дошел до рабочей базы из копии, он не будет обработан.

Использование переменных окружения

Для высоконагруженных систем или сред с развитым DevOps-подходом эффективно использовать переменные окружения сервера приложений. Проанализируем, как это работает. На рабочем сервере устанавливается переменная APP_ENV = PRODUCTION, а на тестовом — APP_ENV = STAGING.

В коде 1С мы можем считывать эту переменную:


Shell = Новый COMОбъект("WScript.Shell");
Environment = Shell.Environment("Process");
CurrentEnv = Environment.Item("APP_ENV");

Если CurrentEnv <> "PRODUCTION" Тогда
    // Блокируем или перенаправляем запрос
КонецЕсли;

Этот метод хорош тем, что он не зависит от данных внутри самой базы (которые могут быть перенесены вместе с копией), а жестко привязан к среде исполнения (серверу).

Заключение

Мы рассмотрели различные уровни защиты: от программных проверок внутри 1С до административных настроек серверов и сетей. Наилучшей практикой считается комбинирование подходов. Рекомендуется использовать встроенную проверку БСП на копию базы для корректного информирования пользователей, а также настраивать сетевые ограничения (через файл hosts или прокси-сервер) для гарантированного пресечения утечки данных в продуктивные сервисы. Помните, что безопасность данных — это комплексная задача, требующая внимания как со стороны разработчика, так и со стороны системного администратора.

← На главную