AI w przemyśle

Jak zabezpieczyć backup danych z maszyn przemysłowych i sterowników PLC w chmurze?

Przez

27 października, 2026

3/5 - (1 vote)

Backup danych z maszyn przemysłowych i sterowników PLC nie jest zwykłą kopią plików na zewnętrznym serwerze. W pakiecie odtworzeniowym mogą znajdować się program sterownika, parametry falowników, konfiguracja sieci, firmware, receptury, ustawienia safety, projekty HMI, dane SCADA oraz informacje potrzebne do uruchomienia konkretnej wersji linii. Utrata jednego elementu może oznaczać nie tylko przestój, lecz także ryzyko uruchomienia maszyny z nieprawidłową logiką. ^[2]

Bezpieczny backup PLC w chmurze powinien więc łączyć trzy cechy: izolację środowiska OT od infrastruktury IT, kryptograficzną ochronę kopii oraz regularnie sprawdzane odtwarzanie. Sama obecność pliku w chmurze nie świadczy jeszcze o jego użyteczności. Kopia musi być kompletna, jednoznacznie opisana, odporna na modyfikację i możliwa do przywrócenia w kontrolowanych warunkach.

Przed wdrożeniem trzeba odpowiedzieć na kilka praktycznych pytań: które dane są niezbędne do odtworzenia pracy maszyny, kto może zainicjować backup, czy sterownik ma być osiągalny z sieci zewnętrznej, jak rozpoznać nieautoryzowaną zmianę programu, ile wersji trzeba przechowywać oraz jak odtworzyć konfigurację po awarii ransomware, wymianie CPU albo uszkodzeniu bramy brzegowej. Kolejne kroki porządkują te decyzje w procedurę możliwą do wdrożenia w zakładzie.

Nawigacja:

Zdefiniowanie zakresu: dlaczego standardowe podejście IT niszczy spójność kopii OT

Logika sterująca to nie to samo co dane procesowe

Pierwszym błędem jest traktowanie wszystkich danych przemysłowych jako jednego zbioru. Zrzut programu PLC, kopia firmware, konfiguracja modułów wejść i wyjść, ustawienia safety oraz projekt HMI tworzą pakiet odtworzeniowy sterowania. Z kolei wartości temperatur, ciśnień, prędkości, alarmów i liczników produkcyjnych są danymi procesowymi. Baza SCADA lub historian może być potrzebna do analizy zdarzeń i odtworzenia parametrów produkcji, ale nie zawsze jest niezbędna do uruchomienia samego sterownika.

Rozdzielenie tych kategorii ułatwia ustalenie priorytetów. Kod PLC i konfiguracja safety zwykle wymagają wysokiej integralności, długiej retencji oraz ścisłej kontroli dostępu. Dane procesowe mogą wymagać większej częstotliwości zapisu, ale innego okresu przechowywania i innego modelu kompresji. Nie należy bezrefleksyjnie kopiować całego dysku komputera operatorskiego, jeśli znajduje się na nim wiele plików tymczasowych, lokalnych eksportów i niezweryfikowanych wersji projektu.

Przydatny jest katalog zasobów, w którym każdy element otrzymuje właściciela, poziom krytyczności oraz informację o sposobie odtworzenia. Przykładowy wpis może określać, że program CPU, plik symboli, konfiguracja modułów bezpieczeństwa i projekt panelu operatorskiego muszą być odtwarzane razem, natomiast logi diagnostyczne są przechowywane w osobnym repozytorium. Taki podział zapobiega sytuacji, w której zespół ma kopię kodu, ale nie ma wersji firmware albo właściwych bibliotek potrzebnych do jego załadowania.

Pułapka „gorącego snapshotu”

W środowisku IT często zakłada się, że snapshot wykonany w dowolnym momencie jest wystarczającą kopią. W przypadku automatyki to założenie bywa niebezpieczne. Program PLC może być właśnie zmieniany, receptura może znajdować się w połowie transferu, a narzędzie inżynierskie może zapisywać pliki pomocnicze w kilku lokalizacjach. Pojedynczy zrzut wykonany bez koordynacji może połączyć elementy pochodzące z różnych wersji.

