Защита управляемых коммутаторов для сетей SCADA и DCS
Управляемые коммутаторы могут повысить прозрачность SCADA-системы, не ухудшая детерминированность трафика. В этом руководстве рассматриваются сегментация, безопасное управление, резервирование, вед...
Управляемый Ethernet-коммутатор в сети SCADA или DCS — это больше, чем просто умножитель портов. Он управляет путями передачи трафика, предоставляет диагностическую информацию и может как ограничить, так и усилить последствия ошибки конфигурации.
Цель проектирования — не максимальное использование функций. Это предсказуемая связь, ограниченный доступ к управлению и достаточный объем данных для диагностики отказов без вмешательства в технологический процесс.
Многоуровневая архитектура разделяет управление на полевом уровне, диспетчерские системы, эксплуатацию объекта и обмен данными с корпоративной сетью.
Начните с анализа трафика и последствий
До изменения настроек коммутатора задокументируйте каждый контроллер, HMI, архиватор, инженерную рабочую станцию, шлюз и канал удаленного доступа. Зафиксируйте необходимые протоколы, узлы взаимодействия, частоту обновления, поведение многоадресной рассылки и требования к восстановлению.
Такая инвентаризация превращает сегментацию в инженерное решение. VLAN сама по себе не является границей безопасности, если маршрутизация и правила межсетевого экрана не обеспечивают предусмотренные пути обмена данными.
NIST SP 800-82 Rev. 3 рассматривает безопасность OT с учетом производительности, надежности и безопасности. В рекомендациях CISA также подчеркиваются сегментация и контролируемый обмен данными между критически важными системами и корпоративными сервисами.
Отделите управление от технологического трафика
Разместите интерфейсы управления коммутаторами в выделенной сети управления. Разрешайте доступ только с авторизованных административных узлов через определенные межсетевые экраны или списки управления доступом.
Отключите неиспользуемые службы управления. Если коммутатор их поддерживает, отдавайте предпочтение SSH и HTTPS. Избегайте Telnet и незашифрованного HTTP, поскольку учетные данные и сеансы могут быть перехвачены.
Измените учетные данные по умолчанию, используйте именованные учетные записи и применяйте ролевую модель разрешений. Централизованная аутентификация может повысить подотчетность, но на предприятии также должен быть задокументирован способ восстановления доступа при недоступности службы аутентификации.
Защитите локальный доступ
Доступ через консоль остается важным во время ввода в эксплуатацию и сетевых сбоев. Поэтому физический доступ должен контролироваться, а локальными учетными данными нельзя бесконтрольно делиться.
Сохраненная конфигурация не должна содержать демонстрационные пароли или учетные данные производителя по умолчанию. Храните учетные данные для восстановления в соответствии с утвержденным на объекте процессом управления доступом.
Используйте сегментацию, соответствующую эксплуатации
Группируйте устройства по функциям, последствиям отказа и потребностям в обмене данными. Примеры: ячейки контроллеров, системы защиты, диспетчерские серверы, оборудование, связанное с безопасностью, и доступ для технического обслуживания.
Не создавайте единую плоскую VLAN предприятия только потому, что все устройства используют промышленный Ethernet. В таком случае скомпрометированная рабочая станция или широковещательный шторм могут затронуть оборудование, которому никогда не требовалась прямая связь.
Доступ к VLAN управления должен осуществляться только через утвержденные административные пути.
При наличии протоколов многоадресной рассылки проверьте IGMP Snooping, размещение querier и поведение резервирования. Неправильная архитектура многоадресной рассылки может перегрузить порты или прервать работу ввода-вывода, даже если обычные тесты одноадресной передачи проходят успешно.
Подходящее оборудование для интерфейсов и шлюзов можно найти в коллекции «Связь и сети». Платформы контроллеров собраны в разделе «Системы PLC и PAC».
Проектируйте резервирование как единую систему
Резервные соединения требуют задокументированного протокола и проверенного времени сходимости. Добавление параллельных кабелей без защиты от петель может привести к широковещательному шторму вместо повышения отказоустойчивости.
Проверьте, используется ли в сети Rapid Spanning Tree, кольцевой протокол производителя, Media Redundancy Protocol или другой метод. Подтвердите совместимость всех участвующих коммутаторов.
Проверьте отказ кабеля, потерю питания коммутатора, восстановление заблокированного порта и восстановление после сбоя. Фиксируйте потерю пакетов и поведение контроллеров, а не только заявленное коммутатором время сходимости.
Журналы и синхронизация времени помогают в диагностике
По возможности отправляйте события коммутатора в защищенную систему журналирования. К полезным событиям относятся изменения состояния линий, ошибки аутентификации, изменения конфигурации, переходы топологии и аварийные сигналы питания.
Согласованное время имеет решающее значение. Без синхронизированных часов оператор не сможет надежно сопоставить переход состояния коммутатора с отказами PLC, аварийными сигналами HMI или событиями межсетевого экрана.
SNMP следует настраивать обдуманно. Ограничьте список станций управления и используйте аутентифицированные зашифрованные версии, если они поддерживаются. Не предоставляйте широкий доступ на запись.
Вводите изменения в эксплуатацию без скрытых рисков
Перед началом работ создайте резервную копию текущей конфигурации. Зафиксируйте модель коммутатора, версию встроенного ПО, активную конфигурацию, подключенные порты и способ отката.
Вносите изменения в утвержденное технологическое окно. После каждого существенного шага проверяйте технологический обмен данными, доставку аварийных сигналов, обновление архиватора, резервирование, удаленный доступ и синхронизацию времени.
Обновления встроенного ПО требуют такой же дисциплины, как и изменения в контроллерах. Изучите уведомления производителя, протестируйте целевую версию в лаборатории и убедитесь в наличии образа для восстановления.
Мнение автора: управляемые коммутаторы приносят пользу, когда их конфигурация понятна и допускает восстановление. Сложная архитектура без ответственных лиц, резервных копий и проверенного поведения при отказах сложнее в эксплуатации, чем более простая задокументированная сеть.