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

В этой статье разберём основные области риска и соберём практический чек-лист, по которому можно провести первичный аудит безопасности 1С.

---

Кому будет полезна эта статья

Материал в первую очередь предназначен для:

• •специалистов по информационной безопасности;
• •администраторов 1С;
• •системных администраторов;
• •руководителей ИТ-служб;
• •разработчиков и архитекторов 1С;
• •внутренних и внешних аудиторов;
• •компаний, которые используют 1С как критичную бизнес-систему.

Чек-лист в конце статьи можно использовать как основу для самостоятельной проверки или как отправную точку для формирования внутреннего стандарта безопасной эксплуатации 1С.

---

Почему безопасность 1С часто недооценивают

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

«1С находится внутри сети — значит, она недоступна злоумышленнику»

Внутренняя сеть не является доверенной по умолчанию. Если атакующий уже получил доступ к рабочей станции, VPN, серверу или учётной записи сотрудника, доступная из внутренней сети 1С становится одной из наиболее интересных целей.

Кроме того, в инфраструктуре нередко остаются административные сервисы, веб-публикации или СУБД, доступные из слишком широких сетевых сегментов.

«Мы регулярно обновляем платформу»

Обновление платформы важно, но закрывает только часть рисков. Оно не исправит:

• •администратора кластера без пароля;
• •избыточные роли пользователей;
• •небезопасную внешнюю обработку;
• •открытый доступ к резервным копиям;
• •пароль или токен, записанный в коде;
• •небезопасную веб-публикацию;
• •чрезмерные права сервисной учётной записи.

«У пользователей есть пароли»

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

«Конфигурация типовая»

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

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

---

Кластер серверов 1С

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

Администратор кластера

После развёртывания кластера необходимо убедиться, что административный доступ защищён аутентификацией.

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

Проверьте:

• •создан ли отдельный администратор кластера;
• •установлен ли надёжный пароль;
• •отсутствуют ли неиспользуемые административные учётные записи;
• •ограничен ли доступ к административным интерфейсам по сети.

RAC и RAS

Инструменты удалённого администрирования должны быть доступны только тем узлам и специалистам, которым они действительно необходимы.

Не стоит оставлять административные порты доступными из пользовательских VLAN, Wi-Fi, VPN общего назначения или других широких сетевых сегментов.

Оптимальная схема — отдельный административный сегмент или jump-host, откуда выполняется управление 1С.

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

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

Особенно опасны варианты, когда служба работает:

• •от Domain Admin;
• •от локального администратора без необходимости;
• •от общей сервисной учётной записи, используемой одновременно другими системами;
• •от персональной учётной записи администратора.

Компрометация процесса 1С в таком случае может дать злоумышленнику существенно больше возможностей в операционной системе и домене.

Разделение контуров

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

• •сетевого доступа;
• •учётных записей;
• •данных;
• •административных прав;
• •резервных копий.

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

---

Пользователи, роли и аутентификация

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

Неактивные и уволенные пользователи

Одна из базовых проверок — сопоставить пользователей 1С с актуальными сотрудниками и техническими учётными записями.

Необходимо выявить:

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

Отключение доступа должно быть частью кадрового процесса, а не выполняться вручную «по памяти» администратора.

Пустые и слабые пароли

Для пользователей с аутентификацией средствами 1С необходимо убедиться, что пароль действительно задан и соответствует принятой политике.

Следует контролировать:

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

Избыточные роли

Пользователь должен иметь только те права, которые необходимы ему для работы.

Особого внимания требуют:

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

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

Служебные пользователи

Интеграции, фоновые задания и роботы должны использовать отдельные технические учётные записи.

Для них стоит отдельно проверить:

• •запрет интерактивного входа, если он не нужен;
• •минимально необходимые права;
• •понятного владельца;
• •назначение каждой учётной записи;
• •процедуру смены секретов.

---

Внешние обработки, расширения и интеграции

Внешние обработки — одна из наиболее чувствительных областей безопасности 1С.

Файл .epf или .erf фактически является исполняемым кодом. Если пользователь может загрузить и запустить произвольную обработку, его реальные возможности могут оказаться существенно шире, чем предполагает набор назначенных ему ролей.

Кто может запускать внешние обработки

Запуск внешних обработок обычными пользователями должен быть запрещён, если этого не требует бизнес-процесс.

Если внешние обработки используются, необходимо понимать:

• •кто имеет право их загружать;
• •кто может запускать их;
• •откуда они поступают;
• •проверяются ли они перед использованием;
• •фиксируется ли версия и источник файла.

Расширения конфигурации

Расширение также содержит исполняемый код и может менять поведение системы.

Необходимо вести инвентаризацию расширений и понимать:

• •зачем установлено каждое расширение;
• •кто его разработал;
• •когда оно обновлялось;
• •проходил ли код проверку;
• •используется ли расширение в продуктиве в текущий момент.

