Защита сервера 1С:Предприятия 8.3 от лишних подключений: кластер, порты, права и веб-доступ

Чтобы ограничить доступ к серверу 1С, закройте четыре двери: задайте администраторов кластера и центрального сервера в консоли, оставьте порты 1540, 1541 и 1560–1591 открытыми только для своей подсети, закройте порт СУБД от клиентов и выпускайте удалённых сотрудников только через веб-сервер с HTTPS или VPN. Логин и пароль пользователя в базе защищают данные внутри конфигурации, но не сам сервер.

Частое заблуждение: «у нас у всех пароли в 1С, значит, сервер защищён». Нет. Если администратор кластера не задан, любой сотрудник с установленной консолью администрирования откроет кластер, увидит все базы, завершит чужие сеансы и даже удалит информационную базу вместе с данными в СУБД. Пароли пользователей при этом не спрашиваются вовсе.

Инструкция общая для платформы 8.3 и не зависит от конфигурации: БП, ЗУП, УТ или ERP — порядок одинаковый. Примеры даны для Windows Server 2016 и новее, для Linux приведены аналоги команд.

Откуда приходят подключения к серверу 1С

Прежде чем что-то закрывать, нарисуйте себе карту трафика. У клиент-серверной 1С несколько независимых входов, и защищать нужно каждый.

Схема подключения такая: клиент сначала обращается к агенту на 1540, затем к менеджеру кластера на 1541 и получает адрес рабочего процесса из диапазона. Диапазон задаётся в свойствах рабочего сервера, а не кластера. Если вы его меняли, правила брандмауэра пишите под свой диапазон.

Администраторы кластера: закрываем консоль от посторонних

Это главный шаг, и его пропускают чаще всего. Пока список администраторов пуст, консоль администрирования серверов 1С пускает любого.

У кластера два уровня администраторов:

• 🔑 Администраторы центрального сервера — могут создавать и удалять кластеры, менять настройки самого агента.
• 🔑 Администраторы кластера — управляют базами, сеансами, рабочими серверами и профилями безопасности внутри конкретного кластера.

Порядок настройки

1. Откройте консоль администрирования серверов 1С:Предприятия на самом сервере.
2. Раскройте ветку центрального сервера, затем узел Администраторы. Добавьте пользователя с паролем. Можно включить аутентификацию операционной системы и указать доменную учётную запись в формате DOMAIN\user.
3. Раскройте Кластеры → <ваш кластер> → Администраторы и добавьте администратора кластера тем же способом.
4. Закройте и заново откройте консоль. Она должна запросить логин и пароль — значит, защита работает.

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

Что дают администраторы кластера ещё

После этого создать новую базу на сервере из окна запуска 1С сможет только тот, кто знает пароль администратора кластера. Это закрывает частую проблему, когда сотрудники «на пробу» плодят базы на боевом сервере.

Для работы из командной строки утилита rac тоже будет требовать учётные данные. Точный синтаксис параметров авторизации для вашей версии платформы смотрите в справке rac help.

Брандмауэр и сетевая изоляция сервера 1С

Сервер 1С не должен быть виден из интернета напрямую. Ни один из портов 1540, 1541, 1560–1591 и 1545 не пробрасывайте на роутере наружу.

Внутри сети тоже не стоит пускать всех. Типичная схема: бухгалтерия в одной подсети, склад в другой, гостевой Wi-Fi в третьей. До сервера 1С доходят только первые две.

Правила для Windows Server

Откройте PowerShell или командную строку от имени администратора. Пример для подсети 192.168.10.0/24:

netsh advfirewall firewall add rule name="1C agent and manager" dir=in action=allow protocol=TCP localport=1540-1541 remoteip=192.168.10.0/24
netsh advfirewall firewall add rule name="1C working processes" dir=in action=allow protocol=TCP localport=1560-1591 remoteip=192.168.10.0/24

После этого проверьте, нет ли более широких разрешающих правил для тех же портов. Их часто создают при установке или «на время» во время отладки. В оснастке Брандмауэр Защитника Windows в режиме повышенной безопасности отсортируйте входящие правила по столбцу локального порта.

Правила для Linux (ufw)

ufw allow from 192.168.10.0/24 to any port 1540:1541 proto tcp
ufw allow from 192.168.10.0/24 to any port 1560:1591 proto tcp
ufw enable

Порт СУБД — только для сервера 1С

Клиенты 1С никогда не ходят в базу данных напрямую: все запросы к СУБД делает рабочий процесс на сервере. Значит, порт 1433 (MS SQL) или 5432 (PostgreSQL) нужно открыть только для адреса сервера 1С. Если СУБД стоит на той же машине — закройте порт для всей сети.

Это важно потому, что через прямое подключение к СУБД можно выгрузить таблицы базы целиком, минуя любые права 1С.

Права пользователей и учётные записи на уровне платформы

Брандмауэр решает, откуда можно подключиться. Права решают, что пользователь сделает, когда подключился.

Пользователи информационной базы

• 👤 Роль «Полные права» и «Администратор системы» — только у 1–2 ответственных. Не выдавайте её «чтобы всё работало».
• 🔐 Включите требования к сложности и сроку действия паролей. В типовых конфигурациях на БСП это раздел Администрирование → Настройки пользователей и прав, далее настройки входа.
• 🚫 Снимите флажок показа пользователей в списке выбора при входе: незачем подсказывать логины.
• 🛡 Не отключайте защиту от опасных действий у обычных пользователей. Она предупреждает при запуске внешних обработок и отчётов, которые могут выполнить произвольный код на сервере.
• 🧹 Уволенным сотрудникам запрещайте вход сразу, а не при следующей чистке.

