Bezpieczeństwo

IronFlock jest zaprojektowany dla przemysłowych i korporacyjnych środowisk IoT, gdzie bezpieczeństwo nie jest opcjonalne. System stosuje architekturę zero-trust z obroną warstwową na każdym poziomie — od łączności urządzeń po izolację danych.

Brak otwartych portów na urządzeniach

Urządzenia brzegowe uruchamiające IronFlock nie eksponują żadnych otwartych portów. Agent urządzenia inicjuje wszystkie połączenia wychodzące do routera komunikatów WAMP. Oznacza to:

• Na sieci urządzeń nie są potrzebne reguły zapory dla połączeń przychodzących.
• Urządzenia nie są wykrywalne ani bezpośrednio adresowalne z internetu.
• Dostęp zdalny działa przez odwrócone tunele — urządzenie łączy się na zewnątrz, nie w drugą stronę.

To eliminuje całą klasę wektorów ataku powszechnych w wdrożeniach IoT, gdzie urządzenia nasłuchują na otwartych portach.

Uwierzytelnianie

IronFlock używa OpenID Connect (OIDC) do uwierzytelniania użytkowników.

Uwierzytelnianie wieloskładnikowe

Wszystkie konta obsługują uwierzytelnianie dwuskładnikowe TOTP (Time-based One-Time Password). Użytkownicy mogą włączyć 2FA w ustawieniach konta używając dowolnej standardowej aplikacji uwierzytelniającej.

Klucze API

Dla dostępu programatycznego, użytkownicy generują klucze API które uwierzytelniają się przy REST API.

Uwierzytelnianie urządzeń

Urządzenia uwierzytelniają się używając WAMP-CRA (Challenge-Response Authentication) z poświadczeniami per urządzenie. Każde urządzenie otrzymuje unikalny sekret podczas procesu flashowania.

Zaszyfrowane transporty

Cała komunikacja w IronFlock jest zaszyfrowana:

Izolacja komunikatów

IronFlock używa WAMP (Web Application Messaging Protocol) do całej komunikacji w czasie rzeczywistym. Router komunikatów wymusza ścisłą izolację między projektami:

Osobne realmy

Każda kombinacja projektu i aplikacji dostaje własny realm komunikatów na routerze WAMP. Realm to całkowicie izolowana przestrzeń nazw — komunikaty opublikowane w jednym realmie są niewidoczne dla wszystkich innych realmów.

Oznacza to:

• Urządzenia w Projekcie A nie mogą widzieć komunikatów z Projektu B.
• Aplikacja X zainstalowana w Projekcie A ma inny realm niż Aplikacja X zainstalowana w Projekcie B.

Uwierzytelnianie realmu

Każde połączenie z realmem wymaga uwierzytelnienia. Urządzenia, serwisy backendowe i klienci UI muszą przedstawić ważne poświadczenia aby dołączyć do realmu.

Izolacja bazy danych

Każdy projekt dostaje własne dedykowane zasoby bazy danych w FleetDB (PostgreSQL):

• Osobne tabele — Każda kombinacja projektu i aplikacji ma własny zestaw tabel szeregów czasowych.
• Osobne poświadczenia — Każdy backend danych ma unikalne poświadczenia połączenia.
• Brak zapytań cross-project — Warstwa bazy danych wymusza że zapytania nie mogą przekraczać granic projektów.

System uprawnień

IronFlock wymusza model uprawnień per zasób gdzie każdy projekt, urządzenie, grupa, aplikacja, pulpit nawigacyjny i backend danych ma własną kontrolę dostępu:

• Właściciel zasobu ma pełną kontrolę i może przyznawać uprawnienia innym użytkownikom.
• Właściciel projektu automatycznie ma pełną kontrolę nad wszystkimi zasobami w projekcie.
• Każde uprawnienie jest dyskretną flagą boolowską — nie ma szerokich ról “admin” które przyznają nieograniczony dostęp.
• Wszystkie zmiany uprawnień są rejestrowane w niezmiennym śladzie audytu.

Bezpieczeństwo łańcucha dostaw oprogramowania

