Bezpieczeństwo dostępu do panelu HMI: hasła, role użytkowników i ślady aktywności

Po co zabezpieczać panel HMI i co chcesz osiągnąć?

Panel HMI jako „pilot” do maszyny, a nie tylko ekran

Panel HMI nie jest zwykłym monitorem. Dla linii produkcyjnej to pilot zdalnego sterowania – z jego poziomu można zatrzymać proces, zmienić tryb pracy, załadować inną recepturę czy wyłączyć część funkcji bezpieczeństwa. Pytanie brzmi: komu faktycznie chcesz dać w rękę taki pilot?

Jeśli HMI służy tylko do podglądu parametrów, ryzyko jest mniejsze – ale większość paneli operatorskich pozwala także na wprowadzanie zmian. W praktyce oznacza to, że osoba stojąca przy panelu ma często większy wpływ na proces niż pracownik biurowy z dostępem do ERP czy systemu jakości.

Bezpieczeństwo dostępu do panelu HMI to nie jest „fanaberia IT”, ale element zarządzania ryzykiem produkcji. Brak kontroli nad tym, kto co może zmienić, wprost przekłada się na awarie, przestoje i kompromisy związane z bezpieczeństwem ludzi.

Konsekwencje braku kontroli dostępu do HMI

Jakie realne problemy pojawiają się, gdy panel jest „otwarty na oścież” i każdy może zrobić wszystko? Najczęściej spotykane konsekwencje to:

• Przypadkowe zmiany receptur – operator zamiast aktualnej receptury ładuje starą wersję, bo ekran nie wymaga żadnego logowania. Produkt wychodzący z linii nie spełnia specyfikacji, ale system jakości nie ma śladu, kto podjął decyzję.
• Zatrzymanie lub rozregulowanie produkcji – ktoś dla „testu” zmienia parametry czasu cyklu, dopuszczalne tolerancje lub limity alarmów. Maszyna zaczyna się zatrzymywać z powodu fałszywych alarmów albo wręcz przeciwnie – przestaje zgłaszać krytyczne stany.
• Wpływ na bezpieczeństwo ludzi – zmiana ustawień związanych z bezpieczeństwem funkcjonalnym (np. tryb serwisowy, wyłączenie kontroli drzwi, blokada skanerów bezpieczeństwa) bez odpowiednich uprawnień stanowi bezpośrednie zagrożenie BHP.
• Problemy audytowe – w branżach regulowanych (spożywcza, farmacja, automotive) audytorzy pytają: kto mógł zmieniać parametry procesu i jak to jest rejestrowane? Brak odpowiedzi to realne ryzyko niezgodności.

Jak dużo z tych scenariuszy już widziałeś u siebie? Czy potrafisz wskazać konkretne przypadki, gdy „ktoś coś nacisnął na panelu” i do dziś nie wiadomo kto?

Różne cele: audyt, bezpieczeństwo, płynność pracy

Projektując bezpieczeństwo dostępu do HMI, dobrze jest nazwać swój główny cel. Co jest dla ciebie ważniejsze w tym momencie:

• spełnienie wymogów audytu/klienta – potrzebujesz śladów, kto zmieniał parametry, by móc to pokazać przy kontroli,
• realne ograniczenie ryzyka – chcesz, by osoby bez kompetencji nie mogły w ogóle wejść na niektóre ekrany,
• dyscyplina i ergonomia pracy – zależy ci, by operatorzy logowali się poprawnie, ale bez zbędnego klikania.

Priorytety można łączyć, ale kolejność jest kluczowa. Jeśli na pierwszym miejscu postawisz maksymalne bezpieczeństwo bez myślenia o ergonomii, szybko doczekasz się karteczek z hasłami przyklejonych do ramy panelu lub jednego wspólnego konta „ombypassowanego” przez wszystkich. Jeśli skupisz się tylko na komforcie operatora, panel stanie się najsłabszym ogniwem całej instalacji.

Pytanie do ciebie: jaki masz dzisiaj priorytet – bezpieczeństwo, ciągłość pracy czy ślad dla audytu? Od odpowiedzi zależy, jak głęboko warto iść w politykę haseł i rolę użytkowników.

HMI całkowicie otwarty vs HMI „zabarykadowany”

Ekstremalne podejścia są bardzo kuszące, ale rzadko się sprawdzają:

• Panel całkowicie otwarty – brak logowania, każdy ma pełny dostęp. Szybka praca, zero barier, ale też pełna anonimowość, wysokie ryzyko błędów i brak możliwości odtworzenia, kto co zrobił.
• Panel przesadnie zabezpieczony – logowanie wymagane do każdego ekranu, długie hasła, krótki czas automatycznego wylogowania. System „bezpieczny na papierze”, ale w praktyce operatorzy omijają go, jak tylko mogą: zostawione na stałe zalogowane konto, wspólne hasła lub kompletny brak akceptacji.

Rozsądny środek to zabezpieczenie tego, co krytyczne (parametry procesu, tryby pracy, konfiguracja komunikacji, ustawienia bezpieczeństwa), przy pozostawieniu łatwego podglądu podstawowych danych. Często skuteczniejsze jest stopniowe zaostrzanie dostępu do najbardziej ryzykownych funkcji niż jednorazowa rewolucja „blokujemy wszystko od jutra”.

Jak wygląda twoja sytuacja dzisiaj – bliżej pełnej otwartości czy hermetycznego systemu? I które obszary najbardziej „bolą”, gdy myślisz o ryzyku?

Podstawy bezpieczeństwa HMI w środowisku przemysłowym

Bezpieczeństwo IT a OT – inne priorytety, inne ograniczenia

W biurze (IT) najważniejsze jest zwykle poufność danych. W produkcji (OT) na pierwszy plan wysuwa się dostępność i bezpieczeństwo fizyczne. Ten konflikt widać przy ustalaniu zasad logowania do paneli HMI.

Dla działu IT naturalne są procedury typu: hasło co 30 dni, długość minimum 12 znaków, blokada konta po 3 nieudanych próbach, wymuszone logowanie co godzinę. W otoczeniu biurowym pracownik spokojnie wpisze takie hasło. Na hali, w rękawicach, pod presją czasu, przy ciągłych przezbrojeniach – takie zasady często powodują frustrację i omijanie systemu.

Bezpieczeństwo dostępu w automatyce musi godzić wymagania IT z realiami pracy operatora. Rozwiązania, które dobrze działają w IT, mogą być zabójcze dla płynności produkcji. Z drugiej strony, „stare nawyki” z automatyki (konto „operator” bez hasła) nie przejdą w świecie rosnących wymogów cyberbezpieczeństwa i audytów.

Miejsce panelu HMI w architekturze systemu

Panel HMI bywa traktowany jako prosty terminal, ale w architekturze ma istotną rolę:

• łączy się bezpośrednio z PLC lub innymi sterownikami,
• czasem jest częścią większego systemu SCADA,
• często ma połączenie z siecią biurową (raporty, MES, ERP, zdalny dostęp),
• może udostępniać usługi sieciowe (VNC, serwer WWW, Modbus/TCP).

To sprawia, że panel bywa mostem między światem IT i OT. Z jednej strony stoi fizycznie na hali, z drugiej ma port Ethernet, USB, czasem Wi-Fi. Niewłaściwie skonfigurowany może być wygodnym punktem wejścia zarówno dla osoby niepowołanej na miejscu, jak i dla kogoś, kto dostał się do sieci.

Zastanów się: czy wiesz dokładnie, jakie połączenia sieciowe ma każdy twój panel HMI? I czy masz listę usług (VNC, webserwer, FTP), które są tam włączone lub wyłączone?

Co faktycznie kontroluje użytkownik HMI

Zakres funkcji dostępnych z poziomu HMI jest bardzo szeroki. Typowe operacje to:

• zmiana parametrów procesu – temperatury, czasy, prędkości, ciśnienia, limity,
• ładowanie, edycja i zapisywanie receptur,
• zmiana trybów pracy (auto, ręczny, serwis, test),
• resetowanie i potwierdzanie alarmów,
• wykonywanie operacji serwisowych – kalibracja, testy wyjść, ręczne sterowanie napędami,
• dostęp do ustawień systemowych – daty, czasu, komunikacji, aktualizacji, backupów.

Bezpieczeństwo dostępu nie musi dotyczyć wszystkiego. Kluczowe jest rozróżnienie, gdzie użytkownik może tylko oglądać, a gdzie może aktywnie wpływać na proces. Czasem sama zmiana widocznego zakresu danych (np. ukrycie mniej potrzebnych zmiennych) już zmniejsza ryzyko przypadkowych zmian.