Учётная запись службы 1С

Служба агента сервера должна работать не от имени LocalSystem и не от администратора домена. Используйте отдельного пользователя, по умолчанию установщик предлагает USR1CV8. Ему нужен доступ к каталогу srvinfo и право входа в качестве службы — и больше ничего.

Если служба работает с правами администратора, то любая обработка с серверным кодом получает те же права на файловую систему и сеть.

Учётная запись в СУБД

В свойствах информационной базы в консоли кластера указан пользователь сервера баз данных. Не используйте sa или postgres. Заведите отдельный логин с правами владельца только на базы 1С.

Ограничения в консоли кластера: блокировка сеансов и профили безопасности

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

Блокировка начала сеансов

Откройте Кластеры → <кластер> → Информационные базы → <база> → Свойства. В карточке базы есть флажок Блокировка начала сеансов включена, поля начала и окончания блокировки, текст сообщения и код разрешения.

• 🔒 Пока блокировка действует, новые пользователи в базу не войдут и увидят ваше сообщение.
• 🔑 Администратор входит, указав код разрешения в параметре запуска /UC<код>, например /UC12345.
• ⏸ Рядом есть флажок блокировки регламентных заданий — полезен на время обновления или переноса.

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

Запрет подключений к базе через список баз

Отдельный способ отрезать часть сотрудников — не давать им строку подключения. Список баз в окне запуска хранится в файлах ibases.v8i, а общий список можно раздавать централизованно через параметр CommonInfoBases в файле 1CEStart.cfg. Убрав базу из общего списка для группы пользователей, вы уберёте её из окна запуска.

Но это не защита, а удобство: зная имя сервера и базы, её добавят вручную. Реальное ограничение дают только брандмауэр, права и блокировка сеансов.

Профили безопасности

В узле Профили безопасности кластера создаётся профиль, который ограничивает серверный код конфигурации: доступ к файловой системе, COM-объектам, внешним компонентам, интернет-ресурсам, запуск приложений. Профиль назначается базе в её свойствах.

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

Уровень безопасности соединения

В свойствах кластера есть параметр Уровень безопасности: небезопасное соединение, защищённое только при установке соединения или постоянно защищённое. Последний вариант шифрует весь трафик между клиентом и кластером. Он немного нагружает процессор, но для сетей, где ходит посторонний трафик, это оправдано.

Доступ из интернета только через веб-сервер или VPN

Удалённым сотрудникам нужен доступ к базе, но не к серверу. Есть три рабочих варианта.

Как сделать веб-публикацию безопасной

1. Публикуйте базу на отдельном веб-сервере (IIS или Apache), который стоит в DMZ, а к серверу 1С ходит по внутренней сети.
2. Включите HTTPS с действующим сертификатом. Обычный http:// с паролями 1С в открытом виде использовать нельзя.
3. Откройте файл default.vrd в каталоге публикации и проверьте, что не указаны атрибуты usr и pwd. Если они заданы, любой открывший адрес попадёт в базу без пароля под этим пользователем.
4. Отключите то, чем не пользуетесь. В default.vrd у элементов веб-сервисов и стандартного интерфейса OData есть атрибут enable: выставьте enable="false" для ненужных.
5. Для HTTP-сервисов, через которые ходят внешние системы, заведите отдельного пользователя базы с ролью только на нужные объекты.
6. Ограничьте адреса, если внешние системы известны заранее: фильтр по IP в IIS или директивы Require ip в Apache.

Пример фрагмента публикации, где отключены веб-сервисы и OData:

<point xmlns="http://v8.1c.ru/8.2/virtual-resource-system"
       base="/buh"
       ib="Srvr=&quot;srv1c&quot;;Ref=&quot;buh&quot;;">
  <ws enable="false"/>
  <standardOdata enable="false"/>
</point>

Журналы: как увидеть, кто стучится к серверу 1С

Ограничения без контроля быстро размываются: кто-то добавил правило «на день», кому-то выдали полные права. Раз в неделю-две просматривайте следы подключений.

Журнал регистрации базы

В типовых конфигурациях: Администрирование → Обслуживание → Журнал регистрации. Что искать:

• ❌ события аутентификации с уровнем «Ошибка» — неудачные попытки входа, особенно серией подряд по одному пользователю;
• 🕒 входы в нерабочее время и с незнакомых компьютеров (имя компьютера видно в колонке события);
• 👤 изменения пользователей и их ролей — кто кому и когда выдал права.

Отфильтруйте журнал по событиям группы Сеанс и Пользователи — так список сократится до нужного.

Консоль кластера

Узел Сеансы показывает, кто подключён прямо сейчас: пользователь, компьютер, приложение (тонкий клиент, веб-клиент, Конфигуратор, COM-соединение). Неожиданное COM-соединение или Конфигуратор у бухгалтера — повод разобраться.

Из командной строки то же самое даёт rac session list с указанием кластера.

Технологический журнал и журналы ОС

Для расследования серьёзных инцидентов включают технологический журнал платформы через файл logcfg.xml в каталоге conf платформы. Он подробный и быстро занимает место на диске, поэтому включайте его точечно и на ограниченное время.

На уровне Windows смотрите журнал безопасности: события входа в систему покажут, кто заходил на сам сервер по RDP или через сетевые ресурсы.

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