Jako ekspert ds. cyberbezpieczeństwa i architektury systemów, odpowiadam na pytania postawione w apelu: https://informacje-lokalne.pl/apel-do-ekspertow-cyberbezpieczenstwa-i-architektury-systemow-informatycznych-w-sprawie-ksef-2026-02-18/, opierając się na przedstawionych w nim założeniach technicznych oraz ogólnych zasadach działania systemów WAF (Web Application Firewall) i protokołów komunikacyjnych.
Jeśli opisana w audycie architektura jest zgodna ze stanem faktycznym – to znaczy: ruch jest terminowany na bramce WAF (Imperva), a w warstwie aplikacji (wewnątrz JSON) nie zastosowano dodatkowego szyfrowania danych biznesowych (tzw. Field Level Encryption lub Application Layer Encryption) – odpowiedzi na Pana pytania są jednoznaczne.
Odpowiedź na Pytanie 1:
Czy operator bramki WAF widzi jawne, niezaszyfrowane metadane (NIP, kwoty, daty, numer faktury)?
Tak. Jest to techniczna konieczność wynikająca z modelu działania WAF w trybie termination (terminacji ruchu SSL/TLS).
Aby system klasy WAF (taki jak Imperva) mógł realizować swoje zadania – czyli analizować ruch pod kątem ataków (np. SQL Injection, XSS) czy anomalii w protokole – musi on odszyfrować ruch HTTPS przychodzący od klienta. W momencie, gdy WAF „zagląda” do środka pakietu, widzi jego pełną zawartość (payload).
Jeżeli projektanci KSeF nie zaimplementowali szyfrowania samej treści danych (np. szyfrowania wartości pól w JSON kluczem publicznym odbiorcy przed wysłaniem), to dla operatora WAF te dane są widoczne w postaci czystego tekstu (cleartext). Operator WAF posiada klucze prywatne niezbędne do zestawienia sesji TLS, a więc z definicji posiada techniczną możliwość wglądu w dane przesyłane wewnątrz tego tunelu.
Odpowiedź na Pytanie 2:
Czy obecność opisanych danych biznesowych w jawnej warstwie komunikacyjnej, widocznych dla operatora infrastruktury pośredniczącej, ma znaczenie architektoniczne i generuje ryzyko systemowe?
Tak, jest to ryzyko o charakterze krytycznym.
- Naruszenie zasady Zero Trust: W architekturze o tak wysokim znaczeniu państwowym (centralny rejestr wszystkich faktur w gospodarce) opieranie bezpieczeństwa danych na zaufaniu do dostawcy zewnętrznego (third-party vendor) jest błędem architektonicznym. Dostawca WAF staje się „zaufanym pośrednikiem” (Trusted Man-in-the-Middle), co w przypadku danych o strategicznym znaczeniu dla ekonomii państwa jest nieakceptowalne.
- Ryzyko wywiadu gospodarczego (Metadata Analysis): Nawet jeśli operator nie przechowuje treści samych faktur (np. nazw towarów), to zestaw metadanych, który Pan wymienił (kto, z kim, kiedy, za ile, jaki typ dokumentu), jest wystarczający do odtworzenia pełnego grafu powiązań gospodarczych w kraju.
- Analiza wolumenu i częstotliwości transakcji pozwala na profilowanie kondycji firm, przewidywanie bankructw, fuzji czy identyfikowanie kluczowych łańcuchów dostaw.
- Dostęp do takich danych przez podmiot zagraniczny (Imperva jest firmą amerykańską) rodzi pytania o suwerenność cyfrową.
- Brak kontroli nad logami: Operatorzy WAF często logują fragmenty zapytań i odpowiedzi w celach diagnostycznych (tzw. request/response sampling). Bez ścisłej kontroli kryptograficznej (szyfrowania danych w warstwie aplikacji), nie ma technicznej gwarancji, że wrażliwe dane biznesowe nie odkładają się w logach operatora chmury, które mogą być przechowywane w innej jurysdykcji.
Podsumowanie eksperckie
Opisany stan rzeczy wskazuje na to, że w architekturze KSeF priorytetem była łatwość integracji i standardowa ochrona przed atakami sieciowymi, a nie poufność danych przed infrastrukturą pośredniczącą.
W systemach o tak krytycznym znaczeniu, standardem powinno być szyfrowanie warstwy aplikacji (E2E), gdzie WAF widzi jedynie nagłówki techniczne i zaszyfrowany blob danych, lub zastosowanie rozwiązań Private Cloud / On-Premise pod pełną kontrolą państwa. Pozostawienie danych biznesowych jawnymi dla operatora WAF to otwarta furtka do masowej analizy danych gospodarczych Polski przez podmiot trzeci.
Przygotowano przy użyciu Gemini 3 Pro