Ryzyko dotyczy również danych procesowych. Kopia bazy SCADA wykonana podczas aktywnego zapisu może zawierać niezamknięte transakcje, niespójne indeksy albo dane z różnych momentów cyklu. Sam plik może być technicznie poprawny, lecz po odtworzeniu nie będzie reprezentował jednego logicznego stanu procesu.

Bezpieczniejszy model przewiduje punkt kontrolny. Dla programu PLC może to być zatwierdzona wersja eksportu wykonana po zakończeniu zmian, z numerem rewizji, identyfikatorem maszyny i sumą kontrolną. Dla danych SCADA oznacza to użycie mechanizmu aplikacyjnego zapewniającego spójność, a nie zwykłe kopiowanie otwartego pliku bazy. Jeśli producent sterownika udostępnia funkcję archiwizacji projektu lub konfiguracji, powinna ona mieć pierwszeństwo przed kopiowaniem przypadkowych katalogów systemowych. ^[1]

Retencja zależna od przezbrojeń i receptur

Jedna polityka retencji dla całego zakładu zwykle nie pasuje do wszystkich linii. Na maszynie produkowanej w stałym trybie wystarczający może być zapis zatwierdzonej wersji po każdej zmianie. Na linii często przezbrajanej trzeba natomiast zachować historię receptur, parametrów oraz zależności między programem PLC a konfiguracją urządzeń wykonawczych.

Retencję najlepiej podzielić na kilka warstw:

kopie operacyjne – najnowsze wersje używane do szybkiego odtworzenia,
kopie wersjonowane – każda zatwierdzona zmiana programu, receptury lub firmware,
kopie długoterminowe – wersje referencyjne związane z partią produktu, audytem albo wymaganiami kontraktowymi,
kopie awaryjne – chronione przed usunięciem i modyfikacją, przeznaczone do odtworzenia po incydencie.

Popularna zasada „zostawiamy tylko ostatnią kopię” nie działa tam, gdzie błędna zmiana może zostać wykryta dopiero po kilku dniach produkcji. W takiej sytuacji najnowsza wersja może być właśnie tą, która zawiera błąd. Retencja powinna uwzględniać czas wykrycia problemu, cykl zatwierdzania zmian oraz okres, przez który produkt może ujawnić skutki nieprawidłowej konfiguracji.

Krok 1: Izolacja architektury – bramka brzegowa zamiast bezpośredniego dostępu PLC do chmury

Segmentacja sieciowa zgodna z modelem Purdue

Sterownik PLC nie powinien być podłączany bezpośrednio do routera z dostępem do internetu. Dotyczy to także sytuacji, w której dostęp ma służyć wyłącznie do wykonywania kopii. PLC nie jest typowym serwerem aplikacyjnym: często ma ograniczone mechanizmy uwierzytelniania, długo niezmieniany firmware i protokoły projektowane z myślą o zaufanej sieci lokalnej.

Architektura powinna rozdzielać poziomy pola, sterowania, nadzoru i systemów zewnętrznych. Model Purdue nie jest gotową konfiguracją bezpieczeństwa, lecz pomaga ustalić, gdzie powinny znajdować się urządzenia i jakie przepływy są dopuszczalne. Sterowniki, moduły rozproszone i urządzenia wykonawcze pozostają w strefie OT. Serwer pośredniczący, broker lub Edge Gateway trafia do kontrolowanej strefy przejściowej, a chmurowy magazyn kopii jest poza zakładową siecią przemysłową.

Najważniejsza zasada brzmi: chmura nie powinna inicjować połączenia do PLC. Brama znajdująca się po stronie zakładu może ustanawiać szyfrowany kanał wychodzący, pobierać zatwierdzone dane i wysyłać paczki do usługi chmurowej. Dzięki temu reguły zapory nie muszą otwierać wejścia z internetu do sieci sterowników.