Jakie ekrany w twoim projekcie HMI zawierają najwięcej możliwości ingerencji? Czy są jakoś wyróżnione, odseparowane, czy każdy może na nie wejść z menu głównego?

Dlaczego HMI bywa najsłabszym ogniwem

Panele operatorskie często są pomijane w politykach bezpieczeństwa, bo:

• są traktowane jako „tylko ekran”, nie jako element sieciowy,
• rzadko są aktualizowane (firmware, środowisko runtime),
• wykorzystują wspólne loginy typu „operator”, „serwis”,
• pracują w trybie serwisowym latami, bo „tak kiedyś zostawiono przy rozruchu”,
• nie mają skonfigurowanego rejestru zdarzeń (logu), mimo że oprogramowanie to oferuje.

Najsłabsze ogniwo nie zawsze wynika z technologii. Częściej jest to kwestia braku jasnego właściciela: dział IT uważa, że HMI to sprawa automatyki, automatyka – że to „tylko wizualizacja”, a utrzymanie ruchu interesuje głównie minimalny czas przestoju.

Jeśli chcesz wzmocnić bezpieczeństwo dostępu do HMI, pierwsze pytanie do zespołu powinno brzmieć: kto jest właścicielem polityki dostępu do paneli operatorskich? Bez tego decyzje będą podejmowane ad hoc, przy każdym nowym projekcie inaczej.

Model zagrożeń dla panelu HMI – kto i jak może zaszkodzić?

Typy użytkowników i ich motywacje

Bezpieczeństwo ma sens dopiero wtedy, gdy wiadomo, przed kim i przed czym ma chronić. Spróbuj nazwać główne typy użytkowników twoich paneli HMI:

• Operator – wykonuje bieżącą produkcję, obsługuje maszynę na co dzień, często pod presją czasu.
• Brygadzista / Lider zmiany – ma większą odpowiedzialność, decyduje o zmianach receptur, zatrzymaniu linii, zgłaszaniu problemów.
• Utrzymanie ruchu – diagnozuje awarie, wykonuje naprawy, testuje urządzenia, często pracuje w trybie ręcznym.
• Automatyk / inżynier procesu – projektuje logikę, aktualizuje oprogramowanie, wprowadza zmiany w konfiguracji.
• Serwis zewnętrzny – przyjeżdża na zlecenie, potrzebuje czasowo wyższych uprawnień do diagnozy.
• Dział IT – nie korzysta z HMI na co dzień, ale ma wpływ na infrastrukturę sieciową, integracje, polityki haseł.
• Goście i osoby przypadkowe – audytorzy, klienci, praktykanci, osoby z innych działów przechodzące przez halę.

Każda z tych grup ma inną motywację i inną skłonność do „obchodzenia” zabezpieczeń. Operator będzie szukał najszybszej ścieżki do uruchomienia produkcji. Utrzymanie ruchu – do skrócenia czasu naprawy. Serwis zewnętrzny – do wykonania zadania w czasie wizyty. Dobrze zaprojektowane role i uprawnienia operatorów uwzględniają te różne potrzeby.

Scenariusze ryzyka: od błędu do sabotażu

Niekontrolowany dostęp do HMI może prowadzić do różnych scenariuszy:

• Przypadkowa zmiana parametru – nowa osoba na linii naciska „Zapisz” zamiast „Cofnij”, zmieniając żywotnie parametry receptury.
• Celowe obchodzenie blokad – operator, żeby przyspieszyć pracę, zmienia limity bezpieczeństwa, opóźnia alarmy lub wyłącza blokady drzwi.
• Sabotaż – sfrustrowany pracownik celowo ustawia błędne parametry, by powodować powtarzające się usterki trudne do zdiagnozowania.
• Błąd serwisanta – serwis zewnętrzny zostawia panel w trybie serwisowym, co później umożliwia nieautoryzowane ruchy w trybie ręcznym.
• Nieuprawniony zdalny dostęp – źle zabezpieczony VNC lub webserwer HMI otwarty do sieci umożliwia zmianę parametrów spoza zakładu.

Zastanów się, które z tych scenariuszy są realne u ciebie. Czy masz już za sobą incydenty, które dziś określiłbyś jako problem bezpieczeństwa dostępu, choć wtedy wyglądały jak „ludzki błąd”?

Dostęp fizyczny a logiczny

Zagrożenia można podzielić na dwie główne kategorie:

• Dostęp fizyczny – ktoś stoi przed panelem i klika to, co widzi na ekranie. Tu kluczowe są: ergonomia logowania operatorów, blokada krytycznych ekranów, tryb wygaszania, lokalizacja panelu (czy stoi „na drodze” czy w strefie z ograniczonym dostępem).
• Dostęp logiczny – ktoś łączy się z panelem przez sieć: z komputera serwisowego, zdalnie przez VPN, czasem (niestety) przez otwarte porty z zewnątrz. Tu kluczowe są: segmentacja sieci, wyłączanie nieużywanych usług, silne uwierzytelnianie i kontrola, kto i skąd może się połączyć.

Jeżeli dziś skupiasz się wyłącznie na jednym z tych obszarów, sprawdź, czy nie zostawiasz drugiego kompletnie otwartego. Nawet najbardziej restrykcyjne hasła nie pomogą, jeśli panel stoi w korytarzu ogólnodostępnym, a z drugiej strony – najlepsza lokalizacja fizyczna nie zrekompensuje otwartego VNC z hasłem „1234”. Jaki masz model dostępu: „zamykamy ludziom drzwi” czy „zamy­kamy interfejsy logiczne”, a może oba na raz?

Przy planowaniu zabezpieczeń pomóż sobie prostą mapą. Zapisz, kto może podejść fizycznie do panelu, w jakich godzinach, i z jakiego zakresu sieci można się do niego podłączyć. Taka „mapa dostępu” szybko pokaże miejsca, w których logowanie przez hasło to jedyne zabezpieczenie – a powinno być jednym z kilku. Czy potrafisz narysować taką mapę dla choćby jednego krytycznego HMI?

Drugi krok to decyzja, które ryzyka akceptujesz, a które chcesz wyeliminować. Być może świadomie pozwalasz operatorom na pracę bez indywidualnych kont, ale równocześnie blokujesz dostęp zdalny i ograniczasz fizyczny dostęp do panelu. Albo odwrotnie: dopuszczasz szeroki dostęp fizyczny, lecz uruchamiasz szczegółowe logowanie użytkowników i rejestr zdarzeń. Ważne, by ten wybór był świadomy, udokumentowany i spójny z polityką całego zakładu – inaczej każdy projektant HMI będzie wymyślał wszystko od nowa.

Na końcu liczy się jedno pytanie kontrolne: gdyby jutro wydarzył się incydent na HMI – poważna awaria, sabotaż albo seria „dziwnych” zmian parametrów – czy byłbyś w stanie powiedzieć, kto, kiedy i z jakiego poziomu zrobił ostatni krok? Jeżeli odpowiedź brzmi „nie”, to znak, że twoje hasła, role użytkowników i ślady aktywności wymagają dopracowania, zanim ktoś inny wykorzysta ich słabości.

Polityka haseł na panelu HMI – jak zaplanować, by ludzie nie „oszukiwali” systemu?

Jakie masz cele, a jakie ograniczenia?

Zanim zaczniesz definiować długość hasła i okres ważności, odpowiedz sam sobie: co chcesz osiągnąć polityką haseł? Ograniczyć sabotaż? Ochronić receptury? Mieć możliwość odtworzenia historii, kto co zrobił? Inne zasady będą potrzebne tam, gdzie panel stoi na pojedynczej maszynie z jedną zmianą, a inne w dużej linii z kilkoma brygadami i rotacją pracowników.

Drugi krok to ograniczenia. Jak operatorzy logują się dziś? Ile mają na to czasu? Czy panel stoi przy stanowisku, gdzie ludzie dotykają go co minutę, czy raczej co godzinę? Im częściej użytkownik musi się logować, tym większa pokusa obchodzenia zabezpieczeń – kartki z hasłem na obudowie, wspólne konto „operator1”, sesja nieblokowana przez tydzień.

Zastanów się: co jest dla ciebie ważniejsze – pełna identyfikowalność każdej akcji, czy raczej odróżnienie minimum: „operator” vs „serwis”? To zadecyduje, czy wchodzisz w indywidualne konta, czy w prostsze poziomy dostępu.

Podstawowe parametry dobrej polityki haseł

Większość środowisk HMI daje kilka przełączników dotyczących haseł. Kluczowe elementy, o których musisz zdecydować:

• Długość i złożoność – czy wystarczy 4–6 znaków, czy wymagane są litery, cyfry, znaki specjalne?
• Okres ważności – czy hasło wygasa po 30, 90, 180 dniach, czy jest bezterminowe?
• Historia haseł – czy użytkownik może użyć ponownie poprzedniego hasła?
• Blokada konta – po ilu nieudanych próbach konto ma się czasowo zablokować?
• Automatyczne wylogowanie – po jakim czasie bezczynności sesja ma wrócić do poziomu „gościa”?

Brzmi prosto, ale każde z tych ustawień może stać się codzienną udręką dla operatorów. Zbyt częsta zmiana haseł lub długa kombinacja na dotykowym ekranie kończy się tym, że ktoś zapisuje hasło na ramie panelu. Czy w twojej hali już gdzieś widać takie „ściągi”?

Długość i złożoność vs. ergonomia na hali

Bezpieczne hasło na komputerze biurowym to jedno, a bezpieczne i używalne hasło na HMI przy linii – drugie. Operator w rękawicach, pod presją restartu maszyny, nie będzie wpisywał skomplikowanej frazy z wielkimi literami i znakami specjalnymi bez błędów.

Dlatego zamiast kopiować politykę haseł z działu IT, zapytaj: ile realnie kliknięć jesteś w stanie „zabrać” operatorowi przy każdej autoryzacji? W wielu zakładach rozsądnym kompromisem jest:

• dla zwykłego operatora: PIN 4–6 cyfr lub proste hasło alfanumeryczne,
• dla ról technicznych i administracyjnych: dłuższe hasło z wyższą złożonością.

Możesz też rozdzielić poziomy: do prostych operacji (start/stop, potwierdzenie alarmu) wystarczy niski poziom dostępu, a do zmian receptur i konfiguracji potrzebna jest dodatkowa autoryzacja drugim poziomem hasła. Czy twoje HMI wspiera taką dwustopniową autoryzację?

Okres ważności hasła – jak nie przesadzić?

Automatyczna zmiana hasła co 30 dni brzmi dobrze w polityce, ale w praktyce na HMI często kończy się ciągłym resetowaniem przez przełożonych. Im częściej trzeba hasło zmieniać, tym mniej użytkownicy chcą wymyślać coś unikalnego.

Dla paneli HMI sensowne bywa podejście etapowe:

• Operatorzy i brygadziści – dłuższy okres ważności (np. 6–12 miesięcy) przy założeniu, że hasła nie są współdzielone.
• Konta techniczne / serwisowe – krótszy okres (np. 3–6 miesięcy) i wymuszona zmiana przy przekazywaniu obowiązków.
• Konta tymczasowe (np. dla serwisu zewnętrznego) – hasła ważne tylko w czasie wizyty lub na kilka dni.

Pytanie kontrolne: jak dziś zmieniasz hasła po odejściu pracownika? Czy masz procedurę, czy robisz to dopiero po pierwszym incydencie?

Wspólne loginy – kiedy akceptować, kiedy zakazać?

Wspólne konto „operator” jest wygodne, ale odbiera ci możliwość przypisania działań do konkretnej osoby. Z drugiej strony wymuszanie indywidualnych loginów na panelu, gdzie przechodzi 30 osób na zmianę, potrafi skutkować paraliżem i kombinowaniem.

Realistyczne rozwiązania, które często się sprawdzają:

• poziom „gość / operator linii” – wspólny, z ograniczonymi uprawnieniami (tylko odczyt + najprostsze działania),
• poziom „operator odpowiedzialny / lider zmiany” – indywidualne konta, identyfikujące osobę, która zatwierdza receptury, zmienia parametry krytyczne,
• poziomy „utrzymanie ruchu / automatyk” – zawsze indywidualne, ze ścisłą kontrolą, kto ma dostęp.

Jeśli dziś masz tylko jedno konto „operator” do wszystkiego, zacznij od małego kroku: dodaj pamiętne konto dla brygadzisty i ogranicz możliwość modyfikacji receptur tylko do niego. Zobacz, jak zespół reaguje, i dopiero potem wprowadzaj kolejne poziomy.

Blokady po nieudanych próbach i wygaszanie sesji

Blokada konta po kilku nieudanych próbach chroni przed „zgadywaniem” hasła, ale w środowisku produkcyjnym łatwo doprowadzić do blokowania się kont przez zwykłe pomyłki. Dlatego:

• ustaw raczej krótką blokadę czasową (np. 1–5 minut) niż całkowite zablokowanie konta do czasu interwencji administratora,
• rozważ różne progi dla różnych ról – np. operator: 5 prób, administrator: 3 próby.

Drugi mechanizm to automatyczne wylogowanie. Panel pozostawiony zalogowany na koncie o wysokich uprawnieniach to zaproszenie do nadużyć. Ustal, po jakim czasie bezczynności sesja ma spadać do poziomu „gość”. Dla ekranów używanych co kilka minut może to być 1–2 minuty, dla ekranów serwisowych – dłużej, ale zawsze z wyraźną informacją, kto jest aktualnie zalogowany.

Spójrz na swoje panele: czy na ekranie głównym widać, kto jest zalogowany i z jaką rolą? Jeśli nie, operatorzy często nawet nie wiedzą, że pracują na poziomie serwisowym.

Struktura ról i uprawnień – jak rozsądnie podzielić dostęp na HMI

Zacznij od procesów, nie od przycisków

Tworzenie ról typu „operator1”, „operator2” bez odniesienia do realnych zadań prowadzi do chaosu. Zamiast patrzeć na to, które przyciski są na ekranie, zacznij od pytania: kto za co odpowiada w procesie? Kto podejmuje decyzję o:

• uruchomieniu / zatrzymaniu linii,
• zmianie receptury lub jej parametrów,
• wejściu w tryb ręczny i sterowaniu napędami,
• zmianie nastaw zabezpieczeń i progów alarmów,
• aktualizacji oprogramowania, backupów, resetów systemu.

Kiedy masz już odpowiedzi, zbuduj wstępny szkic ról, które odzwierciedlają odpowiedzialności, nie stanowiska. Stanowiska mogą się zmieniać, ale odpowiedzialności w procesie zwykle są stabilniejsze.

Przykładowe poziomy ról na HMI

Jeden z prostszych i zarazem skutecznych modeli ról wygląda następująco:

• Poziom 0 – Gość / Odczyt
  Może oglądać podstawowe ekrany: stany maszyn, zamówienia, proste alarmy. Zero możliwości ingerencji.
• Poziom 1 – Operator
  Start/stop w normalnych warunkach, potwierdzanie niekrytycznych alarmów, drobne korekty bez wpływu na bezpieczeństwo. Brak dostępu do parametrów zabezpieczeń i receptur bazowych.
• Poziom 2 – Lider zmiany / Mistrz produkcji
  Zmiana receptur (w dozwolonym zakresie), decyzja o ponownym uruchomieniu po awarii, dostęp do bardziej szczegółowych trendów i raportów.
• Poziom 3 – Utrzymanie ruchu
  Tryb ręczny, testy wyjść, kalibracje, wybrane obejścia blokad – ale pod warunkiem dokumentacji i często z dodatkowymi potwierdzeniami na HMI.
• Poziom 4 – Automatyk / Administrator HMI
  Zmiana konfiguracji, struktury ekranów, logiki wizualizacji, zarządzanie kontami i uprawnieniami.

Nie musisz kopiować tej struktury 1:1. Kluczowe pytanie: czy każde działanie na HMI potrafisz przypisać do jednego z jasno opisanych poziomów odpowiedzialności?

Granice między rolami – gdzie postawić „mur”?

Najsłabsze miejsce w projektach HMI to często granica między operatorem a utrzymaniem ruchu. Jeżeli operator może wejść w tryb ręczny albo wyłączyć istotne blokady, prędzej czy później ktoś to zrobi – z ciekawości, z chęci przyspieszenia pracy, z braku świadomości skutków.

Dlatego dobrą praktyką jest:

• maksymalne ograniczenie trybu ręcznego do ról technicznych,
• odseparowanie ekranów serwisowych w osobnej sekcji z wyraźnym ostrzeżeniem (kolorystyka, baner),
• wymaganie dodatkowego potwierdzenia przy wejściu w tryb serwisowy, np. „Tylko dla UR / automatyki”.

Przejrzyj swoje ekrany: czy operator w 3 kliknięciach może zrobić coś, co projektant przewidział tylko dla serwisu? Jeśli tak – to nie kwestia „dyscypliny”, tylko źle ustawionych ról.

Uprawnienia per ekran, per funkcja czy per obiekt?

Większość środowisk HMI pozwala ustawiać uprawnienia na różnych poziomach:

• cały ekran (np. dostęp tylko od poziomu 2),
• konkretna funkcja (np. przycisk „Zapisz recepturę”),
• konkretny obiekt (np. pole edycji parametru bezpieczeństwa).

Częsty błąd to przypisywanie jednego poziomu do całego ekranu, na którym są zarówno funkcje informacyjne, jak i krytyczne. Efekt: albo wszystko jest zablokowane, albo wszystko otwarte. Rozsądne podejście:

• ekran dostępny już od niższego poziomu (np. 1),
• ale niektóre przyciski / pola edycyjne od wyższych poziomów (2 lub 3).

Dzięki temu operator może zobaczyć parametry i stany, lecz nie zmieni wszystkiego, co widzi. Czy w twoim projekcie masz ekrany „przeładowane” krytycznymi przyciskami, bo tak było wygodniej przy uruchomieniu?

Rola specjalna: „serwis zewnętrzny”

Serwis od dostawcy maszyny często potrzebuje szerokiego dostępu, ale tylko na krótko. Jeżeli ma dostęp do zwykłych kont technicznych, ryzykujesz, że uprawnienia zostaną z tobą na stałe.

Lepszy wariant:

• osobna rola „serwis zewnętrzny” z jasno zdefiniowanym zakresem funkcji,
• konto czasowe – ważne tylko w określonym oknie (np. data od–do),
• wyraźne logowanie wszystkich akcji wykonywanych z tej roli.

Zastanów się, jak dziś wpuszczasz dostawcę na HMI: czy dostaje hasło do konta technicznego, które potem zostaje na zakładzie? Jeżeli tak, to w praktyce tracisz kontrolę nad tym, kto realnie zna dane logowania.

Powiązanie ról HMI z procedurami zakładowymi

Nawet najlepiej zaprojektowane role na HMI nie zadziałają, jeśli nie mają oparcia w procedurach i szkoleniach. Przykłady prostych reguł, które warto powiązać z konfiguracją paneli:

• kto może tworzyć nowe konta i na czyj wniosek,
• kiedy wolno korzystać z trybu ręcznego (np. tylko przy zatrzymanej produkcji, z wpisem do książki serwisowej),
• jak długo może być aktywna sesja na poziomie „utrzymanie ruchu” bez interakcji użytkownika,
• kto zatwierdza zmianę poziomów uprawnień (np. awans operatora na lidera).

Spójrz na swoje zakładowe instrukcje: czy w ogóle wspominają o rolach na HMI, czy są skupione wyłącznie na procedurach technicznych?

Często drobne zmiany w projekcie HMI wymagają też aktualizacji instrukcji pracy i odwrotnie – zmieniasz procedurę, a ekrany zostają po staremu. Dobrą praktyką jest traktowanie konfiguracji ról na HMI jako załącznika do procedur: przy opisie czynności wpisz od razu minimalny poziom roli. Gdy przy audycie ktoś zapyta „kto może zresetować licznik bezpieczeństwa?”, nie szukasz w kodzie PLC, tylko otwierasz instrukcję i widzisz: „rola min. Poziom 3”.

Przeanalizuj też, jak przekazujesz zmiany personelowi. Czy przy każdej większej modyfikacji wizualizacji prowadzisz krótkie szkolenie z naciskiem na to, co zmienia się w uprawnieniach? Czy użytkownicy wiedzą, dlaczego niektóre przyciski nagle wymagają wyższej roli? Jeżeli ograniczasz dostęp „po cichu”, ludzie będą szukać obejść: wspólne hasła, niezamykanie sesji, klikanie „byle działało”.

Dobrym sprawdzianem jest proste ćwiczenie: poproś kilku operatorów i techników, żeby narysowali z pamięci hierarchię ról i zasady logowania. Jeśli powstaje kilka różnych wersji, to znaczy, że system żyje tylko w głowie automatyka. Dąż do tego, żeby zasady były zrozumiałe i dostępne tam, gdzie są potrzebne – np. jako krótka „ściąga” na ekranie logowania.

Jeżeli masz w zakładzie system zarządzania zmianą (MOC), włącz do niego także modyfikacje ról i uprawnień na HMI. Zmieniasz, komu wolno coś wcisnąć na panelu? To jest zmiana w sposobie sterowania maszyną, a nie „kosmetyka IT”. Zadaj sobie pytanie: kto to zatwierdził, kto to przetestował, jak udokumentowałeś wpływ na bezpieczeństwo i ciągłość produkcji?

Bezpieczeństwo dostępu do panelu HMI nie sprowadza się do jednego „mocnego hasła”, ale do spójnego układu: realistycznego modelu zagrożeń, sensownej polityki haseł, przejrzystych ról i czytelnego śladu aktywności. Jeśli po lekturze patrzysz na swoje panele i widzisz zbiór kompromisów sprzed lat, zadaj sobie najprostsze pytanie: co możesz zmienić w ciągu najbliższego tygodnia, żeby choć odrobinę utrudnić życie przypadkowym błędom i ciekawskim palcom? Jedna mała poprawka często otwiera drogę do kolejnych, już bardziej systemowych.

Ślad aktywności na HMI – co, kiedy i o kim chcesz wiedzieć?

Zanim włączysz jakiekolwiek logowanie zdarzeń, zadaj sobie pytanie: co chcesz móc odtworzyć po incydencie? Zwykle są to trzy scenariusze:

• doszło do awarii lub wypadku – „kto co zmienił tuż przed zdarzeniem?”,
• zmieniły się parametry jakości – „kiedy parametry receptury wyszły poza standard?”,
• pojawiają się dziwne zachowania użytkowników – „kto używa kont admina o 3:00 w nocy?”.

Od tych scenariuszy zacznij. Jeżeli dziś doszłoby do poważnego incydentu na linii, czy potrafiłbyś w ciągu godziny zrekonstruować, kto był zalogowany na HMI i jakie akcje wykonywał?

Co logować na panelu HMI, żeby nie utonąć w danych?

Logowanie wszystkiego „jak leci” kończy się folderem z tysiącem plików, których nikt nigdy nie otwiera. Lepiej wybrać kilka kategorii zdarzeń, które faktycznie pomagają w analizie:

• logowanie i wylogowanie użytkowników – z informacją o roli, czasie i miejscu (który panel),
• zmiany parametrów procesu – szczególnie tych powiązanych z bezpieczeństwem, jakością, wydajnością,
• zmiany w konfiguracji systemu – dodanie/edycja/usunięcie kont, zmiany ról, modyfikacje ekranów,
• operacje krytyczne – wymuszenia obejść, wyłączenia blokad, ręczne sterowanie napędami,
• użycie kont o podwyższonych uprawnieniach – każdorazowe wejście w tryb „serwisowy” lub admina.

Przejrzyj obecne logi: czy widzisz w nich konkretne działania użytkownika, czy tylko ogólne informacje typu „Sesja rozpoczęta / Sesja zakończona”?

Jak zapisywać zdarzenia, żeby były przydatne przy analizie?

Sam fakt, że panel „coś” zapisuje, nie oznacza jeszcze, że z tych danych da się skorzystać. Dobre zdarzenie w logu powinno zawierać przynajmniej:

• dokładny znacznik czasu (z sekundami, najlepiej zsynchronizowany z PLC / serwerem czasu),
• ID użytkownika oraz jego aktualną rolę w momencie zdarzenia,
• lokalizację – numer lub nazwę panelu, ewentualnie stację roboczą SCADA,
• opis akcji – co konkretnie się wydarzyło, np. „Zmiana parametru: [Nazwa] 80 → 120”,
• status – powodzenie / błąd, odmowa dostępu, przerwana operacja.

Jeżeli w logu widzisz wpisy typu „Użytkownik 5 – Zdarzenie 37”, to w praktyce jest to tylko tło szumu. Dopytaj dostawcę lub konstruktora systemu: czy możesz zmienić format logów tak, żeby zawierały zrozumiałe opisy?

Lokalne logi na panelu czy centralny system?

W małych instalacjach zwykle wszystkie ślady aktywności lądują na karcie pamięci panelu. To wygodne przy uruchomieniu, ale problematyczne przy większej skali. Zastanów się, która sytuacja jest bliższa twojej rzeczywistości:

• masz jeden–dwa panele i sporadyczne zmiany – lokalne logi wystarczą, o ile dbasz o ich zrzuty i archiwizację,
• masz kilkanaście paneli i wielu użytkowników – bez centralnego zbierania logów trudno o pełny obraz.

Jeżeli zmierzasz w stronę drugiego scenariusza, rozważ:

• wysyłanie kluczowych zdarzeń do serwera SCADA / historian,
• integrację z systemem SIEM lub innym narzędziem IT (jeśli twoje OT i IT współpracują),
• regularny eksport logów z paneli w z góry ustalonym formacie (CSV, syslog, plik binarny z konwerterem).

Jak dziś szukasz przyczyny incydentu? Czy musisz fizycznie chodzić od panelu do panelu, zgrywać pliki na pendrive i ręcznie je przeglądać?

Retencja logów – jak długo trzymać dane o aktywności?

Długość przechowywania logów to zawsze kompromis między pojemnością pamięci a użytecznością danych. Kilka prostych zasad pomaga go sensownie ustawić:

• dla dziennych operacji (logowania, drobne zmiany) często wystarcza kilka tygodni na panelu,
• dla zdarzeń krytycznych i zmian w konfiguracji lepiej utrzymywać historię co najmniej kilka miesięcy, a przy rygorystycznych normach – nawet kilka lat,
• jeśli logi zawierają dane osobowe (ID użytkownika powiązane z konkretną osobą), skonsultuj retencję z działem prawnym / RODO.

Najważniejsze: mieć jasną decyzję (spisaną, nie „w głowie automatyka”), jak długo i gdzie przechowywane są logi oraz kto odpowiada za ich archiwizację. Masz już taką decyzję, czy działasz „do zapełnienia karty SD”?

Przykładowy zestaw zdarzeń do logowania w typowej linii

Jeżeli szukasz punktu wyjścia, możesz zacząć od takiego minimalnego zestawu zdarzeń:

• logowanie / wylogowanie każdego użytkownika, z rozróżnieniem: normalne wylogowanie, automatyczne wylogowanie po czasie, utrata komunikacji,
• w każdej zmianie parametru:
  – nazwa parametru,
  – poprzednia i nowa wartość,
  – wynik walidacji (np. „odrzucono – poza zakresem”),
• każde wymuszenie trybu ręcznego lub wyłączenie blokady bezpieczeństwa,
• przejście w rolę wyższą niż operator (2, 3, 4),
• tworzenie, usuwanie i blokowanie kont użytkowników,
• przy każdej aktualizacji oprogramowania HMI – wersja przed i po plus użytkownik inicjujący.

To nadal jest zestaw „lekki”, ale już pozwala odtworzyć większość sytuacji problemowych. Na ile twój obecny system śladów aktywności zbliża się do powyższego minimum?

Praktyczne scenariusze i typowe pułapki przy zabezpieczaniu HMI

Konfigurując bezpieczeństwo paneli, wejdziesz w kilka powtarzających się sytuacji. Dobrze je wcześniej przewidzieć, zamiast gasić pożary po uruchomieniu.

„Wszyscy logują się na jedno konto” – skąd to się bierze i co z tym zrobić?

Wspólne konto „Operator” to klasyka. Czasem tak jest „bo tak łatwiej”, czasem „bo system nie wspiera więcej użytkowników”, a czasem po prostu nikt nie miał kiedy tego zmienić. Pytanie brzmi: czy jesteś w stanie przypisać konkretną akcję do konkretnej osoby?

Jeżeli nie, pomyśl o takich krokach:

• sprawdź, ile indywidualnych kont HMI faktycznie obsłuży,
• jeśli panel ma limit, rozważ integrację z nadrzędnym systemem (SCADA, domena, system przepustek),
• jeżeli naprawdę musisz mieć jedno konto na zmianę – zadbaj o równoległy zapis obsady zmiany (kto był na jakim stanowisku o danej porze) i powiąż go z logami HMI.

Co już próbowałeś, żeby odejść od wspólnego konta? Czy barierą jest technika, procedury, czy raczej przyzwyczajenie ludzi?

Zmiana ustawień „na chwilę” i zapomniane cofnięcia

Operator, który chce „na moment” obejść blokadę albo podnieść próg alarmu, niemal zawsze obiecuje sobie, że za chwilę przywróci normalne wartości. W praktyce telefon, awaria obok albo zmiana priorytetów robią swoje – tymczasowe ustawienie zostaje na tygodnie.

Technicznie możesz temu przeciwdziałać na kilka sposobów:

• parametry tymczasowe – ustawienie z automatycznym powrotem do wartości nominalnej po określonym czasie lub po spełnieniu warunku (np. zakończenie serwisu),
• wymuszony komentarz – przy zmianach wybranych parametrów pole „Powód zmiany”, zapisywane w logu,
• podwójne potwierdzenie – zmiana wybranego progu wymaga akceptacji drugiej osoby (np. wyższej roli).

Przejrzyj ostatnie poważniejsze incydenty jakościowe lub przestoje: czy ich źródłem nie były właśnie „chwilowe” zmiany na HMI?

Uprawnienia „pod projekt”, które nie nadążają za zmianami organizacji

System startuje z sensownie zdefiniowanymi rolami, ale po roku struktura zakładu wygląda już inaczej. Pojawiają się nowe stanowiska, łączy się działy, zmienia podział odpowiedzialności. Role na HMI zostają po staremu – bo „jeszcze działają”.

Skutek? Albo zbyt szeroki dostęp dla części osób, albo permanentne prośby o „pożyczenie hasła”, bo nowe zadania nie mieszczą się w starych zakresach. Tu pomaga prosty rytuał:

• raz na rok lub przy większej zmianie organizacyjnej przejrzyj listę ról i kont,
• porównaj ją z aktualnymi opisami stanowisk i odpowiedzialności w procesie,
• sprawdź, które konta nie były używane miesiącami – zwykle można je zablokować lub usunąć.

Zadaj sobie pytanie: kiedy ostatni raz patrzyłeś na listę użytkowników HMI i czy pokrywa się ona z aktualnym schematem organizacyjnym?

Testowanie uprawnień – nie tylko przy odbiorze maszyny

Podczas uruchomienia większość energii idzie w testy technologii i bezpieczeństwa maszyn. Uprawnienia na HMI sprawdza się często „przy okazji” – czy operator coś widzi, czy serwis coś może. Potem system żyje własnym życiem.

W praktyce opłaca się mieć prosty scenariusz testowy, który uruchamiasz przy większych zmianach w wizualizacji lub przy aktualizacji oprogramowania. Przykładowo:

• z konta „Operator” sprawdzasz, czy:
  – nie widzisz ekranów serwisowych,
  – nie możesz wejść w tryb ręczny,
  – nie zmienisz progów alarmów bezpieczeństwa,
• z konta „Utrzymanie ruchu” testujesz:
  – dostęp do ekranów diagnostycznych,
  – możliwość włączenia trybu ręcznego tylko po dodatkowym potwierdzeniu,
  – poprawne logowanie każdej krytycznej akcji,
• z konta „Serwis zewnętrzny” sprawdzasz:
  – czy nie widzisz danych, których nie powinieneś (np. innych linii, poufnych raportów),
  – czy konto traci ważność po ustalonym czasie.

Masz dziś spisaną choćby jedną stronę takiego scenariusza, czy polegasz na „zdrowym rozsądku” przy każdej zmianie?

Security by design: kilka decyzji, które warto podjąć na etapie projektu

Jeżeli dopiero projektujesz nową linię, masz największy wpływ na to, jak będzie wyglądać bezpieczeństwo HMI przez kolejne lata. Kilka decyzji na starcie może oszczędzić mnóstwa łatania „po fakcie”. Zastanów się:

• czy chcesz, by role i użytkownicy były definiowane lokalnie na każdym panelu, czy centralnie (np. w SCADA lub domenie AD),
• jakie minimalne poziomy ról będą w ogóle używane – nie ma sensu utrzymywać kilkunastu poziomów, z których połowa jest pusta,
• jak bardzo rozdzielasz dostęp do sterowania (akcji) od dostępu do informacji (trendów, raportów, KPI),
• czy ekrany będą projektowane od razu z myślą o różnych poziomach widoczności i edycji elementów.

Jaki masz dziś wpływ na nowe projekty? Czy wymagasz od dostawców, żeby role, logowanie i ślady aktywności były opisane w dokumentacji tak samo szczegółowo jak schematy elektryczne?

Współpraca OT–IT przy zabezpieczaniu dostępu do HMI

Panele HMI coraz rzadziej działają w pełnej izolacji. Połączenia z bazami danych, serwerami raportowymi, domeną Windows czy chmurą sprawiają, że granica między OT a IT rozmywa się. To rodzi nowe szanse i nowe problemy.

Integracja kont HMI z infrastrukturą IT

Jeżeli zakład ma rozbudowaną infrastrukturę IT (domena, system IAM, karty pracownicze), szkoda byłoby z niej nie skorzystać. Możesz:

• powiązać logowanie na HMI z kontem domenowym – użytkownik wpisuje te same dane, co do komputera,
• wykorzystać karty RFID / przepustki jako nośnik tożsamości – panel odczytuje dane z karty, a rolę przypisuje na podstawie informacji z systemu IT,
• zastanowić się, czy reset haseł i blokowanie kont może obsługiwać helpdesk IT, czy raczej lokalny lider zmiany w produkcji,
• z góry ustalić, co się stanie przy awarii łącza z serwerem domeny – czy HMI ma mieć lokalny „tryb awaryjny” z ograniczonym zestawem kont.

Jeśli integrujesz HMI z IT, zaproś administratora systemów na przegląd projektu zanim powstaną ekrany. Zadaj mu kilka prostych pytań: jak u was wygląda cykl życia kont użytkowników, jak obsługujecie odejścia pracowników, co się dzieje z kontem po roku braku logowania? Dzięki temu nie będziesz budować równoległego, ręcznego świata kont tylko dla kilku paneli na hali.

Podział odpowiedzialności: kto „rządzi” hasłami i rolami?

Przy połączonych światach OT i IT szybko wychodzi na wierzch spór: kto ma decydujący głos w sprawie ról i uprawnień na HMI? Produkcja zwykle chce szybko reagować na zmiany obsady, IT – trzymać się formalnych procedur i standardów cyberbezpieczeństwa. Jeśli tego nie uporządkujesz, skończysz albo z dzikimi kontami „na boku”, albo z paraliżem zmian.

Dobry kompromis wygląda zwykle tak: IT definiuje zasady ogólne (siła haseł, czas ważności, wymogi audytowe, integracja z domeną), a OT decyduje o mapowaniu ról na konkretne funkcje procesowe (co może operator linii, brygadzista, UR). W praktyce oznacza to np. wspólną tabelę: rola IT „StandardUser_OT” odpowiada na panelu poziomowi „Operator”, rola „Maintenance_OT” – „Utrzymanie ruchu” itd.

Zadaj sobie pytanie: kto dziś faktycznie zmienia uprawnienia na HMI, a kto za nie odpowiada „na papierze”? Jeśli to dwie różne osoby lub działy, zatrzymaj się i spisz razem prostą matrycę: kto zgłasza zmianę, kto ją zatwierdza, kto technicznie ją wprowadza i gdzie to notujesz.

Procedury na sytuacje wyjątkowe i awaryjne

Awaria sieci, atak ransomware na domenę, prace serwisowe po godzinach – wtedy wychodzi, czy zasady dostępu do HMI są przemyślane, czy tylko „działają w normalny dzień”. W wielu zakładach w sytuacji kryzysowej kończy się na łamaniu własnych zasad: wspólne konto serwisowe, hasła na kartkach, tymczasowe „odblokowanie wszystkiego”.

Lepsze podejście to kilka prostych reguł spisanych zawczasu. Przygotuj np. zamkniętą kopertę z kontem awaryjnym o szerokich uprawnieniach, dostępną tylko dla dyspozytora lub kierownika zmiany, z obowiązkowym wpisem do rejestru przy każdym użyciu. Dodaj do tego jasno opisaną ścieżkę: kiedy wolno z niej skorzystać, kogo trzeba powiadomić (IT, BHP, kierownika produkcji) i jak szybko po zakończeniu akcji przywracasz normalne ustawienia.

Pomyśl, jakie trzy najbardziej realistyczne scenariusze awaryjne dotyczą twojej hali: brak domeny, brak sieci między HMI a sterownikiem, brak ludzi z pełnymi uprawnieniami na zmianie nocnej. Czy w każdym z nich wiesz dziś, kto i jak dostałby się do krytycznych funkcji na panelu, nie rozwalając przy okazji całej polityki bezpieczeństwa?

Bezpieczeństwo dostępu do HMI nie sprowadza się do „mocnych haseł”, tylko do szeregu małych, świadomych decyzji: jak definiujesz role, jak śledzisz działania, jak współpracujesz z IT i jak przygotowujesz się na wyjątki. Jeśli wybierzesz choć jedno usprawnienie z opisanych pomysłów i wdrożysz je konsekwentnie na jednej linii, szybko zobaczysz, które nawyki działają, a które trzeba poprawić na kolejnych instalacjach. Najważniejsze pytanie brzmi: od czego zaczniesz w swoim zakładzie w najbliższym miesiącu?

Ślady aktywności na panelu HMI – co, jak i po co logować?

Hasła i role są potrzebne głównie po to, żeby wiedzieć, kto co zrobił. Bez sensownego logowania HMI masz tylko iluzję kontroli. Przy incydencie albo awarii zostaje zgadywanie, a nie analiza. Zastanów się: gdyby dziś ktoś zmienił recepturę lub wyłączył alarm, czy byłbyś w stanie wskazać konkretne konto, czas i miejsce?

Jakie zdarzenia na HMI są naprawdę istotne?

Nie chodzi o logowanie wszystkiego „co się da”, tylko tego, co ma znaczenie dla bezpieczeństwa procesu i ludzi. Dobrą bazą do listy krytycznych zdarzeń są: analiza ryzyka, procedury jakościowe i instrukcje stanowiskowe. Pomyśl, które akcje na panelu mogą zmienić zachowanie maszyny lub jakość produktu.

Najczęściej do rejestru powinny trafiać:

• logowania i wylogowania użytkowników (także nieudane próby),
• zmiany parametrów procesu zdefiniowanych jako krytyczne (prędkości, limity momentu, czasy, temperatury, progi alarmowe),
• przełączanie trybów pracy: ręczny/auto, bypass, tryb serwisowy, praca w degradacji,
• akceptacje i kasowania alarmów, szczególnie tych bezpieczeństwa,
• tworzenie, edycja i usuwanie receptur lub programów,
• zmiany w strukturze użytkowników: dodanie konta, zmiana roli, reset hasła, blokada, odblokowanie,
• dostęp do ekranów administracyjnych i serwisowych, także gdy nic tam nie zmieniono.

Sprawdź w swoim systemie: które z tych zdarzeń są dziś logowane, a których brakuje? Masz raczej „wodospad” nic nieznaczących wpisów, czy krótką, użyteczną historię?

Jakie informacje powinna mieć pojedyncza pozycja w logu?

Rejestr zdarzeń jest użyteczny, gdy pozwala odpowiedzieć na proste pytania: kto, co, kiedy, gdzie i jak. Bez tego staje się zbiorem luźnych komunikatów. Warto ujednolicić strukturę wpisu, niezależnie od producenta HMI.

Dla każdego zdarzenia staraj się mieć co najmniej:

• dokładny znacznik czasu (z sekundami, a najlepiej milisekundami – przy szybkich procesach to ma znaczenie),
• tożsamość użytkownika: nazwa konta lub identyfikator z karty RFID,
• rodzaj zdarzenia: logowanie, zmiana parametru, przełączenie trybu, kasowanie alarmu,
• opis obiektu: nazwa zmiennej, receptury, ekranu, funkcji,
• wartość przed i po zmianie (np. „próg temperatury: 80 → 95 °C”),
• źródło: numer panelu, nazwa linii, strefa produkcyjna,
• rezultat: akcja zakończona powodzeniem, odrzucona, wymagała dodatkowego potwierdzenia itp.

Zastanów się: gdy analizujesz jakąś awarię, czego najbardziej brakuje w obecnych logach? Nazwy użytkownika, wcześniejszej wartości parametru, a może informacji, z którego panelu poszła zmiana?

Lokalnie na panelu czy centralnie? Gdzie trzymać logi z HMI

Mały panel często ma własny rejestr zdarzeń, ale to za mało, gdy masz kilka linii, wiele stacji lub wymogi audytowe. Do wyboru masz trzy podstawowe podejścia – każde z innymi konsekwencjami.

1. Logowanie wyłącznie lokalne na HMI

• proste wdrożenie, bez dodatkowej infrastruktury,
• wystarczające dla pojedynczych, mniej krytycznych stanowisk,
• ograniczona pojemność i wygoda przeglądania (mały ekran, eksport „na żądanie”),
• ryzyko utraty historii przy awarii panelu lub wymianie sprzętu.

2. Centralny serwer logów (np. SCADA, baza SQL, syslog)

• zbierasz zdarzenia ze wszystkich HMI w jednym miejscu,
• łatwiejsze raportowanie, korelacja z danymi procesowymi i alarmami,
• lepsze spełnienie wymagań audytowych i norm jakościowych,
• konieczność zaprojektowania mechanizmu buforowania na HMI na wypadek utraty łączności,
• wymóg współpracy z IT (serwer, kopie zapasowe, uprawnienia dostępu do logów).

