OT/IT конвергенция как организационная задача: Роли, зоны ответственности и типовые конфликты
2026-05-07 14:08
Технически «соединить цех с офисом» можно за выходные. Организационно это занимает годы: пока не ясно, кто меняет VLAN на коммутаторе у линии, кто ставит патч на SCADA-сервер и кто ночью отвечает за восстановление, любая конвергенция превращается в бесконечный спор на совещаниях.
Материал ниже про людей и регламенты, а не про очередной новый коммутатор.
Короткий ответ
Конвергенция без модели ответственности ломается на первом же инциденте.
Нужна явная матрица: что относится к OT (технологический контур и его доступность), что к IT (учётные записи, домен, резервное копирование централизованных служб), что к shared (точки, где без совместного SLA не обойтись).
Регламент должен назначать владельца сервиса, владельца платформы и процесс эскалации, иначе вы получите двух администраторов и ноль решений.
В OT привыкли мыслить объектами: линия, узел, проект ПЛК.
В IT мыслят сервисами и политиками: домен, антивирус, патчи, мониторинг.
Конвергенция сталкивает два языка. Если не перевести их на один документ с ролями, конфликт неизбежен.
Типичный симптом: «IT говорит, что всё под контролем, а цех вчера простоял из-за того, что политика антивируса перехватила проектный файл». Обе стороны правы в своей логике и обе неправы без общего регламента.
Кто отвечает за сеть в цеху
На практике встречаются три модели:
1.OT владеет сегментами технологической сети end-to-end. IT помогает централизованно закупкой и мониторингом магистралей, но не трогает ACL без согласования.
2.IT владеет транспортом, OT владеет приложениями. Коммутаторы на линии администрирует IT по шаблонам, изменения на портах OT согласует через заявку.
3.Выделенная команда заводской инфраструктуры (Plant IT). Отдельная группа с двойной отчётностью и явным SLA по OT.
Нет универсально правильного варианта.
Есть правильный для вашего масштаба и культуры. Неправильно одно - когда никто формально не владеет портами у шкафа автоматики.
SCADA-сервера: зона серых споров
SCADA-сервер одновременно похож на сервер приложений и на технологический актив.
Разделение часто такое:
•OT отвечает за приложение SCADA, версию проекта, интеграцию с ПЛК, окна работ и допуск изменений по процессу.
•IT отвечает за ОС как платформу (если она в домене), антивирусную политику, резервное копирование инфраструктуры, допуск к ЦОД и мониторинг железа - по договорённости.
•Shared отвечает за совместные решения: патчи ОС, которые ломают драйверы; обновление .NET; права администратора; подключение к SIEM.
Если это не записано, каждый патч превращается в спектакль.
Типовые конфликты при инцидентах
«Это сеть» против «это приложение». Пока не зафиксирован набор метрик и точка наблюдения, спор бесконечен.
«Мы не можем трогать антивирус» против «без сканирования ИБ не подпишет». Нужны исключения с обоснованием и пересмотром раз в квартал.
«Дайте доменную учётку всем подрядчикам» против «zero trust». Решение через временные учётки, bastion и запись сессий.
«Поставили мониторинг без согласования и положили OPC». Любой новый сборщик метрик в OT - изменение с риском.
Модели операционного взаимодействия
Runbooks на два голоса. Один документ: симптомы, первые проверки OT, первые проверки IT, критерий передачи эскалации.
Совместное окно изменений. OT заводит окно по процессу, IT встраивает своё обслуживание, конфликты разруливаются заранее.
Единый канал инцидентов с классификацией. «Технология остановлена» и «офис медленный» - разные очереди и разные KPI.
Квартальный пересмотр матрицы RACI. Оргструктура меняется быстрее, чем схема сети.
Как оформить регламентом минимально достаточный пакет
•матрица ответственности по функциям (ниже - основа);
Без последнего пункта регламент остаётся PDF для аудита, а не рабочим инструментом.
Таблица: функция - зона OT / IT / shared и типовое распределение
Функция
OT
IT
Shared (совместно)
Логика ПЛК, версии проекта, FAT/SAT
владелец
наблюдатель по запросу
согласование окон и доступов
SCADA-проект, графика, теги, связь с ПЛК
владелец приложения
поддержка платформы по договору
патчи ОС, права admin, антивирусные исключения
Historian, качество архива данных
владелец данных процесса
эксплуатация ВМ/СХД часто у IT
резервное копирование и восстановление end-to-end
Коммутаторы и VLAN у линии
часто владелец в модели OT-centric
часто владелец в модели IT-centric
изменения ACL и мониторинг портов
Active Directory, учётки, MFA
потребитель политики
владелец
исключения для OT-сервисных учёток
Сертификаты, PKI, обновление ЦОД
конечные точки в OT
инфраструктура PKI
сроки и процедура перевыпуска без простоя
Централизованный мониторинг и SIEM
источник событий и фильтрация шума
платформа и корреляция
контракт наполнения и чувствительность данных
Инцидент кибербезопасности в OT
первичная классификация воздействия на процесс
стандартные процедуры ИБ
единый war-room и коммуникации
В колонке shared ключевая идея проста: если без двух сторон решение невозможно или опасно, функция не может быть «чисто OT» или «чисто IT».
Где уместен СТАБУР
В проектах на базе СТАБУР технический контур уже предполагает дисциплину изменений. Организационная конвергенция усиливает этот эффект: меньше конфликтов на инцидентах, быстрее возврат линии в работу, понятнее ответственность при аудитах и при расширении интеграций.
Заключение
OT/IT конвергенция не заканчивается прокладкой кабеля.
Она заканчивается тогда, когда у завода есть общая картина: кто владелец технологического сервиса, кто платформы, как принимаются изменения и как эскалируется инцидент.
Без этого «цифровизация» добавляет только новые поводы для ссор между цехом и ИТ-департаментом.
FAQ
Нужно ли заводить отдельную должность «Plant IT»?
Не всегда, но на средних и крупных объектах это часто окупается снижением времени простоя.
Как уменьшить трение между OT и ИБ?
Через предсогласованные исключения, тестовый контур и измеримые KPI инцидентов, а не через запреты «на всякий случай».
Кто должен подписывать изменение VLAN у линии?
Тот, кто формально владеет политикой сегментации по регламенту, с участием OT как владельца процесса.
Можно ли отдать SCADA полностью в IT?
Можно по модели сервиса, если OT сохраняет владение приложением и процессом изменений.
Что делать, если регламент есть, но его не читают?
Свести к одной странице «кто звонить ночью» и провести учение. Длинный PDF без практики не работает.