Изисквания за ИТ и ОТ при внедряване на CMMS в производството
Внедряването на CMMS в производството се намира на пресечната точка между IT и OT — зона с нарастваща сложност, тъй като облачните системи се свързват с контролните мрежи на производствената площадка. IT мениджърите трябва да удостоверят: облачната сигурност (минимум сертификация SOC 2 Type II, предпочитана ISO 27001), документация за резидентността на данните и за съответствие с GDPR/CCPA, интеграция на SSO и управление на идентичности (Active Directory, Azure AD, Okta), архитектурата на мрежовата сигурност за OT свързаност и ангажиментите по SLA за време на работа и време за реакция на поддръжката. OT мениджърите трябва да удостоверят: метод за свързване на PLC и SCADA (директно API, OPC-UA, Modbus или собствен конектор), съответствие със сегментирането на мрежата (облачният CMMS не трябва да изисква директни правила на защитната стена от OT мрежата към публичния интернет), архитектура на edge шлюз за събиране на машинни данни без излагане на OT системите и опитът на доставчика с индустриалните стандарти за киберсигурност ISA/IEC 62443. Процесът на придобиване на CMMS често включва IT да одобри сигурността без участие на OT, или OT да специфицира изисквания за свързаност без преглед от IT по сигурността — и двата подхода създават скъпи проблеми при изпълнението след сключването на договора.
Мрежова архитектура и сигурност на оперативните технологии (OT) за облачна CMMS
Централният въпрос за мрежовата сигурност при облачни CMMS в производството е как данните от машините се преместват от OT мрежата към облачната платформа. Съществуват три архитектури с различни профили на сигурност. Архитектура 1: директна PLC‑към‑облак — софтуерът на доставчика на CMMS се свързва директно с PLC през заводската мрежа с само изходящи HTTPS връзки към облака. Това е просто, но изисква правила на защитната стена, които позволяват изходящ трафик от OT мрежата, което много OT стандарти за сигурност забраняват. Архитектура 2: граничен (edge) шлюз — специално гранично устройство (индустриален ПК или хардуерен шлюз) се поставя в DMZ между OT и IT мрежите, събира данни от PLC и ги препраща към облака. Това запазва изолацията на OT мрежата и е архитектурата, препоръчвана от ISA/IEC 62443 и насоките на NIST. Архитектура 3: посредник MES — CMMS извлича данни от вече съществуваща MES или historian система, която вече е в IT мрежата, като по този начин запазва изолацията на OT без необходимост от ново гранично хардуерно устройство. При оценка на доставчици на CMMS поискайте диаграма на мрежовата архитектура, която показва точно къде се осъществява свързаността и коя архитектура поддържат. Доставчици, които не могат да представят тази диаграма, не са обмислили последиците за сигурността на OT от техния интеграционен подход.
Суверенитет на данните, стандарти за интеграция и контролен списък за одобрение от ИТ
За IT/OT мениджъри, които извършват преглед на сигурността на доставчик на CMMS, използвайте този контролен списък като отправна точка. Местонахождение на данните: потвърдете, че регионът за хостинг в облака съответства на изискванията на вашата организация за местонахождение на данните и получете писмено потвърждение къде се обработват и съхраняват данните. Сертификати за сигурност: изисквайте доклад SOC 2 Type II (за последните 12 месеца) и прегледайте специално Раздел 7 (Достъпност) и Раздел 9 (Поверителност). Тестове за проникване: поискайте обобщение на най-скорошния тест за проникване от трета страна и статуса на отстраняване на установените проблеми. Сигурност на API: потвърдете, че REST API използва OAuth 2.0 с изтичане на токена и ограничаване на заявките — не удостоверяване с API ключ без изтичане. Стандарти за интеграция: изисквайте поддръжка на OPC-UA за съвременна свързаност с PLC и потвърдете поддръжка на Modbus TCP за наследствено оборудване. Експорт на данни: потвърдете възможност за масов експорт на данни в отворени формати (CSV, JSON) без намеса от страна на доставчика — това е вашата защита на правото на изход. Резервно копиране и възстановяване: изисквайте RPO (Recovery Point Objective) под 1 час и RTO (Recovery Time Objective) под 4 часа за продукционни среди. Достъп на доставчика: изисквайте регистър на достъпа на доставчика, показващ всички достъпи на доставчика до вашата среда, достъпен за вашия екип при поискване. Тези изисквания са разумни за всеки корпоративен доставчик на CMMS и не би трябвало да създават затруднения при оценката на утвърдени платформи.