Чому VLAN недостатньо для захисту мереж OT, які підключаються до Azure?

VLAN логічно розділяють трафік у комутованій мережі, але самі по собі не забезпечують виконання політик безпеки. Без маршрутизованого забезпечення роботи брандмауера між VLAN трафік легко обходить задумані межі. Крім того, спільні фізичні комутатори під VLAN залишаються єдиною точкою відмови як для IT, так і для OT-активів.

Чи мають сервіси на боці виробництва ініціювати вихідні з'єднання до Azure?

Так. Ініціювання вихідних сесій сервісами на боці виробничого майданчика є найкращою практикою, адже це дозволяє не відкривати ризикові вхідні служби прослуховування на боці виробництва. Водночас команди безпеки мають перевіряти кінцеві точки призначення та обмежувати вихідний трафік, щоб хости збору даних не могли вільно звертатися до довільних адрес в інтернеті.

Як побудувати промислову DMZ для безпечної конвергенції OT та IT в Azure

Q: Що таке промислова DMZ у контексті конвергенції OT та IT в Azure?

Промислова DMZ (IDMZ) — це окрема буферна мережева зона між операційними технологіями (OT) на виробничому майданчику та корпоративними IT-середовищами або хмарою, зокрема Azure. Вона містить проміжні сервіси, які гарантують, що компрометація чи збій у корпоративній мережі не зможуть безпосередньо вплинути на програмовані логічні контролери (PLC) на виробничій лінії або дотягнутися до них.

By Mirko Peters · 2026-10-27

Дізнайтеся, як побудувати безпечну промислову DMZ для конвергенції OT та IT в Azure. Захистіть виробничі лінії, сегментуйте мережі та безпечно підключіть PLC вже сьогодні.

Automatically translated with AI from the original post. Read the English original

Cover: OT-IT Convergence on Azure: Connecting PLCs Without Breaking Production

Проєктування промислової DMZ (IDMZ) є необхідним кроком для безпечної конвергенції OT та IT в Azure. У цьому посібнику розглянуто, як створити безпечні мережеві межі, впровадити належні буферні зони та ізолювати архітектури операційних технологій, не піддаючи програмовані логічні контролери (PLC) ризикам корпоративної мережі чи простоям виробництва.

Головне

Промислова DMZ (IDMZ) є критично важливою буферною мережевою зоною між операційними технологіями (OT) і корпоративними IT-системами.
Фізична відстань не є зоною безпеки: обладнання слід групувати за виробничими функціями, рівнем ризику впливу та рівнем довіри.
Ініціювання вихідних сесій з боку виробництва допомагає уникнути потреби в ризикових вхідних службах прослуховування з боку корпоративного або хмарного середовища.
Самих лише VLAN недостатньо для безпеки мережі без суворого маршрутизованого забезпечення роботи брандмауера, який блокує несанкціоноване бічне переміщення.
Спільна комутаторна інфраструктура створює приховані фізичні залежності, які слід задокументувати до запуску будь-якого хмарного проєкту з даними.

Роль промислової DMZ в архітектурі Azure

Під час підключення виробничого обладнання до Microsoft Azure для телеметрії, аналітики продуктивності чи машинного навчання організації стикаються з серйозним архітектурним викликом: як передавати цінні виробничі дані нагору, не відкриваючи небезпечних мережевих шляхів униз. Традиційні правила IT-брандмауера абсолютно непридатні для промислових середовищ, адже скомпрометований корпоративний обліковий запис теоретично може пройти плоскими мережами прямо до контролера лінії.

Тут промислова DMZ стає обов'язковою. IDMZ слугує суворо контрольованою буферною зоною між виробничою та корпоративною мережею. Замість того, щоб дозволяти сервісам Azure або корпоративним застосункам напряму звертатися до контролерів машин, сервіси на боці виробництва передають схвалені, агреговані дані до IDMZ. Звідси корпоративні або хмарні системи споживають дані з буфера, не торкаючись площини керування.

Завдяки такому архітектурному розділенню ви гарантуєте, що у разі проблем із корпоративною базою даних або підключенням до Azure промислове обладнання залишиться повністю незачепленим. IDMZ поглинає вплив і повністю ізолює виробничий процес від збоїв, пов'язаних із хмарою.

Визначення зон за виробничими функціями, а не за відділами

Поширена помилка під час проєктів інтеграції з хмарою полягає в групуванні пристроїв у мережеві зони за фізичною близькістю або належністю до відділу. Комп'ютер, що стоїть в одній шафі з PLC наповнювача, автоматично не належить до зони безпеки наповнювача. Довіру слід заслужити й визначати за функціональною поведінкою.

Ефективне проєктування зон вимагає оцінки того, що станеться, якщо підключена система вийде з ладу або буде скомпрометована. Межа зони має обмежувати, наскільки далеко ця проблема може поширитися через дозволені мережеві з'єднання. Розглянемо лінію пакування зі старими наповнювачами, новішими етикетувальниками та пакувальниками на завершальному етапі. Хоча ці машини поділяють фізичний потік продукції, їм не потрібна спільна плоска, пермісивна мережева зона.

Встановлення довірчих меж

У межах визначеної зони адміністратори допускають певний рівень комунікації відповідно до поточних функцій цих систем. Ключові стратегії для надійного проєктування зон включають:

Обмеження області зони, щоб уся лінія пакування не стала однією великою поверхнею атаки.
Вимога явної документації для кожного перетину зон із зазначенням джерела, призначення та точного дозволеного протоколу.
Заборона широких правил на кшталт «доступ до виробництва» на користь точково спрямованих правил між сервісами.
Гарантування того, що цільові сервіси розпізнають межі і не надають загального доступу до всього заводу за замовчуванням.

Сегментація VLAN проти примусової фільтрації на маршрутизаторі

Віртуальні локальні мережі (VLAN) часто розгортають, щоб розділити корпоративний і промисловий трафік у межах спільних комутаторів. Однак саме по собі розміщення обладнання в окремих VLAN не гарантує безпеки.

Коли трафік рухається між VLAN, безпека цілком залежить від того, як організовано маршрутизацію. Якщо внутрішній мережевий пристрій маршрутизує трафік між промисловими VLAN без суворого контролю з боку stateful-брандмауера, трафік може легко обійти задумані периметри безпеки. Крім того, логічне розділення на одному фізичному комутаторі не усуває залежності від фізичного обладнання. Якщо цей спільний комутатор вийде з ладу, обидві зони одночасно перестануть працювати.

Справжня сегментація мережі вимагає виділених stateful-брандмауерів, розташованих строго між VLAN і зонами. Ці брандмауери мають перевіряти параметри сесій, підтверджувати дозволені операції (наприклад, блокувати команди запису на шляху, призначеному лише для телеметрії) і гарантувати, що навіть коли дозволене з'єднання встановлено, правила базового протоколу не можна використати для видачі несанкціонованих команд машинам.

Керування напрямком сесій і вихідним трафіком

Напрямок з'єднань є фундаментальною опорою безпечної промислової хмарної архітектури. Де це можливо, сервіси на майданчику заводу мають ініціювати вихідні сесії до IDMZ або Azure. Цей шаблон проєктування не дозволяє віддаленим системам вимагати вхідного сервісу, що прослуховує з боку заводу, фактично усуваючи зовнішні небажані спроби з'єднання.

Однак адміністраторам слід уважно перевіряти, що відбувається після встановлення вихідної сесії. Stateful-брандмауери природно дозволяють зворотний трафік для дозволених з'єднань, тобто віддалений майданчик може надсилати дані назад тим самим каналом. Власники програмного забезпечення мають довести, що їхні сервіси відхиляють небажані корисні навантаження, зміни конфігурації або приховані шляхи виконання команд, замасковані під звичайні відповіді сервера.

Облікові дані автентифікації мають відображати це суворе розділення. Обліковий запис, який використовується для збору лише читаних записів про зупинки, ніколи не повинен мати дозволів на зміну рецептур машин, коригування логіки керування або завантаження оновлень прошивки. Дотримання принципу найменших привілеїв як на рівні прикладного застосунку, так і на інтерфейсі шлюзу гарантує, що навіть у разі крадіжки облікових даних зона ураження залишиться щільно обмеженою.

Висновок

Успішне поєднання операційних технологій з Azure вимагає ретельної уваги до мережевих меж, чітких визначень зон і надійних буферів промислової DMZ. Ставлячи безперервність виробництва вище адміністративної зручності, команди ІТ та OT можуть безпечно отримувати цінні дані з виробничого цеху, не ризикуючи жодного разу працездатністю реального виробництва.

Щоб детально розібратися з архітектурними шаблонами, безпечними межами даних і підключенням обладнання без порушення виробництва, обов'язково послухайте повний епізод подкасту M365 FM.

Поширені запитання

Що таке промислова DMZ в контексті конвергенції OT і IT в Azure?

Промислова DMZ (IDMZ) — це окрема мережева буферна зона, розташована між операційними технологіями виробничого цеху та корпоративним IT-середовищем або хмарним середовищем на кшталт Azure. Вона містить проміжні сервіси, які гарантують, що збій або компрометація корпоративної мережі не можуть безпосередньо вплинути на програмовані логічні контролери (PLC) на виробничій лінії або досягти їх.

Чому VLAN недостатньо для захисту OT-мереж, що підключаються до Azure?

VLAN логічно розділяють трафік у комутованій мережі, але самі по собі не забезпечують виконання політик безпеки. Без маршрутизованого забезпечення роботи міжмережевого екрана між VLAN трафік легко може обійти задані межі. Крім того, спільні фізичні комутатори під VLAN залишаються єдиною точкою відмови як для ІТ-, так і для OT-активів.

Чи мають сервіси на боці заводу ініціювати вихідні з'єднання до Azure?

Так. Ініціювання вихідних сеансів сервісами на боці заводу є найкращою практикою, адже це дозволяє не відкривати ризикованих служб прослуховування вхідних з'єднань на боці заводу. Втім, команди безпеки мають перевіряти кінцеві точки призначення та обмежувати вихідний трафік, щоб вузли збору даних не могли вільно звертатися до довільних адрес в інтернеті.

Як правильно визначити зони безпеки для виробничих ліній пакування?

Зони безпеки слід окреслювати за виробничими функціями та спільними ризиками, а не за фізичним розташуванням приміщень чи назвами підрозділів. Обладнання належить до однієї зони, якщо воно виконує пов'язані роботи, потребує однакового рівня захисту та має спільні наслідки відмови, які було оцінено і які завод явно схвалив.