Как построить промышленную DMZ для безопасной конвергенции OT и IT в Azure
By Mirko Peters ·
Узнайте, как построить безопасную промышленную DMZ для конвергенции OT и IT в Azure. Защитите производственные линии, сегментируйте сети и безопасно подключайте ПЛК уже сегодня.
Automatically translated with AI from the original post. Read the English original

Проектирование промышленной DMZ (IDMZ) необходимо для безопасной конвергенции OT и IT в Azure. В этом руководстве рассматривается, как создать защищённые сетевые границы, внедрить надлежащие буферные зоны и изолировать архитектуры операционных технологий, не подвергая программируемые логические контроллеры (ПЛК) корпоративным рискам и простоям производства.
Главное
- Промышленная DMZ (IDMZ) выступает критически важной буферной сетевой зоной, которая находится между операционными технологиями (OT) и корпоративными IT-системами.
- Физическое расстояние не равно зоне безопасности: оборудование необходимо группировать по производственным функциям, степени риска и уровням доверия.
- Инициирование исходящих сеансов со стороны производства помогает избежать необходимости в рискованных входящих прослушивающих службах со стороны корпоративной или облачной среды.
- Одних VLAN недостаточно для сетевой безопасности без строгого маршрутизируемого межсетевого экрана, который блокирует несанкционированное горизонтальное перемещение.
- Общая инфраструктура коммутаторов создаёт скрытые физические зависимости, которые необходимо выявить до запуска любого облачного проекта по данным.
Роль промышленной DMZ в архитектуре Azure
При подключении производственного оборудования к Microsoft Azure для телеметрии, анализа производительности или машинного обучения организации сталкиваются с серьёзной архитектурной задачей: как передавать ценные производственные данные наверх, не открывая опасных сетевых путей вниз. Традиционных правил IT-межсетевого экрана недостаточно для промышленной среды, поскольку скомпрометированная корпоративная учётная запись теоретически может пройти по плоской сети прямо к контроллеру линии.
Именно здесь промышленная DMZ становится обязательной. IDMZ служит строго контролируемой буферной зоной между производственной и корпоративной сетями. Вместо того чтобы разрешать сервисам Azure или корпоративным приложениям напрямую опрашивать контроллеры оборудования, сервисы на стороне производства передают в IDMZ утверждённые, агрегированные данные. Оттуда корпоративные или облачные системы забирают данные из буфера, не обращаясь к уровню управления.
Соблюдая такое архитектурное разделение, вы гарантируете, что при сбое корпоративной базы данных или подключения к Azure управляющее оборудование останется полностью работоспособным. IDMZ принимает на себя риски, сохраняя производственный процесс полностью изолированным от сбоев, зависящих от облака.
Определение зон по производственным функциям, а не по подразделениям
Распространённая ошибка при интеграции с облаком — группировать устройства в сетевые зоны по физической близости или по принадлежности к подразделению. Компьютер, стоящий в одном шкафу с ПЛК наполнителя, автоматически не относится к зоне безопасности наполнителя. Доверие должно зарабатываться и определяться функциональным поведением.
Эффективное проектирование зон требует оценки того, что произойдёт, если подключённая система выйдет из строя или будет скомпрометирована. Граница зоны должна ограничивать то, насколько далеко может распространиться проблема по разрешённым сетевым соединениям. Рассмотрим производственную линию упаковки со старыми дозаторами, новыми этикетировочными машинами и упаковщиками на выходе. Хотя эти машины работают с общим физическим потоком продукции, им не нужна общая плоская сетевая зона с широкими разрешениями.
Установление границ доверия
Внутри определённой зоны администраторы допускают определённый уровень взаимодействия в зависимости от текущих задач этих систем. Ключевые стратегии для надёжного проектирования зон включают:
- Ограничение области зоны, чтобы вся производственная линия упаковки не превращалась в одну огромную поверхность атаки.
- Обязательное документирование каждого пересечения зон с указанием источника, назначения и точного разрешённого протокола.
- Запрет широких правил вроде «доступ к производству» в пользу точечных правил взаимодействия «сервис — сервис».
- Обеспечение того, чтобы целевые сервисы учитывали границы и не предоставляли общий доступ ко всему предприятию по умолчанию.
Сегментация VLAN и маршрутизируемый контроль на межсетевом экране
Виртуальные локальные сети (VLAN) часто применяются для разделения корпоративного и промышленного трафика в рамках общих коммутаторов. Однако простое размещение оборудования в отдельных VLAN не гарантирует безопасность.
Когда трафик перемещается между VLAN, безопасность полностью зависит от того, как организована маршрутизация. Если внутреннее сетевое устройство маршрутизирует трафик между промышленными VLAN без строгого контроля со стороны stateful-межсетевого экрана, трафик легко может обойти заданные защитные периметры. Более того, логическое разделение на одном физическом коммутаторе не устраняет зависимости от физического оборудования. Если общий коммутатор выйдет из строя, обе зоны перестанут работать одновременно.
Настоящая сегментация сети требует выделенных stateful-межсетевых экранов, расположенных строго между VLAN и зонами. Эти межсетевые экраны должны проверять параметры сеансов, контролировать разрешённые операции (например, блокировать команды записи на пути, предназначенном только для телеметрии) и гарантировать, что даже при установленном разрешённом соединении базовые правила протокола не могут быть использованы для отправки несанкционированных команд управления оборудованием.
Управление направлением сеансов и исходящим трафиком
Направление соединений является основополагающим принципом безопасной промышленной облачной архитектуры. По возможности сервисы на стороне производственной площадки должны инициировать исходящие сеансы к IDMZ или Azure. Такой подход позволяет удалённым системам не нуждаться во входящем прослушивающем сервисе на стороне площадки, фактически исключая внешние незапрошенные попытки подключения.
Однако администраторы должны внимательно проверять, что происходит после установления исходящего сеанса. Stateful-межсетевые экраны по своей сути разрешают обратный трафик для разрешённых соединений, а значит, удалённая площадка может передавать данные обратно по тому же каналу. Владельцы программного обеспечения должны подтвердить, что их сервисы отклоняют нежелательные полезные данные, изменения конфигурации и скрытые пути выполнения команд, замаскированные под обычные ответы сервера.
Учётные данные аутентификации должны отражать это строгое разделение. Учётная запись, используемая для сбора записей об остановках только для чтения, никогда не должна иметь разрешений на изменение рецептур оборудования, корректировку логики управления или загрузку обновлений прошивки. Применение принципа наименьших привилегий как на уровне прикладного сервиса, так и на интерфейсе шлюза гарантирует, что даже при краже учётных данных зона возможного ущерба останется жёстко ограниченной.
Заключение
Успешное объединение операционных технологий с Azure требует тщательного внимания к сетевым границам, чётко определённым зонам и надёжным буферам промышленной DMZ. Ставя непрерывность производства выше административного удобства, команды IT и OT могут безопасно получать ценные данные с производственного участка, никогда не рискуя работой действующего производства.
Для более подробного обсуждения архитектурных шаблонов, безопасных границ данных и подключения оборудования без остановки производства обязательно послушайте полный выпуск подкаста M365 FM Podcast.
Часто задаваемые вопросы
Что такое промышленная DMZ в контексте объединения OT и IT в Azure?
Промышленная DMZ (IDMZ) — это выделенная буферная сетевая зона, которая находится между операционными технологиями производственного участка и корпоративной IT-инфраструктурой или облачными средами, такими как Azure. Она размещает промежуточные сервисы, чтобы компрометация или сбой в корпоративной сети не могли напрямую повлиять на программируемые логические контроллеры (PLC) на производственной линии или достичь их.
Почему VLAN недостаточно для защиты сетей OT, подключённых к Azure?
VLAN логически разделяют трафик в коммутируемой сети, но сами по себе не применяют политики безопасности. Без маршрутизируемого межсетевого экрана между VLAN трафик легко может обойти заданные границы. Кроме того, общие физические коммутаторы под VLAN по-прежнему остаются единой точкой отказа как для ИТ-, так и для OT-активов.
Должны ли службы на стороне производственной площадки инициировать исходящие подключения к Azure?
Да. Инициирование исходящих сеансов службами на стороне производственной площадки — это рекомендуемая практика, поскольку она позволяет не открывать на стороне производства рискованные входящие прослушиваемые службы. Однако специалисты по безопасности должны проверять конечные точки назначения и ограничивать исходящий трафик, чтобы узлы сбора не могли свободно обращаться к произвольным адресам в интернете.
Как правильно определить зоны безопасности для производственных линий упаковки?
Зоны безопасности следует выстраивать вокруг производственных функций и общих рисков, а не по планировке помещений или названиям подразделений. Оборудование относится к одной зоне, если выполняет связанные задачи, требует одинакового уровня защиты и имеет общее оценённое последствие отказа, которое предприятие явно одобрило.