Dlaczego chmura, skoro od lat radziliśmy sobie bez niej? Zwolennicy idei zastępowania własnych serwerów wersjami zdalnymi, które są współdzielone z innymi użytkownikami, a oprogramowanie na nich działające traktowane jako usługa, wskazują na wiele zalet takiego rozwiązania. Po pierwsze jest nim skalowalność i elastyczność – zdecydowanie łatwiej zamówić dodatkowe zasoby obliczeniowe, niż wraz ze zmianami w produkcji modernizować własne systemy komputerowe.
W przemyśle ważny jest też wysoki uptime systemów i redundancja, której zapewnienie jest pochodną skalowalności. Brak własnej infrastruktury (a w każdym razie jej minimalizacja) dodatkowo zmniejsza koszty utrzymania systemów. Dotyczy to nie tylko samego sprzętu, ale też oprogramowania – choćby konieczności dokonywania regularnych aktualizacji, patchowania programów, itd. Zapewnianie spójnej polityki w zakresie bezpieczeństwa jest też, zdaniem dostawców oprogramowania, jedną z bolączek polskich zakładów przemysłowych. Chmura może tu dużo zmienić.
Wszystko, a w każdym razie większość, rozbija się o wspomniane bezpieczeństwo. Pogląd, jakoby hakerów i twórców szkodliwego oprogramowania przemysł nie interesował, można dzisiaj włożyć między bajki. Od momentu gdy wykryto robaka Stuxnet, w mediach regularnie pojawiają się informacje o zagrożeniach informatycznych w przemyśle i energetyce. W tym roku firma Positive Research podała, że wykryła luki w zabezpieczeniach aż 60 tys. systemów sterowania podłączonych do Internetu, zaś najświeższym tematem jest pojawienie się zaawansowanego trojana Dragonfly, który atakuje systemy w branży CPG.
W tej sytuacji dostawcy chmurowego SCADA zwracają uwagę na dostępność wielu rozwiązań w zakresie bezpieczeństwa, niejako antycypując pytania klientów. Takimi są protokoły IP Security, technologie VPN oraz SSL, możliwość szyfrowania przechowywanych danych czy tworzenia globalnych rejestrów do kontroli logów. Część z nich niejako przy okazji usuwa dotychczasowe problemy systemów SCADA, w przypadku których luki bezpieczeństwa wynikały ze stosowania niewystarczająco bezpiecznych protokołów, jak "standardowe" DNP3 czy Modbus. Dochodzi do tego możliwość tworzenia zaawansowanych architektur, gdzie tylko wybrane części SCADA - np. odpowiedzialne za przetwarzanie i udostępnianie danych - są przenoszone do chmury.
Czy to wystarczy? Uważam, że chcąc przekonać klientów przemysłowych do cloud computingu firmy powinny rozważyć sięgnięcie po nietypowe rozwiązania. Zapisanie w umowie odpowiedzialności dostawcy usług za bezpieczeństwo danych jest tu całkiem niezłym, choć niestety mało realnym do wdrożenia pomysłem.
Teza, jakoby wybór był zero-jedynkowy - tzn. albo bezwzględnie należało inwestować w rozwiązania w chmurze, albo powinno się jej unikać - nie jest prawdziwa. Każdorazowo zależy to od specyfiki wdrożenia, potrzeb użytkownika i jego akceptacji ryzyka oraz kosztów. Stąd też nie staję po żadnej ze stron dyskusji. Jestem natomiast przekonany co do tego, że na systemy w chmurze jesteśmy skazani, gdyż taki jest trend na rynku oprogramowania. Sprawdziły się one dobrze w branży telekomunikacyjnej, testuje ją biznes, a nawet banki.
Miesiąc temu pisałem o Big Data i obszar ten przynosi pierwsze próby z chmurą również w naszym sektorze. Przemysł zresztą wielokrotnie importował technologie z branży IT i elektroniki konsumenckiej, takie jak choćby Wi-Fi, wykorzystanie urządzeń przenośnych czy zdalnego dostępu, przez co - o ile tylko zostaną spełnione wymogi dotyczące bezpieczeństwa - będzie on również korzystał z cloud computingu.
Osobom zainteresowanym tematyką bezpieczeństwa systemów sterowania polecam publikacje analityczne firmy Trend Micro, które najłatwiej znaleźć wpisując w wyszukiwarce hasło "Trend Micro SCADA ICS". Warto również zapoznać się z opracowaniem "SCADA in the Cloud: A Security Conundrum?" tej samej firmy.
Zbigniew Piątek