Jeśli chcesz pogłębić ten wątek, sprawdź też: Przemysłowe IoT i AI: architektura bezpiecznego systemu zbierania danych z linii. ^[4]

Rola przemysłowej bramy Edge

Brama brzegowa jest jedynym elementem, który powinien znać zarówno lokalne protokoły automatyki, jak i mechanizmy komunikacji z chmurą. Nie oznacza to, że należy umieścić w niej wszystkie funkcje bez dodatkowych zabezpieczeń. Powinna mieć minimalny zestaw usług, wyłączone nieużywane porty, aktualizowany system, oddzielne konta oraz możliwość rejestrowania operacji administracyjnych.

Na bramie można realizować kilka zadań:

pobranie programu i konfiguracji przez dozwolony protokół lokalny,
utworzenie spójnego pakietu wraz z metadanymi,
obliczenie skrótu kryptograficznego i podpisanie manifestu,
szyfrowanie danych przed opuszczeniem strefy OT,
buforowanie kopii przy czasowej utracie łącza,
wysyłanie wyłącznie do zdefiniowanych punktów końcowych,
rejestrowanie, kto i kiedy zatwierdził eksport albo odtworzenie.

Brama nie powinna stać się ukrytym kanałem zdalnego programowania. Funkcja tworzenia backupu musi być oddzielona od funkcji zapisu do sterownika. Jeśli odtworzenie jest dopuszczalne zdalnie, powinno wymagać dodatkowej autoryzacji, zatwierdzenia lokalnego operatora i kontroli zakresu. W wielu zakładach bezpieczniej jest pobierać kopie automatycznie, ale przywracanie wykonywać wyłącznie lokalnie albo przez nadzorowany kanał serwisowy.

Komunikacja jednokierunkowa i tunele mTLS

Najprostszy wariant to transfer jednokierunkowy: dane wychodzą z sieci przemysłowej, ale nie ma technicznej możliwości rozpoczęcia sesji z chmury w kierunku OT. Tam, gdzie nie można zastosować pełnej jednokierunkowości, należy użyć tunelu inicjowanego przez bramę, z wzajemnym uwierzytelnianiem certyfikatami, czyli mTLS.

Stos — Źródło: Pexels | Autor: Marta Branco

Certyfikat bramy powinien być przypisany do konkretnego urządzenia, a nie współdzielony przez wszystkie linie. Utrata jednego certyfikatu nie może otwierać dostępu do całego zakładu. Trzeba też zaplanować unieważnianie certyfikatów, ich rotację i procedurę działania w przypadku awarii wewnętrznego urzędu certyfikacji.

Reguły zapory powinny dopuszczać wyłącznie wymagany kierunek, port i adres usługi. Samo ograniczenie po adresie IP nie wystarcza, jeśli usługa akceptuje dowolny certyfikat lub token. Konfiguracja powinna być okresowo przeglądana, zwłaszcza po zmianie dostawcy chmury, bramy, segmentacji albo oprogramowania sterownika.

Krok 2: Przygotowanie, sanityzacja i szyfrowanie danych u źródła

Zero Trust dla pakietów opuszczających halę

Każdy pakiet wysyłany z hali powinien być traktowany jako potencjalnie niebezpieczny, nawet jeśli powstał w zaufanej sieci. Zasada Zero Trust oznacza tu między innymi weryfikację źródła, zakresu, formatu i uprawnień do transferu. Brama nie powinna wysyłać dowolnych plików znalezionych na dysku komputera inżynierskiego. Eksport musi pochodzić z określonego katalogu, procesu lub konektora, a jego typ powinien odpowiadać zdefiniowanemu zasobowi.

Przed transferem można wykonać walidację schematu: sprawdzić identyfikator maszyny, typ sterownika, wersję projektu, zgodność firmware, obecność wymaganych plików oraz rozmiar pakietu. Nienaturalny wzrost rozmiaru albo pojawienie się rozszerzenia niezgodnego z profilem urządzenia powinno zatrzymać wysyłkę i wygenerować alarm.

