Безопасность АСУ ТП: как выстроить защиту без капитальных вложений

5 ноября 2026

Чаще всего в экспертных кругах вопросы обеспечения информационной безопасности автоматизированных систем управления технологическими процессами (АСУ ТП) рассматриваются в контексте крупных промышленных объектов, включающих значимые объекты критической информационной инфраструктуры. Для таких категорий разработаны детальные нормативные требования, регламентирующие перечень организационных и технических мер защиты, а также предусматривающие значительные финансовые и кадровые ресурсы для их реализации.

При этом значительный сегмент промышленного сектора представлен предприятиями малого и среднего бизнеса. Согласно данным Минпромторга РФ, доля такого бизнеса в 2025 году составила 15%. Многие из этих предприятий эксплуатируют АСУ ТП, но не подпадают под действие Федерального закона № 187-ФЗ «О безопасности критической информационной инфраструктуры Российской Федерации» в части обязательности исполнения всех его требований.

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

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

Одной из самых грубых ошибок, встречающихся при формировании сетевого пространства предприятия — объединение корпоративной офисной (ИТ) и промышленной (АСУ ТП) сетей в одну сетевую структуру. Такая архитектура создает благоприятную среду для распространения вирусов и червей из корпоративного сегмента в производственный. Корпоративный сегмент заражается чаще всего через электронную почту или при просмотре веб-сайтов.

В качестве приоритетной меры можно рассмотреть физическое отделение АСУ ТП от корпоративного сегмента и тем более от интернета. Наилучшим решением было бы полное отсутствие онлайн-доступа, однако на практике это не всегда реализуемо из-за особенностей производственного процесса и удаленного размещения оборудования.

Для устранения этого недостатка необходимо разделить сеть на несколько физических и логических сегментов. Например:

1. Корпоративный сегмент (ИТ-инфраструктура) — содержит рабочие компьютеры административных и финансовых отделов, менеджеров по продажам, руководителей, сервера 1С, файловые хранилища и т.д. Как правило, с этих устройств открыт доступ в интернет.
2. Промышленный сегмент (АСУ ТП) — объединяет контроллеры, умные устройства, серверы и АРМ. В идеале не должен иметь прямого доступа в интернет.
3. Буферная зона (DMZ) — буферная зона, которая организуется между корпоративным и промышленным сегментами для обеспечения обмена данными. Например, для передачи телеметрической информации или организации защищенного удаленного доступа.

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

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

Отдельно стоит сказать об удаленном доступе. Надежнее полностью отказаться от сетевого доступа из корпоративного сегмента в производственный. Угрозы ИБ регулярно развиваются и усложняются: то, что сегодня кажется надежным межсетевым экраном, завтра может стать решетом, пропускающим любой ИИ-запрос. Если технологу неудобно каждый раз идти в цех для сверки параметров ПЛК, а на его корпоративном ПК установлены SCADA, почта и есть доступ в интернет, этот ПК станет удобной точкой входа для нарушителя. Предоставьте доступ к производственному серверу через монитор и KVM-удлинитель: сотруднику не придется каждый раз идти в цех для сверки параметров, а сети останутся физически разделены.

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

Харденинг (от англ. hardening — закалка) — это процесс усиления безопасности компонентов системы путем отключения неиспользуемых функций, сервисов и протоколов, а также ужесточения политик доступа. Его базовый принцип — «запрещено все, что явно не разрешено». По возможности систему нужно привести именно к такому состоянию. Харденинг не требует приобретения дополнительного программного обеспечения и реализуется штатными средствами оборудования, операционных систем и прикладных ПО.

Харденинг можно применять на различных уровнях и компонентах АСУ ТП начиная с физической безопасности оборудования и заканчивая корректировкой настроек SCADA-систем. Ниже рассмотрим эти уровни.

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

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

Программируемые логические контроллеры (ПЛК) — мозг АСУ ТП, управляющий технологическим оборудованием. Если без АРМ и серверов ваша АСУ ТП может еще некоторое время функционировать, то при нарушении работы ПЛК сбой неизбежен. Архитектура большей части ПЛК ориентирована в первую очередь на надежность и предсказуемость работы, а не на информационную безопасность, поэтому при реализации защитных мер приходится учитывать эти ограничения.

