Ключови изводи
За IT/OT мениджър CMMS е още една система за интегриране, обезопасяване и поддържане в работа. Функциите за поддръжка имат по-малко значение в сравнение с това как софтуерът се държи в рамките на по-широката технологична среда. Ако това се направи неправилно, полезен инструмент се превръща в дългосрочна тежест.
CMMS рядко съществува самостоятелно. Той трябва да обменя данни с ERP, historian системи и понякога самите машини. IT/OT мениджърът търси чисти API и стандартни интеграции, защото тежките персонализирани конектори са крехки, скъпи и пречат на бъдещи ъпгрейди.
Свързването на софтуера за поддръжка с оперативната технология повдига реални въпроси: кой какво може да достъпи, къде се съхраняват данните и как е защитена връзката към машините. Силен контрол на достъпа, проследимост и ясна локализация на данните не са приятни екстри за тази роля; те са задължителни изисквания.
Облак или локално, единно влизане, начинът на управление на ъпгрейдите, всичко това решава колко текуща работа ще генерира системата за ИТ. Платформа, която пасва на съществуващите инструменти за идентичност и сигурност и се обновява без ръчна намеса, създава значително по-малко натоварване, отколкото такава, която изисква постоянно подпомагане.
IT/OT мениджър оценява два варианта CMMS. Единият предлага стандартни API, единно влизане и ясна документация за сигурността; другият изисква персонализирана интеграция и отделно влизане. Първият пасва на стека и модела за сигурност с малко допълнителни усилия; вторият добавя остров за управление и нова повърхност за атаки. Функциите за поддръжка бяха сходни; архитектурата реши това.
Свързването на поддръжката с данни от живото производство, включително OEE, увеличава стойността на CMMS, но и умножава работата по интеграция и сигурност. IT/OT мениджърът иска тази връзка да се осъществи чрез чисти, сигурни интерфейси, вместо чрез крехки персонализирани връзки. Запазете демонстрация на Fabrico, за да видите как свързаната поддръжка и OEE данните могат да се впишат в съществуваща архитектура. Вижте също облак срещу локално CMMS.
Чиста интеграция със съществуващите системи, силен контрол на достъпа и управление на данните, сигурна свързаност към оперативната технология и съвместимост със съществуващите инструменти за управление на идентичността и обновяването, за да се поддържа ниско ИТ натоварване.
Може да е, затова връзката трябва да бъде защитена съзнателно, с контрол на достъпа, одит и ясни граници. Ако е направено правилно, производствените данни, които се отключват, оправдават управлявания риск.
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 по сигурността, и двата подхода създават скъпи проблеми при изпълнението след сключването на договора.
Централният въпрос за мрежовата сигурност при облачни 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 и не би трябвало да създават затруднения при оценката на утвърдени платформи.
Искате OEE директно от машините, без ръчно въвеждане?
Вижте на живо
Вход
Блог
