Веб-сервер для 1С: публикация базы, HTTPS и защита от лишнего доступа

Чтобы база открывалась в браузере или в тонком клиенте по http/https, нужен веб-сервер с модулем расширения веб-сервера 1С. Модуль идёт в составе платформы: для IIS это wsisapi.dll, для Apache — wsap24.dll (Windows) или wsap24.so (Linux). Базу публикуют из Конфигуратора или утилитой webinst, после чего на сервере появляется файл публикации default.vrd.

Дальше всё упирается в детали: какой сервер выбрать, под какой учёткой он работает, как подключить сертификат и что именно открыть наружу. Разберём по порядку, от выбора до защиты.

Какой веб-сервер выбрать: IIS, Apache или Nginx

Официально платформа поддерживает IIS и Apache 2.4. Nginx сам модуль 1С не загружает, поэтому его ставят только впереди Apache как обратный прокси.

Практический ориентир: если рядом уже стоит сервер 1С на Windows Server, берите IIS. На Linux ставьте Apache. Nginx добавляйте, когда у вас уже есть опыт его эксплуатации и нужна именно его роль на периметре.

Подготовка сервера перед установкой

До публикации проверьте четыре вещи.

1. Версию ОС. Для платформы 8.3 с интерфейсом «Такси» берите Windows Server 2016 и новее либо актуальный дистрибутив Linux (Ubuntu, Debian, RHEL-совместимые).
2. Разрядность. Определите, какой платформой будете пользоваться: 64-разрядной или 32-разрядной. Модуль расширения веб-сервера берётся из каталога bin той же платформы, и разрядность веб-сервера или пула приложений IIS обязана с ним совпасть.
3. Тип базы. Для публикации в интернет используйте клиент-серверную базу . Файловую можно опубликовать, но веб-сервер будет открывать файл базы сам, и с несколькими пользователями это быстро становится узким местом.
4. Компоненты платформы. При установке платформы должны быть выбраны «Модули расширения веб-серверов». Если их не отметили, запустите установщик в режиме изменения и добавьте.

Для IIS в «Добавлении ролей и компонентов» отметьте в разделе «Разработка приложений» пункты «Расширения ISAPI» и «Фильтры ISAPI». Для проверки подлинности Windows добавьте одноимённый компонент в разделе «Безопасность».

Публикация базы на веб-сервере

Самый короткий путь — Конфигуратор. Запустите его от имени администратора, затем откройте Администрирование → Публикация на веб-сервере.

1. Укажите имя публикации. Оно станет частью адреса: http://сервер/имя.
2. Выберите веб-сервер из списка — IIS или Apache найдутся, если установлены.
3. Проверьте каталог на диске: туда лягут default.vrd и служебные файлы.
4. Отметьте, что публиковать: тонкий клиент, веб-клиент, стандартный интерфейс OData, веб-сервисы и HTTP-сервисы. Берите только то, что нужно.
5. Нажмите «Опубликовать».

То же самое делает консольная утилита. Она нужна, когда публикуете на сервере без графической оболочки или хотите повторяемости:

webinst -publish -iis -wsdir base -dir C:\inetpub\wwwroot\base ^
  -connstr "Srvr=app01;Ref=base;"

Для Apache на Linux вместо -iis указывают -apache24 и путь к конфигурации:

webinst -publish -apache24 -wsdir base -dir /var/www/base \
  -connstr "Srvr=app01;Ref=base;" -confpath /etc/apache2/apache2.conf

Проверьте набор параметров своей версии через webinst -help — состав ключей от релиза к релизу меняется.

Что настроить вручную после публикации

Для IIS:

• Пул приложений: «Включить 32-разрядные приложения» ставьте в True только если используете 32-разрядную платформу; для 64-разрядной — False.
• Права: у группы IIS_IUSRS (или у учётной записи пула) должны быть права на чтение и запись в каталог публикации и на чтение каталога bin платформы.
• Запуск ISAPI-модулей должен быть разрешён для каталога публикации: проверьте в «Сопоставлениях обработчиков» и в «Ограничениях ISAPI и CGI», что wsisapi.dll включён, иначе вместо базы вернётся ошибка 404 или 500.

Для Apache:

• В конфигурацию добавляется LoadModule _1cws_module "…/wsap24.dll". Проверьте, что путь указывает на bin текущей установленной платформы.
• Для каждой публикации в конфиге появляется блок Alias и <Directory>. Лишние блоки старых баз удаляйте только после проверки: Apache не стартует при синтаксической ошибке.

После изменения конфигурации Apache перезапустите. Это оборвёт текущие соединения, поэтому делайте в нерабочее время.

Подключение SSL-сертификата

Без https пароли и данные идут открытым текстом, а ряд функций браузерного клиента и интеграций работает только по защищённому соединению. Для рабочей базы открывайте наружу только 443.

IIS

