Tu apel z pytaniami do ekspertów:
https://informacje-lokalne.pl/apel-do-ekspertow-cyberbezpieczenstwa-i-architektury-systemow-informatycznych-w-sprawie-ksef-2026-02-18/
Odpowiedź na Pytanie 1: Czy WAF widzi te dane?
Tak, potwierdzam bez zastrzeżeń metodologicznych. Twoje obserwacje techniczne są poprawne i odtwarzalne. Wynikają z fundamentalnej właściwości architektury reverse-proxy WAF z terminacją TLS.
Mechanizm jest następujący: gdy klient (np. program księgowy) nawiązuje połączenie HTTPS z
api.ksef.mf.gov.pl, sesja TLS nie kończy się na serwerze MF — kończy się na infrastrukturze Impervy. Imperva odszyfrowuje ruch, analizuje go jako plaintext HTTP, a dopiero potem może (opcjonalnie, w zależności od konfiguracji) nawiązać nowe, osobne połączenie TLS do backendu MF. To wzorzec zwany
TLS termination lub
SSL inspection — jest to standardowy, intencjonalny i udokumentowany sposób działania każdego cloud WAF, w tym Impervy. Nagłówki
X-CDN: Imperva oraz cookies
visid_incap_* i
incap_ses_* w odpowiedziach KSeF jednoznacznie to potwierdzają.
Skoro API KSeF 2.0 zwraca metadane faktur (NIP sprzedawcy i nabywcy, nazwy podmiotów, kwoty netto/VAT/brutto, walutę, numer faktury, daty, typ dokumentu) w formacie JSON bez dodatkowego szyfrowania aplikacyjnego, to operator warstwy WAF — czyli Imperva — ma
pełny, techniczny dostęp do tych danych w postaci plaintext. Nie jest to luka bezpieczeństwa. To jest celowa architektura, z której wynikają określone konsekwencje.
Odpowiedź na Pytanie 2: Czy to ma znaczenie architektoniczne i ryzyko systemowe?
Tak, i to znaczące. Ryzyko jest realne, wielopoziomowe i ma konkretne implikacje prawne.
Poziom 1 — ryzyko operatora (Insider Threat / Third-party Risk)
Imperva jako podmiot komercyjny (USA, obecnie należący do Thales Group) ma techniczną możliwość logowania, analizowania i utrwalania każdego bajtu przechodzącego przez jej infrastrukturę. Nie jest to spekulacja — Imperva sama przyznała, że w 2019 roku doszło do wycieku danych klientów Cloud WAF, w tym kluczy TLS i API. Incydent ten pokazuje, że
nawet infrastruktura dostawcy WAF może być skompromitowana, a wtedy atakujący uzyskuje dostęp do wszystkich danych, które operator widział w plaintext.
Polska gospodarka generuje przez KSeF potencjalnie dziesiątki milionów faktur rocznie. Metadane tych transakcji — NIP kontrahentów, kwoty, częstotliwość — tworzą w agregacie
pełny obraz przepływów gospodarczych kraju, bardziej wartościowy wywiadowczo niż treść samych faktur XML.
Poziom 2 — ryzyko systemowe (Supply Chain / Intelligence Risk)
Z perspektywy architektury systemów państwowych, powierzenie terminacji TLS podmiotowi zewnętrznemu dla infrastruktury krytycznej klasy KSeF jest
decyzją o bardzo wysokim ryzyku systemowym. Analogia: to tak, jakby wszystkie rozmowy telefoniczne obywateli przechodziły przez prywatną centralę telefoniczną o nieznanej polityce logowania, działającą na mocy umowy, której treść nie jest publicznie znana.
Kluczowe jest to, co sam słusznie zauważyłeś:
Ministerstwo Finansów nie publikuje umowy z Impervą, a w szczególności:
-
- zakresu logowanych danych,
-
- jurysdykcji, pod którą podlegają te dane,
-
- mechanizmów audytu dostępu pracowników Impervy do ruchu KSeF.
Poziom 3 — ryzyko prawne (GDPR / Tajemnica Handlowa)
NIP i powiązane dane transakcyjne przedsiębiorców to dane osobowe w rozumieniu RODO (dot. JDG/osób fizycznych) oraz dane stanowiące tajemnicę handlową w rozumieniu dyrektywy UE 2016/943. Ich przetwarzanie przez podmiot trzeci wymaga:
-
- podstawy prawnej (art. 6 lub 28 RODO — umowa powierzenia),
-
- transparentności wobec podmiotów, których dane dotyczą.
Fakt, że MF nie informuje oficjalnie o roli Impervy jako operatora WAF dla KSeF, może oznaczać naruszenie zasady
przejrzystości RODO, niezależnie od tego, czy Imperva faktycznie loguje dane czy nie.
Ocena metodologii audytu
Twoja metodologia jest
poprawna i powtarzalna. Komendy
curl z analizą nagłówków HTTP to standardowe narzędzie weryfikacji architektury sieciowej. Analiza schematu OpenAPI (
InvoiceMetadata) to właściwy sposób identyfikacji pól zwracanych przez API. Błędu metodologicznego nie stwierdzam.
Jedyna granica, której nie da się przekroczyć bez uprawnień: nie wiadomo, co Imperva
faktycznie robi z danymi, które
może zobaczyć. Twój audyt wykazuje możliwość, nie pewność logowania. To jednak nie zmniejsza wagi problemu —
ryzyko architektoniczne istnieje niezależnie od tego, czy operator z niego korzysta.
Rekomendacje architektoniczne
Dla systemu klasy KSeF właściwą architekturą byłoby jedno z poniższych rozwiązań:
-
- WAF on-premise lub sovereign cloud w jurysdykcji polskiej/unijnej, z pełną kontrolą MF nad kluczami TLS i polityką logowania,
-
- Szyfrowanie aplikacyjne pól wrażliwych (field-level encryption) przed wysłaniem do warstwy pośredniczącej, tak aby WAF widział jedynie zaszyfrowane tokeny zamiast plaintext danych biznesowych,
-
- Publiczne ujawnienie umowy z Impervą lub zastąpienie jej podmiotem z pełną transparentnością, audytowalnym SLA i lokowaniem danych wyłącznie w UE.
Precedens istnieje: Cloudflare publikuje szczegółowe warunki przetwarzania danych i przeszło certyfikację ISO 27001 / SOC 2 Type II z pełnym zakresem logowania. Taki standard przejrzystości powinien być
wymogiem minimalnym dla infrastruktury państwowej tej rangi.
Podsumowując: Twoje dwa pytania mają odpowiedź twierdzącą. Architektura jest technicznie poprawna jako WAF, ale nieodpowiednia dla systemu o takiej wrażliwości danych bez publicznej transparentności co do polityki operatora. To nie jest problem Impervy — to problem decyzji architektonicznej MF.
Przygotowano przy użyciu Claude Sonnet 4.6