Szyfrowanie AES-256 i ochrona kluczy

Dane przemysłowe powinny być szyfrowane lokalnie na bramie, zanim opuszczą strefę zakładową. W praktyce stosuje się szyfrowanie symetryczne, na przykład AES-256 w trybie zapewniającym poufność i integralność. Samo zaszyfrowanie pliku bez uwierzytelnienia nie wystarcza, ponieważ napastnik może próbować podmienić pakiet albo uszkodzić jego zawartość bez wykrycia. ^[3]

Ochrona kluczy szyfrujących

Klucz szyfrujący nie może być przechowywany razem z kopią ani zapisany w skrypcie eksportującym dane. Takie rozwiązanie pozwalałoby osobie, która uzyska dostęp do pakietu lub bramy, odczytać również jego zawartość. Klucze należy przechowywać w dedykowanym magazynie, na przykład w module HSM, systemie KMS albo bezpiecznym magazynie sekretów z kontrolą dostępu.

W praktyce warto rozdzielić klucze według zakładu, linii lub grupy zasobów. Klucz używany do szyfrowania backupów jednej instalacji nie powinien automatycznie otwierać kopii wszystkich pozostałych maszyn. Ogranicza to skutki przejęcia pojedynczego konta, bramy lub pakietu konfiguracyjnego.

Procedura zarządzania kluczami powinna określać:

kto może utworzyć, użyć, zrotować i unieważnić klucz,
gdzie klucz jest przechowywany i w jaki sposób jest chroniony,
jak często odbywa się rotacja,
co dzieje się z wcześniej utworzonymi kopiami po rotacji,
jak odzyskać dostęp po awarii systemu KMS lub utracie bramy,
jak rejestrowane są operacje użycia i eksportu klucza.

Rotacja nie może oznaczać utraty możliwości odtworzenia starszych kopii. Pakiet powinien zawierać identyfikator wersji klucza, ale nie sam klucz. Podczas odtwarzania system wybiera właściwą wersję z magazynu kluczy i dopiero po pozytywnym uwierzytelnieniu udostępnia ją uprawnionej procedurze. Dla kopii długoterminowych trzeba zapewnić, że klucz pozostanie dostępny przez cały wymagany okres retencji albo że pakiety zostaną kontrolowanie ponownie zaszyfrowane.

Manifest, skrót i podpis cyfrowy

Każdy pakiet powinien mieć manifest opisujący jego zawartość. Manifest nie zastępuje szyfrowania, lecz pozwala sprawdzić, czy pakiet jest kompletny, pochodzi z właściwego źródła i nie został zmieniony po utworzeniu. Nie należy ograniczać się do nazwy pliku oraz daty eksportu, ponieważ takie pola można łatwo zmodyfikować.

Dobrym uzupełnieniem tego tematu jest także poradnik: Monitorowanie procesów w czasie rzeczywistym: AI jako narzędzie wczesnego ostrzegania.

Manifest może zawierać między innymi:

unikalny identyfikator pakietu,
identyfikator zakładu, linii i maszyny,
typ oraz numer seryjny sterownika,
wersję projektu, firmware i narzędzia inżynierskiego,
listę plików wraz z rozmiarem i skrótem kryptograficznym,
czas rozpoczęcia i zakończenia eksportu,
informację o źródle danych oraz sposobie ich pobrania,
wersję schematu pakietu,
identyfikator klucza szyfrującego,
status walidacji i zatwierdzenia przez operatora lub właściciela zasobu.

Dla każdego pliku należy obliczyć skrót kryptograficzny, na przykład SHA-256 lub SHA-384. Po pobraniu pakietu system chmurowy może ponownie obliczyć skróty i porównać je z manifestem. Taka kontrola wykryje uszkodzenie podczas transferu, niepełne zapisanie pliku oraz zmianę zawartości.

