<WRAP doku>

====== Интеграция и подключение промышленных систем (OT) ======
<WRAP box round>
OT-системы (электроснабжение, охлаждение, безопасность) образуют базовый слой ЦОД, на котором работают IT-сети и сервисы. Цель раздела — зафиксировать принципы интеграции OT, их типовые протоколы, угрозы и практики кибербезопасности при подключении к корпоративной сети и DCIM.
</WRAP>

===== Роль OT в архитектуре ЦОД =====
<WRAP info>
OT обеспечивает непрерывность вычислительного контура: сбой инженерных систем приводит к простоям IT и риску потери данных. Интеграция выполняется так, чтобы телеметрия и управление не создавали новых точек отказа и атак.
</WRAP>

<mermaid>
flowchart TB
  classDef big font-size:14px,stroke-width:1.2px,padding:10px;
  OT["OT: питание, охлаждение, безопасность"]:::big --> IT["IT: серверы, СХД, сеть"]:::big
  IT:::big --> DATA["Данные и сервисы"]:::big
  subgraph MGMT["Контур управления"]
    NMS["NMS (SNMP)"]:::big
    BMS["BMS (Modbus/BACnet)"]:::big
    DCIM["DCIM"]:::big
  end
  NMS --- OT
  BMS --- OT
  DCIM --- NMS
  DCIM --- BMS
</mermaid>

===== Протоколы мониторинга и управления OT =====
<WRAP info>
Исторически в ЦОД применяются три массовых протокола: SNMP, Modbus/TCP и BACnet. Они обеспечивают наблюдаемость через NMS/BMS и интеграцию в DCIM.
</WRAP>

^ Параметр ^ SNMP v1/v2c/v3 ^ Modbus/TCP ^ BACnet/IP ^
| Модель данных | OID-дерево (MIB) | Регистры/катушки | Объекты/службы |
| Транспорт | UDP/161 | TCP/502 | UDP 47808, иногда TCP |
| Тип обмена | опрос/трап | опрос | опрос/подписка COV |
| Безопасность | v1/v2c — нет; v3 — аутентификация и шифрование | нет (по умолчанию), допускает TLS через шлюзы | ограниченная (аутентификация зав. от реализации), без шифрования по умолчанию |
| Где применяется | IT-оборудование, UPS, PDU, часть CRAC/чиллеров | ПЛК, электрика, датчики, счётчики | HVAC/холод, автоматика зданий |
| Плюсы | простота, повсеместная поддержка | простота, детерминизм | объектная модель, COV снижает трафик |
| Минусы | v1/v2c небезопасны | нет нативной безопасности | фрагментация реализаций, устаревшие стек-версии |

<WRAP important>
  * Все три протокола проектировались для изолированных сетей. В «плоской» L2-среде ЦОД без сегментации и контроля — высокий риск компрометации (перехват, подмена значений, несанкционированное управление).
</WRAP>

===== Системы верхнего уровня =====
  * NMS — агрегирует SNMP-телеметрию IT и части инженерки.
  * BMS — ядро «здания» (HVAC, насосы, КИПиА) на Modbus/BACnet.
  * DCIM — сквозной слой: инвентаризация, корреляция событий, ёмкостное планирование; получает данные из NMS/BMS/шлюзов.

<WRAP info>
Высокая детализация телеметрии ведёт к значительным объёмам трафика опроса. В малых ЦОД это было незаметно; в крупных — без оптимизации опрос становится фактором нагрузки на сеть управления и контроллеры.
</WRAP>

==== Оценка трафика опроса ====
<WRAP center>
$$R_{net} = \sum_{i=1}^{N} \left( \frac{S_i}{T_i} \right) \cdot k_{ovh}$$
</WRAP>

где:
- \(N\) — число узлов/контроллеров;
- \(S_i\) — средний объём полезных данных за опрос, байт;
- \(T_i\) — период опроса узла \(i\), с;
- \(k_{ovh}\) — коэффициент накладных расходов протокола и L2/L3 (1.2–1.6 для UDP/IPv4 со SNMP-get/response; для TCP/Modbus берут 1.3–1.8 с учётом квитанций).

<WRAP tip>
Практическое правило: для «быстрых» тегов (критические аварии, статусы выключателей, уставки) — период 1–5 с; для «медленных» тегов (температуры, счётчики энергии) — 10–60 с или COV-подписка.
</WRAP>

===== Уязвимости и типовые проблемы =====
  * Небезопасные версии протоколов: SNMP v1/v2c (community-строки), открытый Modbus и BACnet без шифрования.
  * Плоские L2-сегменты, один общий VLAN «Engineering».
  * Доступ сервисных ноутбуков/подрядчиков к сети без контроля.
  * Шлюзы/конвертеры протоколов без обновлений и без журнала аудита.
  * Отсутствие «права на просмотр» (read-only) для телеметрии — управление доступно по умолчанию.
  * Логические ошибки: перепутанные уставки, широковещательные штормы, циклы опроса с периодом <1 с.

