NIS2 a Twój stos technologiczny - dlaczego wybór frameworka to decyzja o compliance

Środa, 10:00. Spotkanie zarządu. Dyrektor IT prezentuje wyniki audytu gotowości do NIS2. Na slajdzie numer trzy widnieje lista: brak automatycznego wykrywania incydentów, brak monitoringu w czasie rzeczywistym, brak procedury zgłoszenia w 24 godziny, brak audytu łańcucha dostaw. Zarząd patrzy na dyrektora IT. Dyrektor IT patrzy na Tomka.

Tomek wie, że system produkcyjny działa na frameworku, w którym "monitoring" oznacza ręczne sprawdzanie logów raz w tygodniu. Wie, że po ostatniej awarii dowiedział się o niej od klienta. Wie, że pytanie "jak szybko możemy przywrócić system po incydencie?" nie ma odpowiedzi, bo nikt tego nie testował. I wie, że kary za niespełnienie NIS2 sięgają 10 mln EUR.

To nie jest hipotetyczny scenariusz. Od 2024 roku NIS2 obowiązuje w całej UE, a Polska implementuje ją ustawą o krajowym systemie cyberbezpieczeństwa. Jeśli Twoja firma jest na liście - a ta lista jest dłuższa niż myślisz - wymagania są twarde, terminy krótkie, a kary wzorowane na RODO.

Czym jest NIS2 i dlaczego jest surowsza od poprzedniczki

NIS2 (Network and Information Security Directive 2) to dyrektywa UE, która zastąpiła swoją poprzedniczkę z 2016 roku. Mówiąc najprościej: stara regulacja nie nadążyła za rzeczywistością. Ataki ransomware na szpitale, Colonial Pipeline, SolarWinds - pokazały, że wymagania z 2016 roku to za mało.

Co się zmieniło:

Ostatni wiersz jest kluczowy: NIS2 wymaga oceny bezpieczeństwa dostawców. Jeśli Twój software house buduje system, który podlega NIS2 - on też jest w grze.

Kogo obejmuje NIS2

Podmioty kluczowe (essential entities)

Energetyka, transport, bankowość i infrastruktura finansowa, ochrona zdrowia, woda pitna, ścieki, infrastruktura cyfrowa (centra danych, CDN-y, DNS), administracja publiczna, przestrzeń kosmiczna.

Kary: do 10 mln EUR lub 2% rocznego światowego obrotu - co jest wyższe.

Podmioty ważne (important entities)

Usługi pocztowe, gospodarka odpadami, produkcja chemikaliów, produkcja żywności, wyroby medyczne, elektronika, platformy handlowe, wyszukiwarki, usługi chmurowe.

Kary: do 7 mln EUR lub 1,4% rocznego obrotu.

Ważne: próg wejścia

NIS2 dotyczy firm zatrudniających 50+ osób lub z obrotem powyżej 10 mln EUR w wymienionych sektorach. Mikro i małe przedsiębiorstwa są co do zasady wyłączone - chyba że pełnią krytyczną rolę w infrastrukturze (np. jedyny dostawca DNS w regionie).

Ale jest haczyk: nawet jeśli Twoja firma jest poniżej progu, jesteś objęty, gdy Twoi klienci podlegają NIS2 i Ty jesteś elementem ich łańcucha dostaw. Software house budujący system dla szpitala czy operatora energetycznego? Jesteś w łańcuchu dostaw podmiotu kluczowego.

6 wymagań NIS2 i jak odpowiada na nie nasz stack

To jest sedno sprawy. NIS2 definiuje konkretne wymagania techniczne i organizacyjne. Pokażemy, jak Elixir, Phoenix, BEAM i PostgreSQL adresują każde z nich - nie teoretycznie, ale z kodem i architekturą.

1. Zarządzanie ryzykiem i ciągłość działania

Co wymaga NIS2: Wdrożenie polityk analizy ryzyka, plany ciągłości działania, procedury backupu i disaster recovery z określonym RTO/RPO.

Co to oznacza technicznie: System musi działać nawet gdy coś się zepsuje. Musi być plan B. I plan C.

BEAM rozwiązuje to na poziomie architektury, a nie dokumentów:

# Supervisor tree - system naprawia się sam
# Crash jednego procesu nie kładzie reszty
children = [
  {Phoenix.Endpoint, []},          # serwer HTTP
  {App.Repo, []},                  # połączenie z bazą
  {App.IncidentMonitor, []},       # monitoring incydentów
  {App.AuditLogger, []},           # logowanie audytowe
  {App.BackupScheduler, []}        # automatyczny backup
]

# Strategia: jeśli jeden child umrze, restartuj tylko jego
opts = [strategy: :one_for_one, name: App.Supervisor]
Supervisor.init(children, opts)

W tradycyjnym stacku (Java, Node.js, Python): crash jednego komponentu to ryzyko upadku całego serwera. Plan ciągłości działania? Dokument w Wordzie, który mówi "zadzwoń do admina".

W BEAM: crash jednego procesu restartuje tylko ten proces w milisekundach. Reszta systemu nie zauważa. Użytkownik nie zauważa. To nie jest "plan" ciągłości działania - to architektura ciągłości działania.

2. Obsługa i raportowanie incydentów

Co wymaga NIS2: Wykrywanie, analiza i reagowanie na incydenty. Wczesne ostrzeżenie w ciągu 24 godzin, pełny raport w 72 godziny.

Co to oznacza technicznie: System musi sam wykrywać anomalie, natychmiast powiadamiać odpowiednie osoby i generować dane do raportu - automatycznie, nie po tygodniu grzebania w logach.

Phoenix i Elixir mają to wbudowane:

# Telemetry - zdarzeń w systemie jest więcej niż logów
# Phoenix emituje eventy dla KAŻDEGO żądania HTTP automatycznie
:telemetry.attach_many("nis2-incident-detection", [
  [:phoenix, :endpoint, :stop],
  [:ecto, :repo, :query],
  [:app, :auth, :failed_login]
], &App.IncidentDetector.handle_event/4, nil)

defmodule App.IncidentDetector do
  # Wykryj anomalie w czasie rzeczywistym
  def handle_event([:app, :auth, :failed_login], _measurements, meta, _config) do
    count = FailedLoginCounter.increment(meta.ip_address)

    if count > 20 do
      # 20+ nieudanych logowań z jednego IP w ciągu godziny
      App.Incident.create!(%{
        type: :brute_force_attempt,
        severity: :high,
        source_ip: meta.ip_address,
        detected_at: DateTime.utc_now(),
        details: "#{count} nieudanych prób logowania w ciągu godziny"
      })

      # Automatyczne powiadomienie - 24h wymóg NIS2 spełniony w sekundy
      App.Notifications.alert_security_team(:brute_force, meta)
      App.Notifications.notify_csirt(:early_warning, meta)
    end
  end
end

Kluczowe: Telemetry jest wbudowany w Phoenix. Nie instalujesz dodatkowej biblioteki. Nie konfigurujesz agenta. Każde żądanie HTTP, każde zapytanie do bazy, każda operacja - emituje zdarzenie, na które możesz reagować. W Node.js/Express potrzebujesz zewnętrznego middleware, który musi być ręcznie dodany do każdego route'a. W Javie/Spring - aspektów i interceptorów.

3. Bezpieczeństwo łańcucha dostaw

Co wymaga NIS2: Ocena bezpieczeństwa dostawców IT, w tym jakości kodu i procesów wytwórczych.

Co to oznacza technicznie: Musisz wiedzieć, jakie zależności używa Twój system, czy nie mają znanych podatności, i kto je utrzymuje.

Elixir i Hex (menedżer pakietów) dają narzędzia:

# Audyt zależności - sprawdza znane podatności (CVE)
$ mix deps.audit
  No vulnerabilities found.

# Sprawdź licencje zależności
$ mix hex.audit
  Checking for retired packages...
  All packages are up to date.

# Mix lockfile - każda zależność ma hash kryptograficzny
# Nikt nie podmieni pakietu bez wykrycia
$ cat mix.lock
%{
  "phoenix": {:hex, :phoenix, "1.8.0",
    "abc123...",  # hash SHA-256
    [:mix], [...]},
  "ecto": {:hex, :ecto, "3.12.0",
    "def456...",
    [:mix], [...]},
}

Porównaj to z ekosystemem npm (Node.js):