1. Импортируйте сертификат в хранилище компьютера: certlm.msc → «Личное» → «Сертификаты» → импорт файла .pfx.
2. В диспетчере IIS откройте сайт → «Привязки» → «Добавить», тип https, порт 443, выберите сертификат.
3. Если сайт отвечает по http на 80, настройте редирект на https. Сделать это можно модулем «Перезапись URL».

Apache

Нужен модуль mod_ssl. В виртуальном хосте укажите три директивы:

SSLEngine on
SSLCertificateFile    /etc/ssl/certs/1c.example.ru.crt
SSLCertificateKeyFile /etc/ssl/private/1c.example.ru.key

Если сертификат выдан промежуточным центром, добавьте цепочку (SSLCertificateChainFile или объедините цепочку в основной файл — зависит от версии Apache). Бесплатный сертификат Let’s Encrypt получают утилитой certbot; она сама правит конфиг и ставит автопродление.

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

Производительность веб-сервера

Типичная жалоба: «через браузер всё медленно». В большинстве случаев причина не в самом веб-сервере, но настройки на его стороне действительно влияют.

• Сжатие. Включите сжатие ответов (динамическое для IIS, mod_deflate для Apache). Для веб-клиента это заметно уменьшает объём передаваемых данных.
• Keep-Alive. Не отключайте. Постоянное соединение избавляет от повторных рукопожатий, особенно по https.
• Пул приложений IIS. Включённый по умолчанию периодический перезапуск пула (раз в 1740 минут) выбрасывает сеансы в случайное время. Привяжите перезапуск к ночному окну или отключите регулярный и следите за потреблением памяти.
• Время простоя. Пул, который «засыпает» после 20 минут бездействия, первому утреннему пользователю отвечает долго. Поставьте «Время простоя» в 0 или задайте режим запуска AlwaysRunning.
• Лимиты запросов. Если пользователи загружают большие файлы через веб-клиент, поднимите maxAllowedContentLength (IIS) или LimitRequestBody (Apache), иначе загрузка будет обрываться ошибкой.
• Место для сервера. Веб-сервер и сервер 1С держите в одной сети с минимальной задержкой. Публикация через канал в другой город вернёт ту же медлительность.

Отдельно про Apache: на Windows он работает в режиме mpm_winnt и обслуживает запросы потоками одного процесса. Для сотни одновременных веб-клиентов этого хватает, но при росте нагрузки проверяйте использование памяти процессом httpd.

Безопасность веб-доступа к базе

Веб-сервер с 1С часто оказывается единственной службой, видимой из интернета. Закройте остальное.

• 🔒 Порты. Наружу только 443 (и 80 для редиректа). Порты кластера 1С — 1540, 1541 и диапазон рабочих процессов — должны быть доступны только веб-серверу и администраторам.
• 🔒 Минимум публикаций. Не публикуйте тонкий клиент, OData и веб-сервисы «на всякий случай». Каждый вид доступа — отдельная поверхность атаки. Лишнее убирается правкой default.vrd или переопубликованием.
• 🔒 Отдельные публикации. HTTP-сервисы для обменов с внешними системами публикуйте отдельно от пользовательского входа, с ограничением по IP.
• 🔒 Аутентификация. Для доступа из интернета используйте аутентификацию 1С с надёжными паролями или федерацию. Проверку подлинности Windows оставляйте для внутренней сети.
• 🔒 Права файлов. Учётная запись веб-сервера не должна иметь доступа на запись куда-либо кроме каталога публикации.
• 🔒 Обновления. Следите за обновлениями веб-сервера и OpenSSL. Платформа 1С не заменяет их.

Если база должна быть видна из интернета, но пользователи работают из разных мест, имеет смысл поставить перед ней VPN или шлюз с двухфакторной проверкой. Веб-сервер 1С такой функции не даёт.

Типичные ошибки и их диагностика

Проверку начинайте с кода ответа сервера. По нему сразу видно, на чьей стороне проблема.

Если ничего не помогло, увеличьте детализацию журналов: на IIS включите трассировку неудачных запросов, на Apache поднимите LogLevel до debug на время проверки и верните обратно.

Автоматизация развёртывания

Когда публикаций больше пяти или серверов больше одного, ручная настройка перестаёт работать: конфиги расходятся, а восстановление после сбоя превращается в поиск по памяти.

Что вынести в код:

• Сам веб-сервер. Установка IIS с нужными компонентами или Apache с модулями делается скриптом PowerShell, шаблоном Ansible или образом Docker.
• Публикацию. Команда webinst запускается из скрипта с параметрами из переменных. Один и тот же сценарий ставит новую базу и переопубликует после обновления платформы.
• Конфигурацию. default.vrd, виртуальные хосты и параметры SSL храните в системе контроля версий как шаблоны, а секреты — отдельно.

Для Docker есть нюанс: в образ с Apache нужно положить модуль расширения веб-сервера нужной версии платформы и клиентские библиотеки, от которых он зависит. Лицензионные условия на дистрибутив платформы контейнеры не меняют, поэтому образ с платформой держите в закрытом реестре.

Минимальный набор, который стоит включить в сценарий развёртывания:

Частые вопросы