Bezpieczeństwo w systemach przemysłowych okiem architekta systemów

Czytelnik z pewnością ma pełną świadomość, że jeden artykuł nie może być żadnego rodzaju kompendium czy „biblią bezpieczeństwa”. Jako że miałem przyjemność pracować na wielu różnych stanowiskach, m.in. Administratora Sieci, Administratora Systemów, Kierownika Projektów „Opracowanie koncepcji automatyzacji Spółki”, „Wdrożenie Zintegrowanego Systemu Informatycznego”, Kierownika Działu Informatyzacji, a nawet – przez niedługi okres – ABI, czyli Administratora Bezpieczeństwa Informacji, postanowiłem zebrać wiedzę i podzielić się nią. Podkreślę, że doświadczenia zgromadziłem dzięki pracy w ciekawych wielodyscyplinarnych zespołach w różnych branżach. Uczestniczyłem przekrojowo w etapach od projektowania architektury systemów, przez wdrażanie, użytkowanie i utrzymanie, aż po ich rozwój.

Czym jest architektura systemów?

Warto zauważyć, że architektura systemów to coś więcej niż tylko sprzętowy aspekt systemu przemysłowego i jego struktury. Ważne są wszelkie relacje, interakcje i zależności między innymi systemami, użytkownikami oraz środowiskiem, w którym ten system przemysłowy jest wdrażany lub już występuje. Mówiąc o środowisku, mam na myśli m.in. otoczenie biznesowe, społeczne, prawne i techniczne, które ma ogromny wpływ na ewolucję systemów, a więc ich złożoność, wynikającą już z liczebności typów systemów oraz relacji między nimi.

Tylko prawidłowo zaprojektowane i wdrożone narzędzia, używane zgodnie z założeniami i ich przeznaczeniem, pozwalają na bieżące i bezpieczne dostarczanie wiarygodnej informacji, niezbędnej na każdym poziomie zarządzania przedsiębiorstwem. Ma to ogromny wpływ na świadome zarządzanie m.in. bezpieczeństwem, nie tylko na poziomie strategicznym, ale i taktycznym oraz operacyjnym. Pomijamy w tym miejscu wszelkie systemy pracy grupowej, komunikacji biurowej, społecznościowe, wspomagania uczenia, modelowania, symulacji, projektowania i programowania oraz zarządzania infrastrukturą sieciową serwerową i backupu.

W taki sposób można postrzegać systemy użytkowane obecnie, a jak to wyglądało wcześniej i co nas czeka dalej? Pozwolę sobie przytoczyć przykłady od późnych lat 60., czyli okresu, w którym królowała architektura monolityczna. Z jednej strony w obszarze IT dominowały komputery Mainframe, m.in. polska Odra, z drugiej – w obszarze automatyki wielkogabarytowe szafy AKPiA.

Przez kolejne lata można było obserwować niezależny i dwutorowy rozwój tych dwóch dziedzin: informatyki i automatyki. Wraz z pojawianiem się nowych wyzwań gospodarczych rosła ich dojrzałość, a tym samym złożoność, co skutkowało naturalnym zbliżaniem się do siebie tych dziedzin. W pierwszej kolejności nastąpiło to na polu infrastruktury sprzętowej i programowej, a to wymusiło zbliżenie w obszarze organizacyjnym. Obecnie możemy mówić o zintegrowanej architekturze obu dziedzin. Jak należy to rozumieć?

Integracja obejmuje nie tylko zarządzanie warstwą sprzętową, która – w przeciwieństwie do wcześniej odseparowanych fizycznie rozwiązań biznesowych i przemysłowych – została spięta jedną wspólną siecią już w warstwie regulacji (PLC, PAC). Integracja obejmuje także zarządzanie warstwami: programową (systemów wbudowanych, operacyjnych, oprogramowania, aplikacji), danych (informacji i wiedzy), procesów przemysłowych i biznesowych. Ma to przełożenie na zaspokajanie potrzeby efektywnej współpracy ludzi z obszaru omawianych dziedzin. Skutkiem tego jest wspólny cel: dbanie nie tylko o efektywność, ale i – to przede wszystkim – o bezpieczeństwo na każdej z wymienionych warstw, obecnie połączonych ze sobą, a nie jak kiedyś odseparowanych.

