Коротко — при ограничениях «боевой сервер 1С не доступен из интернета» и «интернет‑сервер не должен быть в LAN» обычно делают одно из двух безопасных архитектурных решений: 1) односторонняя отправка данных с внутренней сети наружу (push из LAN → DMZ/облако), либо 2) экспорт дампов/файлов из 1С и их импорт в изолированную зону. Прямых «вытягиваний» с интернет‑сервера в боевой 1С стараются не делать.
Ниже — конкретные варианты, плюсы/минусы и рекомендации.
Варианты обмена
1) Периодический экспорт файлов (XML/JSON/CommerceML) и выгрузка на SFTP/облако
- Что: в 1С (внутри LAN) периодически формируется файл (CommerceML, JSON), затем агент/скрипт отправляет его по SFTP, HTTPS POST или загружает в облачное хранилище (S3/Azure Blob) в DMZ/облаке.
- Плюсы: простая реализация, нет входящих соединений в LAN, легко отлаживать, можно версионировать/логировать.
- Минусы: данные не realtime (интервал зависит от расписания), большие файлы — накладные операции при больших каталогах.
2) Инкрементальная выгрузка (делты) + push событий
- Что: агент в LAN отслеживает изменения (остатки, цены, новые карточки) и сразу отправляет только дельты на внешний endpoint (HTTPS API, очередь).
- Плюсы: ближе к онлайн, меньший трафик, проще держать актуальность.
- Минусы: требуется поддержка отслеживания изменений в 1С (триггеры/обработки), надежность доставки/повторы.
3) Репликация/загрузка в read‑only базу в DMZ (через файлы/бэкапы)
- Что: средствами СУБД или через регулярные restore/import на отдельный сервер в DMZ загружается копия справочников/остатков. Передача данных осуществляется из LAN (push) — дампы или логические выгрузки.
- Плюсы: на DMZ есть полноценная БД для сайта, быстрый доступ, можно делать SQL‑запросы.
- Минусы: сложнее в настройке, потенциальные вопросы с целостностью и персональными данными.
4) Внешний API/очередь (облако) + агент, инициирующий исходящие соединения
- Что: агент в LAN отправляет через HTTPS/AMQP в облачный сервис/очередь, где стоит обработчик, обновляющий сайт.
- Плюсы: масштабируемость, надёжность, можно использовать managed services (SQS, RabbitMQ, Kafka).
- Минусы: нужно продумать idempotency, мониторинг, очередь хранения.
5) Нативные средства 1С (CommerceML, веб‑сервисы)
- Что: 1С умеет выгружать в CommerceML и публиковать веб‑сервисы. Но публикация веб‑сервисов потребует доступности 1С из внешней сети — что у вас запрещено. Поэтому чаще используют обработку/выгрузку CommerceML + push.
- Плюсы: стандартные механизмы интеграции 1С, меньше ручного кодинга.
- Минусы: версия УТ 10.3 старая — возможна доработка/совместимость.
Рекомендованная архитектура (без входящих соединений в LAN)
- На стороне LAN:
- Лёгкий экспорт‑агент (в 1С: внешняя обработка или плановое задание), который формирует:
- Полный dump каталога периодически (например раз в сутки)
- Инкременты/делты по изменённым товарным позициям и остаткам (каждые N минут или при изменении)
- Агент шифрует/подписывает выгрузки и по исходящему HTTPS/SFTP отправляет их в DMZ/облако. Соединения только исходящие.
- На стороне DMZ/облако:
- Приёмный сервис/API/очередь (HTTPS endpoint, SFTP, облачное хранилище).
- Импортер, который валидирует, десериализует и обновляет локальную read‑only БД/кэш сайта.
- CDN/файловое хранилище для изображений (агент также может загружать изображения в CDN и отдавать URL).
- На сайте:
- Чтение только из локальной БД/кэша/индекса в DMZ, а не напрямую из 1С.
- Логика кэширования, TTL, fallback при ошибках импорта.
Безопасность — обязательные меры
- Запрещать входящие соединения в сеть LAN — все соединения инициируются изнутри наружу.
- TLS для всего трафика, предпочтительно с клиентскими сертификатами (mutual TLS) или с сильной аутентификацией (API key + IP whitelist).
- Подпись/хэш и контроль целостности выгрузок (например HMAC), чтобы избежать подмены данных.
- Минимизировать экспортируемые поля — только то, что нужно для сайта (анонизировать персональные/внутренние данные).
- Ограничить объем доступного извне — только каталог/остатки/цены и публичные атрибуты.
- Логи, мониторинг, ретрай/очереди для надежной доставки.
- Версионирование и атомарность импортов (начала/конца выгрузки) для избежания неконсистентности.
- Регулярные проверки и тесты на соответствие GDPR/локальным требованиям по данным (если применимо).
Практические рекомендации
- Если нужна «почти онлайн» актуальность (например, остатки в пределах нескольких минут) — реализуйте инкрементальные сообщения (push) из 1С и приём через очередь/HTTPS в DMZ.
- Если достаточно «раз в N часов» — делайте ежедневный/часовой экспорт CommerceML/JSON.
- Для больших каталогов комбинируйте: полный дамп раз в сутки + ежедневные/почасовые дельты.
- Для картинок: выгружайте их сразу в CDN/облако (S3) и в каталоге храните только ссылки.
- Тестируйте сценарии восстановления: что будет при частичной потере выгрузки, как откатиться.
Чего не стоит делать
- Открывать боевой 1С прямо в интернет.
- Давать DMZ‑серверу прямой доступ в LAN без строгой сегментации и контроля.
- Использовать привычные «pull» интеграции с интернет‑сервера в LAN (они требуют входящих соединений и нарушают ваши ограничения).
Если хотите, могу:
- Предложить пример формата JSON/CommerceML, который удобно импортировать на сайт (поля, структуры, дельты).
- Описать шаги реализации обработок в 1С (внешняя обработка/плановые задания) под вашу версию УТ 10.3.
- Нарисовать конкретный сценарий импорта на стороне DMZ (SFTP→импортер→БД→CDN).
Напишите, какой вариант вы рассматриваете (частота обновлений, объём каталога, необходимость остатков/цен в реальном времени) — подскажу конкретнее.