Koniec izolacji

W dzisiejszym świecie wielu zdarzeń nie da się już kontrolować ręcznie. Ogrom danych koniecznych do przetworzenia wymaga użycia komputerów, zaś ich wykorzystanie jest zależne od pracy uruchomionych aplikacji, których nieprzerwane działanie staje się krytyczne dla funkcjonowania przedsiębiorstw.

W dzisiejszym świecie wielu zdarzeń nie da się już kontrolować ręcznie. Ogrom danych koniecznych do przetworzenia wymaga użycia komputerów, zaś ich wykorzystanie jest zależne od pracy uruchomionych aplikacji, których nieprzerwane działanie staje się krytyczne dla funkcjonowania przedsiębiorstw.

Dotychczas aplikacje o szczególnie krytycznym znaczeniu były uruchamiane w całkowicie izolowanym środowisku. Dotyczyło to np. narzędzi do nadzorowania pracy elektrowni, lokalnych centrów przetwarzania danych itd. Obecnie takie aplikacje są coraz ściślej ze sobą połączone, co oprócz dość szybkiej pracy i łatwej współpracy skutkuje także większą podatnością na ataki i awarie. Dowiodła tego najpoważniejsza awaria energetyczna w Ameryce, która w 2003 r. spowodowała całkowite odcięcie zasilania dla 50 mln użytkowników. Awaria była spowodowana przez błąd oprogramowania jednego z dostawców energii w Ohio. Błąd ten spowodował kaskadę awarii, która skończyła się unieruchomieniem sieci energetycznych w północnej Ameryce.

Ochrona infrastruktury

Oczywiście nie ma powrotu do stanu całkowitej izolacji każdego z centrów, gdyż rozwój technologii i potrzeby dzisiejszego świata wymagają, aby aplikacje ze sobą współpracowały. Poważnym problemem jest jednak takie opracowanie zabezpieczeń, by w znaczący sposób nie spowolnić pracy aplikacji. Zarządzanie energią wymaga, aby działały one w czasie rzeczywistym, zatem nie można wprowadzać zbyt dużych opóźnień w pracy programów. Dotychczas strategie ochrony krytycznych aplikacji przed cyberatakiem nie były znane, ani szczegółowo dopracowane, bowiem izolacja wykluczała możliwość ataków z zewnątrz. Jednak izolacja systemów należy już do przeszłości.

Nowe standardy obejmują wiele zagadnień - od zatrudniania osób odpowiedzialnych za bezpieczeństwo, do zasad opracowywania polityki bezpieczeństwa i eksploatacji systemów o krytycznym znaczeniu. Obejmują one ochroną całą infrastrukturę teleinformatyczną - wszystkie elementy, których awaria może skutkować naruszeniem bezpieczeństwa tej istotnej aplikacji. Co ważniejsze - po ustaleniu standardów wspólnych dla całej energetyki będzie można je wymuszać środkami administracyjnymi.

W wielu firmach są eksploatowane aplikacje o znaczeniu krytycznym, niekoniecznie musi to dotyczyć energetyki, wody czy firm zajmujących się procesami chemicznymi. Przykładowo, poważna awaria systemu dużego operatora telekomunikacyjnego skutkuje potencjalnym paraliżem komunikacyjnym milionów użytkowników tego operatora. Doświadczyli tego całkiem niedawno użytkownicy BlackBerry w USA, gdy problem z komunikacją wyłączył działanie przesyłania maili do końcowych terminali tej usługi. Oczywiście awaria została szybko naprawiona i nie objęła wszystkich użytkowników tej technologii na świecie. Podobne wpadki mieli także polscy operatorzy telekomunikacyjni (awarie bramek SMS, problemy z transmisją danych GPRS), ale nie miały one tak poważnych skutków.

Wspólny język komunikacji

Aplikacje kontrolujące procesy w określonym obszarze muszą się komunikować z pozostałymi aplikacjami w systemie, nawet jeśli są to produkty różnych dostawców, pracujące na różnych platformach. Ważne jest zatem zapewnienie dokładnie określonych standardów komunikacji między nimi. Standardy te powinny być opracowane na tyle dobrze, by spełnione były najważniejsze elementy współpracy: niezawodnie określone sposoby wymiany danych, zestandaryzowane opisy poleceń, zasady poprawności komend i danych wraz z mechanizmami weryfikacji nadawcy i odbiorcy, a także dobrze zdefiniowane akcje, które są dopuszczalne.