Przyszłość architektury systemów

W przyszłości wraz ze wzrostem potrzeb biznesowych i przemysłowych albo będzie rosła złożoność lokalna systemów, albo część warstw zostanie zredukowana miejscowo i przeniesiona do tzw. „chmury” (ang. Cloud). Drugi przypadek będzie ściśle powiązany z rozwojem architektury Przemysłowego Internetu Rzeczy (ang. IIoT – Industrial Internet of Things). Jaki związek ma IIoT z bezpieczeństwem? Dotychczasowe urządzenia pomiarowe i wykonawcze występujące w najniższej warstwie fizycznej będą zastępowane inteligentnymi narzędziami pomiarowymi i wykonawczymi (ang. smart sensors and actors). Posiadają one wbudowane moduły: przetwornika i komunikacji, dzięki którym logika, obecnie wykonywana w warstwach wyższych, będzie częściowo przeniesiona do warstwy najniższej i dodatkowo na tym poziomie nastąpi połączenie z siecią przemysłową.

Skoro dane będą wysyłane cyfrowo w pakietach, integracja sieciowa zejdzie do poziomu warstwy fizycznej, a razem z nią związane z tym elementy bezpieczeństwa stosowane w warstwach wyższych. Konsekwencją tego już na najniższym poziomie będzie m.in. wymagana autoryzacja dla podniesienia wiarygodności przesyłanej informacji. Reakcja rynku jest już widoczna, czego przykładem jest rozwój standardu OPC UA (ang. OPC Unified Architecture), implementowanego przez producentów rozwiązań przemysłowych. Standard ten uwzględnia chociażby wspomnianą autoryzację.

Czy autoryzacja na poziomie analogowych tradycyjnych urządzeń pomiarowych i wykonawczych była niezbędna?

Odpowiedź brzmi „nie”, ponieważ te, podpięte fizycznie do sterownika, komunikowały się bezpośrednio prądowo lub napięciowo, ewentualnie za pomocą przemysłowych protokołów komunikacyjnych odseparowanych fizycznie od sieci biznesowej. Połączenie sieci przemysłowych z biznesowymi i Internetem wymusza wręcz tę autoryzację już w warstwie fizycznej, ponieważ trzeba stwierdzić, czy np. należy obsłużyć pakiet z informacją wysłaną z warstwy wyższej (lub do niej) czy też równoległej od innego inteligentnego urządzenia (lub do niego). Ważne więc będzie potwierdzenie, czy nadawca lub odbiorca jest wiarygodny i czy ma prawo do wysłania lub odbierania danych, a co za tym idzie – do wykonania na nich operacji.

Przenoszenie pozostałych warstw do sieci Internet lub rozbudowa środowiska o kolejne aplikacje czy usługi będzie wiązała się z potrzebą efektywnej i bezpiecznej integracji oraz współpracy z wieloma innymi rozproszonymi systemami. W takim środowisku zalecane byłoby odejście od integracji „na sztywno” (ang. point to point). Alternatywą dla tego może być zastosowanie wzorców architektonicznych i integracyjnych, np. architektury zorientowanej na usługi SOA (ang. Service Oriented Architecture), a w systemach przemysłowych analogicznie ISOA (ang. Industrial SOA). Przykładową metodą integracji może być magistrala usług korporacyjnych ESB (ang. Enterprise Service Bus), a w przemyśle – analogicznie – ECS (ang. Enterprise Control System).

System przyszłości = system złożony