Старые тестовые расширения и временные доработки не должны годами оставаться в промышленной системе.

Интеграции

1С часто взаимодействует с внешними системами через HTTP-сервисы, веб-сервисы, OData, REST, файловый обмен, очереди, COM и другие механизмы.

Для каждой интеграции следует определить:

• •используемый протокол;
• •направление соединения;
• •учётную запись;
• •объём доступных данных;
• •способ хранения секретов;
• •необходимость шифрования;
• •сетевые ограничения.

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

---

Конфигурационные файлы, СУБД и серверная инфраструктура

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

Доступ к СУБД

Сервер базы данных не должен быть доступен «всем внутри сети».

Соединения стоит разрешать только от необходимых серверов приложений и административных узлов.

Проверьте:

• •firewall и ACL;
• •слушающие интерфейсы СУБД;
• •удалённый административный доступ;
• •учётные записи базы данных;
• •права пользователя, от имени которого 1С подключается к СУБД.

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

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

Отдельно нужно исключить:

• •пустые пароли;
• •общие административные логины;
• •использование одной учётной записи для множества несвязанных систем;
• •хранение пароля в открытом виде в скриптах и документации.

Файлы кластера и каталоги 1С

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

Пользователи не должны иметь возможности произвольно изменять файлы сервера 1С.

Следует проверить ACL на Windows и права файловой системы на Linux.

Операционная система

Сам сервер 1С также должен соответствовать базовым требованиям hardening:

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

---

Резервные копии и выгрузки

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

Где хранятся резервные копии

Проверьте все способы резервирования и выгрузки:

• •дампы СУБД;
• •.dt;
• •.1cd;
• •архивы каталогов;
• •снапшоты виртуальных машин;
• •копии на NAS и файловых серверах;
• •копии в облачных хранилищах.

Критичная ошибка — хранить такие файлы в общей сетевой папке, доступной широкому кругу сотрудников.

Права доступа

К резервным копиям должны иметь доступ только те сотрудники и сервисы, которым он требуется для резервирования и восстановления.

Желательно разделять права на:

• •создание резервной копии;
• •чтение резервной копии;
• •удаление;
• •восстановление.

Шифрование

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

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

Наличие файла резервной копии ещё не означает, что из него можно восстановиться.

Процедура резервирования должна включать регулярные тесты восстановления с понятными показателями RPO и RTO.

---

Веб-публикации и удалённый доступ

Публикация 1С через IIS или Apache существенно меняет поверхность атаки: информационная база становится доступна через веб-сервер и потенциально — из внешних сетей.

Инвентаризация публикаций

Первый шаг — определить все существующие публикации и ответить на вопросы:

• •какие базы опубликованы;
• •на каких серверах;
• •по каким адресам;
• •из каких сетей они доступны;
• •кто ими пользуется;
• •действительно ли они всё ещё нужны.

Забытые публикации встречаются чаще, чем кажется.

HTTPS

Удалённый доступ к 1С должен использовать HTTPS с корректно настроенным сертификатом.

Необходимо исключить постоянную эксплуатацию HTTP для передачи пользовательских учётных данных и бизнес-данных.

Доступ из интернета

Прямая публикация информационной базы в интернет без дополнительных защитных мер значительно увеличивает риск.

В зависимости от сценария могут использоваться:

• •VPN;
• •reverse proxy;
• •WAF;
• •дополнительная аутентификация;
• •ограничения по IP;
• •сетевое разделение;
• •MFA на уровне внешнего контура.

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

Веб-сервер

IIS или Apache тоже требуют hardening:

• •актуальная версия;
• •минимальный набор модулей;
• •корректные TLS-настройки;
• •ограничение доступа к конфигурационным файлам;
• •логирование запросов;
• •контроль ошибок и аномалий.

---

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

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

С их помощью можно контролировать доступ к:

• •файловой системе;
• •внешним интернет-ресурсам;
• •COM-объектам;
• •внешним компонентам;
• •другим потенциально опасным ресурсам.

Это особенно важно для внешних обработок, расширений и кода, которому нельзя полностью доверять.

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

Слишком широкий профиль сводит пользу механизма к минимуму. Слишком жёсткий без предварительного тестирования может нарушить работу легитимных интеграций.

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

Краткий итог

Если вы начинаете аудит безопасности 1С, начните с нескольких вопросов:

• •защищено ли администрирование кластера;
• •кто имеет административные права в базах;
• •могут ли пользователи запускать произвольный код через внешние обработки;
• •где лежат резервные копии;
• •кому доступна СУБД;
• •какие базы опубликованы в веб;
• •кто контролирует изменения конфигурации и расширений;
• •можно ли восстановить картину действий пользователя или администратора по журналам.

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

Безопасность 1С — это не отдельный проект, который можно один раз завершить. Это постоянный контроль изменений в системе, правах, коде и инфраструктуре.