Насколько безопасно создание веб-сервиса 1С для интеграции с чат-ботом или прило

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

## Насколько безопасны разные варианты

### 1. Прямо опубликовать 1С в Интернет

Например:

и разрешить внешним пользователям обращаться к опубликованному HTTP-сервису 1С.

Без дополнительных мер это рискованный вариант.

Проблемы:

— 1С становится доступна из внешней сети;
— злоумышленник может подбирать адреса методов;
— любой найденный метод можно вызывать не только из вашего приложения;
— нельзя полагаться на то, что клиентское приложение скрывает какие-то функции;
— при ошибке в серверном коде можно выдать лишние данные;
— возможны перебор идентификаторов, повтор запросов и нагрузка на сервер;
— при использовании общих модулей с флагом «Вызов сервера» можно случайно открыть лишние серверные функции;
— стандартная авторизация пользователя 1С не всегда подходит для внешних клиентов.

Сам факт, что URL неизвестен пользователям, безопасностью не является. Адреса сервисов можно обнаружить по исходному коду приложения, журналам, документации, сообщениям об ошибках или перебором.

### 2. 1С через обратный прокси

Более безопасная схема:

Промежуточный сервер может выполнять:

— проверку токена;
— ограничение количества запросов;
— блокировку подозрительных IP;
— журналирование обращений;
— проверку размера запроса;
— фильтрацию URL;
— проверку заголовков;
— маршрутизацию только к разрешенным методам.

В этом случае сама 1С не должна быть полностью открыта в Интернет. Желательно, чтобы к ней мог обращаться только прокси-сервер по внутреннему адресу или через VPN.

### 3. Микросервис между внешними клиентами и 1С

Для серьезных систем предпочтительнее:

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

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

## Что обязательно должно быть в HTTP-сервисе 1С

### 1. Авторизация каждого запроса

Нельзя ограничиваться проверкой вида:

или передавать логин и пароль в параметрах URL.

Плохо:

Параметры URL попадают в:

— журналы веб-сервера;
— историю браузера;
— прокси;
— системы мониторинга;
— рефереры;
— логи приложения.

Лучше передавать токен в заголовке:

Либо использовать подписанный запрос.

Для небольшого внутреннего приложения подойдет индивидуальный токен для каждого пользователя или устройства. Для полноценного мобильного приложения лучше применять короткоживущие access-токены и refresh-токены через отдельный сервер авторизации.

### 2. Привязка пользователя бота к данным 1С

Для чат-бота нельзя доверять переданному клиентом идентификатору контрагента.

Небезопасно:

Пользователь может заменить идентификатор и получить данные другого контрагента.

Правильная логика:

1. Бот получает идентификатор пользователя Telegram, VK, WhatsApp или другого канала.
2. 1С находит по нему зарегистрированного пользователя.
3. В 1С хранится связь:

4. Контрагент определяется на сервере по токену или идентификатору пользователя.
5. Из запроса не принимается произвольный Контрагент.

То есть пользователь должен запрашивать:

а не:

### 3. Проверка полномочий на сервере

Проверка должна выполняться внутри серверного обработчика 1С до получения данных.

Например, если бот предоставляет:

— баланс;
— задолженность;
— статусы заказов;
— документы;
— персональные данные;
— возможность создать заказ;
— возможность изменить реквизиты,

то для каждой операции должны быть отдельные проверки.

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

или тем более передавать из приложения текст запроса 1С.

Особенно опасные варианты:

Внешний клиент должен передавать только строго определенные параметры. Например:

А сам список доступных действий должен быть зафиксирован в коде 1С.

### 4. Минимальный набор данных

Через чат-бот обычно не нужно отдавать:

— полные паспортные данные;
— внутренние комментарии менеджеров;
— себестоимость;
— закупочные цены;
— полные банковские реквизиты;
— технические идентификаторы объектов;
— служебные пометки;
— лишние контактные данные сотрудников.

Следует создавать отдельные DTO-структуры или структуры ответа, содержащие только необходимые поля.

Например, для клиента:

А не возвращать всю структуру документа 1С или объект документа целиком.

### 5. HTTPS

Обмен должен выполняться только по HTTPS с корректным сертификатом.

Нельзя использовать:

для передачи:

— токенов;
— персональных данных;
— заказов;
— балансов;
— файлов;
— реквизитов клиентов.

Если используется Telegram webhook, HTTPS обязателен. При этом необходимо проверять, что webhook принимает только ожидаемые запросы, а токен бота не хранится в открытом виде в коде или настройках, доступных пользователям.

### 6. Защита от перебора

Даже при наличии авторизации злоумышленник может отправлять тысячи запросов.

Нужно предусмотреть:

— ограничение количества запросов от одного токена;
— ограничение количества запросов от одного IP;
— временную блокировку после большого числа ошибок;
— ограничение размера тела запроса;
— ограничение количества строк в ответе;
— постраничную выдачу;
— журналирование подозрительной активности;
— запрет слишком частого повторения одной операции.

Особенно важно для методов:

— проверки баланса;
— поиска заказов;
— отправки SMS;
— загрузки файлов;
— создания документов;
— отправки сообщений;
— формирования отчетов.

## Безопасность чат-бота

