Sytuacja wyjściowa: gdy „stare, ale działa” zaczyna być problemem
Wyobraź sobie linię produkcyjną, która od kilkunastu lat pracuje bez poważniejszych awarii. SCADA na starym serwerze, sterowniki, panele HMI – wszystko spięte, wszyscy zadowoleni. Któregoś dnia serwer się nie podnosi. Kopia obrazu dysku istnieje, ale po przywróceniu na nowy sprzęt oprogramowanie żąda aktywacji, której nie da się już wykonać. Dostawca: produkt EOL, brak wsparcia, brak prawa do przeniesienia licencji na inny serwer. Produkcja stoi, a każda godzina to wymierna strata.
W wielu zakładach przemysłowych, energetycznych czy wodociągowych stan licencji w systemach OT jest traktowany jak „sprawa drugorzędna”, dopóki wszystko działa. Problem zaczyna się, gdy dochodzi do awarii, incydentu bezpieczeństwa albo audytu zewnętrznego. Wtedy przestarzałe licencje przestają być „kwestią księgową”, a stają się realnym zagrożeniem dla ciągłości biznesu i bezpieczeństwa ludzi.
Główny cel to zidentyfikować, które stare licencje i systemy OT są tylko „nieidealne”, a które naruszają minimalne standardy bezpieczeństwa i zgodności. Dalej – uporządkować je według ryzyka i zaplanować konkretne działania: od audytu i rozmów z dostawcami po migrację albo świadomą, udokumentowaną akceptację ryzyka.
Punkt kontrolny 1: Rozpoznaj, z czym naprawdę masz do czynienia – mapowanie systemów OT i typów „przestarzałości” licencji
Minimum informacji o każdym systemie OT
Bez rzetelnej listy systemów OT cała dyskusja o przestarzałych licencjach jest teoretyczna. Pierwszy punkt kontrolny to stworzenie mapy: system → funkcja → licencja → ryzyko. Nie chodzi o perfekcję, lecz o minimum danych, które pozwoli podjąć decyzję.
Dla każdego istotnego systemu OT zbierz co najmniej:
Nazwę systemu i funkcję w procesie – np. „SCADA linii mieszania farb”, „DCS kotła parowego”, „HMI stacji pomp”.
Producenta i produkt – nazwa dostawcy, wersja oprogramowania (np. SCADA 7.1, firmware sterownika 5.3).
Typ licencji – wieczysta, czasowa, na liczbę tagów, na CPU, na stację inżynierską, na użytkownika, dongle sprzętowy itp.
Identyfikatory – numery seryjne, ID licencji, klucze, numer dongla, parametry sprzętu powiązane z licencją.
Datę wdrożenia i zakres pierwotnej dostawy – co było objęte projektem, jakie moduły i opcje licencyjne.
Informację o wsparciu – data EOL/EOS (koniec produkcji/końca wsparcia), ostatnia znana umowa maintenance/serwisowa.
Właściciela biznesowego – kto w organizacji odpowiada za dany proces/sytem (kierownik obszaru, dyrektor produkcji, OT manager).
Typowe źródła tych danych:
dokumentacja projektowa i protokoły odbioru,
umowy z integratorami i producentami,
faktury, zamówienia, korespondencja z dostawcami,
interfejsy administracyjne systemów (ekrany „About”, zakładki licencyjne, pliki licencyjne),
informacje od pracowników, którzy uczestniczyli w uruchomieniu.
Przykład sygnału ostrzegawczego: linia pakująca sterowana archaicznym panelem HMI, gdzie nie ma żadnej papierowej dokumentacji dotyczącej licencji na środowisko programistyczne sterownika. Sterownik działa, ale nie wiesz, czy posiadasz legalne prawo do modyfikacji programu ani czy możesz odtworzyć system po wymianie sprzętu. W razie awarii będziesz działał „na ślepo”.
Jeżeli dla istotnej części systemów OT nie jesteś w stanie zdobyć nawet powyższego minimum, to sygnał, że ryzyko jest już wysokie – przede wszystkim operacyjne. Brak danych o licencjach często idzie w parze z brakiem planu odtworzeniowego.
Typowe rodzaje „przestarzałości” licencji w OT
Nie każda stara licencja jest od razu problemem prawnym. Często główne ryzyko leży w braku wsparcia i niemożności odtworzenia systemu. Dobrze rozróżnić kilka kategorii przestarzałości:
„Stara, ale legalna” licencja – licencja wieczysta, prawidłowo nabyta, mimo że system jest dawno poza mainstreamem. Produkt może być wciąż wspierany w trybie „extended support” albo nawet już nie wspierany, ale prawo używania dotyczy aktualnej instalacji.
Produkt EOL (End of Life) / EOS (End of Support) – dostawca zakończył rozwój, nie ma patchy bezpieczeństwa, często brak kompatybilności z nowym sprzętem/OS. Licencja może być formalnie ważna, ale z punktu widzenia bezpieczeństwa i odtwarzalności system jest „osierocony”.
Wygasła umowa maintenance/upgrade – legalne prawo do używania obecnej wersji, ale brak prawa/technicznej możliwości aktualizacji. Ryzyko rośnie, gdy nowy sprzęt/OS wymaga nowszej wersji.
Licencja powiązana ze sprzętem – prawo do używania dotyczy konkretnego numeru CPU, MAC adresu, dongla sprzętowego. Wymiana sprzętu może wymagać nowej licencji. Jeżeli umowa tego nie przewiduje, każda awaria sprzętu może oznaczać spór z dostawcą.
Brak licencji na rozszerzenia – SCADA działa legalnie, ale część używanych driverów komunikacyjnych, modułów historycznych czy raportowych nie ma potwierdzonej licencji (np. „tymczasowo pożyczone” podczas uruchomienia).
Licencja czasowa, która wygasła – kontynuacja używania systemu po wygaśnięciu licencji okresowej jest najprostszą ścieżką do naruszeń prawnych.
Sygnały ostrzegawcze, że licencja może być przestarzała lub nieadekwatna:
brak faktur lub zamówień na maintenance/upgrade od wielu lat,
brak odpowiedzi dostawcy na zgłoszenia dotyczące tego produktu (system niesupportowany),
brak nowych wersji pod obsługiwane obecnie systemy operacyjne,
brak jasnej informacji, czy licencję wolno przenieść na nowy sprzęt.
Jeśli licencja jest stara, ale w pełni legalna i dotyczy systemu o niskiej krytyczności, można rozważać świadome utrzymywanie takiego stanu przez jakiś czas. Gdy jednak produkt jest EOL, a jednocześnie kluczowy dla ciągłości produkcji lub bezpieczeństwa, przestarzałość licencji przestaje być „niewygodą” i staje się istotnym zagrożeniem.
Specyfika systemów OT wobec IT przy licencjonowaniu
Systemy OT różnią się od typowych systemów IT nie tylko technologią, ale też filozofią cyklu życia i modelami licencjonowania. To powoduje, że przestarzałe licencje w OT są z zasady bardziej niebezpieczne.
Kluczowe różnice:
Bardzo długi cykl życia – systemy sterowania pracują 10–20 lat (a nawet dłużej), podczas gdy typowy cykl odświeżania IT to 3–5 lat. Oznacza to, że niemal każdy system OT w pewnym momencie będzie działał na przestarzałych komponentach.
Silne powiązanie licencji ze sprzętem – licencje dla sterowników PLC, DCS, HMI są często przypisane do konkretnego CPU, numeru seryjnego, slotu, a nie do „organizacji” lub „użytkownika”. W IT migracja VM na inny serwer zwykle nie narusza licencji; w OT wymiana modułu sterownika może wymagać nowego zakupu.
Systemy czasu rzeczywistego i deterministyczne – zmiana wersji oprogramowania, sterownika, systemu operacyjnego może wpływać na czasy reakcji, deterministykę i stabilność procesu. To czyni upgrade ryzykownym i zniechęca do aktualizacji.
Vendor lock-in – w OT często nie ma łatwej alternatywy dla producenta systemu. Zmiana platformy to gigantyczny projekt migracji (hardware, software, dokumentacja, testy bezpieczeństwa procesowego). Dostawca to wie i nierzadko wykorzystuje w modelu licencjonowania.
Jeśli podejście do licencji OT jest takie jak do licencji biurowych, organizacja szybko wpada w pułapkę: „nie ruszamy, bo działa”, przy jednoczesnym narastaniu ryzyka prawnego, operacyjnego i bezpieczeństwa. Różnica jakościowa polega na tym, że awaria systemu OT zatrzymuje rzeczywisty proces technologiczny, a nie tylko dostęp do poczty.
W skrócie: jeśli nie masz mapy „co, gdzie i na jakich licencjach pracuje w OT”, to każdy incydent może ujawnić nie tylko luki bezpieczeństwa, ale i niezgodności licencyjne. Punkt kontrolny numer jeden to zawsze rozpoznanie stanu faktycznego, nawet jeśli wymaga to wykonanania żmudnej pracy analitycznej.
Punkt kontrolny 2: Oceń trzy wymiary ryzyka – prawne, operacyjne, bezpieczeństwa
Ryzyko prawne – kiedy licencja przestaje chronić użytkownika
Licencja ma dwie strony: daje prawo używania, ale też nakłada ograniczenia. Gdy te ograniczenia są naruszane, organizacja traci ochronę licencyjną i naraża się na roszczenia. W OT zwykle nie chodzi o masowe „piractwo”, ale o szereg szarych stref.
Typowe scenariusze ryzyka prawnego w systemach OT:
Dalsze używanie po wygaśnięciu licencji czasowej – SCADA z licencją na 3 lata, po czym system jest wciąż używany bez odnowienia. Formalnie prawo używania wygasło, mimo że technicznie aplikacja działa.
Instalacje ponad limit – jedna licencja na stanowisko inżynierskie używana do instalacji oprogramowania programistycznego na kilku laptopach, bo „trzeba szybko zrobić zmianę w linii”. Każde dodatkowe stanowisko jest użyciem bez uprawnień.
Klonowanie obrazów dysków – kopiowanie maszyny z aktywowaną licencją na kolejne serwery/proxy VM w ramach „zapasowego środowiska”, bez sprawdzenia, czy EULA pozwala na kopie zapasowe i w jakim zakresie.
„Zapasowe” klucze od integratora – integrator zostawia dodatkowe klucze/dongle „na wszelki wypadek”, bez formalnego potwierdzenia licencji od producenta. Przy audycie producenta taki klucz może zostać uznany za nielegalny.
Zapisy w EULA, które są sygnałem ostrzegawczym:
zakaz przenoszenia licencji na inny sprzęt bez zgody producenta,
brak prawa do tworzenia kopii zapasowych (poza jedną kopią archiwalną),
ograniczenie do konkretnej lokalizacji geograficznej lub jednego zakładu,
zakaz używania w środowisku produkcyjnym (czasem dotyczy „demo” czy „developer edition”, które w praktyce sterują realnym procesem).
Konsekwencje mogą obejmować:
roszczenia finansowe (dopłata do właściwej liczby licencji, kary umowne),
wymuszoną migrację na nowy model licencjonowania, często na mniej korzystnych warunkach,
negatywne wyniki audytów klientów, jednostek certyfikujących lub regulatorów,
skrajnie – konieczność wyłączenia systemu używanego niezgodnie z prawem.
Jeśli system jest krytyczny, a jednocześnie używany niezgodnie z licencją (np. przekroczone limity, wygasła licencja czasowa), utrzymujesz podwójne ryzyko: w razie incydentu stajesz przed wyborem między kontynuowaniem naruszenia a zatrzymaniem produkcji. To typowa sytuacja „pod ścianą”, której lepiej zapobiegać, niż w niej lądować.
Ryzyko operacyjne – co się stanie przy awarii
Drugim wymiarem jest pytanie: czy da się szybko i legalnie odtworzyć system po awarii. Samo to, że system obecnie działa, nie znaczy, że można go bezpiecznie przenieść lub odtworzyć.
Scenariusz awarii serwera SCADA:
Serwer się psuje, dysk jest uszkodzony, brak aktualnej kopii systemu.
Posiadasz stare nośniki instalacyjne i klucz licencyjny, ale system działał na serwerze z Windows Server, który nie jest już dostępny na rynku.
Nowy serwer nie przyjmuje starego systemu operacyjnego, a nowa wersja SCADA, która działa na nowszym OS, wymaga uaktualnienia licencji i licencjonowania nowych sterowników PLC.
Dostawca informuje, że stara wersja jest EOL i nie wspiera przeniesienia licencji na nowy sprzęt.
Konsekwencja: systemu nie da się przywrócić w akceptowalnym czasie (RTO), a każda próba „obejścia” wymaga naruszenia licencji lub improwizowanych rozwiązań. Jeśli SCADA steruje istotną częścią produkcji lub bezpieczeństwem instalacji, mówimy o bezpośrednim zagrożeniu ciągłości biznesu.
Przy ocenie ryzyka operacyjnego ustanów jasne kryteria krytyczności:
Czy utrata systemu zatrzyma produkcję lub usługi krytyczne?
Czy system wpływa na bezpieczeństwo ludzi lub środowiska? (np. sterowanie ciśnieniem, temperaturą, wentylacją, zasilaniem)
Jaki jest realny czas odtworzenia przy obecnym stanie licencji i dokumentacji?
Czy istnieje zweryfikowana i przetestowana ścieżka odtworzenia? (procedury DR, obraz systemu, dostępne nośniki instalacyjne, aktywne wsparcie producenta)
Jeśli na któreś z tych pytań odpowiedź brzmi „nie” albo „nie wiemy”, to sygnał ostrzegawczy. Oznacza to, że przestarzała licencja nie jest tylko formalnością, ale realnie podnosi prawdopodobieństwo przestoju, który trudno będzie zakończyć w akceptowalnym czasie. Punkt kontrolny dla właściciela obszaru OT jest prosty: czy w razie fizycznej awarii sprzętu ktoś potrafi dziś, zgodnie z licencją, postawić ten system od zera.
Przy analizie ryzyka operacyjnego warto przejść od ogólnych stwierdzeń do konkretnych ograniczeń. Przykładowo: jeśli licencja zabrania przenoszenia na inny serwer, to wymiana sprzętu staje się projektem licencyjnym, a nie tylko zadaniem dla utrzymania ruchu. Jeśli brak prawa do kopii zapasowej lub konieczne jest każdorazowe uzyskanie zgody producenta na odtworzenie, to plan DR oparty wyłącznie na snapshotach VM jest iluzoryczny. Im bardziej proces jest krytyczny, tym mniej „uznaniowych” elementów powinno być w procedurze odtwarzania.
Trzeba też jasno rozgraniczyć rozwiązania akceptowalne „na razie” od tych dopuszczalnych w sytuacji awaryjnej. Jeśli dziś właściciel procesu świadomie toleruje pojedynczy serwer bez klastrowania i z przestarzałą licencją, to minimum stanowi udokumentowany scenariusz awaryjny: jakie kroki, w jakiej kolejności, z czyim udziałem oraz na jakich warunkach licencyjnych. Brak takiego scenariusza oznacza, że przy pierwszej większej awarii decyzje będą podejmowane ad hoc, często pod presją produkcji, co zwykle kończy się łamaniem licencji lub prowizorycznymi obejściami na lata.
Z perspektywy zarządzania ryzykiem kluczowe jest odróżnienie systemów, które „da się wyłączyć” od tych, których zatrzymanie generuje kaskadę skutków biznesowych i bezpieczeństwa. Jeśli system OT można legalnie i szybko odtworzyć na nowym sprzęcie – ryzyko operacyjne jest względnie niskie, nawet przy starszych licencjach. Jeśli do odtworzenia potrzebne są wygasłe produkty, nieistniejące już modele licencji lub zgoda producenta, której realnie nie da się uzyskać w nocy z soboty na niedzielę – taki system powinien znaleźć się wysoko na liście priorytetów modernizacji lub renegocjacji licencji.
Ostateczna decyzja, czy akceptować przestarzałą licencję w krytycznym systemie OT, powinna wynikać z trzech prostych punktów kontrolnych: po pierwsze, czy użycie jest zgodne z prawem i nie grozi natychmiastowym sporem licencyjnym; po drugie, czy system można odtworzyć w zadanym czasie bez łamania warunków licencji; po trzecie, czy scenariusz awaryjny nie generuje dodatkowego ryzyka dla ludzi, środowiska lub reputacji firmy. Jeżeli choć jeden z tych warunków nie jest spełniony, przestarzała licencja przestaje być tematem „na później” i powinna trafić na listę zadań do zaplanowania z konkretnym terminem i odpowiedzialnym właścicielem.
Źródło: Pexels | Autor: Ann H
Ryzyko bezpieczeństwa – przestarzałe licencje jako blokada dla patchowania
Trzeci wymiar ryzyka to bezpieczeństwo. W OT przestarzała licencja bardzo często oznacza także przestarzałe, niełatane oprogramowanie – nie z lenistwa administratorów, lecz z powodu ograniczeń licencyjnych i braku wsparcia producenta.
Typowe zależności między licencją a bezpieczeństwem:
Brak prawa do aktualizacji – umowa maintenance wygasła, więc legalny dostęp do nowych wersji i poprawek bezpieczeństwa jest zablokowany. System działa, ale każda nowo wykryta luka zostaje na stałe.
Aktualizacja wymaga zmiany licencji – przejście z wersji X na Y to nie tylko upgrade techniczny, ale też migracja na nowy model licencjonowania (np. subskrypcja zamiast licencji bezterminowej). Z obawy przed kosztami aktualizacje są odkładane.
Patchowanie zależne od konkretnego OS – SCADA działa wyłącznie na starej wersji systemu operacyjnego, która nie jest już wspierana. Wsparcie OT blokuje aktualizacje OS, bo mogłyby „rozsypać” aplikację, więc system pozostaje z znanymi podatnościami.
Brak testowego środowiska z legalną licencją – formalnie licencja obejmuje jeden węzeł produkcyjny. Brak pełnoprawnej instancji testowej uniemożliwia bezpieczne sprawdzenie patchy i zmian konfiguracyjnych.
Przy analizie bezpieczeństwa systemu z przestarzałą licencją podstawowe pytania kontrolne:
Czy producent nadal publikuje łatki bezpieczeństwa dla używanej wersji?
Czy licencja (i maintenance) daje prawo do pobrania i instalacji tych łatek?
Czy istnieje środowisko testowe z legalną licencją, na którym można zweryfikować poprawki?
Czy w ostatnich 12 miesiącach wykonywano jakiekolwiek aktualizacje tego systemu?
Jeżeli odpowiedzi układają się w ciąg „nie / nie wiemy”, system w praktyce staje się „zamrożony”. Wtedy każda nowa luka publikowana w biuletynach bezpieczeństwa przekłada się bezpośrednio na rosnące, niekompensowane ryzyko. Punkt kontrolny jest prosty: jeśli nie da się legalnie i technicznie załatać krytycznych podatności, trzeba ten system traktować jak wysokiego ryzyka – z dodatkowymi barierami (segmentacja, monitoring, ograniczenie zdalnego dostępu) i planem wyjścia z obecnej wersji.
Punkt kontrolny 3: Inwentaryzacja licencji w środowisku 24/7 – jak zbierać dane, nie zatrzymując produkcji
Inwentaryzacja licencji w OT to nie klasyczne „zainstaluj agent i przeskanuj sieć”. Środowisko produkcyjne pracuje 24/7, a każda ingerencja musi być przewidywalna i odwracalna. Dlatego lepiej podejść do tematu etapowo, z jasnym zakresem i priorytetami.
Rozdziel systemy według krytyczności i „dotykalności”
Pierwszym krokiem jest określenie, które systemy można bezpiecznie dotknąć technicznie, a które wymagają wyłącznie „offlinowego” podejścia (dokumenty, rozmowy, oględziny na miejscu).
Systemy wysokiej krytyczności / bez możliwości zatrzymania – główne serwery SCADA, ESD, DCS. Tu zbieranie danych o licencjach odbywa się przede wszystkim przez:
odczyt informacji z interfejsu aplikacji w oknach serwisowych,
rozmowy z integratorami i dostawcami (jakie licencje zostały dostarczone i kiedy).
Systemy średniej krytyczności – stacje inżynierskie, serwery raportowe, archiwizacja danych procesowych. Tu można częściej użyć bezagentowych skanów sieci (np. odczyt banerów, wersji), o ile zostało to uzgodnione z OT i przetestowane.
Systemy pomocnicze – narzędzia diagnostyczne, terminale HMI w warsztatach, komputery serwisowe. Tu zwykle można pozwolić sobie na bardziej klasyczną inwentaryzację IT, z oprogramowaniem do zarządzania zasobami.
Jeśli nie ma jasnego rozdziału, pojawia się typowa pułapka: albo nic nie jest skanowane „żeby nie dotknąć produkcji”, albo skanowane jest wszystko jednym narzędziem, co prowadzi do incydentów (np. zawieszone sterowniki po agresywnym skanowaniu portów).
Źródła danych o licencjach – co zebrać, zanim wejdziesz na produkcję
Zanim ktoś zaloguje się do systemu OT tylko po to, by sprawdzić numer licencji, warto wyciągnąć maksimum informacji z biura. Typowe źródła, które często są niedoceniane:
Umowy ramowe i aneksy – określają typ licencji (wieczysta vs subskrypcja), zasady przenoszenia, warunki maintenance. Pozwalają stwierdzić, czy przeniesienie na nowy serwer jest w ogóle dopuszczalne.
Faktury i protokoły odbioru – liczba pozycji, nazwy SKU, numery części. Z nich można wywnioskować, ile stanowisk/instancji powinno być legalnie zainstalowanych.
Dokumentacja powykonawcza integratora – opisy konfiguracji, spisy stacji, użyte wersje oprogramowania. Jeśli integrator dobrze prowadził projekt, to tam jest mapa, której nie trzeba odkrywać od zera.
Rejestry zmian (change management) – jeśli istnieją, pokazują, kiedy i gdzie doinstalowano dodatkowe komponenty lub rozszerzono licencje.
Punkt kontrolny: jeśli już na poziomie dokumentów nie da się określić, ile licencji i jakiego typu powinno pracować w zakładzie, każda inwentaryzacja techniczna będzie działaniem częściowo „po omacku”. Wtedy sensowne jest rozpoczęcie od odtworzenia minimalnej konfiguracji referencyjnej na papierze (co musiało powstać, aby linia ruszyła) i porównania jej ze stanem obecnym.
Bezpieczne metody zbierania informacji z działających systemów
Gdy zakres jest już znany, trzeba wybrać metody, które nie zakłócą pracy instalacji. Kilka praktycznych zasad:
Zasada „read-only” – dopuszczalne są tylko takie działania, które nie zapisują nic na systemie (przegląd okien konfiguracyjnych, eksport raportu stanu licencji z aplikacji, odczyt logów). Żadnych „czyszczących” skryptów, aktualizacji agentów itp. bez osobnej analizy.
Tryb ręczny zamiast automatycznego – w krytycznych systemach lepiej, aby osoba z OT samodzielnie wyklikała wymagane informacje według przygotowanej checklisty, niż instalować automatyczne narzędzie skanujące sieć.
Okna serwisowe – każda czynność (nawet samo logowanie na sesję RDP) powinna być wykonywana w uzgodnionym oknie czasowym, z możliwością cofnięcia zmian i z osobą odpowiedzialną z utrzymania ruchu na linii.
Rejestr działań audytowych – krótki protokół: kto, kiedy, na jakim systemie był i co sprawdzał. Przydaje się zarówno przy analizie incydentów, jak i przy kolejnych przeglądach.
Jeśli inwentaryzacja jest planowana jak projekt techniczny z udziałem OT, ryzyko zakłóceń spada. Gdy jest traktowana jak „zadanie biurowe” delegowane bezpośrednio do działu IT, pojawia się ryzyko niekontrolowanych działań w krytycznym środowisku.
Minimum danych, które trzeba zebrać dla każdej instancji
Żeby później móc świadomie podjąć decyzje (akceptacja ryzyka vs modernizacja), dla każdej istotnej instancji oprogramowania OT przydaje się ten sam, prosty zestaw pól:
nazwa systemu i rola (SCADA, HMI, historyk, narzędzie inżynierskie),
wersja oprogramowania i systemu operacyjnego,
typ licencji (wieczysta/czasowa/subskrypcja),
informacja o maintenance (aktywny/wygaśnięty, data końca),
liczba instancji/stanowisk dopuszczonych przez licencję,
liczba instancji/stanowisk faktycznie używanych,
możliwość przeniesienia licencji na nowy sprzęt (tak/nie/warunkowo),
status wsparcia producenta (wspierane/EOL/EOS),
kontakt do dostawcy/OEM/integratora odpowiedzialnego za ten komponent.
Punkt kontrolny: jeśli dla danego systemu brakuje więcej niż połowy tych danych, trudno jest racjonalnie ocenić ryzyko i przygotować plan działania. Taki system automatycznie trafia na listę „do dalszego rozpoznania” – z przypisanym właścicielem i terminem uzupełnienia informacji.
Punkt kontrolny 4: Kiedy ryzyko jest już nieakceptowalne – sygnały ostrzegawcze
Nie każda przestarzała licencja wymaga natychmiastowej modernizacji. Natomiast są sytuacje, w których kontynuowanie pracy „jak jest” oznacza poważne przekroczenie akceptowalnego ryzyka biznesowego i bezpieczeństwa. Wtedy potrzebna jest decyzja na poziomie właściciela procesu lub zarządu, a nie tylko działu technicznego.
Zestaw czerwonych flag dla systemów OT
Przy audytach krytycznych systemów powtarza się kilka powtarzalnych sygnałów, że licencje weszły już w strefę „nie do zaakceptowania”:
Wygasła licencja czasowa w systemie krytycznym – system steruje produkcją lub bezpieczeństwem, a prawo używania formalnie już nie istnieje. Producent w każdej chwili może zakwestionować dalszą eksploatację.
Brak jakiegokolwiek wsparcia producenta – system jest EOL/EOS, nie ma możliwości przedłużenia maintenance ani uzyskania oficjalnych łatek. Jedynym „wsparciem” są nieformalne kontakty z integratorem.
Brak legalnej ścieżki odtworzenia po awarii – brak nośników, brak praw do ponownej instalacji lub przeniesienia licencji, stary OS niedostępny, a nowa wersja wymaga projektu migracyjnego.
Łączenie nielegalnych obejść z funkcjami bezpieczeństwa – np. stary klucz licencyjny używany równolegle na kilku stacjach, z których jedna służy do konfiguracji układów bezpieczeństwa.
Brak testów zmian w ogóle – niemożność przeprowadzenia testów z powodu braku licencji na środowisko testowe, więc wszelkie zmiany robi się „na żywym organizmie”.
Jeżeli w jednym systemie występują jednocześnie dwa lub trzy takie sygnały, poziom ryzyka jest zwykle wysoki niezależnie od subiektywnej oceny komfortu pracy zespołu OT. Taki system powinien zostać formalnie oznaczony (np. w rejestrze ryzyk) i mieć przypisany plan działań z terminami.
Prosty test decyzyjny dla właściciela procesu
Dla systemów, w których pojawiają się wątpliwości, można zastosować prosty, trójstopniowy test:
Załóż, że serwer/stanowisko wypadnie dzisiaj z eksploatacji – czy potrafisz w ciągu założonego RTO zgodnie z licencją odtworzyć system? Jeśli nie, pierwszy sygnał.
Załóż, że jutro producent przeprowadza audyt licencyjny – czy możesz pokazać komplet dokumentów i konfigurację zgodną z licencją? Jeśli nie, drugi sygnał.
Załóż, że w tym systemie dochodzi do incydentu bezpieczeństwa – czy byłbyś w stanie obronić przed zarządem/regulatorem tezę, że poziom bezpieczeństwa i zgodności był utrzymywany na minimalnie akceptowalnym poziomie? Jeśli nie, trzeci sygnał.
Jeśli choć na jedno z trzech pytań odpowiedź jest „nie”, system trafia do kategorii „wymaga zaplanowanych działań”. Jeśli „nie” pojawia się dwa lub trzy razy – ryzyko jest na tyle wysokie, że zwykle potrzebna jest decyzja o priorytetowej modernizacji lub renegocjacji licencji, z udziałem zarządu i działu prawnego.
Źródło: Pexels | Autor: Ann H
Punkt kontrolny 5: Rozmowy z dostawcami – jak nie dać się postawić pod ścianą
Przy krytycznych systemach OT to producent lub integrator często „kontroluje stół”: zna ograniczenia techniczne, ma własną politykę licencyjną i swoje tempo wycofywania wersji. Bez przygotowania łatwo wpaść w scenariusz, w którym po awarii lub audycie licencyjnym jedyną „opcją” jest pilny, drogi upgrade na warunkach dostawcy.
Minimalny zestaw pytań do producenta/OEM
Przed jakąkolwiek decyzją (odnowienie, migracja, zmiana licencji) opłaca się potraktować rozmowę z dostawcą jak mini–audyt. Zamiast ogólnego „co pan/pani proponuje?”, lepiej przejść przez konkretną listę pytań:
Status wsparcia dla wersji – do kiedy obowiązuje standardowe wsparcie (EOS), czy jest dostępne wsparcie rozszerzone i na jakich warunkach.
Ścieżka migracji – na jaką wersję można migrować bez konieczności wymiany sprzętu; co jest wymagane przy przeskoku o kilka generacji.
Polityka przenoszenia licencji – czy licencje mogą być przenoszone na nowe serwery/VM, jak wygląda procedura i jakie są ograniczenia (np. maksymalna liczba przeniesień rocznie).
Licencje testowe – czy producent udostępnia bezpłatne lub tańsze licencje na środowisko testowe/symulacyjne dla istniejącej instalacji.
Scenariusz awaryjny – jakie są formalne możliwości odtworzenia systemu po awarii (nośniki, klucze, procedury aktywacji offline).
Jeżeli dostawca unika odpowiedzi lub nie chce ich udzielić na piśmie, to sam w sobie jest to silny sygnał ostrzegawczy. W takiej sytuacji sensowne jest zaangażowanie działu prawnego lub zakupowego wcześniej, zanim pojawi się presja czasu po incydencie.
Jak przygotować się do negocjacji, aby mieć realną pozycję
Najczęstszy błąd to wchodzenie w rozmowy bez danych z inwentaryzacji i bez jasno określonych priorytetów. Wtedy to dostawca definiuje „pilność” problemu. Przed kontaktem z OEM/integratorem dobrze jest przygotować:
Listę systemów z priorytetami – podział na: krytyczne (bez nich linia stoi), ważne (silny wpływ na jakość/bezpieczeństwo), pomocnicze.
Aktualny stan licencji – dla każdego komponentu: typ licencji, status maintenance, EOL/EOS, kluczowe ograniczenia.
Scenariusze techniczne – zarys: „utrzymujemy wersję X na 3 lata”, „migracja do wersji Y z wymianą serwerów w 2 etapie” – nawet jeśli to wstępne opcje.
Szacunkowe okna serwisowe – kiedy realnie można zatrzymać produkcję, na jak długo, z jakim wyprzedzeniem trzeba to ogłosić.
Jeśli rozmowa opiera się na Twojej liście systemów, ryzyka i okien serwisowych, łatwiej utrzymać kontrolę nad zakresem i kolejnością działań. Gdy opiera się tylko na propozycji dostawcy, priorytety zwykle wynikają z jego polityki sprzedażowej, a nie z ryzyka biznesowego zakładu.
Ryzyka ukryte w „pakietach modernizacyjnych”
Producenci często proponują zestawy typu „modernizacja pod klucz”, obejmujące nową wersję, sprzęt i usługi. To może być dobre rozwiązanie, ale wymaga kilku dodatkowych punktów kontrolnych:
Zakres licencji vs obecny stan – czy nowy pakiet faktycznie pokrywa wszystkie istniejące funkcje i stacje, czy wymaga „domówienia” dodatków po wdrożeniu.
Warunki zakończenia starych licencji – czy utrata prawa do starej wersji następuje w momencie zakupu, aktywacji nowej wersji, czy po okresie przejściowym.
Testy przedprodukcyjne – czy w cenie są testy na osobnym środowisku, czy tylko „uruchomienie na produkcji”. Brak budżetu na testy to sygnał, że projekt zakłada podwyższone ryzyko.
Modele licencjonowania – przejście z licencji wieczystej na subskrypcję może obniżyć koszt wejścia, ale zwiększyć koszt i ryzyko w długim terminie (np. uzależnienie od terminowych płatności).
Jeżeli oferta modernizacji nie przewiduje okresu równoległej pracy starego i nowego systemu ani środowiska testowego, ryzyko przestoju jest zwykle wyższe, niż sugeruje dokumentacja sprzedażowa.
Punkt kontrolny 6: Plan przejściowy – jak modernizować, nie zatrzymując zakładu
W wielu obiektach decyzja o modernizacji jest odwlekana właśnie z obawy przed przestojem. Kluczowe jest potraktowanie zmiany licencyjno–technicznej jak projektu migracyjnego, a nie „aktualizacji po godzinach”.
Trójstopniowy model planowania zmian
Przy projektowaniu ścieżki przejściowej pomaga podział działań na trzy etapy, każdy z osobnym zestawem punktów kontrolnych:
Stabilizacja stanu obecnego – uszczelnienie licencji, dokumentacja, minimalizacja ryzyk „tu i teraz”.
Przygotowanie techniczne – budowa środowiska testowego, pilotaże, procedury odtworzenia.
Jeżeli którykolwiek z tych etapów jest pomijany lub łączony „dla oszczędności czasu”, ryzyko niekontrolowanego przestoju rośnie wykładniczo.
Etap 1: Stabilizacja – zanim ruszy projekt modernizacji
Cel: ograniczyć ryzyko awarii i niezgodności licencyjnej w okresie przejściowym, gdy system jeszcze długo będzie pracował w starej wersji. Przydatne działania:
Formalizacja stanu licencji – potwierdzenie (najlepiej mailowe) z dostawcą, jakie wersje i instalacje są akceptowane do czasu migracji.
Plan awaryjny – procedura „cold startu” po awarii, w tym lista nośników, kluczy, kroków aktywacji; przypisany właściciel.
Minimalne twarde zakazy – np. zakaz instalowania nowych instancji SCADA bez formalnego zatwierdzenia; zakaz kopiowania obrazów VM z licencjami na „zapas” poza uzgodnioną procedurą.
Monitoring stanu technicznego – kontrola logów błędów, alarmów systemowych, parametrów dysków/serwerów, by zredukować ryzyko nagłej awarii starego sprzętu.
Jeżeli etap stabilizacji jest wykonany rzetelnie, projekt modernizacji nie musi być prowadzony w trybie „gaszenia pożaru”, co z kolei poprawia pozycję negocjacyjną wobec dostawców.
Etap 2: Przygotowanie – środowisko testowe i pilotaż
Największe ryzyko przy zmianach w OT bierze się z wdrażania „w ciemno” na produkcji. Nawet proste środowisko testowe znacząco obniża to ryzyko. Kilka praktycznych wariantów:
Stacja testowa offline – kopia konfiguracji SCADA/HMI uruchomiona na oddzielnej maszynie (fizycznej lub VM), z symulowanymi wejściami/wyjściami.
Linia pilotażowa – jedna linia, gniazdo lub obszar procesu, na którym testowana jest nowa wersja licencji/oprogramowania przed wdrożeniem globalnym.
Symulatory i „digital twin light” – nawet uproszczony model procesu pozwala przetestować kluczowe funkcje sterowania i archiwizacji.
Kluczowe pytanie w tym etapie: czy dla każdej istotnej zmiany (wersja, licencja, konfiguracja) istnieje miejsce, gdzie można ją bezpiecznie sprawdzić przed wejściem na produkcję. Jeśli odpowiedź brzmi „nie”, migracja odbywa się de facto w trybie wysokiego ryzyka.
Etap 3: Migracja – zasady minimalizujące przestoje
Sam moment przełączenia na nowe licencje/wersje można ułożyć tak, by wpływ na produkcję był kontrolowany. Pomagają w tym następujące zasady:
Małe kroki zamiast „big bang” – podział na moduły: osobno serwery aplikacyjne, osobno HMI, osobno narzędzia inżynierskie; przełączenia w sekwencji, a nie jednocześnie.
Równoległa praca, gdzie to możliwe – przez ograniczony czas stare i nowe środowisko działają obok siebie, co umożliwia porównanie danych i szybki powrót.
Procedura rollback – jasny opis: w jakim momencie i jak długo można się „cofnąć” do poprzedniej wersji; kto podejmuje tę decyzję na zmianie.
Obecność kluczowych osób – podczas okna migracyjnego powinni być dostępni: przedstawiciel OT, automatyk/procesowiec, przedstawiciel dostawcy i osoba decyzyjna z utrzymania ruchu.
Jeśli okno migracyjne nie ma formalnie zaakceptowanego planu i procedury powrotu, każdy nieoczekiwany problem techniczny automatycznie zamienia się w ryzyko nieplanowanego przestoju.
Punkt kontrolny 7: „Tymczasowe obejścia” – granica między pragmatyzmem a utratą kontroli
W praktyce zakładów przemysłowych często pojawiają się nieoficjalne rozwiązania typu „zrobimy obraz dysku na wszelki wypadek”, „sklonujemy maszynę z działającą licencją” czy „użyjemy starego klucza jeszcze na jednej stacji”. Czasem ratują produkcję, ale z punktu widzenia audytu są to strefy podwyższonego ryzyka.
Typowe „obejścia”, które wymagają natychmiastowego uporządkowania
Klonowanie maszyn z zainstalowanymi licencjami – brak jasnej informacji, czy klon jest licencjonowaną instancją, czy kopią „na boku”. Problem eskaluje, gdy klony zaczynają żyć własnym życiem w sieci produkcyjnej.
Niekontrolowane obrazy VM/dysków – archiwa .vmdk/.vhd lub obrazy dysków z kluczami licencyjnymi przechowywane na ogólnych udziałach sieciowych bez ewidencji.
Stare klucze sprzętowe (dongle) w obiegu – brak jednoznacznego przypisania, który dongle należy do której stacji, oraz brak procedury utraty/uszkodzenia.
„Awaryjne” stacje serwisowe – laptopy z instalatorami, crackami, nieudokumentowanymi kluczami, wykorzystywane wyłącznie przy awariach.
Jeżeli w zakładzie istnieje choć jeden z powyższych scenariuszy, minimum to ich ewidencja i przypisanie odpowiedzialności. Pozostawienie takich obejść „w szarej strefie” zwiększa zarówno ryzyko prawne, jak i ryzyko utraty możliwości odtworzenia systemu w kontrolowany sposób.
Jak ucywilizować obejścia, które są faktycznie potrzebne
Nie każde tymczasowe rozwiązanie trzeba natychmiast likwidować; często lepszym podejściem jest jego formalizacja:
Rejestr kopii awaryjnych – spis obrazów, klonów, zapasowych maszyn z informacją: gdzie są, do czego służą, kto może ich użyć i w jakim scenariuszu.
Ograniczony dostęp – kopie z kluczami licencyjnymi pod kontrolą (np. sejf IT/OT, repozytorium z kontrolą dostępu), a nie na wspólnym dysku sieciowym.
Procedura użycia – krótki opis krok po kroku, co się dzieje, gdy taka kopia jest aktywowana: kto ją uruchamia, kto dokumentuje zmianę stanu licencji, jak długo może działać.
Plan wyjścia – termin, do kiedy dane obejście ma zostać zastąpione standardowym, zgodnym rozwiązaniem (np. oficjalną licencją lub nową wersją systemu).
Jeżeli tymczasowe rozwiązanie ma właściciela, opis, ograniczony dostęp i termin likwidacji, z punktu widzenia ryzyka staje się elementem świadomie zarządzanym, a nie tykającą bombą.
Kiedy „tymczasowe” staje się nieakceptowalne
Granica, przy której obejście przestaje być akceptowalne, zwykle przekraczana jest, gdy:
obejście funkcjonuje dłużej niż pierwotnie zakładany okres przejściowy i nie ma realnego planu jego zastąpienia,
rozwiązanie dotyczy systemu krytycznego dla bezpieczeństwa (SIS, ESD, sterowanie ruchem) lub jakości produktu regulowanego (np. farmacja, spożywka),
nie ma możliwości odtworzenia obejścia po awarii, bo jedyna kopia jest „działającą maszyną” bez dokumentacji,
nie da się jednoznacznie wykazać zgodności licencyjnej w razie audytu producenta lub regulatora.
Jeśli choć dwa z powyższych warunków są spełnione, obejście powinno zostać potraktowane jako natychmiastowy punkt działania w rejestrze ryzyk, z decyzją, czy zakład akceptuje taki poziom ryzyka wyłącznie za zgodą zarządu.
Punkt kontrolny 8: Kiedy świadomie utrzymać przestarzałą licencję, a kiedy to już zbyt duże ryzyko
Nie każde stare oprogramowanie trzeba natychmiast wymieniać. W niektórych sytuacjach akceptacja przestarzałej, ale legalnej licencji jest racjonalnym wyborem – pod warunkiem spełnienia kilku kryteriów.
Źródło: Pexels | Autor: Ann H
Praktyczny test można oprzeć na kilku pytaniach kontrolnych. Po pierwsze: czy producent nadal wspiera daną linię produktów choćby w ograniczonym zakresie (np. dostarcza łatki bezpieczeństwa, aktualizuje definicje antywirusowe dla dedykowanych appliance, świadczy płatne wsparcie extended support)? Po drugie: czy system z przestarzałą licencją jest odseparowany sieciowo na tyle, aby zminimalizować ekspozycję na współczesne wektory ataku (strefy, segmentacja, brak bezpośredniego dostępu z biura/Internetu)? Po trzecie: czy istnieje przetestowana ścieżka odtworzenia tego środowiska na wypadek awarii sprzętu – łącznie z nośnikami instalacyjnymi, kluczami i dokumentacją konfiguracji.
Kolejny punkt kontrolny to wpływ na proces i regulacje. Jeśli system pracuje w obszarze o stabilnych wymaganiach (np. linia pomocnicza, monitoring mediów technicznych, archiwum trendów nieużywane do raportowania regulowanego), utrzymanie przestarzałej licencji bywa akceptowalne. Sygnałem ostrzegawczym jest sytuacja, gdy to samo oprogramowanie odpowiada za parametry krytyczne dla jakości produktu objętego wymogami prawnymi lub kontraktowymi – wtedy każdy brak wsparcia, brak walidacji na nowych platformach czy brak łatek bezpieczeństwa automatycznie podnosi ryzyko niezgodności i sporów z klientem lub regulatorem.
Decyzja o pozostawieniu starej licencji wymaga również policzenia pełnego kosztu „nicnierobienia”. W kalkulacji powinny się znaleźć: koszt potencjalnej nieplanowanej przerwy (MTTR przy braku części i wsparcia), koszt ewentualnej migracji awaryjnej „pod presją czasu” oraz koszt ryzyka audytowego (np. kary umowne, przestoje na czas wyjaśniania niezgodności licencyjnych). Jeżeli suma tych ryzyk jest porównywalna z dobrze zaplanowanym projektem modernizacji, utrzymywanie przestarzałego środowiska wyłącznie z powodu „braku budżetu” staje się mało racjonalne.
Za nieakceptowalne należy uznać sytuacje, w których jedyna kopia instalatora zalegalizowanej, choć starej wersji znajduje się na pojedynczym nośniku bez kopii zapasowej, klucze licencyjne nie są nigdzie zarejestrowane poza „szufladą automatyka”, a producent wprost komunikuje brak jakiegokolwiek wsparcia technicznego. Jeśli dodatkowo system ten jest podłączony do sieci z dostępem zdalnym (VPN, serwis zewnętrzny), utrzymanie takiej licencji jest bardziej decyzją o akceptacji wysokiego ryzyka niż świadomą strategią utrzymania ciągłości działania.
Jeżeli przestarzała licencja jest legalna, udokumentowana, objęta choćby minimalnym wsparciem i pracuje w dobrze odseparowanym, stabilnym środowisku, można rozważać jej dalsze utrzymanie przy regularnych przeglądach ryzyka. W każdym innym przypadku bezpieczniejszą decyzją jest zaplanowanie kontrolowanej migracji – z jasno opisanymi punktami kontrolnymi, odpowiedzialnościami i kryteriami akceptacji, zanim to dostawca, awaria lub audyt wymusi ruch w najmniej dogodnym momencie.
Kluczowe Wnioski
Przestarzałe licencje w systemach OT to nie tylko „problem księgowy”, lecz realne ryzyko zatrzymania produkcji i utraty bezpieczeństwa, szczególnie gdy awaria sprzętu uniemożliwia legalne odtworzenie systemu na nowej platformie.
Pierwszy punkt kontrolny to pełna mapa systemów OT: dla każdego systemu trzeba znać jego funkcję w procesie, producenta, typ i identyfikatory licencji, datę wdrożenia, status wsparcia oraz właściciela biznesowego – brak tych danych jest sam w sobie sygnałem ostrzegawczym.
Główne ryzyko często nie wynika z braku legalności, lecz z EOL/EOS i braku maintenance: system może działać, ale nie ma patchy bezpieczeństwa, nie da się go przenieść na nowy sprzęt ani przywrócić po awarii bez konfliktu z dostawcą.
Szczególnie krytyczna jest sytuacja, gdy licencja jest trwale powiązana z konkretnym sprzętem (CPU, MAC, dongle), a umowy nie przewidują jej przeniesienia – każdy poważniejszy incydent sprzętowy może oznaczać natychmiastowy przestój i spór prawny.
Brak udokumentowanych licencji na używane moduły (drivery, archiwizację, raportowanie) lub dalsze korzystanie z wygasłych licencji czasowych tworzy bezpośrednie ryzyko naruszeń prawnych, które może wyjść na jaw podczas audytu zewnętrznego lub inspekcji.
Typowe sygnały ostrzegawcze to m.in. brak umów na maintenance od lat, brak reakcji dostawcy, brak wersji zgodnych z aktualnymi systemami operacyjnymi oraz niejasne zasady przenoszenia licencji – jeśli występuje kilka z nich naraz, ryzyko operacyjne i zgodności jest już wysokie.
Opracowano na podstawie
IEC 62443-1-1: Industrial communication networks – Network and system security – Part 1-1: Terminology, concepts and models. International Electrotechnical Commission (2013) – Podstawowe pojęcia bezpieczeństwa OT, cykl życia systemów sterowania
IEC 62443-2-1: Security for industrial automation and control systems – Part 2-1: Requirements for an IACS security management system. International Electrotechnical Commission (2010) – Wymagania zarządzania bezpieczeństwem IACS, w tym inwentarz aktywów
NIST SP 800-82 Revision 2: Guide to Industrial Control Systems (ICS) Security. National Institute of Standards and Technology (2015) – Różnice IT/OT, cykl życia ICS, ryzyka EOL i braku wsparcia
ISO/IEC 27002: Code of practice for information security controls. International Organization for Standardization (2022) – Dobre praktyki zarządzania aktywami, licencjami i wsparciem oprogramowania
ISA-TR62443-2-3: Patch management in the IACS environment. International Society of Automation (2015) – Zarządzanie poprawkami i wsparciem w systemach OT, konsekwencje EOL
BSA Global Software Survey. BSA The Software Alliance (2018) – Dane o skali nielegalnego oprogramowania i ryzykach prawnych dla organizacji
Software License Management: A Practitioner’s Guide. IT Governance Publishing (2016) – Praktyki zarządzania licencjami, typy licencji, ryzyka braku zgodności
Managing End-of-Life Software Risks in Industrial Control Systems. SANS Institute (2019) – Analiza ryzyk EOL/EOS w ICS, wpływ na bezpieczeństwo i ciągłość działania
Guidance on Cyber Security for Industrial Automation and Control Systems. European Union Agency for Cybersecurity (2021) – Zalecenia ENISA dla OT, inwentaryzacja systemów i zarządzanie cyklem życia
