Wymagania IT i OT dla wdrożenia CMMS w przemyśle
Wdrożenie CMMS w przemyśle znajduje się na styku IT i OT — w obszarze o rosnącej złożoności, gdy systemy chmurowe łączą się z sieciami sterowania na poziomie zakładu. Menedżerowie IT muszą zweryfikować: postawę bezpieczeństwa w chmurze (co najmniej certyfikacja SOC 2 Type II, preferowana ISO 27001), lokalizację przechowywania danych i dokumentację zgodności z RODO/CCPA, integrację SSO i zarządzania tożsamością (Active Directory, Azure AD, Okta), architekturę bezpieczeństwa sieci dla łączności OT oraz zobowiązania w umowie SLA dotyczące dostępności i czasu reakcji wsparcia. Menedżerowie OT muszą zweryfikować: metodę łączności PLC i SCADA (bezpośrednie API, OPC-UA, Modbus lub własny konektor), zgodność segmentacji sieci (chmurowy CMMS nie powinien wymagać wprowadzania bezpośrednich reguł zapory sieciowej z sieci OT do publicznego internetu), architekturę bramki brzegowej do zbierania danych z maszyn bez narażania systemów OT oraz doświadczenie dostawcy w zakresie przemysłowych standardów cyberbezpieczeństwa ISA/IEC 62443. Proces zakupu CMMS często polega na tym, że IT zatwierdza kwestie bezpieczeństwa bez udziału OT, albo OT określa wymagania dotyczące łączności bez przeglądu bezpieczeństwa ze strony IT — oba wzorce powodują kosztowne problemy we wdrożeniu po zawarciu umowy.
Architektura sieci i bezpieczeństwo OT dla CMMS w chmurze
Główne zagadnienie bezpieczeństwa sieciowego dla chmurowego CMMS w przemyśle to sposób, w jaki dane maszynowe przemieszczają się z sieci OT do platformy w chmurze. Istnieją trzy architektury o różnych profilach bezpieczeństwa. Architektura 1: bezpośrednie połączenie PLC → chmura — oprogramowanie dostawcy CMMS łączy się bezpośrednio z PLC przez sieć zakładową, używając wyłącznie wychodzących połączeń HTTPS do chmury. Jest to rozwiązanie proste, ale wymaga reguł zapory umożliwiających ruch wychodzący z sieci OT, co wiele standardów bezpieczeństwa OT zabrania. Architektura 2: bramka brzegowa — dedykowane urządzenie brzegowe (komputer przemysłowy lub urządzenie bramkowe) znajduje się w strefie DMZ pomiędzy sieciami OT i IT, zbiera dane z PLC i przesyła je do chmury. Zachowuje to izolację sieci OT i jest architekturą zalecaną przez ISA/IEC 62443 oraz wytyczne NIST. Architektura 3: pośrednik MES — CMMS pobiera dane z istniejącego systemu MES lub systemu typu „historian”, który już znajduje się w sieci IT, zachowując izolację OT bez konieczności instalowania nowego sprzętu brzegowego. Oceniając dostawców CMMS, poproś o schemat architektury sieci pokazujący dokładnie, gdzie występuje łączność i którą architekturę obsługują. Dostawcy, którzy nie potrafią przedstawić takiego schematu, nie przemyśleli konsekwencji bezpieczeństwa OT wynikających z ich podejścia do integracji.
Suwerenność danych, standardy integracji i lista kontrolna zatwierdzenia przez IT
Dla menedżerów IT/OT przeprowadzających przegląd bezpieczeństwa dostawcy CMMS, użyj tej listy kontrolnej jako punktu wyjścia. Rezydencja danych: potwierdź, że region hostingu w chmurze odpowiada wymaganiom dotyczącym rezydencji danych Twojej organizacji i uzyskaj pisemne potwierdzenie, gdzie dane są przetwarzane i przechowywane. Certyfikaty bezpieczeństwa: wymagaj raportu SOC 2 Type II (z ostatnich 12 miesięcy) oraz szczególnie przejrzyj Sekcję 7 (Dostępność) i Sekcję 9 (Poufność). Testy penetracyjne: zażądaj streszczenia najnowszego testu penetracyjnego wykonanego przez stronę trzecią oraz statusu działań naprawczych dotyczących wykrytych luk. Bezpieczeństwo API: potwierdź, że REST API używa OAuth 2.0 z wygaśnięciem tokenów i ograniczaniem liczby żądań (rate limiting) — a nie uwierzytelniania za pomocą klucza API bez terminu ważności. Standardy integracji: wymagaj wsparcia OPC-UA dla nowoczesnej łączności z PLC i potwierdź obsługę Modbus TCP dla starszego sprzętu. Eksport danych: potwierdź możliwość masowego eksportu danych w otwartych formatach (CSV, JSON) bez udziału dostawcy — to zabezpieczenie możliwości migracji danych przy zakończeniu współpracy. Kopia zapasowa i odzyskiwanie: wymagaj RPO (Recovery Point Objective) poniżej 1 godziny oraz RTO (Recovery Time Objective) poniżej 4 godzin dla środowisk produkcyjnych. Dostęp dostawcy: wymagaj rejestru dostępu dostawcy pokazującego wszystkie przypadki dostępu do Twojego środowiska, dostępnego dla Twojego zespołu na żądanie. Te wymagania są rozsądne dla każdego dostawcy CMMS klasy enterprise i nie powinny stwarzać problemów podczas oceny w przypadku ugruntowanych platform.