Информационная безопасность для сервиса 1С

Почему безопасность 1С — это вопрос устойчивости бизнеса

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

Рисунок 1 – Что входит в информационную безопасность 1С

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

Что именно нужно защищать в инфраструктуре 1С

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

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

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

Инвентаризация: с чего начинается защита

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

Рисунок 2 – Инвентаризация инфраструктуры 1С

В карте инфраструктуры нужно зафиксировать Windows Server, Linux Server, платформу виртуализации, сетевые сегменты, межсетевые экраны, СУБД, компоненты 1С, удаленный доступ, резервное копирование, мониторинг и дополнительные средства защиты. Если какой-то компонент не используется, это тоже стоит указать: так исключаются ложные ожидания и серые зоны.

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

Основные угрозы для 1С

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

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

Рисунок 3 – Типовая цепочка инцидента в инфраструктуре 1С

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

Целевая архитектура защиты

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

Рисунок 4 – Целевая схема доступа к 1С

В практическом виде это означает: пользователи и администраторы подключаются через защищенные каналы, административные действия проходят через bastion или jump-server (выделенный защищённый сервер, через который выполняются административные подключения. Прямой доступ администраторов к продуктивным серверам из пользовательских сегментов должен быть запрещён), серверы 1С и СУБД находятся в отдельных сегментах, резервные копии хранятся изолированно, а события безопасности собираются централизованно.

Виртуализация и серверные платформы

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

1. доступ к интерфейсу управления гипервизором должен быть ограничен доверенными сетями;
2. прямой доступ из пользовательских сегментов к гипервизору должен быть запрещен;
3. обновления безопасности гипервизора и компонентов виртуализации должны устанавливаться после тестирования;
4. парольная политика и MFA должны применяться к административному доступу там, где это поддерживается;
5. действия администраторов, изменения конфигурации, операции со снапшотами и шаблонами должны журналироваться;
6. неиспользуемые сервисы, API, web-консоли, shell-доступ и passthrough-функции должны быть отключены или ограничены;
7. виртуальные сети должны быть разделены по ролям сервисов;
8. шаблоны ВМ и образы должны проверяться перед вводом в эксплуатацию.

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

Windows Server и Linux Server

Windows Server

Для серверов Windows, на которых работают AD, RDS, файловые роли, серверы 1С или СУБД, критичны базовые меры hardening.

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

Linux Server

Для Linux-серверов важны PAM, sudo/sudoers, запрет root-доступа по SSH, централизованный контроль обновлений, доверенные репозитории и минимальный набор сервисов.

• разграничение административных полномочий;
• обновления безопасности по регламенту;
• использование доверенных репозиториев и GPG-подписей;
• ограничение SSH доверенными сегментами;
• отключение парольной аутентификации при использовании ключей или централизованной аутентификации;
• минимизация пользователей с правами администратора;
• использование SELinux или AppArmor там, где это применимо;
• удаление неиспользуемых пакетов, демонов и таймеров;
• шифрование дисков при необходимости.

Учетные записи, пароли и административный доступ

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

1. неиспользуемые учетные записи должны быть удалены или заблокированы;
2. сервисные учетные записи должны быть отдельными и не использоваться интерактивно без необходимости;
3. для всех платформ должны быть настроены длина, сложность, история, срок действия и ротация паролей;
4. типовые и скомпрометированные пароли должны быть запрещены;
5. MFA должна применяться для административного доступа и внешних подключений там, где это технически возможно;
6. права должны выдаваться по ролям и минимуму необходимого;
7. постоянные привилегии следует заменять временными или ограниченными механизмами, где это возможно;
8. пароли не должны храниться в открытых файлах, скриптах и конфигурациях.

Рисунок 5 – Сегментация инфраструктуры 1С по ролям

Сетевая безопасность и сегментация

Сетевая защита должна строиться по принципу «запрещено все, кроме явно разрешенного». Это особенно важно для связки пользовательских подсетей, серверов 1С, СУБД, резервного копирования и административного контура.

Рисунок 6 – Схема административного доступа к серверам 1С, СУБД и ОС