30 zależności, które znasz, vs 1 500 pakietów, z których 1 200 to zależności tranzytywne, o których istnieniu nie wiesz. Który łańcuch dostaw łatwiej audytować?

4. Szyfrowanie i bezpieczeństwo danych

Co wymaga NIS2: Stosowanie kryptografii i szyfrowania tam, gdzie to stosowne, ochrona danych w spoczynku i w transporcie.

Phoenix i Ecto robią to domyślnie:

# config/prod.exs - szyfrowanie połączenia z bazą
config :app, App.Repo,
  ssl: true,
  ssl_opts: [
    verify: :verify_peer,
    cacertfile: "/etc/ssl/certs/ca-certificates.crt"
  ]

# Sesje - podpisane i zaszyfrowane, domyślnie
config :app, AppWeb.Endpoint,
  secret_key_base: "...",  # klucz do podpisu i szyfrowania
  session: [
    store: :cookie,
    signing_salt: "...",
    encryption_salt: "...",
    # HttpOnly, Secure, SameSite - domyślnie włączone
  ]

-- PostgreSQL - szyfrowanie at rest
-- Transparent Data Encryption lub LUKS na poziomie filesystemu

-- Row-Level Security - dostęp na poziomie wiersza
ALTER TABLE incydenty ENABLE ROW LEVEL SECURITY;

CREATE POLICY incydenty_per_org ON incydenty
  USING (organization_id = current_setting('app.org_id')::int);

-- Audit log - kto co kiedy (wymóg NIS2)
CREATE TABLE security_audit_log (
    id BIGSERIAL PRIMARY KEY,
    timestamp TIMESTAMPTZ DEFAULT NOW(),
    user_id INTEGER NOT NULL,
    action TEXT NOT NULL,
    resource TEXT NOT NULL,
    ip_address INET,
    details JSONB
);

W Phoenix nie musisz pamiętać o escapowaniu HTML (anty-XSS) ani o parametryzowaniu zapytań SQL (anty-injection) - framework robi to za Ciebie. Programista musi celowo użyć niebezpiecznej funkcji (raw(), fragment()), żeby obejść zabezpieczenia. Bezpieczny kod jest domyślny. Niebezpieczny wymaga wysiłku.

5. Kontrola dostępu i uwierzytelnianie

Co wymaga NIS2: Polityki kontroli dostępu, uwierzytelnianie wieloskładnikowe (MFA), zarządzanie tożsamością.

# Phoenix.Gen.Auth - generuje kompletny system autentykacji
# z hashowaniem haseł (Argon2), sesjami, tokenami, resetem hasła
$ mix phx.gen.auth Accounts User users

# Wygenerowany kod zawiera:
# - Rejestrację z walidacją
# - Logowanie z rate limitingiem
# - Sesje z czasem wygasania
# - Tokeny do resetu hasła (jednorazowe, z TTL)
# - Potwierdzenie email
# - Hook do dodania 2FA/MFA

# Dodanie TOTP (2FA) - 30 linii kodu
defmodule App.Accounts.UserTOTP do
  use Ecto.Schema

  schema "users_totp" do
    field :secret, :binary, redact: true
    belongs_to :user, App.Accounts.User
    timestamps()
  end

  def verify(totp, code) do
    NimbleTOTP.valid?(totp.secret, code)
  end
end

W tradycyjnych stackach autentykacja to albo zestaw bibliotek do sklejenia (Passport.js + express-session + connect-redis + ...), albo zewnętrzny serwis (Auth0, Keycloak). Phoenix daje gotowy, bezpieczny, audytowalny system auth jednym poleceniem.

6. Monitoring, logi i audytowalność

Co wymaga NIS2: Ciągły monitoring, zdolność do wykrywania anomalii, kompletne logi dla celów audytowych.

Tu BEAM ma przewagę, jakiej żaden inny runtime nie oferuje:

# LiveDashboard - monitoring produkcyjny bez zewnętrznych narzędzi
# Wbudowany w Phoenix, zero konfiguracji
scope "/admin" do
  pipe_through [:browser, :require_admin]
  live_dashboard "/dashboard",
    metrics: AppWeb.Telemetry,
    ecto_repos: [App.Repo]
end

