Публикация 1С на веб-сервере: IIS, Apache и HTTPS

Как браузер попадает в базу 1С

• Браузер: загружает веб-клиент, отправляет действия пользователя. СУБД ему недоступна.
• IIS или Apache: принимает HTTP-запрос; модуль расширения платформы связывает его с 1С.
• Кластер 1С: выполняет прикладную логику, управляет сеансами и обращается к СУБД.
• СУБД: хранит данные; интернет-доступ к её порту для веб-клиента не требуется.

HTTPS шифрует конкретное соединение. Если TLS завершается на прокси, участок до backend надо защищать отдельно: loopback на одном узле либо закрытый сегмент и при необходимости TLS с проверкой сертификата.

Что выбираем: браузер, тонкий клиент или API

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

Веб-доступ не отменяет лицензирование. Нужны права использования конфигурации и платформы; клиент-серверный вариант требует соответствующей серверной лицензии. Подсчёт клиентских лицензий проверяют по фактической схеме выдачи. Само появление HTTPS не даёт основания переходить на КОРП или считать подключения бесплатными.

До начала: паспорт публикации и границы доступа

1. Зафиксируйте полную сборку платформы сервера, веб-модуля и утилиты публикации; проверьте поддерживаемые ОС, Apache/IIS и архитектуру.
2. Выберите техническое имя базы в кластере, адрес сервера 1С, URL и отдельный каталог публикации. Имя каталога БД и Ref — разные сущности.
3. Согласуйте пользователей, способы аутентификации и список нужных API. Для персонала предпочтителен управляемый доступ через VPN или другую согласованную схему.
4. Определите место завершения TLS, сертификат, ответственного за продление и проверки извне.
5. Подготовьте резервные копии базы и веб-конфигурации, окно работ и порядок возврата.

Домен 1c.example.net, сервер app01.example.net и база Accounting ниже условные. Публикация не требует прямого открытия портов кластера или СУБД в интернет. Между веб-узлом и кластером разрешают только фактические служебные соединения вашей топологии; доступность одного порта не доказывает доступность всех рабочих процессов.

Шаг 1. Найдите правильную платформу и модуль

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

В Windows PowerShell сначала найдите установленные утилиты:

Get-ChildItem 'C:\Program Files\1cv8' -Filter webinst.exe -Recurse |
  Select-Object FullName
$platformVersion = '8.3.XX.YYYY' # замените полной установленной версией
$webinst = "C:\Program Files\1cv8\$platformVersion\bin\webinst.exe"
if (-not (Test-Path -LiteralPath $webinst)) { throw 'Уточните путь и версию платформы' }
(Get-Item -LiteralPath $webinst).VersionInfo | Select-Object FileVersion,ProductVersion

На Linux проверьте ОС, пакеты и расположение утилиты:

cat /etc/os-release
uname -m
dpkg-query -W '*1c*' 2>/dev/null
find /opt/1cv8 -type f -name webinst -print

Путь может отличаться по поставке. Разрядность модуля обязана соответствовать процессу веб-сервера; для этого материала все компоненты x64. Разрядность конфигурации как набора прикладных объектов — другое понятие. При ошибке загрузки модуля проверьте зависимости, сборку и архитектуру, а не раздавайте административные права.

Шаг 2. Сохраните конфигурацию до публикации

На IIS выполните от имени администратора:

$stamp = Get-Date -Format 'yyyyMMdd-HHmmss'
& "$env:windir\system32\inetsrv\appcmd.exe" add backup "Before1CPublish-$stamp"
if ($LASTEXITCODE -ne 0) { throw 'Не удалось сохранить конфигурацию IIS' }

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

Для существующего Apache перед изменениями сохраните конфигурацию:

stamp=$(date +%Y%m%d-%H%M%S)
sudo cp -a /etc/apache2 "/root/apache2-before-1c-$stamp"
sudo apache2ctl -t
sudo apache2ctl -S

Для новой установки Linux сначала установите Apache из следующего шага. Каталог существующей публикации, её default.vrd и права также сохраняют отдельно. Не запускайте webinst поверх неизвестного рабочего сайта: утилита меняет конфигурацию сервера.

