Network isolation dla on-prem AI: minimalne wymagania NIS2

Czas czytania: ok. 9 minut. Klaster: nis2. Autor: Fryderyk.

Odpowiedź najpierw

NIS2 nie podaje gotowego schematu segmentacji sieci wokół systemu AI. Art. 21 ustawy o krajowym systemie cyberbezpieczeństwa wymaga za to środków adekwatnych do ryzyka w obszarach bezpieczeństwa sieci, kontroli dostępu oraz rozwoju i utrzymania systemów, a to w praktyce sprowadza się do izolacji. Minimalny sensowny podział dla on-prem AI to trzy strefy: strefa inferencji, w której stoi model i akceleratory, strefa danych z repozytoriami zasilającymi retrieval oraz strefa dostępu, przez którą łączą się użytkownicy i aplikacje. Ruch między strefami przechodzi wyłącznie zdefiniowanymi i logowanymi ścieżkami, a strefa inferencji nie ma swobodnego wyjścia do internetu. Jeśli system AI stoi w jednej płaskiej sieci z resztą infrastruktury, to nie jest tylko dług techniczny. To brak środka zarządzania ryzykiem, który audytor zapisze wprost. Ta notatka pokazuje minimalny podział i to, którą kontrolę Art. 21 domyka każda granica strefy.

Spis treści

1. Dlaczego izolacja to pytanie regulatorne, nie tylko techniczne
2. Trzy strefy: model minimalny
3. Reguły ruchu między strefami
4. Tabela: strefa, co wpuszczasz, co blokujesz
5. Mapowanie stref na Art. 21
6. Trzy błędy, które audytor wychwyci
7. FAQ
8. Disclosure i biases
9. Czego tu nie pokrywam
10. Powiązane notatki

Dlaczego izolacja to pytanie regulatorne, nie tylko techniczne

Segmentacja sieci jest starą, dobrze rozumianą praktyką bezpieczeństwa. Nowe jest to, że przy on-prem AI staje się jednocześnie argumentem compliance. Głównym powodem, dla którego organizacja produkcyjna stawia model u siebie, a nie w chmurze publicznej, jest kontrola nad przepływem wrażliwych danych operacyjnych. Ta kontrola jest wiarygodna tylko wtedy, gdy sieć faktycznie ją egzekwuje. Model uruchomiony lokalnie, ale wpięty w płaską sieć z otwartym wyjściem na zewnątrz, oddaje większość przewagi, dla której go tam postawiono.

Art. 21 ust. 2 wymienia między innymi bezpieczeństwo sieci i systemów informatycznych, kontrolę dostępu oraz bezpieczeństwo w rozwoju i utrzymaniu systemów. Żaden z tych punktów nie każe wdrożyć konkretnej topologii, bo lista jest technologicznie neutralna. Ale audytor, który pyta o środki adekwatne do ryzyka, oczekuje, że system przetwarzający dane wrażliwe będzie odseparowany od reszty, a nie że będzie dzielił segment z drukarkami i stacjami roboczymi. Izolacja jest więc miejscem, w którym decyzja architektoniczna i wymóg regulacyjny spotykają się w jednym artefakcie: w regułach zapory i w diagramie sieci.

Trzy strefy: model minimalny

Minimalny podział, który da się obronić przed audytorem i utrzymać w praktyce, opiera się na trzech strefach.

Strefa inferencji. Tu stoi serwer modelu, akceleratory i warstwa serwująca odpowiedzi. To najbardziej chroniony segment. Nie ma swobodnego dostępu wychodzącego do internetu, a dostęp administracyjny idzie wyłącznie z wydzielonej podsieci zarządzania. Aktualizacje modelu i obrazów wchodzą kontrolowanym kanałem, nie przez otwarte połączenie na zewnątrz.

Strefa danych. Tu żyją repozytoria, indeksy wektorowe i źródła, które zasilają retrieval. Ta strefa przyjmuje zapytania tylko ze strefy inferencji i tylko po zdefiniowanych portach. Nie jest wystawiona bezpośrednio użytkownikom. Jeśli budujesz RAG, to właśnie tu leży większość danych, których nie wolno wyprowadzić poza organizację, więc granica tej strefy jest granicą compliance. Pisałem o samej architekturze retrievalu w osobnej notatce o RAG on-prem.

Strefa dostępu. Tu wpinają się użytkownicy, aplikacje frontendowe i integracje. Ta strefa rozmawia ze strefą inferencji przez jeden zdefiniowany punkt wejścia, najlepiej bramę uwierzytelniającą żądania. Użytkownik nie widzi ani strefy danych, ani wewnętrznych portów modelu.

Trzy strefy to minimum, nie cel docelowy. Większe wdrożenia dokładają osobny segment zarządzania, segment logowania i strefę buforową dla integracji z systemami zewnętrznymi. Ale poniżej trzech stref trudno mówić o izolacji, która cokolwiek egzekwuje.

Reguły ruchu między strefami

Sam podział na strefy nic nie daje, jeśli ruch między nimi jest dowolny. Zasada jest prosta: domyślnie blokuj, jawnie dopuszczaj. Każde dozwolone połączenie ma znany kierunek, znany port i powód zapisany w dokumentacji reguł.

Kierunek ma znaczenie. Strefa dostępu inicjuje połączenie do strefy inferencji, nie odwrotnie. Strefa inferencji sięga do strefy danych, ale strefa danych nie inicjuje niczego w stronę użytkowników. Wyjście do internetu ze strefy inferencji jest domyślnie zamknięte, a jeśli model musi pobrać aktualizację, robi to przez kontrolowany, logowany kanał w oknie serwisowym, nie w trybie ciągłym.

