Audyt Techniczny KSeF – Raport Pełny

Architektura brzegowa, terminacja TLS i suwerenność danych w systemie Krajowego Systemu e-Faktur

---

Streszczenie wykonawcze

Niniejszy audyt techniczny weryfikuje architekturę bezpieczeństwa polskiego systemu KSeF (Krajowy System e-Faktur) w zakresie routingu sieciowego, terminacji połączeń szyfrowanych oraz szyfrowania end-to-end danych. Wszystkie testy są powtarzalne i mogą być zweryfikowane przez każdą osobę posiadającą podstawową wiedzę techniczną. Główne ustalenia:

• • Ruch do KSeF przechodzi przez zagraniczną infrastrukturę Imperva (Thales Group)

• • Połączenia TLS są terminowane (odszyfrowywane) przez Imperva przed przekazaniem do serwerów MF

• • Imperva ma techniczną zdolność wglądu w metadane wszystkich faktur wystawianych w Polsce, co ma bardzo duże znaczenie wywiadowcze.

---

Część I: Routing i delegacja domeny

Test 1.1: Weryfikacja delegacji DNS (rekord CNAME)

Cel: Sprawdzenie, czy ruch do ksef.mf.gov.pl trafia bezpośrednio do infrastruktury Ministerstwa Finansów. Metoda:

Resolve-DnsName ksef.mf.gov.pl -Type CNAME

Wynik:

Name                           Type   TTL   Section    NameHost
----                           ----   ---   -------    --------
ksef.mf.gov.pl                 CNAME  300   Answer     nudnsjz.ng.impervadns.net

Analiza:

• • Domena ksef.mf.gov.pl jest aliasem CNAME do nudnsjz.ng.impervadns.net

• • Domena impervadns.net należy do firmy Imperva (obecnie część koncernu Thales)

• • Ministerstwo Finansów oddelegowało zarządzanie ruchem HTTP/HTTPS do infrastruktury Imperva

Wniosek 1.1: Ruch sieciowy do KSeF jest kierowany do infrastruktury zagranicznej przed dotarciem do serwerów rządowych.

---

Test 1.2: Ustalenie rzeczywistego adresu IP (rekord A)

Cel: Identyfikacja fizycznego punktu styku z systemem KSeF. Metoda:

Resolve-DnsName ksef.mf.gov.pl -Type A

Wynik:

Name                           Type   TTL   Section    IPAddress
----                           ----   ---   -------    ---------
nudnsjz.ng.impervadns.net      A      30    Answer     45.60.74.103

Analiza:

• • Adres IP 45.60.74.103 należy do puli adresowej Imperva

• • Lokalizacja geograficzna: sieć Imperva (USA/Europa)

• • Adres nie należy do polskiej sieci rządowej ani dostawców IT MF

Wniosek 1.2: Punkt wejścia do systemu KSeF znajduje się w infrastrukturze zarządzanej przez zagraniczny podmiot.

---

Test 1.3: Detekcja warstwy WAF (fingerprinting HTTP)

Cel: Potwierdzenie obecności aktywnej warstwy Web Application Firewall przetwarzającej ruch aplikacyjny. Metoda:

curl.exe -vkI https://ksef.mf.gov.pl/

Wynik (istotne nagłówki):

< HTTP/1.1 200 OK
< X-CDN: Imperva
< Server: BigIP
< Set-Cookie: visid_incap_2934032=...;
< Set-Cookie: incap_ses_1234_2934032=...;

Analiza:

• • X-CDN: Imperva – bezpośrednie potwierdzenie obecności Imperva jako warstwy CDN/WAF

• • incap_* cookies – charakterystyczne dla systemu Incapsula (marka Impervy)

• • Server: BigIP – load balancer F5 znajduje się za warstwą Imperva (nie przed nią)

Wniosek 1.3: Każde żądanie HTTP do KSeF jest przetwarzane aplikacyjnie przez Imperva WAF przed przekazaniem do infrastruktury MF.

---

Część II: Terminacja TLS i odszyfrowanie ruchu

Test 2.1: Dowód terminacji TLS przez test różnicowy