Reasumując wprowadzenie do tego, co nas czeka na rynku krajowym w najbliższym czasie: nieunikniony będzie wzrost złożoności systemów. Opisywany jest kontekst polski, gdyż wspomniane wyżej technologie na świecie rozwijają się przynajmniej od 2010 roku, w niektórych krajach nawet od pierwszych lat drugiego tysiąclecia. Tak więc bez względu na to, jaki kierunek rozwoju wybiorą przedsiębiorstwa, potrzeba dbania o poziom bezpieczeństwa będzie znacznie rosła. Zaprezentowana nieunikniona ewolucyjność systemów wręcz zmusza nas do oceny bezpieczeństwa z perspektywy kolejnych etapów funkcjonowania tych systemów, którymi są:

• przygotowanie (uzasadnienie biznesowe, analiza wymagań, projekt architektury systemu, koncepcja wdrożenia, a w niej m.in. plan zarządzania zmianą i ryzykiem);
• budowanie / rozbudowa / przebudowa (projekty wykonawcze, projekty i dokumentacja implementacji architektury, testów, odbiorów i przekazania systemu, dokumentacja zarządzania projektem lub zmianą);
• użytkowanie / eksploatacja / utrzymanie (projekty powykonawcze, bieżąca dokumentacja architektury systemów, instrukcja bezpieczeństwa zarządzania systemami, projekt i dokumentacja zarządzania wersją systemu);
• utylizacja / likwidacja systemu (projekt migracji lub archiwizacji danych oraz bezpiecznej likwidacji systemu z całej architektury systemów).

Przyjęcie tego punktu widzenia jest ważne, ponieważ na każdym z etapów może pojawić się wiele różnych zagrożeń. Zanim przejdę do przykładów, przytoczę podział zagrożeń bezpieczeństwa informacji i systemów teleinformatycznych w organizacjach:

• uchybienia organizacyjne;
• błędy ludzkie;
• błędy techniczne;
• działania rozmyślne;
• siły wyższe.

W dalszej części zaprezentuję przykłady z przytoczonych grup zagrożeń, występujące na etapie przygotowania. Z uwagi na ograniczenia objętościowe publikacji będą one wybiórcze.

Uchybienia organizacyjne

Idealną sytuacją byłaby możliwość wdrożenia wszystkich systemów od zera. Większość przypadków, na jakie natrafimy, to jednak rozbudowa już funkcjonujących. W tym drugim wypadku sytuacja dotyczy albo dobudowania kolejnej warstwy, albo rozbudowania systemu w obrębie już istniejącej. Niemniej we wszystkich tych ewentualnościach warto dążyć do możliwie największych standaryzacji i unifikacji, które pozwolą zminimalizować zagrożenia z grupy uchybień organizacyjnych.

Już na etapie budowania architektury systemu warto pamiętać o stworzeniu lub dostosowaniu istniejących uregulowań organizacyjnych i wdrożeniu ich w życie. Pozwoli to nie tylko je uporządkować czy sformalizować, ale i monitorować stan ich stosowania.

Przyglądając się biznesowemu uzasadnieniu dla wdrażanego systemu, można zauważyć, że celem samym w sobie nie jest wdrażanie systemu, ale umożliwienie osiągnięcia określonej wartości. Przygotowanie i realizacja wprowadzenia systemu jest jedynie środkiem lub narzędziem do realizacji zamierzenia, którym jest ta wartość. Zdarza się, że pomijane jest przygotowanie planu strategicznego, związane z pozbawieniem się ważnych informacji przy podejmowaniu trudnych decyzji, zwłaszcza podczas równolegle realizowanych wdrożeń. Brak określonych celów biznesowych prowadzi do powstania SIWZ zawierającej – oprócz formalnych elementów przetargowych – głównie funkcje. Kończy się to zwykle tym, że wdrożony system – nawet jeśli, owszem, wypełnia zadania, to nie realizuje żadnego konkretnego celu biznesowego, np. planowanego obniżenia kosztów, lub nie usprawnia procesu, a jedynie zwiększa jego złożoność.

Zagrożenia na etapie organizacji pracy

