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,
- okresu retencji logów,
- 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