Cel: Wykazanie, że Imperva odszyfruje połączenia TLS i ma dostęp do zawartości żądań HTTP. Kontekst techniczny: W protokole HTTPS nagłówek Host: jest przesyłany wewnątrz zaszyfrowanego tunelu TLS. Serwer może podjąć decyzję routingową na podstawie tego nagłówka tylko wtedy, gdy wcześniej odszyfrował połączenie. Metoda A – Żądanie domeny głównej:

curl.exe -vkI -H "Host: ksef.mf.gov.pl" https://45.60.74.103/

Wynik A:

< HTTP/1.1 200 OK
< X-CDN: Imperva

Metoda B – Żądanie nieistniejącej subdomeny:

curl.exe -vkI -H "Host: api.ksef.mf.gov.pl" https://45.60.74.103/

Wynik B:

< HTTP/1.1 404 Not Found
< X-CDN: Imperva

Interpretacja:

1. 1. Oba żądania trafiają na ten sam adres IP (45.60.74.103)

1. 1. Oba żądania są identyczne na poziomie TCP/IP (ten sam IP docelowy, port 443)

1. 1. Różnią się wyłącznie nagłówkiem Host:, który znajduje się wewnątrz zaszyfrowanego tunelu TLS

1. 1. Serwer zwrócił różne odpowiedzi (200 vs 404), co oznacza że musiał przeczytać nagłówek Host:

1. 1. Aby przeczytać nagłówek Host:, serwer musiał najpierw odszyfrować połączenie TLS

Wniosek 2.1: Imperva terminuje (odszyfrowuje) połączenia TLS i ma pełny dostęp do zawartości żądań HTTP.

---

Test 2.2: Weryfikacja certyfikatu TLS

Cel: Ustalenie, kto wystawił certyfikat TLS i kto zarządza kluczem prywatnym. Metoda:

$request = [System.Net.HttpWebRequest]::Create("https://ksef.mf.gov.pl")
$request.AllowAutoRedirect = $false
$request.Timeout = 10000
$response = $request.GetResponse()
$cert = $request.ServicePoint.Certificate
$cert2 = New-Object System.Security.Cryptography.X509Certificates.X509Certificate2($cert)

Wynik:

Subject: CN=*.ksef.mf.gov.pl, O=MINISTERSTWO FINANSÓW, L=Warszawa, C=PL
Issuer: CN=GeoTrust TLS RSA CA G1, OU=www.digicert.com, O=DigiCert Inc, C=US
Thumbprint: 6AF8575E9149E4B62C04027912951BFF43A75DEE
Serial Number: 0F5862885DD1E7E769405CD16AE6480D
Not Before: 12/08/2025 01:00:00
Not After: 12/08/2026 00:59:59
Signature Algorithm: sha256RSA

Subject Alternative Names:
  Nazwa DNS=*.ksef.mf.gov.pl
  Nazwa DNS=ksef.mf.gov.pl

Analiza:

• • Certyfikat wystawiony dla Ministerstwa Finansów (pole Subject)

• • Wystawca: DigiCert Inc (amerykańska CA)

• • Certyfikat typu wildcard (*.ksef.mf.gov.pl)

Uwaga: Obecność certyfikatu wystawionego dla MF nie oznacza, że klucz prywatny znajduje się w serwerowni MF. W architekturze z WAF/CDN to Imperva używa certyfikatu MF (klucz prywatny dostarczony przez MF) do terminacji połączeń klient-WAF. Wniosek 2.2: Certyfikat jest legalny i wystawiony dla MF, ale klucz prywatny musi znajdować się na serwerach Imperva, aby możliwa była terminacja TLS (wykazana w Teście 2.1).

---

Test 2.3: Analiza nagłówków odpowiedzi HTTP

Cel: Potwierdzenie przetwarzania żądań przez WAF i identyfikacja architektury backendowej. Metoda:

Invoke-WebRequest -Uri "https://ksef.mf.gov.pl/api/online/Session/Status" -Method GET -UseBasicParsing

Wynik (nagłówki odpowiedzi):

X-CDN: Imperva
Server: BigIP
X-Iinfo: 11-71233930-71233935 NNNY CT(3 10 0) RT(1770400518836 37) q(0 0 0 -1) r(0 0) U12
Set-Cookie: visid_incap_3145187=...; Domain=.mf.gov.pl; Secure; SameSite=None
Set-Cookie: incap_ses_520_3145187=...; Domain=.mf.gov.pl; Secure; SameSite=None