Маршрут A. Подготовьте IIS на Windows Server

На новом согласованном веб-узле в PowerShell администратора:

Get-WindowsFeature Web-Server,Web-ISAPI-Ext,Web-ISAPI-Filter,Web-Mgmt-Console
Install-WindowsFeature Web-Server,Web-ISAPI-Ext,Web-ISAPI-Filter,Web-Mgmt-Console,Web-Http-Logging
Import-Module WebAdministration
Get-Website | Select-Object Name,State,PhysicalPath,Bindings
Get-WebAppPoolState -Name DefaultAppPool

Проверьте Success и необходимость перезагрузки в выводе установки. Роль, сайт и пул — разные уровни. Перед первой публикацией ограничьте сетевой доступ до завершения настройки; наличие default page не означает готовность 1С.

• В IIS Manager проверьте ISAPI and CGI Restrictions и разрешение именно нужного модуля платформы там, где оно требуется режимом обработки.
• В приложении проверьте Handler Mappings: запросы должны обрабатываться модулем выбранной версии.
• Не разрешайте запуск всех неизвестных ISAPI/CGI ради устранения одной ошибки. Модель ограничений объясняет Microsoft.

Шаг 3. Подготовьте параметры публикации в Конфигураторе

Откройте нужную базу Конфигуратором соответствующей версии: Администрирование → Публикация на веб-сервере. Сначала сверьте, какую базу вы открыли. Публикация тестовой копии под production-адресом — полноценная ошибка доступа.

1. Имя: accounting, без пробелов и кириллицы; каталог — отдельный путь публикации.
2. Выберите IIS или Apache 2.4 согласно маршруту, включите доступ клиентских приложений.
3. Если интеграций нет, не публикуйте стандартный OData и сервисы по умолчанию. Проверьте HTTP/SOAP-сервисы и сервисы расширений на соответствующих вкладках.
4. Для нужных интеграций согласуйте точечный список и отдельные учётные записи с минимальными правами.
5. Сохраните настройки в отдельный файл-шаблон publication-template.vrd. Его точный состав определяется версией платформы.

Имена вкладок и набор флагов зависят от сборки. Перед применением проверьте сохранённый XML: нет ли неожиданного включения сервисов по умолчанию или чужой строки подключения. Не редактируйте атрибуты по памяти. Официальное описание окна и webinst помогает сопоставить параметры. При повторной публикации шаблон может заменить действующий default.vrd: индивидуальные настройки надо перенести осознанно.

Маршрут A. Опубликуйте клиент-серверную базу

Создайте новый каталог. Укажите ранее проверенный путь $webinst и подготовленный шаблон. Не используйте корень C:\inetpub\wwwroot как каталог публикации.

