Stacja monitoringu środowiska OT/IoT ESP32

Cel i zakres projektu

Chciałem sprawdzić, czy potrafię zbudować od podstaw własną stację z informacjami i możliwością sterowania światłem. Wybrałem dane przydatne dla mnie, a ekran dotykowy pozwalał przechodzić między kolejnymi widokami.

Stacja wykorzystuje ESP32 i panel Nextion HMI. Przetestowałem współpracę z moim systemem, przełączanie ekranów oraz włączanie i wyłączanie oświetlenia z panelu. Projekt jest prywatnym prototypem edukacyjnym.

Co ujawniły domowe testy?

Pierwsza wersja nie ograniczała dostępu do panelu sterowania. Podczas domowych testów dzieci zaczęły korzystać z ekranu dotykowego, włączając i wyłączając oświetlenie. Ta sytuacja ujawniła brak ochrony funkcji pozwalających zmieniać stan urządzeń.

W odpowiedzi zabezpieczyłem panel sterowania hasłem. Zabezpieczenie dodałem po zaobserwowaniu problemu; dotyczyło dostępu do sterowania, a nie całego interfejsu. Było to proste usprawnienie prototypu wynikające z obserwacji jego użytkowania.

Ograniczenie funkcji i wydzielenie sieciowe

Pozostawiłem dodatkowe, niepotrzebne w tym projekcie funkcje i porty ESP32 niewłączone. Był to element ograniczania powierzchni ataku. Urządzenie pracuje w osobnej podsieci. To wydzielenie sieciowe; zakres izolacji zależy również od reguł komunikacji między podsieciami.

Dlaczego Security-by-Design jest istotne?

Z tego doświadczenia wyciągnąłem wniosek, że dostęp do informacji i możliwość sterowania warto rozpatrywać oddzielnie już podczas projektowania. W tym znaczeniu Security-by-Design jest dla mnie istotne: pytania o to, kto może korzystać z funkcji i jakie skutki może wywołać jego działanie, powinny pojawić się przed uruchomieniem rozwiązania.

W moim prototypie ochrona panelu była późniejszą korektą. Ta kolejność pokazała mi wartość wcześniejszego uwzględnienia kontroli dostępu, zamiast czekania, aż zwykłe użytkowanie ujawni jej brak.

Projekt skłonił mnie również do refleksji nad zasadą Least Privilege: dostęp do funkcji powinien odpowiadać potrzebom i odpowiedzialności użytkownika. Jest to wniosek dotyczący projektowania uprawnień, a nie deklaracja wdrożenia różnych ról w moim prototypie.

Przełożenie na biznes

W środowisku przemysłowym zakres uprawnień powinien wynikać z roli, kompetencji i odpowiedzialności za proces. Podgląd danych, obsługa urządzenia oraz zmiana konfiguracji oznaczają różne poziomy wpływu na działanie systemu. Interfejs powinien uwzględniać te różnice, a zmiany parametrów podlegać ustalonym zasadom.

Ważny jest również sposób reagowania na odchylenia. Jeżeli wcześniej stabilny proces zaczyna działać nieprawidłowo, sama korekta nastaw może jedynie zamaskować przyczynę. Najpierw trzeba ustalić, co się zmieniło i dlaczego. Zmiana parametrów może być uzasadniona, ale powinna wynikać z diagnozy oraz oceny jej wpływu na proces.

Domowy prototyp pozwolił mi zaobserwować prosty mechanizm: dostęp do sterowania daje możliwość wpływania na działanie systemu. W organizacji trzeba powiązać tę możliwość z odpowiedzialnością i zarządzaniem zmianą.

Wyniki i ograniczenia

Sprawdziłem wyświetlanie wybranych informacji, nawigację dotykową, sterowanie światłem oraz dostęp do panelu sterowania przez ekran z hasłem. Nie wdrażałem różnych poziomów uprawnień. Opis nie przedstawia testów odporności na obejście hasła, dokładności pomiarów ani długotrwałej niezawodności, więc nie potwierdza gotowości do zastosowania przemysłowego.

Podsumowanie

Projekt pozwolił mi połączyć budowę własnego urządzenia z obserwacją sposobu jego użytkowania i wprowadzeniem korekty. Najważniejszy wniosek dotyczy projektowania funkcji sterujących: trzeba określić nie tylko to, co urządzenie potrafi, lecz także kto i na jakich zasadach może wpływać na jego działanie.