# Co widzisz w LiveDashboard:
# - Zużycie pamięci per proces BEAM
# - Liczba procesów (i ostrzeżenie przy anomalii)
# - Czasy odpowiedzi HTTP (p50, p95, p99)
# - Zapytania SQL (najwolniejsze, najczęstsze)
# - Kolejki (Oban jobs)
# - ETS tables
# - Port/socket usage

# BEAM :observer - głęboka inspekcja w runtime
# Możesz zobaczyć KAŻDY proces, jego stan, pamięć, message queue
# W produkcji, na żywo, bez restartu, bez wpływu na działanie systemu

Porównaj to z typowym stackiem Node.js/Java:

LiveDashboard to nie zabawka. To pełnoprawny dashboard monitoringowy, dostępny z przeglądarki, bez instalacji zewnętrznych narzędzi, bez konfiguracji agentów, bez kosztu licencji. Audytor NIS2 pyta "pokaż mi monitoring systemu" - otwierasz URL w przeglądarce.

Pełna mapa: wymagania NIS2 → nasz stack

To nie jest lista "co trzeba doinstalować". To lista tego, co jest już wbudowane i wymaga co najwyżej konfiguracji, nie implementacji od zera.

Koszt compliance: nowy system vs dorabianie do legacy

Budowa nowego systemu z myślą o NIS2 (Elixir/Phoenix/PostgreSQL)

Dorabianie NIS2 do legacy systemu (PHP/Java/.NET/Node.js)

Różnica jest 3-5x. I to nie dlatego, że Elixir jest "magiczny". To dlatego, że BEAM został zaprojektowany przez Ericssona do systemów telekomunikacyjnych, które musiały spełniać wymagania regulacyjne dotyczące ciągłości działania i monitoringu 40 lat zanim ktokolwiek wymyślił słowo "NIS2".

Monitoring, izolacja awarii, hot code reload, clustering, strukturalne logi - to nie są "ficzery" dodane w późniejszych wersjach. To fundamenty platformy.

Odpowiedzialność osobista zarządu - nowy wymiar

NIS2 wprowadza coś, czego w poprzedniej dyrektywie nie było: osobistą odpowiedzialność członków zarządu za cyberbezpieczeństwo. Zarząd musi zatwierdzać środki zarządzania ryzykiem i nadzorować ich wdrożenie. Niewystarczające środki mogą skutkować:

• Karami finansowymi dla firmy (do 10 mln EUR / 2% obrotu)
• Osobistą odpowiedzialnością członków zarządu
• Tymczasowym zakazem pełnienia funkcji kierowniczych

To zmienia dynamikę rozmowy. CTO nie może już powiedzieć zarządowi "bezpieczeństwo to kwestia IT". Zarząd musi rozumieć i zatwierdzać decyzje technologiczne, bo odpowiada za nie osobiście.

Wybór stosu technologicznego, który ma bezpieczeństwo i monitoring wbudowane domyślnie - zamiast stacka, w którym trzeba to "dorobić" - to decyzja, którą zarząd powinien świadomie podjąć.

Raportowanie incydentów - timeline NIS2

NIS2 definiuje ścisły harmonogram zgłaszania incydentów:

Wykrycie incydentu
    │
    ├── 24h ──→ Wczesne ostrzeżenie do CSIRT
    │           (co się stało, wstępna ocena)
    │
    ├── 72h ──→ Pełne zgłoszenie incydentu
    │           (zakres, wpływ, podjęte działania)
    │
    └── 1 mies. ──→ Raport końcowy
                    (analiza root cause, wnioski)

24 godziny na wczesne ostrzeżenie. Jeśli Twój system nie ma automatycznego wykrywania incydentów, dowiadujesz się o nich od klientów - a to oznacza, że 24h już minęło, zanim w ogóle wiesz, co się stało.

W Phoenix z Telemetry pipeline wygląda tak:

# Automatyczny pipeline raportowania NIS2
defmodule App.NIS2.IncidentPipeline do
  # Krok 1: Wykrycie (automatyczne, real-time)
  def detect(%Event{type: :security_anomaly} = event) do
    incident = App.Incident.create!(event)

    # Krok 2: Wczesne ostrzeżenie (automatyczne, < 1 minuta)
    App.NIS2.EarlyWarning.send_to_csirt(incident)
    App.Notifications.alert_management(incident)

    # Krok 3: Zbieranie danych do raportu (automatyczne)
    App.NIS2.Report.start_collecting(incident)
  end

  # Raport generuje się z danych, które system
  # już zbiera (Telemetry, audit log, logi)
  def generate_72h_report(incident) do
    %{
      incident_id: incident.id,
      detected_at: incident.detected_at,
      scope: App.NIS2.Report.assess_scope(incident),
      affected_users: App.NIS2.Report.count_affected(incident),
      actions_taken: App.NIS2.Report.list_actions(incident),
      # Dane z audit_log i telemetry - już istnieją
      timeline: App.NIS2.Report.build_timeline(incident)
    }
  end
end

W systemie bez wbudowanego monitoringu: Tomek w panice przegląda logi, próbuje odtworzyć przebieg incydentu z fragmentarycznych danych, pisze raport w Wordzie. 24 godziny? Tomek potrzebuje 24 godzin, żeby znaleźć logi.

Kiedy nasz stack NIE rozwiązuje NIS2

Bądźmy uczciwi. Elixir/Phoenix/BEAM/PostgreSQL daje Ci solidne fundamenty techniczne. Ale NIS2 to nie tylko technologia:

• Dokumentacja - musisz mieć spisane polityki, procedury, analizę ryzyka. Framework tego za Ciebie nie napisze.
• Szkolenia - pracownicy muszą wiedzieć, czym jest phishing i jak zgłaszać incydenty. To nie jest kwestia kodu.
• Testy penetracyjne - musisz je zlecać regularnie. Żaden framework nie zastąpi pentestera.
• Prawnik - potrzebujesz kogoś, kto zna NIS2 od strony prawnej i pomoże Ci z politykami.
• Proces - kto jest odpowiedzialny za raportowanie? Kto kontaktuje CSIRT? Kto informuje zarząd? To wymaga procedur, nie kodu.

Technologia to 50% gotowości do NIS2. Drugie 50% to procesy, ludzie i dokumentacja. Ale to pierwsze 50% to fundament - jeśli Twój system nie potrafi wykryć incydentu automatycznie, najlepsza procedura na papierze jest bezwartościowa.

Checklist techniczny NIS2

Odpowiedz na te pytania dla swojego systemu:

Ciągłość działania

• Czy system działa, gdy jeden komponent ulegnie awarii?
• Czy potrafisz zdefiniować RTO i RPO?
• Czy backup jest automatyczny, zaszyfrowany i regularnie testowany?
• Czy potrafisz przywrócić system z backupu w określonym czasie?

Wykrywanie i raportowanie incydentów

• Czy system wykrywa anomalie automatycznie (nie "Tomek sprawdza logi")?
• Czy masz alerty na podejrzane zdarzenia (brute force, nietypowy ruch)?
• Czy potrafisz wygenerować raport incydentu w 24h?
• Czy logi pozwalają odtworzyć chronologię incydentu?

Bezpieczeństwo danych

• Czy połączenia z bazą są szyfrowane (SSL/TLS)?
• Czy hasła są hashowane (Argon2/bcrypt)?
• Czy masz MFA dla kont administracyjnych?
• Czy masz Row-Level Security lub równoważną kontrolę dostępu?

Łańcuch dostaw

• Czy wiesz, ile zależności (bibliotek) ma Twój projekt?
• Czy regularnie sprawdzasz je pod kątem znanych podatności?
• Czy lockfile zawiera hashe kryptograficzne pakietów?
• Czy Twój software house/dostawca jest audytowany?

Jeśli masz więcej niż 4 odpowiedzi "nie" - Twoja infrastruktura nie spełnia wymagań NIS2 i narażasz firmę na kary do 10 mln EUR.

NIS2 nie zniknie. Kary będą egzekwowane. Zarząd odpowiada osobiście. A wybór stosu technologicznego, który ma monitoring, izolację awarii i bezpieczeństwo wbudowane od pierwszego dnia - to nie jest decyzja techniczna. To decyzja o compliance.

Porozmawiajmy - zrobimy gap analysis Twojego systemu pod kątem NIS2 i pokażemy, ile wymagań Twój obecny stack spełnia, a ile wymaga przebudowy.