Analiza:

• • X-CDN: Imperva – jawne potwierdzenie przetwarzania przez Imperva

• • X-Iinfo – nagłówek diagnostyczny Impervy zawierający metadane przetwarzania

• • Server: BigIP – load balancer F5 znajduje się za Impervą (nie przed nią)

• • incap_* cookies – tracking/session management przez Imperva

Architektura faktyczna:

[Klient] --TLS--> [Imperva WAF] --TLS?--> [BigIP F5] --> [Serwery KSeF MF]
                      ↑
                 terminacja TLS

Wniosek 2.3: Imperva jest pierwszą warstwą odbierającą ruch HTTPS i przetwarza każde żądanie zanim trafi ono do infrastruktury MF.

---

Część III. Dodatkowe testy sieciowe

Test 3.1: Routing DNS/IP

Metoda: $env = @(„ksef.mf.gov.pl”,”api-test.ksef.mf.gov.pl”,”api-demo.ksef.mf.gov.pl”) Resolve-DnsName $env -Type CNAME,A | Select NameHost, IPAddress Wynik: ksef.mf.gov.pl → CNAME: nudnsjz.ng.impervadns.net | IP: 45.60.74.103 api-test → fdk3rx6.ng.impervadns.net | IP: 45.60.74.103 api-demo → 4sgun8h.ng.impervadns.net | IP: 45.60.74.103 Geolokacja: Imperva Inc., USA VA Ashburn (AS19551) [web:55] Analiza: Potwierdzenie audytu v1 – wszystkie env przez Impervę (USA edge). Brak polskich IP.​

---

Test 3.2: Terminacja TLS / Host Routing

Metoda: [TrustAllCertsPolicy włączone] Invoke-WebRequest https://45.60.74.103/ -H @{Host=”ksef.mf.gov.pl”} Invoke-WebRequest https://45.60.74.103/ -H @{Host=”api-test.ksef.mf.gov.pl”} Wynik: Host=ksef: 200 OK | Headers: HSTS, text/html Host=api-test: 302 | Headers: X-Iinfo, no-cache Analiza: Różne resp mimo ident IP/TLS → Imperva terminuje TLS, routuje po Host/SNI.

---

Test 3.3: WAF Imperva – Ślady Sesji

Metoda: Invoke-WebRequest https://api-test.ksef.mf.gov.pl/ -H @{User-Agent=”Mozilla/5.0″} Wynik: 200 OK (docs HTML) X-Iinfo: 12-84941297-84939131 SNNN RT(1770412161869 37138) q(0 0 0 -1) r(0 0) U12 [web:46] /api/session → 404 | /api/info → 403 Analiza: WAF loguje timing/sesje; blokuje API. Metadane (IP/UA) u Thales.​

---

Test 3.4: Mock Faktura – Payload Visibility

Komenda: POST https://api-test.ksef.mf.gov.pl/api/invoices/inbound Body: <Invoice xmlns=”urn:ksef.mf.gov.pl:2024:01:FA(2)”><Header><Version>2</Version></Header></Invoice> Content-Type: application/xml Wynik: 404 NotFound X-Iinfo: 12-84941297-84939131 PNNN RT(1770412161869 112260) q(0 0 0 0) r(0 0) U6 Analiza: Jawny XML zalogowany/odrzucony przez WAF. W realu AES-256 chroni, ale bez auth – ryzyko.​ Wniosek

• • E2E API 2.0: AES-256 + RSA (nieczytelny blob), ale metadane/logi Imperva.​

---

Część IV. Analiza szyfrowania aplikacyjnego (API 2.0)

4.1. Deklaracje w dokumentacji

Zgodnie z oficjalną dokumentacją API 2.0:

• • Obowiązkowe szyfrowanie AES-256-CBC dla wszystkich faktur

• • Klucz symetryczny AES szyfrowany algorytmem RSAES-OAEP (SHA-256/MGF1)

• • Token uwierzytelniający szyfrowany kluczem publicznym KSeF

---

4.2. Potwierdzenia od integratorów

Przegląd forów technicznych wykazał:

• • ✅ Najczęstsze błędy: „Błąd odszyfrowania pliku”, problemy z paddingiem AES

