Zgodność

HurricaneOS a regulacje UE

Trzy reżimy UE dotyczą urządzeń podłączonych do sieci, a to, który wiąże Ciebie, zależy od tego, co robisz. Jeśli operujesz flotą w objętym sektorze, dotyczy Cię NIS2. Jeśli wprowadzasz produkty na rynek, dotyczą Cię dyrektywa o urządzeniach radiowych i Cyber Resilience Act. Niektóre organizacje są jednym i drugim. Ta strona jest podzielona w ten sam sposób, bo te obowiązki nie są wymienne. To techniczne odwzorowanie w dobrej wierze, nie porada prawna.

Regulacje w skrócie

Regulacja	Kogo wiąże	Status
NIS2 — dyrektywa (UE) 2022/2555	Operatorzy usług kluczowych i ważnych	Obowiązuje. Nowelizacja UKSC w Polsce od 3 kwietnia 2026
Akt delegowany do RED (UE) 2022/30, art. 3.3(d)(e)(f)	Producenci wprowadzający na rynek UE urządzenia radiowe	Obowiązkowe od 1 sierpnia 2025
Cyber Resilience Act — rozporządzenie (UE) 2024/2847	Producenci produktów z elementami cyfrowymi	Raportowanie z art. 14 obowiązuje od 11 września 2026; pełne wymogi od 11 grudnia 2027

Jedno zastrzeżenie warte uwagi, bo to szczegół, który większość dostawców pomija: normy zharmonizowane EN 18031-1/-2/-3 zostały opublikowane w Dzienniku Urzędowym z ograniczeniami w styczniu 2025. Sekcje „rationale" i „guidance" nie dają domniemania zgodności, więc ścieżka normatywna jest węższa, niż sugeruje samo powołanie się na EN 18031. Lepiej to zaplanować, niż odkryć przy ocenie.

Jeśli operujesz flotą — NIS2

NIS2 nakłada obowiązki na operatorów, nie na oprogramowanie. Jeśli świadczysz usługi kluczowe lub ważne w objętym sektorze, to Ty jesteś podmiotem, który dyrektywa wskazuje, i tylko Ty możesz być zgodny. Żaden system operacyjny nie może być „zgodny z NIS2" za Ciebie, a każdy dostawca, który twierdzi inaczej, nie przeczytał dyrektywy.

To, co platforma może zrobić, to unieść ciężar technicznych środków, których NIS2 od Ciebie oczekuje, i dać Ci dowody na ich posiadanie. Poniżej artykuł 21 ust. 2 — dziesięć środków, które musi podjąć każdy objęty podmiot — wobec tego, co zapewnia HurricaneOS.

Używamy trzech uczciwych etykiet:

Zapewnione: platforma robi to domyślnie; dziedziczysz to.
Wspierane: platforma daje mechanizm, ale musisz go skonfigurować, obsługiwać lub rozszerzyć.
Po Twojej stronie: obowiązek organizacyjny, którego platforma nie może za Ciebie wypełnić. Mówimy to wprost, zamiast udawać.