<WRAP important>
Комбинация физического доступа к щитовой + небезопасный OT-протокол = возможность изменить уставки (например, отключить автоматику охлаждения) без следов в IT-SIEM.
</WRAP>

===== Принципы безопасной интеграции OT =====
  * **Сегментация по Purdue/зонам:** OT-полевой уровень (L0–L1) — изоляция; контроллеры (L2) — отдельные VLAN/VRF; диспетчеризация (L3) — через L3-фаервол.
  * **Политика «по умолчанию запрещено»:** allow-list по IP/UDP/TCP-портам (161/162, 502, 47808 и др.), раздельные ACL для чтения и управления.
  * **Шлюзы и брокеры:** SNMP-прокси, Modbus-шлюз с маппингом в «белый» реестр тегов; преобразование BACnet COV в события DCIM.
  * **Разделение ролей:** сбор данных — изолированный «коллектор» (read-only); команды управления — только с защищённого jump-host по MFA.
  * **Криптозащита и учёт:** SNMPv3 (authPriv), VPN/MTLS для удалённого доступа, централизованный syslog/OT-SIEM.
  * **Оптимизация опроса:** COV для BACnet, групповые get-bulk для SNMP, агрегация регистров Modbus, разные периоды по критичности.
  * **Надёжность:** резервные контроллеры/шлюзы, двойные сети управления (A/B), независимое питание NMS/BMS/DCIM.
  * **Синхронизация времени:** NTP/PTP для корреляции событий.
  * **Подрядчики:** временные учётки, отдельный «гостевой» сегмент, запись экрана на jump-host.
  * **РФ-контекст:** для объектов КИИ — категорирование и меры защиты по требованиям ФСТЭК; журналирование действий и контроль НСД.

===== Быстрый чек-лист внедрения =====
  * Инвентаризация всех узлов OT, протоколов и портов.
  * L3-сегментация OT↔IT; запрет east-west между зонами OT.
  * Перевод SNMP на v3; Modbus/BACnet — через шлюз с ACL и журналом.
  * Разделение «telemetry-RO» и «control-RW» по разным политикам и учёткам.
  * Настройка DCIM как «читателя», а не управляющего контура.
  * Настройка порогов и hysteresis для событий; подавление «шторма» алертов.
  * Тест аварийных сценариев: потеря связи, ложные уставки, отказ контроллера.

===== Мини-пример расчёта трафика телеметрии =====
<WRAP info>
50 устройств по SNMP, средний ответ 800 байт, период 10 с, \(k_{ovh}=1{,}3\):  
\(R_{net}= 50 \times (800/10) \times 1{,}3 \approx 5{,}2\ \text{кбит/с}\).  
Даже при увеличении до 500 устройств и периода 5 с — порядка 104 кбит/с. Узкое место чаще CPU контроллеров и обработка в менеджерах, а не пропускная способность сети.
</WRAP>

===== Типовая схема угроз (для обсуждения с ИБ) =====
<mermaid>
flowchart LR
  classDef big font-size:22px,stroke-width:1.2px,padding:10px;

  A["Физический доступ"]:::big --> B["Инсайдерские угрозы"]:::big
  A:::big --> C["Сбои инженерных систем (OT)"]:::big
  B:::big --> D["Взлом IT-инфраструктуры (сетевые атаки)"]:::big
  C:::big --> D
  D:::big --> E["Компрометация сервисов и данных"]:::big
  E:::big --> F["Методы защиты (сегментация, мониторинг, резервирование)"]:::big
</mermaid>

===== Ключевые идеи =====
<WRAP tip>
  * OT — фундамент ЦОД; его сбои быстро транслируются в простои IT и риски для данных.  
  * Основные «языки» OT в ЦОД: SNMP, Modbus/TCP, BACnet; по умолчанию они небезопасны.  
  * NMS/BMS/DCIM дают наблюдаемость, но требуют сегментации, строгих ACL и read-only интеграции.  
  * Сетевая нагрузка от телеметрии обычно умеренная; критичнее — безопасность и устойчивость контроллеров.  
  * Обязательны SNMPv3, шлюзы с белыми списками тегов, jump-host с MFA и A/B-резервирование управления.  
  * Для РФ: учитываем требования к объектам КИИ, журналирование и контроль удалённого доступа подрядчиков.  
  * Проектирование интеграции OT начинается с инвентаризации, зонирования и модели угроз.
</WRAP>

</WRAP>