• • ✅ Wymuszanie szyfrowania – brak przypadków akceptacji plaintext XML

• • ✅ Oficjalne biblioteki (.NET, Java) implementują szyfrowanie lokalne​

---

4.3. Czego NIE zweryfikowano

❌ Brak empirycznego potwierdzenia przechwycenia zaszyfrowanego ruchu (wymaga konta testowego) ❌ Brak weryfikacji czy Imperva posiada klucze prywatne MF ❌ Brak możliwości testowania backdoorów lub wyjątków od szyfrowania

---

Część V. Analiza architektoniczna – kluczowy problem

5.1. Dylemat bezpieczeństwa w systemach masowych

W systemach typu Business-to-Government obsługujących miliony użytkowników, WAF na brzegu sieci musi inspekcjonować ruch w celu:

1. 1. Ochrony przed atakami XML:
      • • XML Bomb (Billion Laughs)
      • • XXE (XML External Entity)
      • • XPath Injection
      • • XSLT Injection

1. 1. Walidacji struktury dokumentów:
      • • Zgodność ze schematem XSD
      • • Limity rozmiaru i złożoności
      • • Rate limiting na podstawie zawartości

1. 1. Wykrywania anomalii:
      • • Nietypowe wzorce danych
      • • Próby obejścia walidacji
      • • Ataki DoS na poziomie aplikacji

---

5.2. Niemożność inspekcji zaszyfrowanego payloadu

Jeśli faktury są zaszyfrowane end-to-end (klient → backend MF), WAF Imperva: ❌ Nie widzi struktury XML – nie może wykryć ataków XML Bomb ❌ Nie może walidować schematu – przepuszcza nieprawidłowe dokumenty ❌ Nie może limitować na podstawie zawartości faktury ❌ Jest „ślepy” na ataki aplikacyjne

---

5.3. Konsekwencje dla backendu MF

Przy milionach faktur dziennie, serwery MF musiałyby:

1. 1. Deszyfrować każdą fakturę (AES-256-CBC – operacja CPU-intensive)

1. 1. Parsować XML i walidować zgodność ze schematem

1. 1. Wykonywać walidację biznesową

To gigantyczne obciążenie obliczeniowe, które:

• • Zwiększa koszty infrastruktury o rząd wielkości

• • Wydłuża czas odpowiedzi API

• • Czyni system podatnym na ataki DoS (wysyłanie złośliwych zaszyfrowanych dokumentów)

---

5.4. Precedensy w innych systemach B2G

Systemy porównawcze:

System	Szyfrowanie payloadu	Metoda zabezpieczenia
ePUAP (PL)	❌ Nie	TLS + podpis kwalifikowany
JPK (PL)	❌ Nie	TLS + podpis
e-Deklaracje (PL)	❌ Nie	TLS + podpis
PEPPOL (EU)	⚠️ Opcjonalne	TLS + AS4 protocol
KSeF API 1.0 (PL)	❌ Nie	TLS + podpis XML
KSeF API 2.0 (PL)	✅ Deklarowane	TLS + AES-256 + podpis

KSeF 2.0 jest jedynym systemem w Polsce deklarującym obowiązkowe szyfrowanie dokumentów na poziomie aplikacji.

---

Część VI. Hipoteza: Imperva posiada klucze prywatne MF

6.1. Logika architektoniczna

Aby system był funkcjonalny i bezpieczny, musi zachodzić następujący scenariusz:

[Klient]
  ↓ Generuje klucz AES-256
  ↓ Szyfruje fakturę XML
  ↓ Szyfruje klucz AES kluczem publicznym MF (RSA)
  ↓ Pakuje do HTTPS

[Imperva WAF]
  ↓ Deszyfruje TLS (✅ UDOWODNIONE)
  ↓ Ekstrahuje encryptedSymmetricKey
  ↓ Deszyfruje klucz AES używając KLUCZA PRYWATNEGO MF (❓ HIPOTEZA)
  ↓ Deszyfruje fakturę XML
  ↓ INSPEKCJA: walidacja XSD, wykrywanie ataków, rate limiting
  ↓ Ponownie szyfruje (opcjonalnie) dla backendu
  ↓ Routing do BigIP

[Backend MF]
  ↓ Otrzymuje zwalidowaną fakturę (plaintext lub ponownie zaszyfrowana)
  ↓ Walidacja biznesowa i zapis

