Как открыть веб-клиент 1С и не оставить лишний доступ

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

Что именно делает веб-сервер при публикации 1С

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

Для публикации нужны совместимые компоненты веб-расширения платформы и выбранного веб-сервера. В Linux для Apache подключают расширение 1С; mod_php к этому механизму не относится. Это другая технология, и установка PHP-модуля не публикует базу 1С. В Windows используют IIS и компоненты, необходимые конкретной конфигурации обработчиков. Если расширение не зарегистрировано, не той разрядности или относится к другой версии платформы, публикация может не открыться. Сначала сверяю состав компонентов и версию, а уже потом ищу проблему в правах или маршрутизации.

Опубликуйте только нужные компоненты

Штатная точка старта в Конфигураторе — «Администрирование → Публикация на веб-сервере». В мастере выбирают веб-сервер, имя и каталог публикации, а затем отмечают нужные возможности: веб-клиент, HTTP-сервисы, веб-сервисы и, если это требуется, OData. Перечень зависит от задачи и конфигурации. Не отмечайте всё «на всякий случай»: каждый опубликованный интерфейс становится дополнительным способом обратиться к базе, который придётся учитывать при проверке прав и сетевых правил. Публикацию можно изменить позже, но решение о составе лучше принять до выдачи адреса пользователям и интеграциям.

Файл default.vrd описывает параметры публикации. Само наличие файла не доказывает, что опубликован только веб-клиент: проверьте выбранные компоненты и итоговое поведение по каждому адресу. Учитывайте и режим базы. Для клиент-серверной базы веб-расширение взаимодействует с кластером 1С; файловый вариант имеет отдельный каталог данных и требования к доступу процесса к нему. Документация 1С отдельно указывает права к каталогу файла базы для файлового варианта. Значит, безоговорочное «веб-серверу нужно только чтение» может сломать файловую базу. Права определяют по используемому варианту и конкретным путям, а не по универсальному совету из статьи в интернете.

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

Права файлов и разрядность IIS

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

У IIS настройка пула Enable 32-Bit Applications отвечает за запуск 32-разрядных процессов на 64-разрядной Windows. Её значение зависит от архитектуры установленного веб-расширения 1С и выбранного обработчика. Не следует механически включать 32-разрядный режим для любой публикации или утверждать, что разрядность «всегда обязана совпадать» без проверки компонентов. Если расширение x86, а пул запускает только x64-процесс, это вероятная причина ошибки загрузки; если компоненты x64, включение 32-битного режима само по себе ничего не исправит. Сверьте архитектуру платформы, расширения и настройки пула по фактической конфигурации.

Для Apache действует тот же принцип минимальных прав, но имена системных пользователей и групп зависят от дистрибутива и способа запуска службы. Не назначайте владельцем root и не добавляйте запись для условной группы www-data по шаблону: это не универсальная настройка. Проверьте эффективного пользователя процесса Apache, владельца каталога публикации и права на файл базы, если база файловая. После изменения прав повторите вход и операцию, которая должна сохранять данные. Иначе легко получить либо неработающую публикацию, либо широкую запись там, где она не нужна.

Включите HTTPS и проверьте сертификат

Если пользователи подключаются через сеть, в которой вы не контролируете каждый узел, передавайте учётные данные и рабочие данные по HTTPS. Для этого веб-серверу нужен действующий сертификат, правильно привязанный к имени публикации, и настроенная цепочка доверия. TLS защищает канал между клиентом и веб-сервером, но не исправляет слабый пароль, избыточную роль или уязвимый код конфигурации. Не называйте HTTPS «полной защитой»: это необходимый слой для сетевого соединения, а не пропуск к безопасной архитектуре.

Проверьте, что сертификат не истёк, имя узла в сертификате совпадает с адресом, а браузер не сообщает об ошибке доверия. Затем проверьте, что обычные ссылки и закладки ведут на HTTPS, а HTTP не оставлен как альтернативный рабочий вход без необходимости. Перенаправление на защищённый адрес настраивают на веб-сервере, но сам факт редиректа не означает, что исходный запрос уже был зашифрован: первый переход по HTTP всё ещё не защищён. Для внутренней сети используйте сертификат, которому доверяют управляемые клиентские устройства; иначе пользователи быстро привыкнут игнорировать предупреждения браузера.

Ограничьте сетевой доступ к публикации

Если круг пользователей ограничен и их адреса стабильны, добавьте сетевой фильтр на межсетевом экране или веб-сервере. В Apache 2.4 для этого применяется Require ip из mod_authz_host; IIS умеет ограничивать доступ через компонент IP Address and Domain Restrictions. Это правила веб-сервера, а не настройка ролей 1С. Сначала определите реальные источники запросов: адреса офисов, прокси, шлюза или интеграционного узла. Если перед веб-сервером стоит обратный прокси, сервер может видеть адрес прокси, а не исходного пользователя. Неправильная схема доверия к заголовкам прокси способна сделать фильтр бесполезным или закрыть доступ всем.

Фильтр по IP полезен как дополнительный рубеж, но не заменяет аутентификацию. Динамические адреса, мобильный интернет и внешние интеграции требуют отдельного решения; не добавляйте широкие диапазоны только потому, что иначе «не подключается». Для интеграции заведите отдельную учётную запись 1С с минимально необходимыми правами и откройте ей только нужный сетевой путь. После включения ограничений проверьте доступ и с разрешённого, и с запрещённого источника, включая IPv4 и IPv6, если оба протокола доступны. Смотрите журнал отказов, чтобы отличить ожидаемое ограничение от ошибки маршрутизации.

Если публикация доступна сотрудникам из разных сетей, проектируйте удалённый доступ как отдельную часть инфраструктуры: кто аутентифицирует пользователя, где завершается TLS, какой адрес видит IIS или Apache и как отзывать доступ у ушедшего сотрудника. Здесь нет одной галочки, которая подходит всем. Не публикуйте базу на публичный адрес лишь потому, что это быстрее на старте. Сначала зафиксируйте нужные сценарии, откройте только соответствующие сетевые маршруты, а затем проверьте их с каждой категорией пользователя.

Настройте роли и проверьте публикацию до запуска

В 1С разделите учётные записи по задачам. Пользователю веб-клиента нужны только операции его рабочего процесса; учётной записи обмена — только действия, необходимые конкретной интеграции. Не выдавайте всем роль администратора ради быстрого запуска: такая роль может дать полномочия на изменение настроек и данных, которые оператору не нужны. Точные права зависят от конфигурации, поэтому проверьте их на тестовых пользователях и типовых сценариях: просмотр, создание документа, изменение и удаление. Роли и ограничения данных задаются в 1С; настройки Apache или IIS не могут сузить полномочия, уже выданные приложением.

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

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

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