• firewall должен быть включен на уровне хостов и сетевых границ;
• удаленный административный доступ должен быть разрешен только по защищенным каналам из доверенных сегментов;
• прямой RDP и SSH из Интернета должны быть запрещены;
• MFA для администраторов должна использоваться везде, где поддерживается;
• для внешних и межсегментных сервисов должны использоваться актуальные версии TLS и доверенные сертификаты;
• серверы 1С и СУБД не должны иметь прямой неограниченный выход в Интернет;
• доступ между зонами должен быть ограничен нужными портами и направлениями;
• при необходимости используются IDS/IPS ( скажется на производительности сервера 1с), выделенный контур администрирования и jump-server.

Защита СУБД

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

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

Прикладная безопасность 1С

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

Рисунок 7 – Прикладной уровень 1С и зоны контроля

• агент сервера, менеджер кластера и рабочие процессы должны запускаться под отдельными сервисными учетными записями с минимально необходимыми правами;
• доступ к каталогам публикаций, web-каталогам, конфигурационным файлам и журналам 1С должен быть ограничен;
• web-публикации должны работать по HTTPS с актуальными версиями TLS и корректными сертификатами;
• средства контроля целостности конфигураций должны быть включены там, где они используются;
• внешние обработки, внешние отчеты, COM/OLE, внешние компоненты и расширения должны разрешаться только по утвержденному перечню;
• журнал регистрации 1С должен фиксировать аутентификацию, изменения прав, административные действия и критичные операции;
• MFA стоит использовать для web-доступа и внешних пользователей там, где это возможно;
• фоновые и регламентные задания должны контролироваться по автору, цели, правам и внешним вызовам;
• для разных контуров и категорий данных стоит использовать раздельные кластеры или информационные базы;
• для критичных файлов и конфигураций нужен контроль целостности.

Резервное копирование и восстановление

Резервная копия — последняя линия защиты. Она должна быть не просто создана, а защищена от удаления, шифрования и несанкционированного изменения.

Рисунок 8 – Мониторинг и журналирование инфраструктуры 1С

1. регулярно создаются копии данных, конфигураций, публикаций, параметров кластера 1С, ключевых конфигурационных файлов ОС и СУБД;
2. копии хранятся в защищенном и изолированном хранилище;
3. включены оповещения о сбоях резервного копирования;
4. процедура восстановления протестирована;
5. резервные копии защищены от удаления, шифрования и несанкционированного изменения;
6. для повышения устойчивости используются offline, offsite или immutable-копии;
7. backup-архивы шифруются при необходимости защиты от утечки.

Важный критерий зрелости — не наличие задания резервного копирования, а подтвержденное восстановление. Если восстановление не тестировалось, бизнес не знает реальное время простоя и не может оценить последствия аварии.

Мониторинг, журналирование и поиск инцидентов

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

Рисунок 9 – Централизованный сбор событий безопасности

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

Чек-лист для оценки текущего уровня защиты

Этот чек-лист можно использовать как первый аудит перед модернизацией инфраструктуры 1С.

План внедрения на 180 дней

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

Рисунок 10 – Практический план внедрения защиты 1С

Результат

Хорошо защищенная 1С-инфраструктура дает не только техническую безопасность, но и понятный бизнес-результат.

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

Итоговая цель — не «поставить больше средств защиты», а сделать работу 1С устойчивой: чтобы атака, ошибка или сбой не приводили к полной остановке бизнеса и потере управляемости.

Короткий FAQ

Достаточно ли антивируса на сервере 1С?

Нет. Антивирус или EDR — только один слой. Нужны MFA, ограничение удаленного доступа, сегментация, контроль прав, резервное копирование и журналирование. Важно отметить, что антивирус может замедлить скорость работы 1с, особенно файловых баз. Требуется тонкая настройка антивируса

Почему нельзя открыть RDP к серверу 1С из Интернета?

Потому что прямой административный доступ резко повышает риск подбора пароля, эксплуатации уязвимостей и захвата сервера. Доступ должен идти через VPN, MFA и контролируемый jump-server.

Что важнее: резервное копирование или мониторинг?

Обе меры нужны вместе. Backup помогает восстановиться, а мониторинг помогает заметить инцидент и понять его масштаб.

Нужно ли разделять сервер 1С и СУБД?

Для серьезной инфраструктуры разделение ролей повышает управляемость, безопасность и отказоустойчивость, но при отказе от технологии Shared Memory общая скорость работы сервиса может снизиться. Минимум нужно ограничить сетевой доступ и права между компонентами.

Как понять, что защита 1С настроена нормально?

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