---

6.2. Dlaczego ta hipoteza jest jedyną spójną

Scenariusz A: Imperva NIE ma kluczy

• • ❌ WAF nie może inspekcjonować ruchu

• • ❌ System narażony na ataki XML Bomb, XXE

• • ❌ Backend MF przeciążony deszyfrowaniem milionów faktur

• • ❌ Architektura nie ma sensu bezpieczeństwowego

Scenariusz B: Imperva MA klucze prywatne MF

• • ✅ WAF może inspekcjonować i walidować faktury

• • ✅ Ataki są blokowane na brzegu

• • ✅ Backend MF otrzymuje zwalidowane dane

• • ✅ Architektura jest spójna

Scenariusz C: Szyfrowanie E2E jest iluzją

• • ⚠️ Faktury w rzeczywistości wysyłane jako plaintext XML

• • ⚠️ „Szyfrowanie” tylko w dokumentacji dla pozorów

• • ⚠️ Wymagałoby zmowy lub niekompetencji po stronie MF

---

6.3. Implikacje posiadania kluczy przez Imperva

Jeśli Imperva posiada klucze prywatne Ministerstwa Finansów:

1. 1. Pełny dostęp do treści faktur – mimo „szyfrowania E2E”

1. 1. Możliwość odczytu danych podatkowych wszystkich polskich przedsiębiorców

1. 1. Jurysdykcja USA – CLOUD Act daje FBI dostęp do danych

1. 1. Naruszenie suwerenności cyfrowej – kluczowa infrastruktura państwa kontrolowana zagranicznie

1. 1. Potencjalne naruszenie RODO – brak kontroli nad danymi osobowymi

---

Podsumowanie wyników audytu

Test	Przedmiot badania	Wynik	Status
1.1	Delegacja DNS	CNAME → impervadns.net	⚠️ Ruch przez Imperva
1.2	Adres IP	45.60.74.103 (pula Imperva)	⚠️ IP zagraniczny
1.3	Fingerprinting WAF	Nagłówek X-CDN: Imperva	⚠️ WAF potwierdzony
2.1	Terminacja TLS	Test różnicowy pozytywny	🔴 Imperva odszyfrowuje
2.2	Certyfikat	Wystawiony dla MF	⚠️ Klucz u Impervy
2.3	Architektura	Imperva → BigIP → MF	🔴 Imperva jest pierwsza
3.1	Routing DNS/IP	Geolokacja: Imperva Inc.	⚠️ Imperva
3.2	Terminacja TLS	Imperva terminuje TLS	🔴 Metadane widoczne
3.3	Ślady Sesji	Metadane (IP/UA) u Thales	🔴 Metadane u Thales
3.4	Payload Visibility	Jawny XML	🔴 AES-256 chroni

Wnioski końcowe

1. Potwierdzone fakty techniczne

✅ Ruch do KSeF przechodzi przez Imperva

• • Dowód: CNAME DNS, adres IP, nagłówek X-CDN

✅ Imperva terminuje (odszyfrowuje) połączenia TLS

• • Dowód: Test różnicowy z nagłówkiem Host: (Test 2.1)

---

3. Implikacje prawne i suwerenności

Jurysdykcja

🔴 USA (CLOUD Act 2018)

• • Imperva należy do Thales Group (francuska spółka-matka)

• • Thales posiada znaczące operacje w USA

• • CLOUD Act umożliwia organom USA żądanie danych od firm amerykańskich i ich zagranicznych oddziałów

🔴 Francja

• • Thales to francuski koncern zbrojeniowy

• • Podlega francuskiemu prawu i nadzorowi państwowemu

• • Potencjalny dostęp służb wywiadowczych Francji

🟡 Mechanizmy ochrony (teoretyczne)

• • Comity analysis (analiza kolizji jurysdykcji)

• • Data Protection Addendum (DPA)

• • Problem: Historycznie mało skuteczne wobec CLOUD Act

RODO

⚠️ Potencjalne naruszenie RODO

• • Transfer danych do państw spoza UE wymaga odpowiednich zabezpieczeń (Art. 44-50 RODO)

• • USA nie mają decyzji o adekwatności po unieważnieniu Privacy Shield