Środek art. 21 ust. 2	HurricaneOS	Co faktycznie robimy
(a) Analiza ryzyka i polityki bezpieczeństwa SI	Po Twojej stronie	Twoja ocena ryzyka i zestaw polityk. Dostarczamy inwentaryzację floty, stan wersji OS i bazową konfigurację, których analiza ryzyka warstwy urządzeń potrzebuje jako danych wejściowych.
(b) Obsługa incydentów	Wspierane	Monitoring stanu i automatyczne wycofanie po nieudanym rozruchu na poziomie OS i sprzętu. Wykrywanie i pierwsza reakcja dla floty urządzeń; resztą zarządza Twój SOC.
(c) Ciągłość działania, kopie, DR, zarządzanie kryzysowe	Wspierane	Aktualizacje A/B oznaczają, że nieudana aktualizacja wraca bez wizyty na miejscu, a urządzenie można przywrócić do stanu fabrycznego i skonfigurować ponownie bez ponownego wgrywania obrazu. Kopie danych aplikacyjnych i plan kryzysowy są po Twojej stronie.
(d) Bezpieczeństwo łańcucha dostaw	Wspierane	Każdy zbudowany przez Ciebie obraz jest skanowany pod kątem znanych podatności (CVE), z wynikami per usługa według wagi. Nadal oceniasz nas jako dostawcę.
(e) Bezpieczeństwo w nabywaniu, rozwoju, utrzymaniu; obsługa podatności	Zapewnione	Comiesięczne aktualizacje bezpieczeństwa, backporty CVE na Twoją konkretną płytę, weryfikowana dostawa OTA i udokumentowany kontakt do zgłoszeń. Rdzeń tego, co kupuje subskrypcja.
(f) Polityki oceny skuteczności środków zarządzania ryzykiem	Wspierane	Wyniki skanu CVE przy każdym buildzie, wersja systemu i historia aktualizacji każdego urządzenia oraz dane o stanie urządzeń w Twoim dashboardzie. Ocena względem Twojej polityki jest po Twojej stronie.
(g) Podstawowa higiena cybernetyczna i szkolenia	Po Twojej stronie	Szkolenie personelu to obowiązek organizacyjny. Platforma zmniejsza powierzchnię ataku: niezmienny system plików root uniemożliwia operatorowi przypadkowe osłabienie urządzenia.
(h) Kryptografia i, w stosownych przypadkach, szyfrowanie	Wspierane	Kanały urządzenie–chmura są szyfrowane i wzajemnie uwierzytelniane (wzajemny TLS), z kluczem tożsamości urządzenia przechowywanym w TPM 2.0. Szyfrowanie danych aplikacji w spoczynku nie jest objęte tym odwzorowaniem; zapytaj nas, co dotyczy Twojego profilu sprzętowego.
(i) Bezpieczeństwo kadr, kontrola dostępu, zarządzanie aktywami	Wspierane	Dostęp do konsoli per konto oraz kompletny, wiarygodny rejestr urządzeń. Bezpieczeństwo kadrowe i Twój dostawca tożsamości są po Twojej stronie.
(j) Uwierzytelnianie wieloskładnikowe, zabezpieczona komunikacja	Wspierane	Wzajemnie uwierzytelniane, szyfrowane kanały urządzenie–chmura (wzajemny TLS, tożsamość urządzenia oparta na sprzęcie). Logowanie do konsoli odbywa się na indywidualnych kontach. MFA w Twoim zespole jest po Twojej stronie.

Rozpocznij

Zobacz HurricaneOS w akcji

Umów 30-minutowe demo albo zapytaj o trial na płycie, którą certyfikujemy, lub na wynajętej jednostce. Rozmowa do niczego nie zobowiązuje.

Umów demo

Jeśli wprowadzasz produkty na rynek — RED i CRA

To celowo krótsza połowa. Naszym głównym klientem jest operator floty; jeśli jesteś producentem, platforma nadal wnosi realną wartość, ale praca nad zgodnością jest po Twojej stronie i wolimy określić jej zakres z Tobą na rozmowie, niż sugerować odwzorowanie, którego nie zrobiliśmy dla Twojego konkretnego produktu.

Co Cię wiąże i od kiedy. Od 1 sierpnia 2025 cyberbezpieczeństwo z artykułu 3.3(d)(e)(f) RED jest obowiązkowe dla nowych bezprzewodowych produktów podłączonych do sieci wprowadzanych na rynek UE — bez tego nie oznaczysz produktu CE i nie sprzedasz go. W ramach CRA raportowanie podatności i incydentów z artykułu 14 obowiązuje od 11 września 2026 i obejmuje także produkty już w polu. Pełne obowiązki secure-by-design i utrzymania cyklu życia wchodzą 11 grudnia 2027.

