Bezpieczeństwo i architektura

Stack jawnie, nie „zaufaj nam”

To samo, co pokazalibyśmy audytorowi Twojego klienta - zero czarnej skrzynki. Poniżej rozróżniamy wprost, co jest gotowe dziś, a co dopiero planujemy.

To nie jest certyfikat ani raport z audytu

SZBIhub nie posiada dziś certyfikacji ISO/IEC 27001, atestacji SOC 2 ani zewnętrznego testu penetracyjnego - i nie twierdzimy inaczej. Ta strona to opis architektury, jaką faktycznie budujemy, punkt po punkcie, z jawnym oznaczeniem elementów planowanych („docelowo”) wobec tych już działających. Sprzeczność z tym, co produkt faktycznie robi, zgłoś na kontakt@szbihub.pl.

Dwa różne systemy poniżej

Ta strona publiczna (szbihub.pl, ten serwis) jest w 100% statyczna - bez backendu, bazy danych czy formularzy zapisujących dane bezpośrednio tutaj. Platforma SZBIhub to osobny produkt (repozytorium app-nis2) - tam żyją rejestry, dokumenty i dane organizacji partnerów. Sekcje niżej opisują oba systemy osobno, żeby nigdy ich nie mylić.

Ta strona publiczna

szbihub.pl - dziś, jako fakt