Warto zauważyć, że przyjęty standard jest w założeniach niezależny od szczegółów implementacji. Jest tylko jeden warunek konieczny - wszystkie strony muszą korzystać z tego samego, dobrze określonego standardu. Sposobów komunikacji może być wiele - od bezpośrednich połączeń TCP/IP, aż do wymiany plików tekstowych przygotowywanych zgodnie z szablonem. Liczy się to, by każda ze stron współpracowała z pozostałymi tak samo.

Weryfikacja każdej ze stron jest niezbędna, bowiem dla zapewnienia bezpieczeństwa należy wykluczyć możliwość sfałszowania komunikatów. Cyfrowe podpisywanie każdego komunikatu znacząco zmniejsza prawdopodobieństwo fałszerstwa lub przyjęcia przesyłki uszkodzonej podczas transferu. Może ono także zapewnić niezaprzeczalne potwierdzenie prawidłowego rozkodowania każdego z przesyłanych komunikatów przez odbiorcę.

Żelazne reguły bezpieczeństwa

Oprócz zasad komunikacji muszą być określone ramy poleceń i danych, które aplikacja może przyjąć. Zabezpieczenia te są bardzo ważne, bowiem żaden program nie powinien przyjąć niewiarygodnych danych, które zostały wygenerowane wskutek błędu. System powinien być na tyle odporny, by nie przyjmował danych, które wychodzą poza dopuszczalne ramy - np. gdy podano temperaturę jako liczbę ujemną, a skala jest zdefiniowana w stopniach Kelvina lub napięcie wykracza o rząd wielkości poza wartości możliwe do osiągnięcia w praktyce. Każdy komunikat musi zostać sprawdzony nie tylko pod względem zgodności z szablonem, ale także pod kątem dopuszczalności przekazywanych danych.

Przygotowanie takich reguł jest dość trudne, gdyż wielu kombinacji nie da się przewidzieć, niemniej można określić typowe symptomy awarii aplikacji. System jako całość powinien być odporny na awarię pojedynczego ogniwa - w razie wykrycia błędów w jego pracy, względnie podejrzenia naruszenia stabilności systemu jako całości, wątpliwa aplikacja powinna zostać natychmiast odcięta od wpływu na pracę systemu. W każdym module odpowiedzialnym za komunikację powinien znajdować się mechanizm umożliwiający izolację każdego z ogniw. Brak takiego mechanizmu może potencjalnie powodować groźny efekt domina - załamanie systemu poprzez wywoływanie załamań kolejnych węzłów. Oczywiście nie każdy system jest wrażliwy na takie ataki, niemniej są dziedziny, takie jak energetyka lub komunikacja, gdzie zależności techniczne między węzłami dają, choćby teoretycznie, takie możliwości.

U siebie czy na zewnątrz

Aplikacja może być eksploatowana na dwa sposoby - albo w obrębie przedsiębiorstwa, gdzie jest uruchomiona i wykorzystywana przy użyciu własnej infrastruktury, albo jako usługa zarządzana przez firmę zewnętrzną. W pewnych przypadkach dobrze sprawdza się podejście mieszane, gdy sprzęt znajduje się w firmie, ale obsługuje go personel zewnętrzny. Oba podejścia mają swoje zalety i wady, powszechnie są one znane, gdy dotyczy to typowych usług (poczta elektroniczna, WWW itd.). Gdy zaś chodzi o aplikacje o znaczeniu krytycznym dla firmy, hosting poza siedzibą lub obsługa przez zewnętrzną firmę na terenie przedsiębiorstwa wymaga bardzo dobrego przygotowania się do wdrożenia systemu przez obie strony.

W celu komercyjnej reprodukcji treści Computerworld należy zakupić licencję. Skontaktuj się z naszym partnerem, YGS Group, pod adresem [email protected]

TOP 200