Ochrona sieciRED 3.3(d). Urządzenia startują bez otwartego interfejsu zarządzania. Aplikacje działają odizolowane w kontenerach, a płaszczyzna kontrolna przyjmuje polecenia wyłącznie po wzajemnym uwierzytelnieniu.
Ochrona danych i prywatnościRED 3.3(e). Tożsamość urządzenia to klucz wygenerowany i przechowywany w TPM 2.0, a tożsamość jest zaprojektowana tak, by nie dało się jej skopiować na inne urządzenie, więc ruch jest powiązany z jednym, konkretnym, prawdziwym punktem końcowym. Transport jest uwierzytelniony i szyfrowany; magazyn danych każdej aplikacji jest odizolowany.
Ochrona przed nadużyciamiRED 3.3(f). Każde urządzenie trzyma własny klucz tożsamości w TPM 2.0, a tożsamość jest zaprojektowana tak, by nie dało się jej skopiować na inne urządzenie; płaszczyzna kontrolna przyjmuje urządzenie dopiero po wzajemnym uwierzytelnieniu.
Bezpieczne domyślniezałącznik I CRA. Urządzenie startuje w stanie utwardzonym, z niezmiennym rdzeniem, którego przejęta aplikacja nie nadpisze.
Aktualizacje przez cały cykl życiaobsługa podatności w CRA. Comiesięczne aktualizacje bezpieczeństwa OS przez powietrze na całą flotę, z automatycznym powrotem do znanego dobrego stanu przy nieudanej aktualizacji.
Dowody do raportowaniaartykuł 14 CRA. Wyniki skanu CVE przy każdym buildzie oraz historia wdrożeń i historia wersji systemu i aktualizacji każdego urządzenia — to, czego wymaga 24-godzinne wczesne ostrzeżenie i 72-godzinne zgłoszenie.

Tam, gdzie jesteśmy Twoim dostawcą, a nie Twoją platformą

Kiedy oceniasz swój łańcuch dostaw, jesteśmy w nim, i masz prawo do dowodów, a nie zapewnień. Co Ci damy:

naszą jurysdykcję i hosting w UE (hostowane w UE, w ramach EOG) na piśmie;
wyniki skanu CVE dla każdego obrazu, który budujesz, per usługa i według wagi;
nasz harmonogram ujawniania podatności i aktualizacji bezpieczeństwa, umownie;
powiadomienie w takim czasie, by — jeśli podatność w OS dotknie Twojej floty — dowiedzieć się na czas i dotrzymać własnych terminów wynikających z artykułu 23 NIS2 albo artykułu 14 CRA — oba liczą 24 godziny, a potem 72.

Czego nie będziemy twierdzić

Zgodnie z tym, jak mówimy o bezpieczeństwie wszędzie indziej na tej stronie:

Nie twierdzimy, że HurricaneOS „jest zgodny" z którymkolwiek z tych reżimów. Zgodność przypisana jest Tobie; platforma jest środkiem do niej.
Nie twierdzimy, że platforma wypełnia Twoje środki organizacyjne — szkolenia, ład korporacyjny, Twoją własną ocenę ryzyka, odpowiedzialność zarządu.
Nie twierdzimy, że niezmienność czy tożsamość urządzenia oparta na sprzęcie są wyróżnikiem. To standard, i wymieniamy je tu, bo regulacje o nie proszą — nie jako wyróżniki.
Nie twierdzimy, że wykrywanie naruszeń fizycznych jest właściwością platformy. TPM utrudnia wyciągnięcie klucza, co jest czymś innym niż wykrywanie fizycznej ingerencji. Reakcja na naruszenie na poziomie obudowy jest dostępna tylko na sprzęcie, który budujemy sami, specyfikowana per projekt.

Wymóg sprzętowy

Sprzętowy fundament zaufania nie jest tu opcjonalny. Do certyfikacji profilu sprzętowego wymagamy TPM 2.0 — płyta bez niego nie może bezpiecznie zarejestrować się w chmurze, więc jej nie wspieramy. To właśnie sprawia, że powyższe twierdzenia dotyczą każdego wspieranego urządzenia, a nie tylko części, i warto sprawdzić to wcześnie w swoim zestawieniu materiałowym, jeśli przynosisz własny sprzęt.

Zgłoś podatność

Jeśli odkryjesz podatność w HurricaneOS lub na tej stronie, napisz na contact@globalstorm.cloud.

Opisz ją na tyle dokładnie, by dało się ją odtworzyć, i daj nam rozsądny czas na reakcję, zanim ujawnisz ją publicznie.

Ten sam kontakt w formacie maszynowym: /.well-known/security.txt

Porozmawiajmy

Podaj swój sektor, to czy operujesz czy produkujesz, i orientacyjną liczbę bramek, a odwzorujemy te środki na Twoje konkretne wdrożenie. Twoje obowiązki w ramach tych regulacji i ich krajowych transpozycji są do ustalenia przez Ciebie i Twoich prawników.

Porozmawiajmy