Ten serwis (Astro, statyczny build, Cloudflare Pages) nie ma nic do złamania - nie ma serwera aplikacyjnego ani bazy danych.

  • Zero backendu, zero PII

    Strona jest w 100% statyczna (Astro, build-time) - żadnego serwera aplikacyjnego, bazy ani przechowywania danych po stronie tego serwisu. Jedyne formularze na stronie to kalkulatory liczące wyłącznie w przeglądarce; zapis na kurs e-mailowy to zwykły odnośnik e-mail, a zgłoszenie konta NFR to odnośnik do formularza w osobnej aplikacji app.szbihub.pl - żadne dane nie trafiają na infrastrukturę tej strony.
  • Wymuszone HTTPS + nagłówki bezpieczeństwa

    Hosting (Cloudflare Pages) serwuje wyłącznie po HTTPS. Skonfigurowane nagłówki odpowiedzi (public/_headers w tym repozytorium): HSTS, ścisła Content-Security-Policy (script-src 'self', bez 'unsafe-inline') na wszystkich stronach marketingowych, narzędziowych i prawnych, X-Frame-Options: DENY, X-Content-Type-Options: nosniff, ograniczona Permissions-Policy. Jedyny wyjątek to dokumentacja pod /docs/*, gdzie generator (Starlight) wymaga kilku własnych skryptów inline oraz własnych atrybutów style= (tam, i wyłącznie tam, script-src i style-src dopuszczają 'unsafe-inline') - ta ścieżka jest w 100% statyczna, a pozostałe dyrektywy (object-src 'none', base-uri 'self', form-action 'self', frame-ancestors 'none') obowiązują tam bez zmian.
  • Zero cookies, zero trackerów

    Dziś nie zbieramy żadnych statystyk odwiedzin - stąd brak bannera zgody na cookies (pełny opis: /cookies). W przyszłości możemy uruchomić samohostowaną, cookieless analitykę (Plausible, UE) bez profilowania użytkowników; zanim to nastąpi, zaktualizujemy politykę cookies. Żadnych pikseli reklamowych ani trackerów stron trzecich.
  • Kalkulatory 100% po stronie przeglądarki

    Kalkulator kwalifikacji i generator terminów (/narzedzia) liczą wyłącznie w przeglądarce - wpisane dane nigdzie nie są wysyłane.

Platforma SZBIhub

Architektura produktu - co działa, co jest planowane

Platforma to osobny produkt (repozytorium app-nis2) - poniżej stan faktyczny, nie zapowiedź marketingowa.

  • Stack

    .NET 10, PostgreSQL, hosting docelowo w UE (VPS OVHcloud, Warszawa - zatwierdzony D-R2-10) - żadnego podprocesora danych Twoich klientów spoza Europy.
  • Uwierzytelnianie i dostęp

    Rejestracja wyłącznie przez zaproszenie (token, TTL), polityka haseł min. 12 znaków, blokada konta po 5 nieudanych próbach logowania. Uwierzytelnianie dwuskładnikowe (TOTP) z kodami odzyskiwania, wymuszone dla ról administracyjnych (PlatformAdmin, PartnerAdmin).
  • Izolacja tenantów

    Partner -> organizacja klienta to twarda granica danych. Dziś: globalne filtry zapytań na każdej encji przypisanej do organizacji/partnera + blokada zapisu poza właściwym zakresem (próba zapisu z cudzym identyfikatorem organizacji jest odrzucana), pokryte kanonicznym zestawem testów izolacji. Docelowo (F4): dodatkowo Postgres Row-Level Security jako druga, niezależna warstwa ochrony (defense-in-depth).
  • Audit log append-only

    Rejestr zdarzeń (logowania, eksporty, impersonacje, zatwierdzenia dokumentów) zapisywany w trybie append-only na poziomie aplikacji - każdy wpis niesie aktora, ewentualnego impersonatora, partnera, organizację i identyfikator korelacji. Docelowo (F4) wzmacniany dodatkowo triggerem bazodanowym blokującym UPDATE/DELETE na wpisach.
  • Szyfrowanie

    Ta strona publiczna: HTTPS wymuszony już dziś (patrz wyżej). Platforma: instancja podapp.szbihub.pl odpowiada po HTTPS - pomiar z 11 sierpnia 2026 dał HTTP 200 na/healthz, a TLS na sprawdzonej subdomenie najemcy działa (reverse proxy z certyfikatem wildcard). Ten pomiar objął dostępność po HTTPS i certyfikat jednej subdomeny; nie objął szyfrowania danych w spoczynku - stanu at-rest nie deklarujemy tu dziś. Osobno zmierzone szyfrowanie kopii zapasowych opisujemy niżej.
  • Backupy i procedura restore

    Kopie bazy danych wykonujemy od 17 lipca 2026: szyfrowane po naszej stronie (AES-256-CBC z PBKDF2 i solą) przed wysłaniem do Scaleway Object Storage we Francji, po HTTPS. Pomiar kosza z 12 sierpnia 2026: 27 kopii dziennych za okres 17.07-12.08.2026 - po jednej na każdy dzień tego okresu, bez przerw - oraz 2 kopie miesięczne; zadanie startuje codziennie o 02:00 UTC. Obiekty mają blokadę Object Lock w trybie GOVERNANCE (35 dni). Granica: GOVERNANCE to nie COMPLIANCE - kto ma uprawnienie do pominięcia blokady, może obiekt usunąć przed terminem, i tak to tu nazywamy. Retencja 30 dziennych + 12 miesięcznych jest skonfigurowana, ale nie zaobserwowana: cykl przycinania nie usunął dotąd żadnej kopii (najstarsza miała w dniu pomiaru 26 dni). Element planowany (F4) - nie deklarujemy wykonanego restore'u na produkcji ani działającego alarmu przy braku kopii; alarm nie istnieje operacyjnie.
  • Eksport bez lock-in

    Już dziś: każdy rejestr (aktywa, ryzyka, incydenty, dostawcy) eksportujesz do CSV lub PDF z poziomu platformy. Docelowo (F4): pełny eksport wszystkich danych organizacji jednym kliknięciem (komplet dokumentów, rejestrów i terminów w jednym archiwum) - funkcja planowana, jeszcze niedostępna. Zero lock-in to zasada projektowa, nie tylko slogan.

Dostawcy

Subprocesorzy

Kto ma dostęp do jakich danych, w jakim celu i gdzie - jawnie, z lokalizacją.

PodmiotKategoriaCel przetwarzaniaLokalizacjaDane przetwarzane
OVHcloud (OVH Groupe SAS)hostingHosting aplikacji oraz bazy danych Platformy.UE - Polska (Warszawa)Wszystkie dane powierzone.
Scaleway TEM (Scaleway SAS)emailWysyłka e-mail transakcyjnych.UE - Francja (brak transferów poza UE)Adres e-mail, imię/nazwisko odbiorcy, treść powiadomienia.
Scaleway Object Storage (Scaleway SAS)backupPrzechowywanie kopii zapasowych danych Platformy.Francja - UEZaszyfrowane kopie zapasowe bazy danych Platformy.
Cloudflare, Inc.networkObsługa DNS oraz infrastruktury publicznej strony internetowej.Sieć krawędziowa Cloudflare. Pomiar 2026-08-16: przez proxy CF przechodzi wyłącznie publiczna strona szbihub.pl; ruch aplikacji app.szbihub.pl trafia bezpośrednio na VPS OVHcloud (poz. 1), z pominięciem Cloudflare.Publiczna strona statyczna nie zawiera danych powierzonych; Cloudflare obsługuje zapytania DNS strefy i metadane ruchu do tej strony. Ruch aplikacji app.szbihub.pl nie przechodzi przez proxy CF (pomiar 2026-08-16), więc dane powierzone nie trafiają do tego podprocesora.

Ta sama lista - jako Załącznik B umowy powierzenia (art. 28 ust. 2 RODO) - jest publikowana na stronie /dpa.

Poza listą podprocesorów

Te podmioty i to oprogramowanie nie są podprocesorami danych powierzonych - w brzmieniu źródła DPA (kwalifikację potwierdza radca przed publikacją produkcyjną):

  • Paddle.com Market Limited (Londyn)

    Merchant of Record; przetwarza dane rozliczeniowe kupującego jako ODRĘBNY ADMINISTRATOR (paddle.com/privacy); nie przetwarza danych Organizacji.

  • Plausible (self-host)

    Planowane narzędzie analityki odwiedzin strony publicznej - cookieless, zbiorcze statystyki bez profilowania. Na dzień tej wersji NIE działa: dziś nie zbieramy żadnych statystyk odwiedzin. Może zostać uruchomione wyłącznie jako oprogramowanie self-host na własnej infrastrukturze Usługodawcy (na VPS z poz. 1) - wtedy nie będzie odrębnym podmiotem przetwarzającym; przed uruchomieniem zaktualizujemy Politykę prywatności i Politykę cookies.

  • GlitchTip (self-host)

    Planowane narzędzie monitoringu błędów aplikacji. Na dzień tej wersji NIE działa. Może zostać uruchomione wyłącznie jako oprogramowanie self-host na własnej infrastrukturze Usługodawcy (na VPS z poz. 1) - wtedy nie będzie odrębnym podmiotem przetwarzającym; założenie projektowe dla error-trackingu: bez danych osobowych w zdarzeniach.

Zgłaszanie luk

Zgłaszanie podatności

Znalazłeś lukę bezpieczeństwa? Chcemy o niej wiedzieć.

security.txt (RFC 9116)

Maszynowo czytelny plik pod adresem /.well-known/security.txt - kontakt, data wygaśnięcia i odnośnik do tej strony jako polityki. Bez opublikowanego klucza PGP (nie mamy dziś procesu zarządzania kluczem - nie udajemy inaczej).

Kontakt

Zgłoszenia przyjmujemy na kontakt@szbihub.pl. Dziś czyta je i odpowiada na nie osobiście założyciel (nie mamy jeszcze formalnego dyżuru ani programu bug bounty z wynagrodzeniem) - potwierdzamy odbiór i informujemy o dalszych krokach.

Historia

Changelog bezpieczeństwa

Wpisy dotyczące bezpieczeństwa i architektury - najnowsze pierwsze.

  • Strona /security opublikowana

    11 lipca 2026

    Architektura bezpieczeństwa platformy (izolacja tenantów, audit log, MFA, backupy, eksport danych) opisana wprost - co działa dziś, a co jest planowane na etap F4. Lista subprocesorów, security.txt (RFC 9116) i proces zgłaszania podatności.

Pełny changelog produktu (wszystkie kategorie): /changelog.