Brak prawidłowego zdefiniowania zakresu i potrzeb oraz umiejętnej zamiany ich na realne i wymierne wymagania, z uwzględnieniem występujących sprzeczności między oczekiwaniami różnych interesariuszy, to kolejny przykład prowadzący albo do rozwiązania konfliktu na późniejszych etapach wdrożenia, albo do istotnych braków czy też mało przydatnych lub zbędnych funkcji w systemie. Poważnym zagrożeniem w pierwszym przypadku jest nieplanowany wzrost kosztów spowodowanych zmianami, które są zdecydowanie tańsze na etapie projektowania niż na etapie wdrożenia, a tym bardziej – eksploatacji systemu. W drugiej sytuacji istnieje ryzyko braku możliwości spełnienia podstawowych atrybutów jakościowych lub bezpieczeństwa.

Warto zauważyć, że żaden z wykonawców nie potrafi czytać w myślach inwestora, tym samym duża odpowiedzialność w przygotowaniu się do wdrożenia leży zarówno po stronie inwestora, jak i wykonawcy. Z tego powodu coraz częściej praktykuje się budowanie zespołu po stronie inwestora, gotowego na wielodyscyplinarne ustalenia i prace, które należy przeprowadzić wspólnie z wykonawcą. Toteż nierzadko w składzie zespołu pojawiają się oprócz pracowników dziedzinowi specjaliści i konsultanci. Metoda „zaprojektuj i zrealizuj” sprawdzała się dobrze w czasach, gdy systemy były autonomiczne, niezależne od innych systemów przemysłowych i systemów IT. Dzisiaj ta metoda może prowadzić najwyżej do braku spójności między systemami na wielu poziomach, m.in. infrastruktury, oprogramowania, aplikacji czy danych.

Kolejne przypadki zagrożeń mogą być spowodowane bagatelizowaniem etapu poznania nowych procesów jeszcze przed ich wdrożeniem. Dotyczy to zarówno procesów realizowanych przez system, jak i tych odbywających się poza nim. Efektem tego jest odkrywanie systemu dopiero po jego wdrożeniu. Organizacja ma ogromny wpływ na architekturę systemu i jej bezpieczeństwo, które z kolei mają ogromny wpływ na organizację. Pozbawianie siebie jej modelu, a w ramach tego – rezygnacja ze zweryfikowanej struktury organizacji, może skutkować niewłaściwym rozłożeniem zadań wśród załogi. Skrajnym przypadkiem może być brak możliwości zmapowania nowych zadań z posiadanymi pracownikami.

Niewłaściwe wyznaczenie odpowiedzialności i kompetencji lub brak możliwości ich przydzielenia jest poważnym zagrożeniem dla obsługi, utrzymania i rozwoju nowo wdrażanego systemu. Dlatego o zasobach ludzkich, które będą potrzebne nie tylko w trakcie wdrożenia, ale i po wdrożeniu, warto pomyśleć już na etapie planowania. Podczas mówienia o zasobach ludzkich ważne jest, aby pomyśleć lub skonsultować, jakie narzędzia będą potrzebne do utrzymywania systemu w trakcie wdrożenia oraz po wdrożeniu. Stare narzędzia przy zmianie technologii często nie dają możliwości zarządzania nowym systemem, a nawet jeśli, to tylko w ograniczonym zakresie. Bez możliwości skutecznego i wiarygodnego diagnozowania systemu nawet najlepszemu specjaliście trudno jest zadbać o prawidłowy jego stan.

Wielka rola harmonogramu wdrożenia

W zakresie planowania projektu można wykazać zagrożenia w postaci braków w harmonogramie wdrożenia, zwłaszcza w obszarze procesu wdrożenia systemu przemysłowego i jego integracji z istniejącym środowiskiem. Przyczyny należy się dopatrywać w tym, że zwykle przetarg wygrywają firmy budowlane, mające niewielkie pojęcie na temat złożoności systemów przemysłowych oraz IT, czerpiące swoją wiedzę z doświadczenia zdobytego w poprzednich latach. Okres historyczny, który służy im za podstawę, jest błędnym punktem odniesienia. To powoduje, że harmonogram w zakresie konstrukcji budynku i technologii jest zdecydowanie bardziej prawidłowy niż w zakresie systemów mających przynieść wartość związaną z automatyzacją procesów przemysłowych.

