Как предоставить доступ к 1С через OData REST только на чтение без снятия конфигурации с поддержки

← На главную

При интеграции сторонних систем (например, внешних витрин, аналитических сервисов или ИИ-агентов) часто требуется предоставить доступ к данным базы через стандартный интерфейс OData. Однако стандартный протокол OData в 1С поддерживает не только чтение (GET), но и модификацию данных посредством запросов POST, PATCH, PUT и DELETE. Если необходимо оставить типовую конфигурацию на полной поддержке и гарантировать, что внешний сервис не сможет повредить или перезаписать данные, возникает сложная архитектурная задача.

Рассмотрим подробно несколько проверенных способов решения этой проблемы: от настройки веб-сервера до программных механизмов в расширениях платформы 1С:Предприятие.

Способ 1. Блокировка модифицирующих HTTP-методов на уровне веб-сервера

Проанализируем самый надежный способ, который вообще исключает попадание небезопасных запросов в саму платформу 1С. Метод заключается в запрете всех HTTP-глаголов, кроме безопасных для чтения (GET и HEAD), на стороне обратного прокси-сервера (Nginx) или веб-сервера (IIS, Apache).

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

Разберем по шагам два варианта настройки веб-сервера:

Выделение отдельной веб-публикации для OData. Создадим отдельную публикацию базы данных (например, /base_odata) с собственным файлом default.vrd. В этой публикации разрешим только OData, а на веб-сервере для этого URL-пути полностью запретим любые методы, кроме GET и HEAD. Дополнительно можно ограничить доступ по списку доверенных IP-адресов.
Фильтрация по URL-шаблону внутри существующей публикации. Если отдельную публикацию поднять невозможно, настроим фильтрацию строго по пути протокола /odata/standard.odata/.

Посмотрим на пример конфигурации для веб-сервера Nginx, где доступ к стандартному интерфейсу OData строго ограничен только чтением:


location ~* ^/ib_name/odata/standard.odata/ {
    limit_except GET HEAD {
        deny all;
    }
    proxy_pass http://127.0.0.1:8080;
    proxy_set_header Host $host;
    proxy_set_header X-Real-IP $remote_addr;
}

При такой настройке при попытке отправить POST, PUT, PATCH или DELETE веб-сервер вернет клиенту ошибку 405 Method Not Allowed или 403 Forbidden, не передавая запрос серверу 1С.

Способ 2. Использование обобщенных подписок на события в расширении (платформа 8.3.17+)

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

Выясним причину, почему это работает: вызовы через OData выполняются на сервере и полностью инициируют штатные транзакции записи объектов. Все серверные события жизненного цикла (ПередЗаписью, ПриЗаписи, ПередУдалением) срабатывают точно так же, как и при обычной интерактивной или программной работе.

Разберем по шагам создание блокирующей подписки в расширении:

Создадим расширение конфигурации с назначением Адаптация или Дополнение.
Добавим объект ПодпискаНаСобытие с именем, например, ЗапретЗаписиODataПользователемПередЗаписью.
В свойстве Источник укажем базовые обобщенные типы метаданных: СправочникОбъект, ДокументОбъект, ПланВидовХарактеристикОбъект, РегистрСведенийНаборЗаписей и другие необходимые типы. Затягивать конкретные справочники и документы основной конфигурации в расширение не требуется.
В свойстве Событие выберем ПередЗаписью.
Создадим общий модуль в расширении и опишем обработчик с проверкой текущего пользователя.

Посмотрим на пример программного кода обработчика:


Процедура ЗапретЗаписиODataПередЗаписью(Источник, Отказ) Экспорт
    Если Отказ Тогда
        Возврат;
    КонецЕсли;
    
    ТекущийПользовательИБ = ПользователиИнформационнойБазы.ТекущийПользователь();
    Если ТекущийПользовательИБ <> Неопределено И ТекущийПользовательИБ.Имя = "ODataBot" Тогда
        Отказ = Истина;
        ВызватьИсключение "Модификация данных через OData для данного пользователя запрещена.";
    КонецЕсли;
КонецПроцедуры

Аналогичным образом создается вторая подписка на событие ПередУдалением для блокировки удаления данных. Если внешний клиент попытается отправить изменяющий запрос, 1С вернет HTTP-статус ошибки с описанием сбоя, а исходные данные останутся нетронутыми.

Способ 3. Замена OData на собственный HTTP-сервис в расширении

Стандартный OData отдает всю модель базы и может создавать повышенную нагрузку на систему сложными неоптимизированными запросами с фильтрами $filter и соединениями $expand. Альтернативный архитектурный подход — закрыть OData вовсе и создать собственный HTTP-сервис внутри расширения конфигурации.

Рассмотрим подробнее преимущества такого подхода:

Строгий контроль методов. В HTTP-сервисе в расширении создаются только шаблоны с методом GET. Методы POST, PUT, DELETE физически отсутствуют в структуре сервиса, поэтому передать модифицирующий запрос в систему невозможно технически.
Оптимизация производительности. Запросы пишутся на платформенном языке 1С с использованием временных таблиц, нужных индексов и ограничений выборки.
Безопасность метаданных. Сервис отдает только строго определенные поля и структуры (в формате JSON), скрывая от внешнего ИИ-бота служебные таблицы и конфиденциальные данные.

Способ 4. Подключение к реплике базы данных на уровне СУБД

Если для интеграции критически важен доступ онлайн, но риски блокировок или повреждения рабочей базы недопустимы, используют аппаратное разделение на уровне системы управления базами данных (СУБД):

Настраивается постоянная потоковая репликация основной базы в режиме реального времени (например, Read-Only Replica в СУБД PostgreSQL или группа доступности Always On с маршрутизацией только на чтение в Microsoft SQL Server).
К базе-реплике подключается отдельный рабочий сервер «1С:Предприятия».
На этой отдельной базе публикуется интерфейс OData.

В этой схеме СУБД физически запрещает любые транзакции записи на уровне дисковой подсистемы реплики, что на 100% исключает возможность модификации данных через OData и полностью изолирует рабочую базу от аналитической нагрузки.

Способ 5. Программная настройка состава стандартного интерфейса OData

Если требуется ограничить перечень таблиц, доступных для внешнего сервиса, воспользуемся стандартным методом платформы:


МассивОбъектов = Новый Массив;
МассивОбъектов.Добавить(Метаданные.Справочники.Номенклатура);
МассивОбъектов.Добавить(Метаданные.Документы.РеализацияТоваровУслуг);

СеансСтандартногоИнтерфейсаOData.УстановитьСостав(МассивОбъектов);

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