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. 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)

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