Zdarza się, że ta część harmonogramu jest szczątkowa lub niepełna, dlatego też czas potrzebny na wdrożenie jest niedoszacowany. Dodatkowo bagatelizowana lub wręcz pomijana jest realna ocena złożoności systemu. Wdrożony w taki sposób niekompletny system jest poważnym zagrożeniem bezpieczeństwa, mimo że podstawowe zadania, do których został stworzony, działają poprawnie. Dlatego też w harmonogramie warto uwzględnić testy odbiorowe nie tylko części budowlanej i technologicznej, ale przede wszystkim scenariusze testów systemu przemysłowego i IT. Powinny one być realizowane regularnie na wielu poziomach zarówno przez wykonawcę, jak i inwestora.

Zakres testów szczegółowych powinien obejmować poziomy od komponentów, szablonów i elementów cząstkowych aż po moduły i interakcję między nimi. Na wyższym poziomie szczegółowości zalecane jest opracowanie scenariuszy użycia systemu w warunkach pracy normalnej i awaryjnej. Często planowany czas odbiorów jest niewystarczający, czego powodem jest uwzględnienie odbiorów ilościowych, a pominięcie lub niedoszacowanie czasowe odbiorów uwzględniających testy jakościowe, wydajnościowe i bezpieczeństwa całego systemu.

Dopasowanie zespołu jako jeden czynników sukcesu

Dobrze, jeśli decyzja inwestora o powołaniu wielodyscyplinarnego zespołu wynika z wcześniej postawionego sobie celu nadrzędnego: ratowania obecnych systemów lub rozpoczęcia procesu długofalowej spójnej rozbudowy. W tym pierwszym wypadku wystarczą osoby pełniące funkcję „strażaka” w każdej z dziedzin. W drugim – dobrze jest osiągnąć efekt synergiczny z połączenia ról „policjanta” i „strażaka”.

Przykładem efektu synergii są wzajemne pobudzanie czy zwiększanie czujności całego zespołu, które przekładają się m.in. na podniesienie poziomu bezpieczeństwa. Obie role są ważne, zwłaszcza że znacznie się od siebie różnią. Pierwsza polega na „gaszeniu pożarów”, czyli rozwiązywaniu złożonych branżowych problemów natychmiast. Nastawiona jest raczej na rozwiązania tymczasowe lub tzw. „obejścia”, ale także pozwala utrzymać projekt w ryzach czasowych. Ważna jest w sytuacjach, gdy napotkane błędy proceduralne lub systemowe nie mogą zostać szybko poprawione, np. z powodu wyższego priorytetu postawionego rozliczeniom z dofinansowań. Druga funkcja skierowana jest na szukanie zgodności wdrażanego systemu z założeniami i celami, odnajdywanie i usuwanie przyczyn ewentualnych problemów zamiast samych objawów, a także zbieranie doświadczeń i wniosków pozwalających na poprawę długofalowych realizacji kolejnych wdrożeń.

Dobrze jest zadbać o to, aby obie role się uzupełniały, a nie wykluczały czy konkurowały ze sobą, zwłaszcza że różne jest ich wykorzystanie na kolejnych etapach w cyklu funkcjonowania systemu. Nie jest tajemnicą, że „policjant” z zasady nie jest lubiany. Dlatego warto pomyśleć o postawieniu w tej roli zewnętrznego eksperta branżowego lub zewnętrzną firmę. Ludzie niestety często mylnie utożsamiają rolę z człowiekiem, przez co zlecanie niewdzięcznej roli pracownikowi inwestora może być kłopotliwe w późniejszym okresie utrzymania czy rozwoju kolejnych systemów.

Bez „namaszczenia” konsultantów przez inwestora jakiekolwiek funkcje mają znikomą rolę w efekcie prac zespołów, a tym samym – w osiągnięciu celów cząstkowych i strategicznych. Zaleca się więc, aby inwestor powołujący konsultantów odpowiednio ich „umocował”. Należy się też liczyć z tym, że niezależne konsultacje inwestora ze specjalistami branżowymi w zakresie systemów przemysłowych i IT mogą być oceniane jako marnowanie czasu potrzebnego na posuwanie do przodu prac budowlanych. Wynika to oczywiście z braku pełnej wiedzy na temat złożoności docelowego systemu, a nie tylko jego części objętej jednym z przetargów.