У чат-ботов есть отдельная проблема: сам пользователь мессенджера не всегда однозначно идентифицирован.

Например, если клиент просто знает номер телефона или переслал ссылку, этого недостаточно для выдачи персональных данных.

Для привязки клиента можно использовать:

1. Идентификатор пользователя мессенджера.
2. Одноразовый код из SMS или электронной почты.
3. Ссылку с одноразовым токеном.
4. Подтверждение номера телефона.
5. Ручное подтверждение менеджером.
6. Связку с личным кабинетом.

Пример безопасной регистрации:

После регистрации запрос «Показать задолженность» должен использовать уже сохраненную связь Telegram ID с контрагентом.

Нельзя считать подтвержденным пользователя только потому, что он знает номер договора. Номер договора может быть известен нескольким сотрудникам или попасть в переписку.

## Безопасность мобильного приложения

Не следует хранить в мобильном приложении:

— постоянный пароль к 1С;
— общий токен компании;
— учетные данные администратора;
— адреса внутренних серверов;
— секретный ключ подписи в открытом виде;
— полномочия, которые должны проверяться на сервере.

Все, что находится в мобильном приложении, потенциально может быть извлечено. Поэтому приложение нельзя считать доверенной стороной.

Правильный принцип:

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

## Если используется веб-сервис SOAP

Веб-сервис 1С можно использовать, но для новых интеграций чаще удобнее HTTP-сервис с JSON.

SOAP сам по себе не делает систему безопасной. Необходимо отдельно настроить:

— HTTPS;
— аутентификацию;
— авторизацию операций;
— ограничение доступных методов;
— проверку входных XML;
— ограничение размера XML;
— защиту от повторной отправки;
— журналирование.

Не стоит публиковать наружу универсальный веб-сервис с большим количеством экспортных методов только потому, что он уже существует в конфигурации.

## Настройки публикации

Для рабочей системы желательно:

— публиковать только конкретный HTTP-сервис;
— не публиковать всю информационную базу без необходимости;
— не включать OData для внешних клиентов без строгой необходимости;
— не открывать стандартные административные интерфейсы;
— использовать отдельный URL для API;
— ограничить доступ к публикации по IP, если это возможно;
— вынести публикацию за reverse proxy;
— отключить подробные сообщения об ошибках во внешнем контуре;
— не возвращать клиенту тексты исключений 1С и трассировки.

Внешнему пользователю нельзя отдавать такие ответы:

Это может раскрыть структуру конфигурации и внутренние имена объектов.

Лучше возвращать нейтральный ответ:

А подробности записывать в защищенный журнал.

## Разделяйте методы по назначению

Вместо одного большого API лучше сделать несколько узких операций:

Для каждого метода отдельно определить:

— кто может его вызвать;
— какие параметры разрешены;
— какие данные возвращаются;
— какие действия выполняются;
— нужна ли дополнительная проверка;
— можно ли повторно выполнять операцию.

Особое внимание нужно уделить POST-операциям. Если запрос создает документ, платеж, заявку или заказ, повторная отправка может создать дубликат. Для таких операций нужен идентификатор идемпотентности, например requestId.

## Нужна ли отдельная учетная запись 1С

Если внешний сервис подключается к 1С под пользователем, лучше создать отдельного технического пользователя:

Для каждого интеграционного направления желательно использовать отдельную учетную запись.

Права должны быть минимальными:

— только необходимые справочники;
— только необходимые документы;
— без административных ролей;
— без интерактивной работы;
— без доступа к лишним данным;
— без права изменения настроек;
— без доступа к администрированию пользователей.

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

## Нужен ли режим привилегированных действий

Если HTTP-сервис работает в привилегированном режиме, это существенно увеличивает последствия ошибки.

Не следует включать привилегированный режим для всего обработчика. Если он действительно нужен, нужно:

— минимизировать участок кода;
— перед ним проверить токен и полномочия;
— не использовать входные параметры напрямую;
— не выполнять произвольные запросы;
— не возвращать объекты целиком;
— отдельно проверять принадлежность данных пользователю.

Опасная схема:

Если злоумышленник сможет подобрать идентификатор, он получит данные вне обычной системы прав.

## Рекомендуемая архитектура для чат-бота

Для большинства задач подходит следующая схема:

В 1С:

1. Таблица зарегистрированных внешних пользователей.
2. Индивидуальный токен или серверная проверка токена.
3. Связь внешнего пользователя с контрагентом или физическим лицом.
4. Набор фиксированных HTTP-методов.
5. Проверка полномочий в каждом методе.
6. Ограниченный состав ответа.
7. Журнал обращений.
8. Ограничение частоты запросов.
9. Отдельный технический пользователь.
10. Отсутствие произвольных запросов и выполнения кода.

Для небольшого внутреннего проекта можно начать с прямого HTTP-сервиса 1С, но даже тогда его следует закрыть HTTPS, токенами, ограничением методов и reverse proxy. Для внешних клиентов безопаснее разместить API-шлюз или промежуточный сервис в DMZ, а 1С оставить во внутренней сети.

Рекомендую посмотреть здесь:

— https://infostart.ru/1c/articles/1615125/
— https://infostart.ru/1c/articles/2517789/
— https://infostart.ru/1c/articles/1368626/