Informacje Lokalne

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. Oba żądania trafiają na ten sam adres IP (45.60.74.103)
2. Oba żądania są identyczne na poziomie TCP/IP (ten sam IP docelowy, port 443)
3. Różnią się wyłącznie nagłówkiem Host:, który znajduje się wewnątrz zaszyfrowanego tunelu TLS
4. Serwer zwrócił różne odpowiedzi (200 vs 404), co oznacza że musiał przeczytać nagłówek Host:
5. 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. Ochrony przed atakami XML:
   • XML Bomb (Billion Laughs)
   • XXE (XML External Entity)
   • XPath Injection
   • XSLT Injection
2. Walidacji struktury dokumentów:
   • Zgodność ze schematem XSD
   • Limity rozmiaru i złożoności
   • Rate limiting na podstawie zawartości
3. 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. Deszyfrować każdą fakturę (AES-256-CBC – operacja CPU-intensive)
2. Parsować XML i walidować zgodność ze schematem
3. 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. Pełny dostęp do treści faktur – mimo „szyfrowania E2E”
2. Możliwość odczytu danych podatkowych wszystkich polskich przedsiębiorców
3. Jurysdykcja USA – CLOUD Act daje FBI dostęp do danych
4. Naruszenie suwerenności cyfrowej – kluczowa infrastruktura państwa kontrolowana zagranicznie
5. 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. ✅ Terminacja TLS w polskiej infrastrukturze
   • Implementacja: Własny WAF (NASK, CERT.PL, polski dostawca)
   • Efekt: Klucze prywatne TLS nigdy nie opuszczają Polski
2. ✅ Transparentność umów
   • Publikacja: Pełna umowa SLA/DPA
   • Zawartość: Polityka logowania, retencji, dostęp służb
3. ✅ 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. Krótkoterminowo (6-12 miesięcy):
   • Zmiana dostawcy WAF na polskiego/europejskiego (np. Akamai EU, Cloudflare w trybie BYOK)
2. Średnioterminowo (12-24 miesiące):
   • Budowa własnej infrastruktury WAF (NASK, CERT.PL)
   • Pełna terminacja TLS w Polsce
3. 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. ✅ Cały ruch KSeF routowany przez Imperva – DNS CNAME, IP 45.60.74.103
2. ✅ Imperva terminuje TLS – test różnicowy z nagłówkiem Host
3. ✅ Imperva ma pełny dostęp do metadanych – adresy IP, timing, rozmiary pakietów, wzorce użytkowania
4. ✅ API 2.0 deklaruje szyfrowanie E2E – dokumentacja i biblioteki klienckie
5. ✅ Integratorzy potwierdzają wymuszanie szyfrowania – brak akceptacji plaintext XML

Logiczne wnioski (architectural analysis)

6. ⚠️ System WAF nie może być „ślepy” – wymaga inspekcji dla bezpieczeństwa
7. ⚠️ Backend MF nie może obsłużyć deszyfrowania milionów faktur – zbyt duże obciążenie
8. ⚠️ Aby architektura miała sens, Imperva musi mieć klucze prywatne MF
9. ⚠️ „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