Как ограничить доступ к oData в 1С и обеспечить безопасность данных?

← На главную

Автоматически генерируемый REST-интерфейс (oData) в платформе 1С:Предприятие — это мощный и удобный инструмент для интеграции с внешними системами. Однако его доступность «из коробки» несет серьезные риски для информационной безопасности. Если пользователь имеет права на чтение объектов в базе данных, он может без труда подключиться к интерфейсу oData (например, через Microsoft Excel или Power BI) и выгрузить конфиденциальную информацию в обход интерфейсных ограничений форм.

В этой статье мы подробно рассмотрим, как правильно защитить oData, настроить безопасность на уровне веб-сервера, разграничить доступ с помощью файла публикации default.vrd, а также исправим типичные ошибки синтаксиса при построении oData-запросов.

Почему возникает проблема безопасности oData?

Рассмотрим стандартную ситуацию. В конфигурации 1С:Бухгалтерия настроен профиль для менеджера с правами «Только чтение». В пользовательском интерфейсе вывод списка контрагентов или партнеров для него заблокирован программно. Тем не менее, проходя по ссылке вида .../odata/standard.odata/Catalog_Контрагенты?$format=json под учетными данными этого же сотрудника, мы получаем полный список контрагентов со всеми реквизитами.

Это происходит потому, что стандартный REST-интерфейс выполняет только платформенные проверки прав (роли и RLS) и игнорирует любые ограничения, прописанные на уровне форм («ПриСозданииНаСервере», программная видимость колонок и т.д.). Если чтение объекта разрешено ролью — oData отдаст эти данные.

Для решения этой проблемы мы можем использовать несколько уровней защиты. Разберем их по шагам.

Решение 1. Разделение точек входа через файл публикации default.vrd

Самый надежный и архитектурно правильный способ ограничить oData — разделить публикацию базы данных на две независимые точки входа на веб-сервере (например, Apache или IIS). Мы создадим одну публикацию для работы пользователей, в которой полностью отключим REST-интерфейс, и вторую — исключительно для интеграционных сервисов.

Выполним настройку по шагам:

Создадим первую публикацию для обычных пользователей (например, с алиасом /MyBase). В каталоге этой публикации найдем файл default.vrd и принудительно отключим в нем стандартный интерфейс oData, установив значение параметра в false:


<?xml version="1.0" encoding="UTF-8"?>
<point xmlns="http://v8.1c.ru/8.2/virtual-resource-system"
       xmlns:xs="http://www.w3.org/2001/XMLSchema"
       xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance"
       base="/MyBase"
       ib="Connect=&quot;Srvr=server;Ref=MyBase;&quot;">
    <standardOData enable="false"/>
</point>

Создадим вторую публикацию для интеграции с внешними системами (например, с алиасом /MyBase_Integration). В ее файле default.vrd мы, наоборот, включим REST-интерфейс:


<?xml version="1.0" encoding="UTF-8"?>
<point xmlns="http://v8.1c.ru/8.2/virtual-resource-system"
       xmlns:xs="http://www.w3.org/2001/XMLSchema"
       xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance"
       base="/MyBase_Integration"
       ib="Connect=&quot;Srvr=server;Ref=MyBase;&quot;">
    <standardOData enable="true"/>
</point>

Важный совет по безопасности: Доступ к публикации /MyBase_Integration необходимо жестко ограничить на уровне веб-сервера. Мы можем разрешить запросы к этому URL-адресу только для определенных IP-адресов внешних систем или настроить авторизацию по SSL-сертификатам. Обычные пользователи физически не смогут обратиться к oData, так как на их основной точке входа этот интерфейс полностью отключен.

Решение 2. Использование Nginx в качестве реверсивного прокси

Если нет возможности или желания создавать несколько публикаций в 1С, мы можем использовать Nginx перед нашим веб-сервером (Apache/IIS) для фильтрации запросов. Nginx будет выступать в роли реверс-прокси и блокировать любые попытки обратиться к путям oData для всех, кроме доверенных источников.