Zaleca się, żeby dobierać zespół po stronie inwestora w taki sposób, aby powołany do wykonania analizy, opracowania architektury systemu i długofalowej koncepcji jej wdrożenia, mógł koordynować kolejne prace zespołów projektowych. Istotne jest to, gdy projekt ma być długofalowy i podzielony na wiele etapów związanych z automatyzacją wielu lub wszystkich obiektów firmy. Na początkowym etapie brakuje zwykle formuł jasno definiujących obszar zarządzania wiedzą. Pojawiają się one w trakcie poznawania i analizowania środowiska. Z tego powodu wiedza jest rozległa, poziom szczegółowości tworzonej dokumentacji jeszcze ogólny, a dostępna dokumentacja infrastruktury zwykle szczątkowa lub mało aktualna.

W związku z powyższym w celu uniknięcia skutków nieciągłości działania nie zaleca się zmiany lub likwidacji tego zespołu zaraz po etapie rozpoczynającym projekt. Może to skutkować potrzebą ponownego poświęcenia czasu i pieniędzy na zapoznanie się każdego nowego zespołu ze środowiskiem wdrożenia i architekturą systemów dotychczasowych oraz tych będących w trakcie wdrożenia. Poza tym nowy zespół może nie identyfikować się z pierwotnymi założeniami i celami, na które nie miał wpływu. To może prowadzić do niechęci do ich realizacji, a w efekcie – do wielopoziomowego braku spójności z wdrożonymi wcześniej częściowo lub całkowicie rozwiązaniami. Skutkiem mogą być szczątkowo uruchomione części systemu pozostawione bez opieki i właściciela, co może być poważną luką w zabezpieczeniach systemu końcowego.

Myślmy proaktywnie!

W przypadku inwestycji wymagających przetargu można też wykazać mniej lub bardziej świadome niedoszacowanie części związanej z systemem przemysłowym, związane z chęcią wygrania przetargu za najniższą cenę. Zdarza się, że generalny wykonawca przekazuje taki stan podwykonawcy systemu przemysłowego i zostawia go z odpowiedzialnością za poprawne wykonanie całości. Ten przykład ewidentnie ma ogromny wpływ na jakość – a tym samym bezpieczeństwo – wdrażanych systemów przemysłowych już na etapie planowania i kosztorysowania.

Ostatni przypadek w tej grupie wynika z braku przekonania do podejścia proaktywnego, będącego przeciwieństwem reaktywnego. Podczas projektowania budynku dla każdego oczywiste jest wykonanie dla niego projektu architektonicznego, który pokazuje estetykę obiektu, jego wygląd, funkcjonalność itd. Zawiera on różne perspektywy, m.in. schemat ogólny budynku w przekroju, jego profil, rozmieszczenie na działce, czasami projekty instalacji. Warto się w tym momencie zastanowić, dlaczego tak naprawdę jest on wykonywany. Choćby dlatego, że tak pokazany budynek – często nie tylko w 2D, ale i 3D – pozwala uzmysłowić koszty przewidziane na jego wybudowanie. Różnym ekipom budowlanym (interesariuszom) umożliwia pokazanie punktów wspólnych i kolizyjnych.

Ma to przełożenie na bezpieczeństwo procesu budowy, budynku jako konstrukcji, a także ludzi w nim przebywających. Analogicznie jest z systemami przemysłowymi i IT, które można porównać do projektu budowlanego, a w przypadku ich większej ilości – do projektu urbanistycznego. Czy takie zestawienie dziedzin wystarcza, żeby przekonać do podejścia proaktywnego?

Projekt architektury IT i systemów

