Как защитить сервер 1С: полное руководство по безопасности

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

Защита сервера 1С строится слоями: сетевая изоляция, ограничение доступа к серверу приложений и СУБД, разграничение прав внутри 1С, шифрование каналов, резервное копирование и мониторинг. Ни один из слоёв не работает в одиночку — открытый порт PostgreSQL сведёт на нет самые строгие права в конфигураторе.

Материал ориентирован на администраторов, которые обслуживают клиент-серверную архитектуру 1С (сервер 1С:Предприятия + СУБД). Большинство рекомендаций применимы и к файловым базам, опубликованным на веб-сервере, но там свои особенности.

Сетевая изоляция: закрываем доступ извне

Первый и самый важный шаг — убедиться, что сервер 1С и сервер СУБД недоступны из интернета и лишних сегментов локальной сети. Кластер 1С использует порты 1540–1541 (агент и менеджер кластера) и диапазон 1560–1591 (рабочие процессы). СУБД слушает свои порты: 1433 для MS SQL Server, 5432 для PostgreSQL. Все они должны быть доступны только тем машинам, которым это реально нужно.

На межсетевом экране (встроенном брандмауэре Windows, nftables/iptables в Linux или периметровом firewall) разрешите подключения к портам кластера только с рабочих станций пользователей и серверов публикации (веб-сервер с тонким/веб-клиентом). Порт СУБД должен принимать соединения только с сервера 1С — и больше ни откуда. Типичная ошибка — открыть 1433 «на всю сеть», после чего базу можно перебирать паролем с любой машины.

Убедитесь, что сервер не имеет «белого» IP-адреса и не проброшен через NAT. Проверить это можно сканированием с внешнего адреса или с машины из другого сегмента сети командой telnet или Test-NetConnection по нужным портам — соединение не должно устанавливаться.

Защита кластера серверов 1С

Кластер 1С по умолчанию после установки не имеет администраторов — это означает, что любой, кто достучался до порта 1540, может подключиться консолью администрирования и управлять базами: создавать, удалять, менять настройки. Первое действие после установки — создать администратора кластера с сильным паролем.

Откройте консоль управления серверами 1С, в свойствах кластера добавьте администратора, задайте пароль длиной не менее 12–16 символов. После этого подключение консолью и любые административные операции будут требовать аутентификации. Отдельно добавьте администраторов на уровне каждой информационной базы — это второй независимый барьер.

Учётная запись, под которой работает служба агента сервера 1С (по умолчанию USR1CV8 в Windows), должна быть служебной: без прав локального администратора на других серверах, без доступа к лишним сетевым ресурсам, с запретом интерактивного входа. Если эту учётную запись скомпрометируют, ущерб будет минимальным.

1. 1
   Откройте консоль управления серверами 1С и подключитесь к кластеру
2. 2
   В свойствах кластера создайте администратора с сильным паролем
3. 3
   Для каждой информационной базы задайте отдельного администратора ИБ
4. 4
   Проверьте: подключение консолью без пароля должно отклоняться
5. 5
   Ограничьте права служебной учётной записи агента сервера (USR1CV8)

Защита СУБД и доступа к данным напрямую

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

Для MS SQL Server: используйте отдельную служебную учётную запись, отключите или переименуйте sa, задайте ему сложный пароль и отключите его для входа, если используется Windows-аутентификация. Учётная запись сервера 1С должна иметь права только на свои базы (db_owner на конкретные БД), а не sysadmin на весь экземпляр. Для PostgreSQL: уберите метод trust из pg_hba.conf, разрешайте подключения только с адреса сервера 1С, используйте scram-sha-256 для паролей.

# Пример pg_hba.conf: доступ только с сервера 1С
hostssl  all  usr1c  192.168.10.5/32  scram-sha-256
host     all  all    0.0.0.0/0        reject

Включите шифрование соединений между сервером 1С и СУБД (SSL/TLS), если серверы разнесены по разным машинам или сегментам сети. Трафик между ними содержит все данные базы в открытом виде и легко перехватывается в общей сети. Дополнительно рассмотрите шифрование дисков (BitLocker, LUKS) на сервере СУБД — это защитит данные при физическом изъятии оборудования.

Разграничение прав внутри 1С

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

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

Включите для всех пользователей аутентификацию: парольную (с политикой сложности, если она настроена в свойствах ИБ) или аутентификацию ОС. Запретите работу под общими учётными записями — они делают невозможным расследование инцидентов. Уволенным сотрудникам доступ блокируется в день увольнения: снимается флаг «Аутентификация 1С:Предприятия» и завершаются активные сеансы через консоль кластера.

Резервное копирование как защита от шифровальщиков

Резервные копии — последняя линия обороны, и именно она спасает при атаках программ-вымогателей, которые остаются главной угрозой для серверов 1С. Требования к бэкапам: регулярность, изолированность хранилища и проверка восстановления.

Копии базы делайте средствами СУБД (полные ежедневно, разностные или копии журнала транзакций чаще) и/или выгрузкой в dt. Хранилище копий должно быть недоступно для записи с самого сервера 1С под его служебной учётной записью — иначе шифровальщик, захвативший сервер, зашифрует и бэкапы. Подходящие варианты: отдельный сервер бэкапов, который сам забирает копии (pull-модель), объектное хранилище с версионированием, ленты или съёмные диски по расписанию.

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

Обновления, журналирование и мониторинг

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

Включите журнал регистрации в информационной базе с записью событий доступа, изменения данных и ошибок. Для критичных баз настройте выгрузку журнала во внешнюю систему (SIEM или хотя бы в отдельный файл вне сервера) — при инциденте злоумышленник часто пытается замести следы. Настройте оповещения о событиях: вход администратора в нерабочее время, массовое изменение данных, ошибки СУБД, переполнение дисков.

Частые вопросы о защите сервера 1С