3. Model hybrydowy

• część zdarzeń (najważniejsze) idzie do systemu centralnego, reszta zostaje lokalnie,
• lokalne logi służą bieżącej diagnostyce na zmianie, centralne – analizom długoterminowym,
• w razie awarii sieci produkcja ma nadal wgląd w ostatnie operacje na panelu.

Jak dziś wygląda u ciebie przepływ informacji: operator widzi swoje logi lokalnie, a szef produkcji lub jakości ma zdalny dostęp do pełnej historii? Czy każdy „szpera” w innym systemie i nikt nie ma pełnego obrazu?

Dostęp do logów – kto może patrzeć i kto może je zmieniać?

Ślady aktywności są wrażliwe. Z jednej strony trzeba zapewnić przejrzystość dla osób odpowiedzialnych za proces. Z drugiej – uniemożliwić ciche „sprzątanie” historii po błędach czy nadużyciach. Zadaj sobie pytanie: kto może dziś kasować logi lub resetować panel do ustawień fabrycznych?

Praktyczne zasady są zwykle takie:

• operatorzy mogą przeglądać wybrane logi lokalnie (np. zmiany parametrów na ich linii), ale bez możliwości ich modyfikacji,
• brygadzista i utrzymanie ruchu mają szerszy wgląd – z kilku zmian, kilku paneli – nadal bez prawa usuwania,
• kierownictwo, jakość, bezpieczeństwo ma dostęp do pełnej historii przez system raportowy lub centralny serwer,
• kasowanie i archiwizacja logów odbywa się automatycznie według polityki retencji albo ręcznie, ale tylko przez kilka z góry określonych funkcji administracyjnych IT/OT.

Jeżeli dziś kasowanie logów jest dostępne z tego samego poziomu, co zwykłe zmiany receptur, zatrzymaj się. To zaproszenie do kłopotów przy pierwszym poważniejszym incydencie.

Od logów do konkretnej reakcji – jak używać śladów aktywności

Sam rejestr zdarzeń niczego nie poprawia, jeśli nikt do niego nie zagląda albo nie wyciąga wniosków. Spójrz, czy masz choć kilka prostych reguł wykorzystania logów w codziennej pracy.

Kilka praktycznych zastosowań:

• analiza po incydencie – każda poważna awaria lub „prawie-wypadek” powinny mieć w standardzie: zrzut logów z HMI z ostatnich godzin, wraz z komentarzem UR i brygadzisty,
• przeglądy okresowe – raz na miesiąc ktoś z OT/UTR przegląda wybrane logi (np. zmiany progów alarmów, użycie konta awaryjnego) i szuka podejrzanych wzorców,
• szkolenia – przy omawianiu błędów ludzkich na linii odwołujesz się do konkretnych zdarzeń z logów (anonimowo, jeśli trzeba), pokazując, co się stało i jak można było temu zapobiec,
• kontrola dostępu – logi pomagają wychwycić konta „widma”: użytkownicy, którzy się nigdy nie logują, albo odwrotnie – konto, które loguje się do kilku linii naraz o dziwnych porach.

Masz dziś kogoś, kto ma wprost wpisane w zakres obowiązków: „przegląd logów z HMI raz na X czasu” i jasny szablon raportu? Czy raczej zakładasz, że „jak będzie coś podejrzanego, to ktoś zauważy”?

Bezpieczne zarządzanie hasłami, tokenami i kartami w praktyce

Politykę haseł można pięknie opisać w dokumencie, ale w hali produkcyjnej liczy się to, co ludzie są w stanie realnie stosować. Zbyt skomplikowane zasady kończą się kartkami przyklejonymi do panelu, zbyt proste – przypadkowymi logowaniami „na kogoś”. Jak znaleźć środek?

Jak uprościć życie użytkownikom bez utraty bezpieczeństwa

Każdy dodatkowy krok przy logowaniu to potencjalny punkt oporu. Zanim zaostrzysz wymagania, zadaj sobie pytanie: co dokładnie chcesz dzięki temu osiągnąć? Ochronę przed kim – pracownikiem, który ma fizyczny dostęp, czy kimś z zewnątrz?

Przydatne są proste usprawnienia:

• logowanie zbliżeniowe (RFID) zamiast ręcznego wpisywania haseł na dotykowym ekranie – krócej trwa i zachęca do częstszego wylogowywania się,
• krótkie kody PIN powiązane z kartą lub kontem domenowym – panel weryfikuje „co masz” (kartę) i „co wiesz” (PIN),
• automatyczne wylogowanie po bezczynności dobrane do typu stanowiska – na szybkich liniach krótsze, na stanowiskach nadzorczych dłuższe,
• przycisk „szybkiego przełączenia użytkownika” – umożliwia zmianę osoby zalogowanej bez zamykania ekranów i przerywania pracy.

Jeżeli chcesz, by ludzie faktycznie używali kont osobistych, zrób test: ile czasu zajmuje typowemu operatorowi pełne zalogowanie z poziomu ekranu startowego? Jeżeli przekracza kilkanaście sekund, zaczną szukać skrótów.

Wspólne konta a odpowiedzialność – kiedy naprawdę nie ma wyjścia?

Indywidualne konta są ideałem, ale rzeczywistość bywa inna: szybkie rotacje, pracownicy tymczasowi, serwisy zewnętrzne. Pojawia się pokusa jednego konta „Operator” dla wszystkich na zmianie. Czy to zawsze zło absolutne? Niekoniecznie, jeśli świadomie ograniczysz takie konto i otoczysz je dodatkowymi zabezpieczeniami.

Kilka kompromisów, jeśli nie da się od razu przejść na pełną indywidualizację:

• wspólne konto tylko dla najniższego poziomu uprawnień, bez dostępu do zmian krytycznych parametrów,
• wszystkie akcje wymagające wyższego poziomu muszą być potwierdzone kontem imiennym (brygadzista, UR),
• czasowe podnoszenie uprawnień – operator loguje się wspólnym kontem, ale do wejścia w tryb serwisowy potrzebuje dodatkowego logowania brygadzisty,
• rejestr kto jest na zmianie – przy incydencie wiesz, które osoby faktycznie były obecne przy panelu, nawet jeśli korzystały ze wspólnego konta bazowego.

Pomyśl, czy dziś nie próbujesz wymagać od operatorów rzeczy nierealnych przy obecnej organizacji zmian. Czasem lepiej przejść etap pośredni (dobrze ograniczone konto wspólne + imienne potwierdzenia) niż udawać, że każdy ma swoje konto, a i tak wszyscy znają to samo hasło.

Zarządzanie cyklem życia nośników tożsamości (karty, breloki, tokeny)

Karta RFID lub brelok zbliżeniowy potrafią znacząco poprawić komfort pracy. Pod warunkiem, że ktoś panuje nad ich obiegiem. Gubione, pożyczane, „na stałe” zostawiane przy maszynie – to codzienność, jeśli nie ma jasnych zasad.

Przy projektowaniu systemu dostępu na karty odpowiedz sobie na kilka pytań:

• kto wydaje i odbiera karty – HR, lider zmiany, dział bezpieczeństwa, IT?
• jak szybko blokujesz kartę po zgłoszeniu zagubienia lub odejściu pracownika,
• czy karta jest personalizowana (imię, nazwisko, foto), żeby naturalnie zniechęcać do pożyczania,
• czy karty mają różne poziomy dostępu (np. inny typ dla operatorów, inny dla UR),
• czy masz procedurę dla gości i serwisu: karty tymczasowe, ważne tylko w określonym czasie.

Dobrym nawykiem jest okresowy przegląd listy kart i przypisanych im osób. Przy okazji wychodzą na jaw „martwe dusze” – identyfikatory przypisane do pracowników, którzy od dawna tu nie pracują, ale teoretycznie nadal mają dostęp do paneli.

Reset haseł i dostęp awaryjny a bezpieczeństwo

W praktyce duża część naruszeń bezpieczeństwa wynika nie z ataków zewnętrznych, ale z „pomocy” przy resetach. Hasła wysyłane SMS-em, dyktowane przez telefon, uniwersalne „hasło serwisowe” – to wąskie gardła, które łatwo przeoczyć.

Warto usystematyzować kilka rzeczy:

• kto ma prawo resetować hasła i jak weryfikuje tożsamość osoby proszącej o reset,
• czy reset wymaga odnotowania w prostym rejestrze (kto, kiedy, którego konta dotyczył),
• jak wygląda pierwszy login po resecie – użytkownik powinien zostać zmuszony do zmiany hasła na własne,
• jak długo działa dostęp awaryjny i czy po użyciu konta serwisowego system wymusza później powrót do normalnych, imiennych logowań.

