В кибербезопасности АСУ ТП легко улететь слишком высоко: зоны, кондуиты, SOC, SIEM, политики, зрелость, аудит. Все это важно, но на объекте часто проблема начинается ниже - у конкретного ПЛК в шкафу. Кто знает пароль? Кто может загрузить проект? С какого ноутбука подключаются? Через какой порт? Где лежит резервная копия? Почему сервисный Ethernet все еще торчит в общей сети? Что будет, если подрядчик подключится «на пять минут»?
Ошибка начинается с фразы «ПЛК же не в интернете». Может быть, не в интернете. Но к нему подключается инженерный ноутбук, его видит SCADA, к нему иногда дают удаленный доступ, его проект лежит на рабочем ПК, прошивку обновляют с флешки, а сервисный порт вспоминают только на пуске. Нижний уровень редко выглядит как драматичная атака. Чаще это цепочка бытовых решений, которые постепенно делают контроллер слишком доступным.
Эта статья не заменяет IEC 62443 и не дублирует тему OT SOC. В статье «IEC 62443 на практике» мы уже разбирали зоны, кондуиты и стартовые меры для цеха. Здесь говорим проще: что реально может сделать малая служба АСУ ТП вокруг ПЛК, чтобы снизить риск без огромного проекта.
ПЛК защищают не потому, что он «секретный»
ПЛК защищают потому, что он управляет реальным процессом. Для бизнеса важна не романтика кибератаки, а последствия: линия стоит, насос запускается не в том режиме, уставка меняется без следа, проект потерян, диагностика недоступна, восстановление занимает ночь вместо часа.
На нижнем уровне есть несколько вещей, которые особенно чувствительны. Во-первых, проект ПЛК: в нем логика, адреса, связи, иногда технологические ноу-хау. Во-вторых, доступ к загрузке и онлайн-изменениям. В-третьих, сетевые настройки и сервисные интерфейсы. В-четвертых, инженерная станция, через которую все это обслуживают. В-пятых, резервная копия, без которой любой инцидент становится длинным восстановлением.
Если эти элементы не управляются, даже хороший сетевой периметр не спасает. Можно построить красивую сегментацию, но оставить общий инженерный пароль на контроллере. Можно закрыть удаленку, но подключать к ПЛК ноутбук, который вчера был в гостиничном Wi-Fi. Можно делать бэкапы, но хранить только старую версию проекта без библиотек и прошивки.
Пользователи и пароли: начать с того, кто вообще может менять ПЛК
Первый практический вопрос: кто имеет право подключаться к ПЛК и что именно он может делать. Оператору не нужен доступ к загрузке проекта. Дежурному инженеру может быть нужна диагностика и просмотр статусов. Разработчику нужна возможность менять проект, но не постоянно и не без фиксации. Подрядчику доступ нужен только на конкретную задачу и на ограниченное время.
Общий пароль кажется удобным, пока ничего не случилось. После инцидента он превращает журнал в бесполезную фразу «кто-то вошел». Поэтому даже на небольшом объекте стоит разделить хотя бы базовые роли: просмотр, наладка, изменение проекта, администрирование. Если платформа не дает тонкой RBAC-модели на самом контроллере, границы переносят на инженерную станцию, удаленный доступ, хранение проекта и процедуру допуска.
Подробно про роли и запрет общих паролей есть отдельная статья «RBAC в АСУ ТП». Для ПЛК главный вывод простой: нельзя потом требовать точного расследования, если все подключались под одним именем и одним паролем.
Проект ПЛК - это актив, а не просто файл
Проект контроллера часто живет странной жизнью. Одна версия на ноутбуке наладчика, другая на сервере, третья в письме подрядчика, четвертая загружена в ПЛК после ночной правки. В такой ситуации кибербезопасность и эксплуатационная надежность сходятся в одной точке: никто не знает, какая версия является настоящей.
Проект нужно защищать как инженерный актив. У него должна быть версия, владелец, место хранения, история изменений и понятная процедура выдачи. Нельзя хранить его только на ноутбуке одного сотрудника. Нельзя отправлять полный архив кому попало «для консультации». Нельзя загружать изменения в рабочий ПЛК без резервной копии текущего состояния и записи, что менялось.
Это не про бюрократию. Если проект украден, поврежден или потерян, объект теряет управляемость. Если проект подменен, команда может долго искать ошибку в железе. Если проект устарел, восстановление после замены контроллера превращается в угадывание.
Удаленный доступ: не прямая дорога к контроллеру
Удаленный доступ нужен. Подрядчики поддерживают редкое оборудование, инженеры помогают на пуске, иногда нужно быстро посмотреть состояние без выезда. Но доступ к ПЛК не должен выглядеть как VPN «во всю подсеть». Подрядчик не должен видеть все контроллеры цеха только потому, что ему нужно проверить один узел.
Нормальная схема для малой службы АСУ ТП: доступ выдается по заявке, на окно работ, через согласованную точку входа, с журналом действий и ограничением по нужным адресам. Если есть возможность использовать jump host, MFA и запись сессии - это уже большой шаг вперед. Если такой инфраструктуры нет, минимум все равно остается: отдельная учетная запись, ограниченный срок, список разрешенных узлов, сопровождение работ и отзыв доступа после завершения.
В статье «Кибербезопасная удаленка для подрядчиков в OT» это разобрано шире. Для нижнего уровня важно помнить: удаленка заканчивается не на VPN. Она заканчивается там, где человек получает возможность читать, менять или загружать проект ПЛК.
Сеть: ПЛК не должен видеть больше, чем нужно
Для ПЛК вредна плоская сеть, где все видят всех. Контроллеру обычно нужны конкретные связи: SCADA или HMI, соседние устройства, шлюз, инженерная станция в окне обслуживания, иногда сервер времени или historian через промежуточный уровень. Ему не нужен доступ к офисной сети целиком, камерам, гостевому Wi-Fi, интернету или чужим участкам без причины.
Малая служба АСУ ТП не всегда может сразу построить идеальную сегментацию. Но она может сделать базовые вещи: знать IP-адреса контроллеров, убрать случайные патч-корды, не подключать инженерный порт к общей сети, согласовать список разрешенных обменов, запретить маршруты «для удобства» и держать схему сети актуальной. Если есть управляемый коммутатор или межсетевой экран, правила должны быть короткими и понятными: кто к кому и зачем.
Хороший вопрос на приемке: можно ли с обычного офисного ноутбука увидеть ПЛК? Если да, это не всегда значит немедленную катастрофу, но точно значит, что радиус риска слишком большой.
Прошивка: обновлять не всегда быстро, но всегда осознанно
Прошивка ПЛК - тонкая тема. В IT привыкли к частым обновлениям, в OT каждое обновление должно проходить через окно работ, тест и план отката. Но это не значит, что прошивки можно игнорировать годами. В старых версиях могут быть ошибки, уязвимости, несовместимости с новыми библиотеками и проблемы восстановления.
Практичный подход: вести реестр версий прошивок, знать, где взять установочные пакеты, хранить их вместе с проектом и бэкапом, заранее читать release notes, тестировать обновление на стенде или резервном устройстве, фиксировать результат. Если обновление откладывается, это должно быть осознанное исключение, а не «никто не помнит, какая там версия».
Главное - не обновлять ПЛК на рабочем объекте как обычную программу на ноутбуке. Перед прошивкой нужны резервная копия, окно работ, план отката и человек, который понимает последствия.
Резервная копия: защита от киберинцидента тоже начинается с восстановления
Когда говорят про кибербезопасность, часто забывают простую вещь: если контроллер нужно срочно восстановить, бэкап важнее красивой политики. Без рабочей резервной копии любое повреждение проекта, ошибка загрузки, сбой носителя или неудачное обновление превращаются в долгий простой.
Полный комплект для восстановления ПЛК - это не только файл проекта. Нужны версия среды разработки, библиотеки, target-пакеты или device descriptions, прошивка, сетевые настройки, карта I/O, параметры связи, описание учетных записей без открытых паролей, инструкция загрузки и проверочный сценарий. И главное - бэкап нужно хотя бы иногда восстанавливать на изолированном стенде.
Подробный разбор есть в статье «Резервное копирование и восстановление ПЛК/SCADA». Для этой темы вывод короткий: защита ПЛК без проверенного восстановления остается надеждой.
Инженерный ноутбук: самый недооцененный путь к ПЛК
Нижний уровень часто защищают вокруг шкафа, но забывают про ноутбук. А именно он подключается к контроллеру, хранит проекты, библиотеки, драйверы, пароли к стендам, VPN-профили, старые архивы и утилиты. Если инженерный ноутбук заражен или используется как обычный бытовой компьютер, ПЛК получает риск через сервисный кабель.
Реалистичный минимум: отдельная инженерная машина или хотя бы отдельный профиль для OT-работ, обновленный антивирус или контроль приложений по политике предприятия, запрет случайных флешек, шифрование диска, учет подключений к объектам, хранение проектов в репозитории или архиве, а не только на рабочем столе. Для подрядчиков - отдельное правило: нельзя подключать непроверенное устройство напрямую к нижнему уровню без согласования.
Это не паранойя. Это признание факта: инженерный ноутбук часто является мостом между внешним миром и контроллером.
Сервисный порт: маленький разъем с большими последствиями
USB, Ethernet, mini-USB, сервисный разъем на двери шкафа, временная розетка в щите - все это нужно для обслуживания. Но сервисный порт должен иметь статус. Он не должен быть непонятной дырой, куда можно подключиться без учета.
Минимальные вопросы простые. Где расположен порт? Подписан ли он? Кто имеет физический доступ? Подключен ли он постоянно к сети или только на время работ? Видит ли через него ПЛК всю производственную сеть? Нужно ли закрывать порт заглушкой, ключом, шкафом или регламентом? Фиксируется ли факт подключения?
Физическая безопасность здесь не менее важна, чем сетевые правила. Если любой человек у шкафа может подключить ноутбук к сервисному порту, пароль на SCADA уже не выглядит достаточной защитой.
Чек-лист: 10 минимальных мер для ПЛК
Этот чек-лист не делает объект «сертифицированным». Он закрывает самые частые дыры, которые малая служба АСУ ТП реально может контролировать без большого бюджета.
Что не стоит делать
Не стоит начинать с запрета всего подряд. Если инженеру нужно каждый день обслуживать линию, он найдет обходной путь. Не стоит переносить офисные правила без адаптации: агрессивные обновления, случайные перезагрузки и блокировки портов могут остановить производство. Не стоит хранить пароли в проекте, в названии файла или на листке внутри шкафа. Не стоит давать подрядчику постоянный доступ «чтобы потом не дергать ИБ».
И еще одно: не стоит считать безопасность отдельной задачей ИБ. На нижнем уровне владелец риска всегда рядом с производством. ИБ может дать методику, сеть может дать ограничения, но инженер АСУ ТП знает, какой ПЛК за что отвечает и что сломается при неправильном действии.
Итог
ПЛК в контуре кибербезопасности - это не абстрактный актив в таблице. Это контроллер, к которому кто-то подключается, который кто-то прошивает, чей проект где-то хранится и который управляет реальным процессом. Поэтому защищать нужно не только сеть вокруг него, но и пользователей, пароли, проект, удаленный доступ, прошивки, резервные копии, инженерный ноутбук и сервисные порты.
Для малой службы АСУ ТП разумный старт - не большой SOC, а дисциплина нижнего уровня: знать, кто может подключиться, по какому пути, с какого устройства, что он может изменить и как объект вернется в работу после ошибки. Это уже кибербезопасность, только без громких слов.
Обсуждение