• • Pytanie: Czy terminacja TLS w USA = transfer poza UE?

Art. 46 wymaga odpowiednich zabezpieczeń, np. Standard Contractual Clauses. Problem: Ministerstwo Finansów nie ujawniło:

• • Czy istnieje umowa DPA (Data Processing Agreement) z Imperva

• • Jakie są podstawy prawne przekazywania danych do USA

• • Czy przeprowadzono DPIA (Data Protection Impact Assessment)

---

4. Porównanie: Deklaracje MF vs. Rzeczywistość techniczna

Aspekt	Deklaracja MF	Rzeczywistość techniczna
Szyfrowanie danych	✅ „Dane są szyfrowane”	⚠️ Szyfrowanie terminowane przez Imperva
Bezpieczeństwo	✅ „System jest bezpieczny”	⚠️ Nie jest bezpieczny przed Impervą
Transparentność	❓ Brak oświadczenia	❌ Brak publicznej umowy z Imperva/Thales
Suwerenność	❓ Brak oświadczenia	🔴 Terminacja TLS poza Polską

---

5. Różnica: Zdolność techniczna vs. Faktyczny dostęp

Należy rozróżnić:

Kwestia	Status
Czy Imperva widzi metadane?	✅ Tak – to daje praktyczną wiedzę dającą dużą przewagę konkurencyjną na rynku.
Czy Imperva może odczytać treść faktury?	❓ Nieznane – jeśli nie może, to system bardzo traci na bezpieczeństwie.
Czy Imperva odczytuje faktury?	❓ Nieznane – wymaga dostępu do umowy SLA/DPA
Czy Imperva przechowuje faktury?	❓ Nieznane – zależne od konfiguracji
Czy służby USA/FR mają dostęp?	❓ Nieznane – prawnie możliwe (CLOUD Act)
Czy służby USA/FR korzystały z dostępu?	❓ Nieznane – brak publicznych danych

Wniosek interpretacyjny: Audyt wykazuje zdolność techniczną, nie faktyczne wykorzystanie. To różnica między:

• • „Imperva może zobaczyć każdą fakturę”

• • „Imperva patrzy i zapisuje każdą fakturę”

---

6. Rekomendacje techniczne

Dla pełnego bezpieczeństwa system KSeF powinien:

1. 1. ✅ Terminacja TLS w polskiej infrastrukturze
      • • Implementacja: Własny WAF (NASK, CERT.PL, polski dostawca)
      • • Efekt: Klucze prywatne TLS nigdy nie opuszczają Polski

1. 1. ✅ Transparentność umów
      • • Publikacja: Pełna umowa SLA/DPA
      • • Zawartość: Polityka logowania, retencji, dostęp służb

1. 1. ✅ Audyt zewnętrzny
      • • Przeprowadzenie: niezależny audyt bezpieczeństwa
      • • Zakres: weryfikacja faktycznego logowania i dostępu

Obecny stan:

• • ❌ Żaden z powyższych warunków nie jest spełniony

• • ⚠️ Architektura nie chroni przed wglądem warstwy WAF

• • 🔴 Pełna zależność od zagranicznego dostawcy w kluczowym systemie fiskalnym

---

Odpowiedzi na kluczowe pytania

Czy faktury w KSeF są bezpieczne?

Odpowiedź techniczna: Faktury są chronione przed:

• • ✅ Przechwyceniem przez osoby trzecie w tranzycie (szyfrowanie TLS)

• • ✅ Modyfikacją przez atakujących (podpis cyfrowy XML)

• • ✅ Atakami sieciowymi typu DDoS (WAF Imperva)

Faktury NIE są chronione przed:

• • ❌ Wglądem przez operatora WAF (Imperva/Thales)

• • ❌ Potencjalnym dostępem służb wywiadowczych USA/Francji (CLOUD Act)

• • ❌ Logowaniem metadanych przez warstwę CDN (IP, timing, rozmiary)

• • ❌ Utratą poufności w przypadku nacisku prawnego/politycznego na Thales

Odpowiedź prawna: Wykracza poza zakres audytu technicznego. Wymaga analizy:

• • Umowy SLA/DPA między MF a Thales/Imperva (niedostępne publicznie)

• • Zgodności z RODO (czy terminacja TLS = transfer danych poza UE?)