New-Item -ItemType Directory -Path 'C:\inetpub\1c\accounting' -ErrorAction Stop
$descriptor = 'C:\1c-publish\publication-template.vrd'
if (-not (Test-Path -LiteralPath $descriptor)) { throw 'Нет проверенного шаблона публикации' }
& $webinst -publish -iis -wsdir accounting `
  -dir 'C:\inetpub\1c\accounting' `
  -connstr 'Srvr=app01.example.net;Ref=Accounting;' `
  -descriptor $descriptor
if ($LASTEXITCODE -ne 0) { throw 'Публикация завершилась с ошибкой' }

Проверьте фактический сайт и пул. Штатная публикация IIS ориентируется на Default Web Site / DefaultAppPool. Не рассчитывайте, что произвольный сайт будет выбран автоматически. Перенос на другой сайт выполняют отдельно с проверкой handler, каталога, привязок и прав.

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

New-WebAppPool -Name '1CWeb'
Set-ItemProperty 'IIS:\AppPools\1CWeb' -Name managedRuntimeVersion -Value ''
Set-ItemProperty 'IIS:\AppPools\1CWeb' -Name enable32BitAppOnWin64 -Value $false
Set-ItemProperty 'IIS:\Sites\Default Web Site\accounting' -Name applicationPool -Value '1CWeb'
icacls 'C:\inetpub\1c\accounting' /grant 'IIS AppPool\1CWeb:(OI)(CI)(RX)'
Get-WebApplication -Site 'Default Web Site' | Select-Object Path,ApplicationPool,PhysicalPath

Пул 1CWeb не должен обслуживать посторонние приложения. Проверьте его фактическую identity и субъект Anonymous Authentication: им может быть IUSR либо identity пула. Приведённое разрешение дано только identity пула; при другом субъекте требуется отдельная точечная настройка. Сведения об идентификаторах пулов есть у Microsoft. Каталог публикации требует чтения и выполнения; запись для служебных временных файлов предоставляют отдельно по реальной необходимости. Не делайте пул локальным администратором.

Маршрут B. Подготовьте Apache 2.4 на Ubuntu

Этот маршрут альтернативен IIS. На новой системе установите Apache из репозитория ОС; компонент веб-расширения 1С установите из дистрибутива нужной платформы.

sudo apt update
sudo apt install apache2
apache2 -v
sudo apache2ctl -V
sudo apache2ctl -M
sudo apache2ctl -S

Проверьте версию, загружаемые модули и выбранные VirtualHost. Если впереди будет Nginx на том же узле, заранее измените listener Apache на свободный локальный порт, например 127.0.0.1:8080, и согласуйте VirtualHost с этим адресом. Уберите конфликтующие Listen 80/443 только у целевого сервиса, не нарушая посторонние сайты. Конфигурацию сначала сохраните.

Нельзя просто добавить второй Listen к уже занятому порту. Не смешивайте инструкции Debian/Ubuntu с путями httpd из RHEL/Astra/другой сборки. На ОС с SELinux/AppArmor проверяйте точный запрет в журнале и штатную политику; отключение защиты целиком не является настройкой публикации.

Маршрут B. Выполните webinst и проверьте модуль

В той же версии платформы задайте фактический путь, проверьте шаблон и новый каталог. В этом примере предполагается стандартный конфигурационный файл Ubuntu.

one_c_dir='/opt/1cv8/x86_64/8.3.XX.YYYY' # замените фактическим путём
test -x "$one_c_dir/webinst" || exit 1
test -f /root/1c-publish/publication-template.vrd || exit 1
sudo install -d -m 0750 -o root -g www-data /var/www/1c/accounting
sudo "$one_c_dir/webinst" -publish -apache24 \
  -wsdir accounting -dir /var/www/1c/accounting \
  -connstr 'Srvr=app01.example.net;Ref=Accounting;' \
  -confpath /etc/apache2/apache2.conf \
  -descriptor /root/1c-publish/publication-template.vrd

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

sudo grep -R -n -E 'LoadModule|SetHandler|ManagedApplicationDescriptor|accounting' /etc/apache2
sudo apache2ctl -t
sudo apache2ctl -M
sudo apache2ctl -S
sudo namei -l /var/www/1c/accounting/default.vrd

Ожидается Syntax OK, загрузка модуля именно выбранной платформы, доступный default.vrd и соответствие URL физическому каталогу. Не добавляйте второй LoadModule при уже существующем модуле: публикации могут зависеть от одного и того же расширения. Для чтения default.vrd веб-пользователю нужен проход по родительским каталогам и чтение файла. Не открывайте каталог базы в DocumentRoot.

При первой загрузке или смене бинарного модуля запланируйте перезапуск Apache с учётом всех публикаций на нём. После успешной проверки конфигурации, в согласованное окно: sudo systemctl restart apache2. Затем проверьте службу и журнал. Для обычных изменений допустимость graceful/reload определяют по типу изменения; режимы управления Apache различаются.

Шаг 4. Проверьте backend до настройки внешнего адреса

Сначала локальный запрос на веб-узле, затем вход тестовой учётной записью через защищённый административный доступ. Для выбранного локального порта Apache:

curl -sS -o /dev/null -w 'HTTP=%{http_code}\n' \
  http://127.0.0.1:8080/accounting/
sudo journalctl -u apache2 --since '-10 min' --no-pager
sudo tail -n 50 /var/log/apache2/error.log

На IIS используйте фактическую привязку сайта; при привязке по имени передайте соответствующий Host, а не проверяйте случайный default site по IP. Подключение к БД, ошибка лицензии и отказ аутентификации — разные причины. Код 200 или страница входа не подтверждают выполнение прикладной операции.

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

Шаг 5. Настройте HTTPS: напрямую или через прокси

Вариант 1: TLS на IIS. В IIS Manager установите сертификат с приватным ключом в подходящее хранилище компьютера, откройте целевой сайт → Bindings → Add → https. Выберите 443, имя 1c.example.net и нужный сертификат; при нескольких сайтах на одном IP согласуйте SNI. Проверьте DNS, SAN, срок и полную цепочку доверия. Это привязка сайта, она может затронуть все приложения этого сайта. Настройка TLS и параметры bindings описаны Microsoft.

Вариант 2: TLS на Apache. Настройте отдельный VirtualHost 443 с именем сайта, сертификатом, ключом и публикацией. Штатные SSL-параметры и политику TLS сверяйте с установленной версией. Руководство Apache показывает базовые элементы. Нельзя перенести Alias в HTTP-vhost и считать, что он автоматически сработал в другом HTTPS-vhost.

Вариант 3: Nginx перед Apache. Ниже отдельный server-блок для случая, когда оба сервиса находятся на одном узле и Apache уже проверен на 127.0.0.1:8080. Сертификат и ключ должны существовать; пути условные. Это пример для адаптации, не готовый nginx.conf всего сервера.

server {
    listen 443 ssl;
    server_name 1c.example.net;
    ssl_certificate     /etc/ssl/1c/fullchain.pem;
    ssl_certificate_key /etc/ssl/1c/privkey.pem;
    ssl_protocols TLSv1.2 TLSv1.3;

    location /accounting/ {
        proxy_pass http://127.0.0.1:8080;
        proxy_set_header Host $host;
        proxy_set_header X-Forwarded-Proto $scheme;
        proxy_set_header X-Forwarded-For $remote_addr;
        proxy_read_timeout 120s;
    }
    location / { return 404; }
}

В proxy_pass намеренно нет URI после порта: путь /accounting/ передаётся backend без замены. Значение 120s — пример интервала ожидания между чтениями ответа upstream, не обещание завершения отчёта за две минуты. Подберите его по замерам; бесконечный timeout скрывает зависания. X-Forwarded-For здесь перезаписывается адресом клиента для единственного доверенного прокси. При цепочке балансировщиков нужна отдельная модель доверия.

HTTPS к клиенту не означает HTTPS к backend на другом сервере. Для удалённого upstream примените согласованное защищённое соединение, проверку имени и CA; не отключайте проверку сертификата. Документация proxy-модуля и HTTPS Nginx объясняет параметры.

Шаг 6. Проверьте сертификат, маршрут и продление

sudo nginx -t
# Только если проверка успешна:
sudo systemctl reload nginx
curl --resolve 1c.example.net:443:192.0.2.10 \
  -sS -o /dev/null -w 'HTTP=%{http_code}\n' \
  https://1c.example.net/accounting/

Адрес 192.0.2.10 замените адресом своей точки HTTPS. --resolve позволяет проверить нужный узел с правильным именем и SNI до изменения DNS. Не добавляйте -k: тогда вы перестанете проверять доверие сертификату. Для корпоративного CA установите доверенную цепочку штатным способом.

1. Из разрешённой сети откройте адрес в поддерживаемом браузере без предупреждений.
2. Проверьте конечный URL, переходы, вход, выход и отсутствие запросов к незашифрованным ресурсам.
3. Отдельно проверьте недоступность backend извне и отсутствие лишних опубликованных API.
4. Зафиксируйте способ продления, перезагрузку нужного сервиса после замены сертификата и наблюдение за сроком действия.

Если адрес переходит с HTTP на HTTPS, не полагайтесь на редирект как на защиту первого запроса с секретами. Пользователям выдавайте сразу HTTPS-адрес. HSTS вводят после проверки схемы и всех затрагиваемых имён, а не включают вслепую для всего домена.

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

• Персональный вход: уникальные пароли генерируются в менеджере паролей; общая учётная запись бухгалтера мешает разбору событий.
• Разные уровни: Anonymous Authentication на IIS может позволять доступ до модуля, после которого действует аутентификация самой 1С. Это не означает автоматический вход в базу. Схему проверьте именно на своём приложении.
• Без секретов в публикации: не вшивайте привилегированный Usr/Pwd в строку подключения ради автоматического входа; не передавайте пароли через URL или команды, попадающие в историю.
• Сервисы по списку: веб-клиент, /hs/, /ws/ и OData требуют отдельных проверок. Удаление ссылки из интерфейса не закрывает endpoint.
• Подрядчики: персональный ограниченный доступ, срок, журналирование и отзыв после работ. Удалённый доступ без контроля повышает риск.
• Прокси и MFA: дополнительная аутентификация требует проверки совместимости тонкого клиента и интеграций; защита формы браузера не гарантирует защиту всех путей.

WAF, ограничение попыток и VPN выбирают по модели угроз. Они не заменяют обновление платформы, права внутри базы, резервные копии и контроль внешних обработок.

Если база файловая: права и расположение другие

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

• Храните 1CD вне веб-корня и любых доступных по HTTP каталогов. Не делайте резервные выгрузки скачиваемыми по URL.
• Определите реального пользователя процесса и анонимного доступа; выдайте ему необходимый доступ только к нужной базе.
• Не выдавайте Everyone Full Control и не меняйте владельца всего диска ради запуска.
• Проверьте фоновые задания, конкурентные обращения и ограничения выбранного режима. Для нагруженной совместной работы оцените клиент-серверный вариант.

Согласованную копию файловой базы получают с учётом работающих сеансов. Копирование открытого 1CD без контроля согласованности не становится надёжным бэкапом лишь потому, что рядом есть веб-сервер.

Если не открывается: короткий маршрут диагностики

Для IIS сохраняйте HTTP-статус, substatus и Win32-status. Для Apache — access/error log нужного vhost. На прокси полезны upstream_status и время ответа upstream. Укажите единый часовой пояс и синхронизацию времени. Журнал регистрации и технологический журнал 1С отвечают на другие вопросы, чем access log; сопоставляйте их по времени и сеансу.

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

Приёмка: проверяем больше, чем страницу входа

1. Адрес: из разрешённой сети открывается нужная база по HTTPS; сертификат доверен.
2. Роли: пользователь видит свой объём данных; интеграционная учётная запись не получила лишних прав.
3. Операции: выбранные отчёты, формы, вложения, печать и подпись проходят проверку с фактического рабочего места.
4. Сеансы: вход/выход, повторный вход и разрыв связи не оставляют необъяснимого расхода лицензий или зависших операций.
5. Нагрузка: измерено время репрезентативных операций при согласованном числе пользователей. Один запрос curl не является нагрузочным тестом.
6. Защита: ненужные API закрыты, backend не обходится внешним прямым адресом, база и копии не скачиваются как файлы.
7. Эксплуатация: копия проверена, продление сертификата назначено, ответственный и возврат записаны.

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

Обновление платформы и возврат без сюрпризов

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

• Сначала репетиция на изолированной копии с отключёнными production-обменами и фоновыми заданиями.
• Сохраните конфигурацию, default.vrd, ACL, версии и соответствующую резервную копию БД.
• Определите общее окно: перезапуск Apache или общего пула может затронуть соседние публикации.
• После обновления повторите функциональную приёмку, проверку API и TLS.
• При возврате восстановите согласованный комплект платформы, обработчика и настроек. Совместимость изменённой базы с прежней платформой проверяйте отдельно.

Не откатывайте весь сервер IIS из общей копии ради одной публикации без оценки последующих изменений других сайтов. Не удаляйте действующую базу и не подменяйте её тестовой, пытаясь исправить ошибку модуля.

Два файла для внедрения и передачи в поддержку

Публикация 1С и дальнейшее сопровождение

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