Разработка мобильных приложений на платформе 1С, взаимодействующих с центральной базой данных через HTTP-сервисы — это современный стандарт автоматизации мобильных рабочих мест. На этапе локальной разработки и тестирования все работает отлично. Однако при переносе решения в продуктивную среду перед системными администраторами и разработчиками встает серьезный вызов: как открыть доступ к базе 1С из интернета так, чтобы не поставить под угрозу корпоративную безопасность?
В этой статье мы подробно разберем, почему стандартные методы «быстрой» публикации несут в себе критические угрозы, и пошагово спроектируем надежную, защищенную архитектуру для работы мобильных клиентов с вашей базой 1С через HTTP-сервисы.
Давайте проанализируем исходную ситуацию. Часто для тестов и даже для небольшой работы используется файловая база данных. Если вы планируете выставить HTTP-сервисы файловой базы напрямую в интернет через веб-сервер (Apache или IIS), вы совершаете критическую ошибку.
Выясним причину, почему это опасно. При публикации файловой базы веб-сервер должен иметь прямой физический доступ к файлу базы данных 1Cv8.1CD. В случае взлома самого веб-сервера, уязвимости в его коде или банальной ошибки в конфигурации (например, если останется активной функция листинга каталогов), злоумышленник сможет напрямую скачать файл вашей базы данных. Вся коммерческая информация моментально окажется у третьих лиц.
Кроме того, файловая база не предназначена для параллельной обработки множества веб-запросов. Вы столкнетесь с постоянными блокировками таблиц и зависаниями мобильных клиентов.
Решение: Переведите базу 1С в клиент-серверный режим под управлением СУБД (PostgreSQL, MS SQL, Oracle или IBM DB2). В такой архитектуре веб-сервер взаимодействует только с кластером серверов 1С, который, в свою очередь, обращается к СУБД. Сам физический файл базы данных находится в изолированном сегменте сети, полностью недоступном из интернета.
Классический подход, упомянутый в обсуждении — это проброс портов (Port Forwarding) на роутере с изменением стандартного порта 80/443 на случайный (например, 8443). Однако «безопасность через сокрытие» (security through obscurity) не защищает от современных сканеров портов, которые за секунды обнаружат открытый веб-сервер.
Рассмотрим альтернативные современные сценарии, которые позволяют вообще не открывать входящие порты на вашем роутере:
Tailscale или ZeroTier. Эти решения работают на базе протокола WireGuard. Сервер 1С и мобильные телефоны объединяются в одну виртуальную локальную сеть. База 1С физически отсутствует в публичном интернете, а доступ к HTTP-сервису имеют только устройства с установленным и авторизованным ключом VPN.Когда мы выполняем стандартную публикацию базы из Конфигуратора 1С, платформа генерирует файл настроек default.vrd. По умолчанию туда прописывается доступ ко всем возможным интерфейсам: веб-клиенту, тонкому клиенту и стандартному интерфейсу OData. Это существенно увеличивает поверхность потенциальной атаки.
Посмотрим на пример правильной настройки файла default.vrd. Если база должна обслуживать исключительно мобильные устройства по HTTP, мы обязаны вручную отключить все лишние программные интерфейсы. Отредактируем файл конфигурации следующим образом:
<?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="/hs_exchange"
ib="Srvr="1C-Server";Ref="TradeDB";">
<!-- Полностью отключаем веб-клиент и тонкий клиент -->
<ws enable="false" publishByDefault="false"/>
<!-- Отключаем стандартный интерфейс OData -->
<standardOdata enable="false"/>
<!-- Публикуем ТОЛЬКО конкретный HTTP-сервис -->
<httpServices publishByDefault="false">
<service name="МобильныйОбмен" alias="mobile" enable="true"/>
</httpServices>
</point>
При такой конфигурации злоумышленник, попытавшись открыть вашу ссылку в браузере, не увидит даже окна авторизации 1С. Система будет отвечать только по конкретному адресу вашего HTTP-сервиса, например: https://my-domain.com/hs_exchange/hs/mobile/v1/.
Ни в коем случае не выставляйте Apache или IIS напрямую «смотреть» в глобальную сеть. Настоятельно рекомендуется установить перед ними обратный прокси-сервер — Nginx. Он возьмет на себя роль защитного экрана.
Разберем по шагам преимущества использования Nginx в связке с веб-сервером 1С:
Стандартная базовая авторизация (Basic Auth), передающая имя пользователя и пароль в заголовке каждого запроса, допустима только при обязательном использовании HTTPS-шифрования. Но даже в этом случае безопасность внутри самой 1С требует жестких ограничений:
Специфика мобильного интернета заключается в его нестабильности. Рассмотрим типичную ситуацию: мобильное устройство отправляет в 1С запрос на создание нового документа «Заказ клиента». Сервер 1С успешно принял данные, создал и записал документ, но в момент отправки HTTP-ответа 200 OK связь оборвалась. Мобильный клиент не получил подтверждения и отправляет этот же пакет данных повторно.
Чтобы избежать дублирования документов в вашей базе данных, HTTP-сервисы 1С должны быть спроектированы как идемпотентные.
Проанализируем алгоритм решения этой проблемы. Мобильный клиент при формировании документа на своей стороне должен генерировать уникальный идентификатор транзакции (например, GUID) и передавать его в заголовке запроса (например, X-Transaction-ID). В 1С перед созданием нового объекта необходимо выполнить проверку:
// Пример обработки входящего запроса в HTTP-сервисе 1С
ИдентификаторТранзакции = Запрос.Заголовки.Получить("X-Transaction-ID");
Если ЗначениеЗаполнено(ИдентификаторТранзакции) Тогда
// Ищем, не создавали ли мы ранее документ с таким ключом
НайденныйДокумент = Документы.ЗаказПокупателя.НайтиПоРеквизиту("ИдентификаторТранзакции", ИдентификаторТранзакции);
Если Не НайденныйДокумент.Пустая() Тогда
// Документ уже существует, повторно создавать не нужно. Просто возвращаем успех.
Ответ = Новый HTTPСервисОтвет(200);
Ответ.УстановитьТелоИзСтроки("{""status"":""success"",""info"":""Документ уже был записан ранее""}");
Возврат Ответ;
КонецЕсли;
КонецЕсли;
// Если документ не найден — запускаем стандартную логику создания и записи документа
Применение такой проверки гарантирует консистентность данных в вашей информационной базе независимо от качества связи на мобильных устройствах сотрудников.
Резюмируя все вышесказанное: безопасная публикация базы 1С в интернет — это комплексная задача. Отказавшись от файлового режима, настроив защищенный туннель Cloudflare или обратный прокси Nginx, ограничив видимость в default.vrd и реализовав строгие контроли на уровне кода 1С, вы создадите надежную, быструю и неуязвимую систему для мобильной работы ваших сотрудников.