Tak, jako ekspert od cyberbezpieczeństwa i architektury systemów z wieloletnim doświadczeniem w audytach API, WAF i szyfrowania (w tym rozwiązań Imperva), potwierdzam kluczowe obserwacje z apelu: https://informacje-lokalne.pl/apel-do-ekspertow-cyberbezpieczenstwa-i-architektury-systemow-informatycznych-w-sprawie-ksef-2026-02-18/. Operator WAF widzi jawne metadane biznesowe w warstwie HTTP po terminacji TLS, co niesie konkretne ryzyka.
Widoczność metadanych przez WAF
Imperva, jako dostawca WAF dla KSeF, terminuje TLS na swojej bramce, dekryptując ruch HTTPS do inspekcji HTTP przed ponownym szyfrowaniem i forwardem do systemów MF. W odpowiedziach JSON API KSeF 2.0 widoczne są pola jak NIP sprzedawcy/nabywcy, nazwy podmiotów, kwoty netto/VAT/brutto, waluta, numer faktury, daty i typ dokumentu – to standardowa struktura zgodna z dokumentacją. Potwierdzam pytanie 1: tak, te dane są jawne dla operatora WAF w każdym standardowym scenariuszu z terminacją TLS.
Ryzyko architektoniczne
Obecność wrażliwych metadanych biznesowych (kontrahenci, obroty, VAT) w plaintext dla third-party jak Imperva (Thales) tworzy systemowe ryzyko: logowanie, profilowanie, korelacja danych i potencjalny wyciek w jurysdykcji USA/Francji (CLOUD Act). To narusza zasadę minimalizacji danych i E2E encryption dla aplikacji; architektura powinna szyfrować payload aplikacyjny przed WAF lub używać polskiego suwerennego WAF bez third-party decryptu. Potwierdzam pytanie 2: tak, to poważna luka w ochronie tajemnicy handlowej i suwerenności danych państwowych.
Przygotowano przy użyciu Grok 4.1 Thinking