Безопасность сервера 1С: что закрыть, настроить и проверять

Сервер 1С чаще всего взламывают не хитрым эксплойтом, а через открытый в интернет порт, пароль admin и RDP без ограничений. Закройте внешний доступ, разделите права, настройте шифрованные копии вне сервера — этого хватает, чтобы отсечь большинство реальных атак.

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

Изолируйте сервер: физически и в сети

Сервер приложений 1С и СУБД не должны смотреть в интернет напрямую. Это правило номер один, остальное вторично.

Физический доступ

Если сервер стоит в офисе, а не в дата-центре, он живёт в запираемом помещении или шкафу. Иначе флешка с загрузочной ОС решает всё: диск читается в обход паролей Windows и Linux.

• 🔒 Включите шифрование диска (BitLocker в Windows, LUKS в Linux) — украденный сервер не раскроет базы.
• 🔌 Подключите ИБП: аварийное выключение при скачке питания портит файлы СУБД чаще, чем кажется.
• 🔑 Пароль на BIOS/UEFI и запрет загрузки с внешних носителей.

Сетевая схема

Минимальная правильная схема — три зоны:

СУБД (PostgreSQL, MS SQL) лучше вынести на отдельную машину или хотя бы разрешить подключение к ней только с адреса сервера 1С. Пользователям доступ к порту базы не нужен вообще.

Настройте брандмауэр и закройте лишние порты

Откройте только то, что действительно используется. Типовой набор для клиент-серверной 1С выглядит так:

Диапазон рабочих процессов можно сузить в настройках кластера, если пользователей немного. Проверьте, что реально слушает сервер:

# Linux
ss -tlnp | grep -E '1540|1541|15[6-9][0-9]|5432'

# Windows (PowerShell)
Get-NetTCPConnection -State Listen | Where-Object { $_.LocalPort -in 1540,1541,1545,5432,1433 }

Сканирование снаружи покажет картину, которую видит атакующий. Запустите nmap с любой внешней машины по IP сервера: если в ответе есть 1540, 1541, 3389 или 5432, закрывайте сразу.

RDP и SSH

Порт RDP 3389 в открытом виде — основной вход для шифровальщиков. Варианты по возрастанию надёжности:

1. Сменить порт — не защита, но отсекает массовые сканеры.
2. Ограничить доступ по IP-адресам в брандмауэре.
3. Пустить RDP только через VPN или шлюз удалённых рабочих столов.
4. Включить проверку подлинности на уровне сети (NLA) и блокировку учётной записи после нескольких неверных попыток.

Для SSH — вход только по ключам, PasswordAuthentication no в sshd_config, root-вход запрещён.

Разделите доступ: администраторы, пользователи, базы

Кластер и ОС

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

Пользователи базы

В самой базе 1С:

1. Уберите пользователей без пароля. В списке пользователей включите колонку с признаком аутентификации и пройдите глазами.
2. Для каждого сотрудника — личная учётная запись. «Бухгалтер1» с общим паролем не даёт ни защиты, ни следов в журнале.
3. Права — через профили групп доступа, а не роль «Полные права» каждому. Полные права нужны двум-трём людям.
4. Включите требования к паролю: минимальная длина, запрет простых значений, срок действия. Параметры ищите в настройках пользователей и прав раздела «Администрирование».
5. Уволенного сотрудника отключайте в день ухода, а не удаляйте: история действий в журнале регистрации сохранится.

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

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

Опасные действия и расширения

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

Резервное копирование и восстановление: правило 3-2-1

Всё остальное можно потерять и пережить. Базу без копии — нет.

Правило 3-2-1: три копии данных, на двух разных типах носителей, одна из них — вне площадки. Для сервера 1С это выглядит так:

Пример ночного дампа PostgreSQL:

pg_dump -U postgres -Fc -f /backup/buh_$(date +%F).dump buh_base

Копию нужно хранить не на том же диске и не на том же сервере. Если шифровальщик дошёл до сервера, он дойдёт и до подключённой сетевой папки с копиями, если она примонтирована постоянно. Копии лучше «забирать» отдельной машиной или писать в хранилище, где нельзя изменить уже записанное.

Проверка восстановления

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

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

