Projekt stanowi uniwersalne środowisko bazowe, zaprojektowane w celu wdrożenia bezpiecznej struktury sieciowej łączącej świat automatyki przemysłowej (OT) oraz systemów IT/IoT. Zgodnie z założeniami Modelu Purdue (ISA-95)Zamiast płaskiej struktury sieci, podzielono ją na trzy niezależne podsieci wirtualne (VLAN) kontrolowane centralnie przez zaporę sieciową. Stanowi to gotowy fundament infrastrukturalny, na którym realizowane będą kolejne projekty aplikacyjne, wymagające konkretnych konfiguracji reguł firewall.
Infrastruktura sprzętowo-sieciowa została zaprojektowana w taki sposób, aby odzwierciedlić fizyczne i logiczne połączenia pomiędzy warstwą sprzętową, środowiskiem wirtualizacji oraz fizycznymi urządzeniami obiektowymi. Poniższy schemat przedstawia kompletną architekturę logiczną oraz szczegółowe przypisanie urządzeń do konkretnych stref zabezpieczeń.
Rys 1. Strukturalny podział urządzeń i wirtualnych hostów na dedykowane strefy VLAN 66, VLAN 30 oraz VLAN 20.
- 1. VLAN 66 (IT / MANAGEMENT):
-
Co tu mieszka:
- Host zarządzający (WIN10 + VMWARE WORKSTATION PRO + WIN_11 + TIA PORTAL v21 + TIA PLCSIM ADVANCED)
- Switche: CISCO CBS350 + Mikrotik CRS310
- Raspberry Pi: DNS - Adguard Home + serwer stron APACHE
- Mini Komputer z Proxmox: HOME ASSISTANT, Failover dla PfSense, maszyny testowe
- Dostęp do Internetu: TAK. Połączenie przez zaporę NGFW pfSense - tutaj rządzą reguły pomiędzy Vlanami - zmostkowaną do routera ISP.
- Co tu mieszka: Gateway dla Sonoff (Zigbee), kamery, odkurzacz, sterowniki bram...
- Dostęp do Internetu: NIE.
- Co tu mieszka: Wirtualne PLC (S7-1500 / PLCSIM Advanced), fizyczne LOGO!9, Raspberry Pi PICO połączone Ethernetem oraz wszystkie bezpośrednio podłączone czujniki, liczniki, przyciski...
- Dostęp do Internetu: NIE.
- Firewall w pfSense: BLOKADA NA WSZYSTKO.
Rys 2. Konfiguracja i mapowanie wirtualnych interfejsów VLAN 66, VLAN 30 oraz VLAN 20 na zaporze pfSense.
Wdrożono politykę Default Deny. Zaimplementowano regułę blokującą ruch wychodzący i przychodzący na absolutnie wszystkie kierunki na poziomie zapory sieciowej PfSense. Sterownik PLC, moduł LOGO!9 oraz Raspberry Pi PICO pracują w strefie odciętej. Wskazana konfiguracja stanowi bazowy stan wyjściowy (Hardened Baseline)Dedykowane reguły oraz porty komunikacji przemysłowej będą dodawane w trakcie tworzenia konkretnego projektu i w zależności od potrzeb konfiguracji zapory.
Rys 3. Izolacja bezwzględna strefy OT (VLAN 20) – całkowita blokada ruchu sieciowego na zaporze pfSense.
Urządzenia IoT w podsieci VLAN 30 zostały objęte całkowitym zakazem komunikacji z pozostałymi interfejsami, podsieciami oraz siecią Internet. Aby poprawić przejrzystość reguł- wszystkie zakazane strefy docelowe zostały spięte w jeden zbiorczy ALIAS SIECIOWY na który nałożono regułę typu Block. Włączono logowanie potencjalnego ruchu z Vlanu 30 (IoT) w celu dodatkowego monitoringu sterowników firm "made in P.R.C".
Rys 4. Tabela reguł VLAN 30 na zaporze pfSense – izolacja ruchu aliasem sieciowym stanowiąca punkt wyjściowy dla strefy IoT z aktywnym logowaniem zdarzeń.
Bezpieczny dostęp zdalny do infrastruktury sieciowej zrealizowany przy użyciu VPN Tailscale. Wdrożone reguły routingu oraz polityki ACL ściśle ograniczają ruch zewnętrzny – połączenie z tunelem VPN umożliwia komunikację wyłącznie z podsiecią zarządzającą MANAGE (VLAN 66)Jakikolwiek ruch oraz próby nawiązania połączeń z poziomów VPN do odizolowanych stref automatyki OT oraz IoT zostały całkowicie zablokowane na poziomie zapory, co uniemożliwia bezpośredni dostęp do krytycznych segmentów sieci z zewnątrz.
Rys 5. Konfiguracja restrykcji dla interfejsu Tailscale – zezwolenie na ruch wyłącznie do strefy MANAGE (VLAN 66) przy bezwzględnej blokadzie dostępu do stref OT i IoT.
Przedstawiona architektura sieci stanowi elastyczny stan wyjściowy (Baseline Configuration) zaprojektowany z myślą o skalowalnej rozbudowie. Struktura pozwala na wdrażanie kolejnych komponentów automatyki przemysłowej i budynkowej. W kolejnych etapach projekty będą rozszerzane o integrację sterowników PLC SIEMENS oraz rozwiązań Smart Home jak LOXONE czy GRENTON
Poza implementacją logiki działania sterowników, kluczowym celem jest głębokie monitorowanie oraz ekstrakcja wszelkich możliwych danych diagnostycznych i telemetrycznych z podłączonych urządzeń. Pozwoli to na pełną kontrolę środowiska, generowanie szczegółowych wykresów wydajnościowych, wczesne wykrywanie anomalii w ruchu sieciowym oraz natychmiastowe raportowanie potencjalnych awarii sprzętowych, zanim wpłyną one na ciągłość działania systemu.