To ten zestaw reguł, a nie sam fakt postawienia modelu lokalnie, jest dowodem, że dane nie wyciekają poza organizację. Reguły zapory i logi połączeń to artefakt, który pokazujesz audytorowi. Diagram sieci bez odpowiadających mu reguł jest deklaracją, nie kontrolą.

Tabela: strefa, co wpuszczasz, co blokujesz

Strefa	Wpuszczasz	Blokujesz
Inferencja	Żądania ze strefy dostępu, zarządzanie z podsieci admin	Wyjście do internetu, ruch bezpośrednio od użytkowników
Dane	Zapytania ze strefy inferencji na zdefiniowanych portach	Dostęp od użytkowników, inicjowanie połączeń na zewnątrz
Dostęp	Ruch użytkowników i aplikacji przez bramę	Bezpośredni wgląd w strefę danych i porty modelu

Wydrukuj tę tabelę i zestaw ją z realną konfiguracją zapory. Każda linia, której nie umiesz odwzorować w regule, to luka do opisania.

Mapowanie stref na Art. 21

Izolacja nie jest osobnym obowiązkiem NIS2. Jest sposobem, w jaki domykasz kilka obszarów Art. 21 naraz. Bezpieczeństwo sieci pokrywasz samym podziałem i regułami ruchu. Kontrolę dostępu domyka to, że użytkownik nie dosięga bezpośrednio ani modelu, ani danych. Bezpieczeństwo w rozwoju i utrzymaniu wspiera kontrolowany kanał aktualizacji, bo zmiana modelu nie oznacza otwarcia sieci na oścież. Logi połączeń między strefami zasilają obszar oceny skuteczności, bo dają dowód, że reguły faktycznie działają, a nie tylko istnieją na diagramie. Pełne mapowanie dziesięciu obszarów na system AI opisałem w osobnej ściądze NIS2.

Trzy błędy, które audytor wychwyci

Pierwszy: płaska sieć z modelem obok wszystkiego innego. Najczęstszy i najłatwiejszy do wychwycenia, bo wystarczy jedno spojrzenie na diagram. Lokalne uruchomienie modelu bez segmentacji daje złudzenie kontroli, której nie ma.

Drugi: strefy istnieją na diagramie, ale reguły ruchu są zbyt szerokie. „Dozwolone any-any wewnątrz sieci wewnętrznej" to nie izolacja. Audytor porówna diagram z konfiguracją i różnica będzie widoczna od razu.

Trzeci: otwarte, ciągłe wyjście strefy inferencji do internetu pod pozorem aktualizacji. To najgroźniejszy błąd, bo tworzy dokładnie tę ścieżkę wyprowadzenia danych, której on-prem miał zapobiec. Aktualizacja to okno serwisowe i kontrolowany kanał, nie stałe łącze.

FAQ

Czy NIS2 wymaga konkretnej liczby stref?

Nie. Ustawa nie podaje topologii ani liczby segmentów. Wymaga środków adekwatnych do ryzyka. Trzy strefy to praktyczne minimum, które łatwo obronić, ale liczba wynika z twojej analizy ryzyka, nie z przepisu.

Czy on-prem automatycznie spełnia wymóg izolacji?

Nie. Samo postawienie modelu lokalnie nie tworzy izolacji. Bez segmentacji i reguł ruchu lokalny model może być tak samo otwarty jak dowolny inny serwer w płaskiej sieci. Izolację tworzy konfiguracja, nie lokalizacja.

Jak to się ma do chmury publicznej?

W chmurze publicznej granica przepływu danych biegnie także przez dostawcę i jego podprocesorów, co przenosi część analizy na łańcuch dostaw. Zestawiłem to w osobnej notatce o publicznym LLM a NIS2. Przy on-prem granica jest wewnątrz twojej sieci, więc ciężar dowodu spoczywa na twoich regułach zapory i logach.

Czy segmentacja wystarczy do zgodności?

Nie. Izolacja pokrywa część obszarów Art. 21, ale nie zastępuje analizy ryzyka, obsługi incydentów, umowy z dostawcą ani nadzoru kierownictwa. Jest jednym z filarów, nie całą konstrukcją.

// disclosure i biasesDisclosure i biases

Piszę z perspektywy osoby pracującej nad rozwiązaniami AI uruchamianymi poza chmurą publiczną, więc naturalnie akcentuję wątki kontroli przepływu danych i architektury on-prem. Starałem się oddzielić wymóg regulacyjny od preferencji technicznej. Ten tekst nie jest opinią prawną ani projektem sieci dla konkretnej organizacji. Model trzech stref to uproszczenie robocze, a nie jedyny poprawny wzorzec.

// co tu nie pokrywamCzego tu nie pokrywam

Nie wchodzę w konkretne produkty zapór, rozwiązania mikrosegmentacji ani konfiguracje pod danego dostawcę. Pomijam segmentację na poziomie kontenerów i orkiestracji, która zasługuje na osobną notatkę. Nie omawiam też szczegółów szyfrowania ruchu wewnątrz stref ani zarządzania tożsamością maszynową, bo to osobne obszary. Skupiam się na minimalnym podziale sieci i jego związku z Art. 21.

Powiązane notatki

• AI on-prem w europejskiej produkcji 2026: kompletny przewodnik architektoniczny
• RAG on-prem: architektura, chunking, retrieval i co naprawdę wpływa na jakość
• Public cloud LLM a NIS2: szybka analiza Art. 21 ust. 1 lit. d
• NIS2 plus AI: mapowanie Art. 21 na konkretne kontrole, jedna ściąga