Шифрование и архивация копий (на примере 7-Zip)

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

7-Zip умеет шифровать архив алгоритмом AES-256. Для формата 7z есть ключ, который прячет ещё и имена файлов:

7z a -t7z -mx=5 -mhe=on -p backup_2026-10-07.7z buh_2026-10-07.dt

Без значения после -p программа спросит пароль сама, и он не попадёт в историю команд. В скриптах пароль читают из защищённого файла или переменной окружения, а не пишут прямо в текст.

Правила обращения с паролем архива:

1. Длинная фраза из 4-5 слов надёжнее короткого «сложного» пароля.
2. Пароль хранится отдельно от копий — в менеджере паролей или запечатанном конверте у руководителя.
3. Пароль, потерянный вместе с единственным администратором, равен потере копий. Он должен быть известен как минимум двум людям.

Уровень сжатия -mx=5 — разумный компромисс по скорости. База 20 ГБ в .dt обычно ужимается в несколько раз, но на сервере с 2 ядрами максимальное сжатие -mx=9 займёт заметно больше времени, и при ночном окне это важно.

Обновляйте платформу, конфигурации и систему

Уязвимости находят и в операционной системе, и в СУБД, и в самой платформе. Старый сервер на Windows Server, давно снятой с поддержки, — готовая мишень.

Порядок обновлений:

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

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

Отдельно про веб-публикацию. Веб-сервер (Apache, IIS, nginx в роли прокси) обновляйте так же регулярно, как и сервер 1С. Публикуйте только нужные базы и только сервисы, которые нужны внешним системам. Лишние HTTP-сервисы и OData без необходимости не включайте.

Защитите сервер от вирусов и шифровальщиков

Антивирус на сервере 1С нужен, но настроить его надо с умом, иначе база начнёт тормозить.

Исключения из проверки

Постоянная проверка файлов в реальном времени тормозит каталоги СУБД и кластера. Добавьте в исключения:

• каталоги данных PostgreSQL или SQL Server;
• каталог кластера 1С (reg_1541 и временные файлы сеансов);
• каталог файловых баз 1Cv8.1CD;
• процессы ragent, rmngr, rphost, 1cv8.

Эти же каталоги проверяйте полным сканированием по расписанию, ночью, когда сеансов нет.

Против шифровальщиков

• Пользователи без прав администратора на своих машинах: большинство заражений приходит с рабочих мест.
• Запрет запуска программ из каталогов временных файлов и загрузок (политики Windows).
• Почту фильтровать на шлюзе: письма со вложениями .js, .vbs, .iso, архивы с паролем.
• Отключить SMB первой версии и не выставлять 445 наружу.
• Копии, недоступные с заражённой машины, — это единственная гарантированная защита, остальное снижает вероятность.

Мониторинг и реакция на инциденты

Атаку надо заметить до того, как зашифрованы данные. Для этого достаточно трёх вещей.

Что смотреть

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

План на случай инцидента

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

1. Отключить сервер от сети (кабель или виртуальный сетевой адаптер), но не выключать питание, если нужна диагностика памяти.
2. Зафиксировать время, симптомы, текст требования, если есть.
3. Сменить все пароли с чистой машины: ОС, СУБД, кластер, базы, почта администратора.
4. Развернуть сервер заново из проверенного образа и восстановить базы из последней копии, созданной до заражения.
5. Разобраться в причине, прежде чем вернуть сервер в сеть: иначе атака повторится тем же путём.

Что ещё стоит сделать

Меры, которые не вошли в основные шаги, но дают заметный эффект:

• 🧹 Чистка лишнего. Старые тестовые базы, забытые публикации, неиспользуемые учётные записи, консоли, оставленные на сервере разработчиком.
• 🕒 Время. Синхронизация с надёжным источником: без неё логи разных систем не сопоставить при расследовании.
• 📜 Регламент. Документ на 2-3 страницы: кто что может, кто отвечает за копии, как согласуются изменения.
• 🧪 Разделение сред. Тестовая и боевая базы на разных серверах или хотя бы под разными учётными записями.
• 👥 Подрядчики. Доступ внешних специалистов — на время работ, под личной учёткой, с отзывом после завершения.

Для самопроверки пройдите по списку:

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