Для ПЛК рекомендуется реализация следующего комплекса мер:

• Ограничение доступа. Необходимо изменить заводские имена учетных записей и пароли, ограничить возможность подключения к ПЛК от недоверенных источников, например, инженерной станции или сервера архива и обязательно исключить прямой доступ в интернет, отключить неиспользуемые порты.
• Резервное копирование. Рабочие версии конфигураций и проектов рекомендуется хранить на отдельных съемных дисках, отключенных от сети. В случае блокировки ПЛК или шифрования хранилища с проектом его можно будет оперативно восстановить.
• Мониторинг. Регулярный контроль ошибок и аномалий в работе ПЛК позволит своевременно обнаружить сбои и принять меры до полной потери контроля.

Защита на уровне BIOS/UEFI является важным, но часто игнорируемым элементом обеспечения безопасности серверов и АРМ в АСУ ТП. BIOS загружается сразу при включении питания АРМ и отвечает за инициализацию и проверку работоспособности аппаратных компонентов. Компрометация BIOS/UEFI позволяет злоумышленнику получить доступ к системе на уровне, недоступном для обнаружения стандартными средствами защиты операционной системы, и добраться до ядра ОС на этапе ее загрузки. Кроме того, нарушение настроек BIOS/UEFI может привести к несанкционированной загрузке системы с внешних носителей, сбросу аппаратных паролей и изменению критических параметров работы оборудования.

Для BIOS/UEFI рекомендуется реализация следующего набора мер:

• Установка пароля администратора BIOS/UEFI. Позволит предотвратить несанкционированное изменение конфигурации, порядка загрузки и параметров безопасности.
• Запрет загрузки с внешних носителей. Исключает возможность запуска системы с внешнего носителя: USB-флешки или внешнего жесткого диска.
• Отключение неиспользуемых аппаратных интерфейсов. На аппаратном уровне снижает количество потенциальных угроз и исключает возможность подключения несанкционированных устройств. Рекомендуется деактивировать порты, не задействованные в эксплуатации АРМ или сервера: неиспользуемые USB-порты, последовательные (COM) и параллельные (LPT) порты, встроенные аудиоустройства, картридеры и т.д.
• Включение защиты от выполнения кода. Предотвращает выполнение кода в областях памяти, помеченных как неисполняемые.
• Отключение технологии Wake-on-Lan. Позволяет удаленно включить АРМ или вывести его из спящего режима. Если удаленный доступ отсутствует, то эту функцию необходимо отключить.
• Активация Secure Boot (для UEFI). Включает режим безопасной загрузки, предотвращая запуск модифицированного кода на этапе инициализации.
• Отключение функции виртуализации, например AMD-V или Intel-VT. Запрещает использование технологии виртуализации в ОС.

АРМ операторов и сервера SCADA, как правило, функционируют под управлением «голых» операционных систем (ОС), то есть с минимальным набором параметров безопасности.
Помимо удаления всех ненужных и неиспользуемых приложений (Cortana, Xbox, браузеров по умолчанию и т.д.), для усиления защиты ОС рекомендуется выполнить следующие настройки:

• Настроить групповой доступ к компонентам системы. Например, оставить административные права для группы администраторов, а операторов вывести в отдельную группу пользователей, которой будет разрешено запускать только специализированное ПО (СПО), необходимое для производственных задач. Если хватает навыка, то лучше всего настроить режим «киоск». По возможности необходимо персонифицировать учетные записи — присвоить каждой учетной записи уникальное имя, например, oper_ivanov_i. Так будет проще отслеживать действия пользователей и запускаемые ими процессы.
• Переименовать и отключить все стандартные учетные записи пользователей: администратора, гостя, admin, root и т.д.
• Включение парольной политики, которая будет определять сложность пароля при входе в учетную запись. Ранее мы предлагали сделать это на уровне документации, теперь можно сделать на программном уровне. Длина пароля должна быть не менее 12 символов и сочетать буквы разных регистров, цифры и символы.
• Настроить тайм-аут отключения сессии администратора в течение 15 минут простоя.
• Отключить неиспользуемые сетевые службы и протоколы — например, FTP, IPv6, SNMP, если их применение не обосновано технологией;
• Включить встроенный межсетевой экран и в нем закрыть все неиспользуемые порты за исключением тех, которые задействованы в обмене данными с контроллерами и смежными компонентами, механизм поиска этих портов был описан выше.
• Ограничить доступ к общим папкам, если они есть. Как правило, специальное ПО самостоятельно ходит на общедоступный ресурс и забирает с него данные, необходимые для работы. Для таких папок можно оставить доступ только для учетной записи, под которой работает специальное ПО, и администратора. Доступ обычных пользователей должен быть ограничен.