Zastanów się, kiedy naprawdę potrzebujesz „master hasła” lub uniwersalnego konta serwisowego. Czy da się je zastąpić mechanizmem jednorazowych kodów przekazywanych przez dyżurnego inżyniera OT, ważnych np. tylko kilka godzin i tylko dla konkretnego panelu? Taki drobiazg potrafi mocno ograniczyć ryzyko nadużyć przy wsparciu zdalnym.

Przy resetach haseł wielu zakładów gubi się na etapie weryfikacji. Czy osoba prosząca o reset dzwoni z numeru firmowego? Czy jest na liście uprawnionych do pracy przy danej linii? Ktoś to sprawdza, czy wystarczy, że „powie nazwisko i numer stanowiska”? Uporządkowanie tych kilku kroków bywa ważniejsze niż kolejne skomplikowane wymagania co do długości hasła.

Przemyśl też scenariusz awaryjny: co się dzieje, gdy utracisz dostęp do kluczowego konta administracyjnego HMI? Gdzie jest zapisany sposób odzyskania kontroli – w głowie jednego automatyka, w notatniku szefa UR, czy w krótkiej, dostępnej procedurze, do której ma dostęp również dyżurny manager zmiany? Kryzys to najgorszy moment na improwizację.

Na koniec spójrz na cały system dostępu do paneli HMI jak na element codziennej pracy, a nie „dodatek IT”. Jakie masz dzisiaj trzy najważniejsze słabości: hasła, role, logi, a może obieg kart? Wybierz jeden obszar, ustal konkretny, mały cel na najbliższe 3 miesiące i doprowadź go do końca. Lepiej zrobić jeden dobrze domknięty krok niż po raz kolejny poprawić prezentację o cyberbezpieczeństwie, która i tak zostanie w szufladzie.

Najczęściej zadawane pytania (FAQ)

Jak zabezpieczyć panel HMI przed nieuprawnioną zmianą parametrów?

Na początek odpowiedz sobie: kto faktycznie powinien móc coś zmieniać, a kto tylko oglądać dane? Od tego zależy podział na role (np. operator, lider zmiany, utrzymanie ruchu, serwis). Najprostszy krok to zablokowanie ekranów z parametrami procesu, recepturami i trybami pracy i zostawienie bez logowania tylko podglądów oraz podstawowych przycisków „Start/Stop”, jeśli to bezpieczne.

Praktycznie robi się to przez:

• przypisanie poziomów uprawnień do ekranów lub przycisków,
• wymaganie logowania przy wejściu na „wrażliwe” ekrany (receptury, konfiguracja, tryb serwisowy),
• fizyczne rozdzielenie ekranów do podglądu i do ustawień (np. osobne menu „Ustawienia – tylko dla uprawnionych”).

Sprawdź na swoim projekcie: które 2–3 ekrany niosą największe ryzyko, jeśli ktoś „poklika dla zabawy”? Zacznij od nich.

Jakie role użytkowników ustawić na panelu HMI (operator, serwis, administrator)?

Najpierw zmapuj funkcje, a dopiero potem nazwy ról. Kto ma:

• tylko obsługiwać maszynę (start/stop, zmiana produktu w ramach zatwierdzonych receptur),
• korygować parametry procesu w wąskich granicach,
• mieć pełen dostęp do konfiguracji, komunikacji, trybów serwisowych?

Od tego wyjdź, zamiast od gotowych etykiet „operator”, „admin”.

Typowy, praktyczny podział to:

• Operator – obsługa bieżąca, brak dostępu do edycji receptur i ustawień bezpieczeństwa,
• Lider / brygadzista – zmiana wybranych parametrów, ładowanie i zapisywanie receptur,
• Utrzymanie ruchu / serwis – tryby ręczne, diagnostyka, testy I/O, ale bez zmiany polityki haseł,
• Administrator – konfiguracja panelu, komunikacji, użytkowników.

Zadaj sobie pytanie: które operacje dziś robi „każdy”, a wolałbyś je ograniczyć do 1–2 ról?

Jakie zasady haseł na HMI są realne w warunkach produkcyjnych?

Klucz to kompromis między bezpieczeństwem a ergonomią. Operator w rękawicach, przy przezbrojeniu co 20 minut, nie wpisze chętnie 16‑znakowego hasła z losowymi znakami. Zastanów się: ile realnie razy dziennie ma się logować i ile sekund możesz mu „zabrać” bez blokowania produkcji?

Praktyczne podejście:

• długość hasła np. 6–8 znaków, proste do wpisania na ekranie dotykowym,
• automatyczne wylogowanie po dłuższej bezczynności (np. 10–30 min, a nie 60 s),
• inne, mocniejsze hasła dla rzadko używanych kont „serwis” / „admin”,
• jeśli to możliwe – karty RFID, breloki lub logowanie z czytnika zamiast klepania hasła co chwilę.

Sprawdź, co już budzi opór na hali: długość hasła, częstotliwość logowania, czy może liczba różnych kont?

Czym różni się bezpieczeństwo panelu HMI od typowego bezpieczeństwa IT?

W IT priorytetem jest zwykle poufność danych. Na produkcji najważniejsze są nieprzerwana praca i bezpieczeństwo ludzi. Dlatego procedury typu „zmiana hasła co 30 dni, blokada konta po 3 błędnych próbach” mogą na hali sparaliżować linię, jeśli operator trzy razy pomyli się w rękawicach.

Na HMI potrzebujesz podejścia „hybrydowego”: część zasad z IT (indywidualne konta, sensowne hasła, wyłączone nieużywane usługi sieciowe), ale dopasowanych do realiów OT (czas wylogowania, sposób logowania, widok ekranów). Zadaj sobie pytanie: które polityki IT możesz wdrożyć 1:1, a które wymagają modyfikacji, żeby nie skończyło się karteczkami z hasłami na ramie panelu?

Co to jest ślad aktywności (audit trail) na HMI i po co go włączać?

Ślad aktywności to rejestr, kto i kiedy wykonał daną operację na panelu: zalogowanie, zmiana parametru, załadowanie receptury, wejście w tryb serwisowy. Bez tego, gdy coś pójdzie nie tak, zostaje tylko „ktoś coś nacisnął” – ale nikt nie wie kto i kiedy.

Audit trail przydaje się szczególnie:

• w branżach regulowanych (spożywcza, farmacja, automotive) – audytorzy pytają o to wprost,
• przy analizie przyczyn awarii lub serii reklamacji,
• przy podnoszeniu dyscypliny pracy (wiesz, kto zmieniał parametry i z jakiego konta).

Sprawdź w swoim oprogramowaniu HMI: czy masz funkcję logów użytkowników? Jeśli tak, jakie zdarzenia są logowane domyślnie, a które możesz dodatkowo włączyć?

Czy każdy ekran HMI powinien być zabezpieczony hasłem?

Nie. Zabezpieczenie „wszystkiego na głucho” prowadzi zwykle do jednego wspólnego konta i hasła zapisanego na obudowie. Rozsądniej jest rozdzielić:

• ekrany informacyjne i podstawowe sterowanie – bez logowania lub z minimalnymi wymaganiami,
• ekrany z parametrami procesu, recepturami, trybami pracy – dostęp po zalogowaniu odpowiedniej roli,
• ekrany serwisowe i konfiguracyjne – dostęp rzadki, ale silniej zabezpieczony.

Zadaj sobie pytanie: na których ekranach błąd użytkownika może zatrzymać linię albo naruszyć bezpieczeństwo? Te ekrany powinny być pierwsze do zabezpieczenia.

Dlaczego panele HMI często stają się najsłabszym ogniwem bezpieczeństwa?

W praktyce HMI często traktuje się jak „ładny ekran”, a nie urządzenie sieciowe i „pilot” do maszyny. Efekt? Lata bez aktualizacji firmware, domyślne konta „operator/1234”, włączone VNC lub webserwer, o których nikt już nie pamięta, i brak realnej kontroli, kto co zmienia.

Jeśli chcesz to zmienić, zrób szybki przegląd:

• jakie usługi sieciowe są włączone (VNC, HTTP, FTP, Modbus/TCP),
• czy nadal używane są konta typu „operator bez hasła”,
• czy panel nie jest „tymczasowo” zostawiony w trybie serwisowym od rozruchu,
• czy masz listę paneli i ich połączeń z innymi systemami.

Odpowiedz sobie szczerze: który z tych punktów najbardziej pasuje do twojej instalacji – i od niego zacznij porządki.