Bezpieczeństwo nie kończy się na sposobie działania oprogramowania — zaczyna się od tego, jak oprogramowanie jest budowane i dostarczane. IronFlock Supervisor, jedyny komponent IronFlock działający bezpośrednio na Twoich urządzeniach, jest budowany za pomocą wzmocnionego, w pełni zautomatyzowanego łańcucha dostaw, dzięki czemu możesz zaufać dokładnie temu, co trafia do Twojej floty.

• Minimalna powierzchnia ataku — Supervisor jest dostarczany jako pojedynczy, statycznie linkowany plik binarny Go bez zewnętrznych zależności środowiska uruchomieniowego i bez wbudowanego interpretera. Nie ma menedżera pakietów, nie ma drzewa bibliotek dynamicznych ani niczego nasłuchującego połączeń przychodzących — co radykalnie zmniejsza to, co atakujący mógłby obrać za cel.
• Ciągłe skanowanie podatności — Każde wydanie jest skanowane pod kątem znanych podatności (CVE) zarówno w naszym własnym kodzie, jak i we wszystkich zależnościach, przy użyciu analizy uwzględniającej osiągalność, która koncentruje się na ścieżkach kodu, które plik binarny faktycznie może wykonać. Skany są również uruchamiane według harmonogramu tygodniowego, więc podatności ujawnione po wydaniu danej wersji nadal pojawiają się w odniesieniu do już wdrożonych kompilacji.
• Wykaz materiałów oprogramowania (SBOM) — Każde wydanie publikuje kompletny SBOM w formacie CycloneDX — pełny inwentarz każdego komponentu i wersji, które weszły w skład pliku binarnego. Daje to Tobie oraz Twoim audytorom dokładną przejrzystość co do tego, co uruchamiasz.
• Podpisane, weryfikowalne kompilacje — Każdy binarny plik wydania niesie ze sobą poświadczenie pochodzenia podpisane przez sigstore, kryptograficznie powiązane z jego dokładną zawartością. Podpis wykrywa manipulacje i można go niezależnie zweryfikować, dzięki czemu możesz potwierdzić, że plik binarny został wytworzony przez potok IronFlock i nie został zmieniony podczas transmisji.
• Bramkowane, zautomatyzowane wydania — Budowanie, podpisywanie i publikowanie odbywają się w kontrolowanym potoku CI — nigdy na komputerze pojedynczego programisty. Nic nie jest publikowane, dopóki nie przejdzie pełny zautomatyzowany zestaw testów i zabezpieczeń, co gwarantuje, że dostarczany artefakt jest dokładnie tym, który został przetestowany i poświadczony.
• Bezpieczne aktualizacje over-the-air — Aktualizacje OTA są dostarczane przez zaszyfrowane kanały i pochodzą wyłącznie z opublikowanych przez IronFlock, podpisanych kompilacji — dzięki czemu urządzenia aktualizują się same, nigdy nie otwierając portu przychodzącego ani nie ufając niezweryfikowanemu artefaktowi.

Razem te mechanizmy kontroli zapewniają Ci weryfikowalny łańcuch nadzoru od kodu źródłowego po plik binarny działający na każdym urządzeniu.

Zgodność

Architektura bezpieczeństwa IronFlock obsługuje zgodność z:

• IEC 62443 — Bezpieczeństwo przemysłowych systemów automatyki i sterowania
• ISO 27001 — Zarządzanie bezpieczeństwem informacji
• SOC 2 — Kontrole organizacji usługowej dla bezpieczeństwa danych
• GDPR — Dane przechowywane w centrach danych UE (konfigurowalne), ślad audytu dla dostępu do danych
• EU Cyber Resilience Act (CRA) — SBOM-y dla każdego wydania oraz udokumentowany, ciągły proces obsługi podatności bezpośrednio odpowiadają na podstawowe obowiązki CRA dotyczące produktów z elementami cyfrowymi.
• SLSA / NIST SSDF — Podpisane pochodzenie kompilacji oraz bramkowany potok CI są zgodne z uznanymi ramami integralności łańcucha dostaw i bezpiecznego rozwoju oprogramowania.

Połączenie zaszyfrowanych transportów, uwierzytelniania, izolacji danych per projekt, szczegółowych uprawnień, kompleksowego rejestrowania audytu oraz wzmocnionego łańcucha dostaw oprogramowania zapewnia mechanizmy kontroli wymagane przez te ramy.