Рассмотрим пример конфигурационного файла Nginx, в котором доступ к /odata/ разрешен только для IP-адреса интегратора 192.168.1.100, а для остальных запросов возвращается ошибка доступа 403:


server {
    listen 80;
    server_name 1cserver.local;

    # Общие настройки для работы с базой 1С
    location /MyBase/ {
        proxy_pass http://127.0.0.1:8080/MyBase/;
        proxy_set_header Host $host;
        proxy_set_header X-Real-IP $remote_addr;
    }

    # Ограничение доступа к oData
    location ~* ^/MyBase/odata/ {
        allow 192.168.1.100; # Разрешаем доступ только для сервера интеграции
        deny all;            # Блокируем доступ для всех остальных IP
        
        proxy_pass http://127.0.0.1:8080;
        proxy_set_header Host $host;
        proxy_set_header X-Real-IP $remote_addr;
    }
}

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

Решение 3. Тонкая настройка прав в 1С (БСП) и использование RLS

Для управления доступом к oData непосредственно из конфигурации 1С рекомендуется использовать возможности современных версий Библиотеки стандартных подсистем (БСП):

Специальная роль: В БСП предусмотрена предопределенная роль УдаленныйДоступOData. Назначьте ее только тому служебному пользователю, который будет осуществлять обмен данными.
Настройка состава oData: Перейдите в раздел Администрирование -> Синхронизация данных -> Настройка автоматического REST-сервиса. Здесь можно интерактивно определить только те справочники и документы, которые действительно необходимы для интеграции. Платформа применит метод УстановитьСоставСтандартногоИнтерфейсаOData(), закрыв доступ ко всем остальным объектам метаданных.

Важная деталь при работе с RLS: Если у пользователя настроено ограничение доступа на уровне записей (RLS), стандартный oData-запрос к списку объектов вернет ошибку авторизации HTTP 401 или HTTP 403, как только попытается прочитать хотя бы одну запрещенную запись. Чтобы этого избежать, обязательно передавайте в строке запроса параметр allowedOnly:

http://server/MyBase/odata/standard.odata/Catalog_Товары?allowedOnly=true

В этом случае платформа отфильтрует выборку на уровне СУБД и вернет только те записи, которые разрешены правами пользователя, не вызывая сбоя соединения.

Решение 4. Разработка собственного HTTP-сервиса (обертки)

Если стандартный oData кажется вам слишком небезопасным или неудобным в настройке, лучшим решением будет создание собственного HTTP-сервиса внутри базы 1С (или в расширении конфигурации). Для быстрой разработки таких сервисов подойдёт конструктор API для обмена с другими системами.

Собственный HTTP-сервис позволяет полностью контролировать логику:

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

Исправление ошибки синтаксиса: совместное использование $filter и $select

Разработчики часто сталкиваются с ошибкой при попытке одновременно отфильтровать данные и ограничить состав возвращаемых полей в oData. Рассмотрим ошибочный запрос:

.../Catalog_Организации?$filter=ИНН eq '11111111111111'?$select=Ref_Key

При таком написании платформа вернет ошибку или проигнорирует один из параметров. Выясним причину: в URI-строке знак вопроса ? должен использоваться ровно один раз — для отделения адреса ресурса от параметров запроса. Все последующие параметры должны объединяться с помощью амперсанда &.

Проанализируем правильный вариант написания запроса:

.../Catalog_Организации?$filter=ИНН eq '11111111111111'&$select=Ref_Key

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

Резюме

Оставлять автоматический интерфейс oData открытым для всех пользователей — критическая уязвимость. Для обеспечения безопасности используйте комплексный подход: отключайте oData в пользовательских публикациях файла default.vrd, ограничивайте доступ к служебным адресам на уровне веб-сервера с помощью Nginx или IIS и всегда создавайте выделенных служебных пользователей для обмена данными.