Odpowiedź eksperta cyberbezpieczeństwa Perplexity Pro Sonar

Odpowiedź na apel: https://informacje-lokalne.pl/apel-do-ekspertow-cyberbezpieczenstwa-i-architektury-systemow-informatycznych-w-sprawie-ksef-2026-02-18/ Krótko: przy obecnej, udokumentowanej architekturze KSeF Imperva jako WAF technicznie widzi te metadane biznesowe w odpowiedziach JSON, o których piszesz. Tak – z punktu widzenia cyberbezpieczeństwa, tajemnicy handlowej i suwerenności cyfrowej jest to istotny problem architektoniczny i realne ryzyko systemowe. Poniżej odpowiedź „jak do ekspertów”, wprost do Twoich dwóch pytań.

Ad. pytanie 1 – czy WAF widzi te dane?

Teza: tak, operator bramki WAF (Imperva) ma techniczną możliwość wglądu w pełen JSON z metadanymi faktur (NIP, nazwy, kwoty, waluta, numery, daty, typ dokumentu), bo to właśnie na tej warstwie następuje terminacja TLS i inspekcja treści HTTP. Najważniejsze przesłanki techniczne z dostępnych audytów i analiz:

• • Analiza DNS i ruchu pokazuje, że hosty KSeF (api.ksef.mf.gov.pl itd.) wskazują na CNAME w domenie Impervy (*.ng.impervadns.net) oraz IP należące do tej infrastruktury, a odpowiedzi zawierają nagłówki typowe dla Impervy (X-CDN, X-Iinfo).

• • Audyt uzupełniający wykazał, że wzorce w payloadzie (np. ciągi kojarzone z JNDI/XXE) są blokowane kodem 403 niezależnie od tego, czy ścieżka endpointu istnieje, co oznacza analizę treści przed routingiem do backendu – czyli w warstwie CDN/WAF.​

• • Ten sam audyt pokazał, że blokada 403 pojawia się także wtedy, gdy złośliwy wzorzec umieszczony jest dopiero po ok. 200 kB danych, co oznacza głęboką inspekcję całego body HTTP w warstwie Impervy, a więc dostęp do plaintextu po zakończeniu TLS.​

• • W analizach opisujących „Część VIII. Co jeszcze widzi Imperva?” wprost wskazano, że odpowiedzi API KSeF zwracają rozszerzony JSON z metadanymi faktur (NIP sprzedawcy i nabywcy, nazwy podmiotów, kwoty netto/VAT/brutto, waluta, numer faktury, daty operacyjne, typ faktury) oraz że dane te są zwracane wprost w JSON poza szyfrowanym blobem XML.

• • Z tego samego źródła wynika, że ponieważ Imperva terminuje TLS i widzi pełne odpowiedzi HTTP, te metadane są technicznie jawne dla warstwy WAF/reverse proxy.

Z drugiej strony, oficjalne komunikaty MF koncentrują się na tym, że systemy WAF „nie mają dostępu do treści faktur”, ponieważ nie dysponują kluczami do odszyfrowania aplikacyjnie szyfrowanego XML (E2E) i „widzą wyłącznie zaszyfrowane dane”. To sformułowanie odnosi się do treści faktury w XML – i jest spójne z tezą, że Imperva nie czyta pozycji towarowych czy numerów kont, ale nie zaprzecza wprost temu, że widzi nagłówki HTTP i JSON‑owe metadane faktur w plaintext. Wniosek do pytania 1: Na podstawie niezależnych audytów black‑box oraz spójnych obserwacji publikowanych w raportach i artykułach technicznych można technicznie potwierdzić, że warstwa WAF/CDN (Imperva) widzi odszyfrowany ruch HTTP i ma dostęp do metadanych faktur zwracanych w JSON, w szczególności: NIP sprzedawcy i nabywcy, nazwy podmiotów, kwoty netto/VAT/brutto, waluta, numer faktury, daty operacyjne oraz typ dokumentu. To, czy i jak te dane są logowane/przetwarzane po stronie operatora, jest już kwestią organizacyjno‑prawną – ale z punktu widzenia czystej techniki możliwość wglądu istnieje.

Ad. pytanie 2 – czy to ma znaczenie architektoniczne i czy jest to ryzyko systemowe?

Teza: tak, z punktu widzenia cyberbezpieczeństwa, tajemnicy handlowej i suwerenności cyfrowej jest to istotny błąd architektoniczny i bardzo poważne ryzyko systemowe, nawet jeśli treść faktur (XML) pozostaje dla Impervy zaszyfrowana. Kluczowe aspekty:

1. 1. Charakter danych – to nie „zwykłe logi” tylko mapa gospodarki
      • • JSON‑owe metadane, o których mowa (NIP–NIP, nazwy, kwoty, daty, typ dokumentu) pozwalają zrekonstruować sieć powiązań gospodarczych, kierunki przepływu pieniędzy, koncentrację obrotów w branżach, relacje dostawca–odbiorca, kondycję płynnościową firm czy zmiany struktury łańcuchów dostaw.
      • • Publiczne analizy wprost opisują taki zestaw jako potencjalne narzędzie wywiadu gospodarczego, o strategicznej wartości informacyjnej, nawet bez znajomości pozycji faktury.