В данном случае к специализированному ПО относятся: SCADA-системы, ПО для создания человеко-машинного интерфейса (HMI), среды разработки для контроллеров, ПО для управления OPC-серверами и прочее ПО, используемое в работе АСУ ТП.

Настройки безопасности СПО необходимо синхронизировать с настройками ОС. Например, для обычных пользователей (операторов) можно включить режим «киоска», в котором будут добавлены ярлыки исключительно необходимого для работы ПО, а все действия в системе будут запрещены. Если в своей работе оператор использует только одно приложение, то рекомендуется настроить его автозапуск при входе в учетную запись и запретить сворачивать его или выключать без разрешения администратора.

Внутри самого СПО, при наличии необходимого функционала, необходимо:

• Включить и настроить парольную политику для запуска СПО и внесения изменений.
• Обеспечить ролевой доступ к управлению и изменению технологического процесса. Необходимо сделать несколько групп пользователей, например, администраторы, технологи и операторы. Административной группе дать полный доступ к управлению системой, технологам — возможность менять уставки и параметры техпроцесса, а операторам — только мониторинг и квитирование ошибок.
• Настроить запрет выхода из СПО для пользовательских учетных записей: при попытке выхода или сворачивании СПО система будет запрашивать пароль администратора, ограничивая доступ к системе.
• Включить журналирование событий безопасности, если такое поддерживается СПО или самим проектом. Это позволит отслеживать, под какой учетной записью выполнялись неудачные попытки входа в систему, несанкционированное изменение проекта и т.д.

К периферийным устройствам можно отнести сетевые принтеры, KVM-консоли, NTP-серверы, ИБП с сетевыми картами и прочие сетевые устройства, которые могут выступать точками входа для злоумышленников.

Для защиты периферийного оборудования стоит применить следующее:

• отключить веб-интерфейс при отсутствии эксплуатационной необходимости;
• удалить или переименовать заводские учетные записи и пароли на всех устройствах с сетевым интерфейсом;
• отключить все неиспользуемые и незащищенные протоколы, например, Telnet, SNMP v1, оставить только актуальные версии;
• отключить все неиспользуемые функции устройства, например, Wi-Fi, Bluetooth, AirPrint.

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

Чтобы оградить производство от большей части базовых угроз необходимо:

1. написать простые и понятные для всех правила информационной гигиены;
2. актуализировать парк своих активов;
3. разделить сеть на сегменты, ограничить удаленный доступ;
4. отключить и заблокировать неиспользуемые порты, протоколы, ПО и т.д.

Дополнительно — несколько рекомендаций, которые помогут избежать проблем при внедрении защиты:

• Проверяйте все изменения и настройки на тестовом оборудовании, которое не имеет прямого влияния на техпроцесс.
• Меняйте настройки безопасности постепенно, это позволит сразу заметить какой параметр пагубно влияет на работоспособность системы.
• Перед реализацией защиты проработайте ролевую модель на бумаге и согласуйте ее с персоналом, непосредственно задействованном на производстве.
• Читайте мануалы разработчиков оборудования и ПО. Любимый инженерный подход «Да тут и без инструкции все понятно» может остановить работу производства на длительный срок.
• Если вы планируете модернизацию производства или его расширение, предусмотрите защиту еще на стадии проекта, чтобы вопросы безопасности не пришлось решать в спешке на этапе внедрения.

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