Warto zastanowić się nad projektem architektury systemu lub systemów. Same wymagania to jeszcze nie jest architektura. Gdyby te same wymagania zostały przekazane dwóm różnym architektom, to zaproponują system spełniający je, ale o różnej architekturze, choćby dlatego że jest to zespół wielu perspektyw przedstawionych na diagramach powiązanych ze sobą i obrazujących system.

Wyobraźmy sobie sytuację, w której zapytamy wielu lekarzy specjalistów o ich punkt widzenia i poprosimy o przedstawienie diagramu przedstawiającego człowieka. Każdy z nich przedstawi coś innego. Powiązane diagramy układów krwionośnego, nerwowego, kostnego, skóry, psychiki będą jednak odzwierciedlały budowę człowieka i jego relacje z innymi ludźmi oraz środowiskiem, a także ich wzajemny wpływ na siebie. Przełóżmy to na architekturę systemów: jest to swego rodzaju dokumentacja tego, co ma powstać lub tego, co już istnieje.

Każdy działający system ma swoja architekturę, tylko czy zwykle nie jest tak, że nie ma osoby, która ją zna? Jest ona ukryta w szczątkowych albo zbyt zawiłych dokumentacjach tekstowych, które zwykle lądują w segregatorach na dnie szuflady. Czasami kryje się w kodzie programu binarnego, niedostępnego dla użytkownika i programisty, lub też w głowach specjalistów, których nieobecność powoduje brak dostępu do wiedzy na jej temat. Są również przypadki, gdy jest dostępna i otwarta technicznie, lecz prawnie ograniczona do udostępniania. Jak w takim przypadku w zespołach wielodyscyplinarnych świadomie analizować, planować rozwój i budowę bezpiecznego systemu i systemów, a zwłaszcza połączeń między nimi? Jak bezpiecznie przekazywać informacje wszystkim interesariuszom w zakresie wystarczającym do realizacji wdrożenia?

Skoro wspomniałem o dokumentacji – jaka ona powinna być? Na pewno użyteczna dla wielu interesariuszy, ukazująca systemy z wielu perspektyw. Zwykle prezentuje się w niej punkt widzenia losowych podmiotów i daje możliwość weryfikacji, m.in. bezpieczeństwa, tylko z ich perspektywy. Użyteczność dokumentacji to także jej jednoznaczność, wiarygodność, aktualność, modyfikowalność i czytelność. Aby ją osiągnąć, należy już od etapu planowania starać się stosować przeznaczone do tego narzędzia (oprogramowanie), notacje, normy, najlepiej ustandaryzowane dla każdej z warstw, czyli jednoznaczne w zapisie i odczycie.

Jako przykład może posłużyć dokumentacja warstwy fizycznej elektryki. Zakładając, że na etapie tworzenia projektów budowlanych schematy elektryczne tworzone są z zastosowaniem obowiązujących norm, możemy bez zastanowienia powiedzieć, iż dla wszystkich znających te zasady jasne będzie, że kółko z wpisanym wewnątrz krzyżykiem oznacza żarówkę. Czy zatem poznanie standardów lub norm dokumentacyjnych na każdej innej warstwie systemów jest ważne? W przypadku tworzenia architektury systemu warto powołać się na przydatne notacje, m.in. BMM, BPMN, UML, SysML, AutomationML czy ArchiMate.

Dobór odpowiednich metodologii czy narzędzi, w których można zrealizować to zadanie, jest już poza tematem. Można stworzyć i zastosować swoją własną notację w obrębie małej, zamkniętej grupy. Należy jednak liczyć się z tym, że albo nie będzie ona jednoznaczna dla wszystkich, albo będzie wymagała opracowania dokumentów standaryzujących i wyjaśniających jej znaczenie. Każde odstępstwo od zasad będzie więc zwiększać ryzyko nieprawidłowej komunikacji między interesariuszami, zwłaszcza w zakresie tożsamego rozumienia wymagań i architektury systemu na wszystkich etapach jego działania. W konsekwencji może to prowadzić do pojawiania się kolejnych zagrożeń z grupy „błędy ludzkie”.

Łukasz Wojtkowiak