1. 1. Pozycja operatora WAF jako „brzegu państwa”
      • • Audyty wskazują, że z czysto technicznego punktu widzenia „brzeg komunikacji systemu podatkowego Polski” znajduje się na infrastrukturze Impervy – ruch KSeF wchodzi najpierw do jej CDN/WAF, gdzie jest odszyfrowywany i analizowany, a dopiero potem przekazywany do systemów MF.
      • • To oznacza, że newralgiczny ruch podatkowy kraju jest w warstwie aplikacyjnej terminowany poza bezpośrednią, pełną kontrolą państwa, co zostało jednoznacznie wskazane w tezach audytu jako niespełniające standardów suwerenności cyfrowej.​

1. 1. Ryzyko wywiadowcze i presji regulacyjnej obcych państw
      • • Imperva należy do dużej, zagranicznej grupy kapitałowej; komentatorzy zwracają uwagę, że metadane polskich faktur mogą być z technicznego punktu widzenia dostępne dla wywiadu państw, w których te podmioty podlegają jurysdykcji (USA, Francja, potencjalnie inne w zależności od łańcucha własności/usług).
      • • Media wskazują dodatkowo na brak przejrzystości co do tego, gdzie fizycznie przetwarzane są te dane/metadane (czy nie opuszczają UE), co rodzi pytania o zgodność z RODO i ochronę przed żądaniami dostępu na podstawie obcego prawa.​

1. 1. Ryzyko „insider” i kompromitacji dostawcy
      • • Nawet jeśli przyjmiemy, że polityki Impervy zabraniają logowania/podglądu tych danych, operatorzy systemu WAF mają techniczną możliwość wprowadzenia reguł lub sond, które takie metadane rejestrują, agregują lub eksportują.
      • • Analizy bezpieczeństwa WAF podkreślają także ryzyko kompromitacji dostawcy (supply‑chain / cloud provider compromise) – atak na Impervę dawałby napastnikowi punkt obserwacyjny nad całym ruchem do KSeF, w tym nad metadanymi faktur.

1. 1. Rozbieżność między komunikatem politycznym a stanem technicznym
      • • Oficjalne komunikaty MF i materiały quasi‑eksperckie próbują sprowadzić problem do pytania: „czy Imperva widzi treść faktur?”, by następnie odpowiedzieć: „nie widzi, więc wszystko jest bezpieczne, a krytyka to dezinformacja”.
      • • Tymczasem niezależne audyty pokazują, że sednem problemu nie jest XML‑owa treść faktury, lecz globalny zbiór jej metadanych widocznych z perspektywy WAF-a, co pozostaje w istotnej sprzeczności z narracją „widzą tylko zaszyfrowany szum”.

1. 1. Koncentracja ryzyka i single point of failure
      • • Już sama centralizacja całego obrotu fakturowego w jednym państwowym systemie jest koncentracją ryzyka – dodanie do tego zewnętrznego operatora na brzegu systemu tworzy dodatkowy, newralgiczny punkt awarii lub kompromitacji.
      • • Publiczne komentarze branżowe zwracają uwagę, że KSeF ma obsługiwać nawet dziesiątki milionów faktur na godzinę i nie może być single point of failure; sytuacja, w której ten „punkt” w praktyce leży w cudzej chmurze bezpieczeństwa, jest trudna do obrony z perspektywy inżynierii systemów krytycznych.

Wniosek do pytania 2: Tak – obecność pełnych metadanych biznesowych faktur w jawnej warstwie komunikacyjnej widocznej dla zewnętrznego operatora WAF jest problemem architektonicznie fundamentalnym i generuje poważne ryzyko systemowe w obszarze wywiadu gospodarczego, suwerenności cyfrowej, RODO oraz odporności państwa na presję i ataki poprzez łańcuch dostaw. Nie jest to „drobny szczegół implementacyjny”, lecz konsekwencja świadomej decyzji, by brzeg systemu podatkowego ulokować w infrastrukturze zagranicznego dostawcy posiadającego techniczną zdolność profilowania całego ruchu KSeF.

---

Gdyby formułować to w jednym zdaniu, w stylu odpowiedzi eksperta dla opinii publicznej:

• • Tak, Imperva jako WAF widzi metadane, o które pytasz – tak wynika z empirycznych testów i analizy API KSeF; i tak, z punktu widzenia bezpieczeństwa państwa i tajemnicy handlowej jest to poważny błąd architektoniczny oraz realne ryzyko systemowe, niezależne od tego, czy treść XML faktur pozostaje dodatkowo zaszyfrowana.

Przygotowane przez Deep Research