Manifest powinien być dodatkowo podpisany cyfrowo kluczem należącym do konkretnej bramy albo zakładowej usługi podpisującej. Klucz prywatny podpisu musi być chroniony niezależnie od danych backupu. Nie należy przechowywać go w tym samym katalogu, w którym powstają eksporty. Przy weryfikacji trzeba sprawdzić nie tylko sam podpis, ale również ważność certyfikatu, jego przeznaczenie, status unieważnienia i przypisanie do właściwej bramy.

Wykrywanie podmiany i powtórnego użycia pakietu

Integralność pliku nie jest jedynym problemem. Napastnik może próbować przesłać prawidłowy, lecz stary pakiet, który zawiera znaną lukę albo nieaktualną konfigurację. Dlatego manifest powinien zawierać numer sekwencyjny, znacznik czasu oraz identyfikator poprzedniej zatwierdzonej wersji. System przyjmujący kopię musi odrzucić pakiet o numerze już wykorzystanym lub pochodzący spoza dozwolonego okna czasowego, chyba że operator świadomie zatwierdzi import historycznej wersji.

Nie każdy starszy pakiet jest nieprawidłowy. Może być potrzebny podczas analizy awarii albo odtworzenia stanu sprzed błędnej zmiany. Różnica polega na tym, że użycie takiej wersji powinno być jawne, rejestrowane i objęte dodatkową autoryzacją, a nie traktowane jako zwykły automatyczny transfer.

Krok 3: Transfer i kontrola przyjęcia pakietu

Procedura wysyłki od eksportu do magazynu

Transfer powinien przebiegać według stałego procesu, który można odtworzyć z logów. Przykładowa kolejność wygląda następująco:

Utwórz punkt kontrolny – zakończ eksport zatwierdzonych danych i oznacz wersję, której dotyczy kopia.
Zweryfikuj źródła – sprawdź, czy każdy plik pochodzi z dozwolonego konektora, katalogu lub systemu inżynierskiego.
Wykonaj kontrolę kompletności – porównaj zawartość z profilem maszyny i wymaganymi elementami.
Zbuduj manifest – dodaj metadane, rozmiary, skróty, identyfikator pakietu i wersję klucza.
Podpisz manifest – użyj klucza przypisanego do konkretnej bramy lub procesu podpisującego.
Zaszyfruj pakiet – wykonaj tę operację przed zapisaniem danych w buforze przeznaczonym do wysyłki.
Prześlij kopię – użyj wyłącznie zdefiniowanego kanału wychodzącego i punktu końcowego.
Potwierdź przyjęcie – odbiorca powinien potwierdzić identyfikator pakietu, poprawność podpisu, skrótów i zapisu.
Zamknij zadanie – zapisz wynik, czas trwania, rozmiar pakietu oraz ewentualne ostrzeżenia.

Potwierdzenie przyjęcia nie powinno oznaczać wyłącznie odpowiedzi „plik odebrany”. System docelowy musi zweryfikować, czy pakiet jest kompletny, podpisany przez zaufane źródło, zgodny z profilem maszyny i zapisany bez błędów. Dopiero wtedy można oznaczyć kopię jako gotową do odtworzenia.

Buforowanie po utracie łącza

Brak połączenia z chmurą nie powinien przerywać lokalnego procesu tworzenia kopii. Brama może przechować zaszyfrowany pakiet w buforze, ale bufor również wymaga kontroli dostępu, limitu pojemności i ochrony przed usunięciem. Należy ustalić, ile kopii może oczekiwać na wysyłkę oraz które pakiety mają pierwszeństwo.

Po odzyskaniu łącza brama powinna wysłać pakiety w kolejności wynikającej z polityki retencji, a nie bezwarunkowo przesłać wszystko, co znajduje się na dysku. Warto przewidzieć alarm przy zapełnieniu bufora, przekroczeniu maksymalnego wieku niewysłanej kopii lub wielokrotnym odrzuceniu pakietu przez usługę chmurową.

Kontrola przyjęcia po stronie chmury

Magazyn chmurowy powinien rozdzielać co najmniej trzy stany kopii:

odebrana – transfer zakończył się technicznie, ale pakiet nie przeszedł jeszcze pełnej walidacji,
zatwierdzona – podpis, skróty, manifest i kompletność zostały sprawdzone,
gotowa do odtworzenia – wykonano dodatkową kontrolę wymaganych zależności i można użyć kopii w procedurze przywracania.

Nie należy pozwalać, aby każdy plik znajdujący się w magazynie był automatycznie dostępny do odtworzenia. Pakiet odrzucony, niekompletny albo niespójny powinien trafić do izolowanego obszaru analizy. Jego usunięcie lub ponowne zatwierdzenie musi wymagać uprawnienia niezależnego od konta, które wykonało transfer.

Krok 4: Test odtworzenia i kontrola kompletności

Odtworzenie jako kryterium skuteczności backupu

Backup należy uznać za skuteczny dopiero wtedy, gdy można go wykorzystać w kontrolowanym odtworzeniu. Sam poprawny status transferu nie potwierdza, że projekt otworzy się w odpowiednim narzędziu, firmware będzie zgodny, a konfiguracja urządzeń da się przywrócić bez brakujących bibliotek lub haseł.

Test powinien odbywać się poza produkcyjnym sterownikiem albo w specjalnie przygotowanym środowisku testowym. W zależności od rodzaju zasobu może obejmować:

odszyfrowanie pakietu z użyciem właściwej wersji klucza,
weryfikację podpisu i wszystkich skrótów,
otwarcie projektu w wymaganej wersji narzędzia inżynierskiego,
sprawdzenie zgodności firmware i bibliotek,
odtworzenie konfiguracji na urządzeniu testowym lub emulatorze,
porównanie parametrów z zatwierdzonym manifestem,
sprawdzenie, czy dokumentacja i instrukcja uruchomienia są dostępne.

Jeżeli pełne odtworzenie na identycznym sterowniku nie jest możliwe, trzeba jasno opisać zakres testu zastępczego. Otworzenie pliku projektu nie jest równoznaczne z potwierdzeniem, że można bezpiecznie uruchomić maszynę. Dla funkcji safety, napędów i modułów komunikacyjnych należy określić dodatkowe czynności weryfikacyjne oraz wymagane zatwierdzenie technologa lub integratora.

Checklista wdrożeniowa

Przed uznaniem procedury za gotową do pracy sprawdź:

każdy zasób ma określone źródło, właściciela i wymagany zakres kopii,
eksport nie pobiera przypadkowych plików z komputera operatorskiego lub inżynierskiego,
pakiet jest szyfrowany przed opuszczeniem strefy zakładowej,
klucze szyfrujące nie są przechowywane razem z backupem,
istnieje procedura rotacji i odzyskania kluczy,
manifest zawiera listę plików, rozmiary, skróty, wersje i identyfikator maszyny,
manifest jest podpisany kluczem przypisanym do właściwej bramy,
system wykrywa ponowne użycie pakietu, cofnięcie wersji lub nieoczekiwany numer sekwencyjny,
bufor lokalny ma limit pojemności i generuje alarm przy przepełnieniu,
chmura rozróżnia pakiety odebrane, zatwierdzone i gotowe do odtworzenia,
odtworzenie wymaga osobnej autoryzacji od tej używanej przy tworzeniu kopii,
wykonano test odszyfrowania, weryfikacji integralności i otwarcia projektu,
wynik testu ma datę, osobę odpowiedzialną i opis ograniczeń.

Najważniejsze ostrzeżenia operacyjne

Nie przechowuj klucza w skrypcie. Nawet jeśli skrypt jest dostępny tylko administratorom, jego kopia może trafić do repozytorium, backupu stacji roboczej albo systemu zgłoszeń.
Nie uznawaj pliku za zaufany tylko dlatego, że pochodzi z wewnętrznej sieci. Źródło musi być potwierdzone podpisem, certyfikatem albo innym mechanizmem przewidzianym w polityce.