• • Oceny ryzyka w kontekście CLOUD Act i służb wywiadowczych

Odpowiedź polityczna: Decyzja o użyciu zagranicznej (amerykańsko-francuskiej) infrastruktury do obsługi krytycznego systemu fiskalnego zawierającego dane wszystkich polskich przedsiębiorców jest:

• • Decyzją polityczną (nie techniczną)

• • Decyzją o zależności strategicznej

• • Decyzją o granicach suwerenności cyfrowej

Suwerenność cyfrowa: Kontrola kluczy kryptograficznych przez zagraniczną firmę oznacza:

• • Brak faktycznej kontroli nad danymi podatkowymi polskich firm

• • Zależność strategiczna – Imperva może wyłączyć system

• • Ryzyko szpiegostwa gospodarczego – dostęp do wszystkich transakcji B2B w Polsce

---

Czy można to zmienić?

Tak, istnieją alternatywy:

1. 1. Krótkoterminowo (6-12 miesięcy):
      • • Zmiana dostawcy WAF na polskiego/europejskiego (np. Akamai EU, Cloudflare w trybie BYOK)

1. 1. Średnioterminowo (12-24 miesiące):
      • • Budowa własnej infrastruktury WAF (NASK, CERT.PL)
      • • Pełna terminacja TLS w Polsce

1. 1. Długoterminowo (24+ miesięcy):
      • • Strategia suwerenności cyfrowej dla systemów krytycznych
      • • Certyfikacja bezpieczeństwa (Common Criteria EAL4+)

Koszt: Szacunkowo 5-20 mln PLN (zależnie od rozwiązania). To promil budżetu KSeF.

---

Podsumowanie

Potwierdzone fakty (hard evidence)

1. 1. ✅ Cały ruch KSeF routowany przez Imperva – DNS CNAME, IP 45.60.74.103

1. 1. ✅ Imperva terminuje TLS – test różnicowy z nagłówkiem Host

1. 1. ✅ Imperva ma pełny dostęp do metadanych – adresy IP, timing, rozmiary pakietów, wzorce użytkowania

1. 1. ✅ API 2.0 deklaruje szyfrowanie E2E – dokumentacja i biblioteki klienckie

1. 1. ✅ Integratorzy potwierdzają wymuszanie szyfrowania – brak akceptacji plaintext XML

Logiczne wnioski (architectural analysis)

6. 6. ⚠️ System WAF nie może być „ślepy” – wymaga inspekcji dla bezpieczeństwa

6. 6. ⚠️ Backend MF nie może obsłużyć deszyfrowania milionów faktur – zbyt duże obciążenie

6. 6. ⚠️ Aby architektura miała sens, Imperva musi mieć klucze prywatne MF

6. 6. ⚠️ „Szyfrowanie E2E” chroni przed MITM, ale nie przed Imperva

Niewiadome (unverified)

❓ Czy Imperva faktycznie posiada klucze prywatne MF? ❓ Czy istnieje backdoor/wyjątek od szyfrowania? ❓ Jakie są podstawy prawne tej architektury? ❓ Czy przeprowadzono ocenę ryzyka (DPIA)?

Weryfikowalność

Każdy może powtórzyć te testy. Wymagane narzędzia (bezpłatne):

• • PowerShell (Windows)

• • curl (Windows/Linux/Mac)

• • nslookup lub Resolve-DnsName

Wszystkie polecenia podane w audycie są powtarzalne i weryfikowalne.

---

Data audytu: 6 lutego 2026 Metodologia: Black-box testing, OSINT, analiza publicznych zasobów Zakres: Architektura bezpieczeństwa bez ingerencji w system produkcyjny Narzędzia: PowerShell, curl, DNS lookup, analiza nagłówków HTTP Autor: Audyt obywatelski weryfikowalny przez każdego

---

Niniejszy audyt nie narusza żadnych przepisów prawa. Przy jego przeprowadzaniu nie wykorzystano żadnego zwierzęcia. Wszystkie testy wykorzystują publicznie dostępne zasoby i standardowe narzędzia diagnostyczne. Nie przeprowadzono żadnych prób penetracji systemu ani ataków na infrastrukturę KSeF.

Grzegorz GPS Świderski Kanał Blogera GPS GPS i Przyjaciele X.GPS65