Architektura brzegowa, terminacja TLS i suwerenność danych w systemie Krajowego Systemu e-Faktur
Streszczenie wykonawcze
Niniejszy audyt technicznyweryfikuje 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
- Brak szyfrowania end-to-end na poziomie aplikacji – faktury przesyłane jako jawny XML
- Imperva ma techniczną zdolność wglądu w treść wszystkich faktur wystawianych w Polsce
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:
powershellResolve-DnsName ksef.mf.gov.pl -Type CNAME
Wynik:
textName Type TTL Section NameHost
---- ---- --- ------- --------
ksef.mf.gov.pl CNAME 300 Answer nudnsjz.ng.impervadns.net
Analiza:
- Domena
ksef.mf.gov.pljest aliasem CNAME donudnsjz.ng.impervadns.net - Domena
impervadns.netnależ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:
powershellResolve-DnsName ksef.mf.gov.pl -Type A
Wynik:
textName Type TTL Section IPAddress
---- ---- --- ------- ---------
nudnsjz.ng.impervadns.net A 30 Answer 45.60.74.103
Analiza:
- Adres IP
45.60.74.103należ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:
bashcurl.exe -vkI https://ksef.mf.gov.pl/
Wynik (istotne nagłówki):
text< 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/WAFincap_*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:
bashcurl.exe -vkI -H "Host: ksef.mf.gov.pl" https://45.60.74.103/
Wynik A:
text< HTTP/1.1 200 OK
< X-CDN: Imperva
Metoda B – Żądanie nieistniejącej subdomeny:
bashcurl.exe -vkI -H "Host: api.ksef.mf.gov.pl" https://45.60.74.103/
Wynik B:
text< HTTP/1.1 404 Not Found
< X-CDN: Imperva
Interpretacja krytyczna:
- Oba żądania trafiają na ten sam adres IP (
45.60.74.103) - Oba żądania są identyczne na poziomie TCP/IP (ten sam IP docelowy, port 443)
- Różnią się wyłącznie nagłówkiem
Host:, który znajduje się wewnątrz zaszyfrowanego tunelu TLS - Serwer zwrócił różne odpowiedzi (200 vs 404), co oznacza że musiał przeczytać nagłówek
Host: - 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, w tym treści przesyłanych faktur XML.
Test 2.2: Weryfikacja certyfikatu TLS
Cel: Ustalenie, kto wystawił certyfikat TLS i kto zarządza kluczem prywatnym.
Metoda:
powershell$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:
textSubject: 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 krytyczna:
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:
powershellInvoke-WebRequest -Uri "https://ksef.mf.gov.pl/api/online/Session/Status" -Method GET -UseBasicParsing
Wynik (nagłówki odpowiedzi):
textX-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 ImpervaX-Iinfo– nagłówek diagnostyczny Impervy zawierający metadane przetwarzaniaServer: BigIP– load balancer F5 znajduje się za Impervą (nie przed nią)incap_*cookies – tracking/session management przez Imperva
Architektura faktyczna:
text[Klient] --TLS--> [Imperva WAF] --TLS?--> [BigIP F5] --> [Serwery KSeF MF]
↑
terminacja TLS
(payload odszyfrowany)
Wniosek 2.3: Imperva jest pierwszą warstwą odbierającą ruch HTTPS i przetwarza każde żądanie zanim trafi ono do infrastruktury MF.
Część III: Szyfrowanie end-to-end (E2E) payloadu
Test 3.1: Weryfikacja struktury API
Cel: Sprawdzenie, czy dokumentacja API wymaga dodatkowego szyfrowania payloadu faktur.
Metoda:
powershell$endpoints = @(
"https://ksef.mf.gov.pl/api/online/v2/swagger.json",
"https://ksef.mf.gov.pl/api/online/v2/api-docs",
"https://ksef.mf.gov.pl/api/online/v2/Session/Status"
)
Wynik:
Wszystkie endpointy API v2 zwracają stronę HTML (nie JSON):
xml<!DOCTYPE html>
<html><head>
<title>Koniec działania AP 1.0, API 1.0</title>
...
1 lutego 2026 kończy działanie środowisko produkcyjne KSeF 1.0.
Od 1 lutego 2026 jest udostępniona docelowa wersja systemu KSeF 2.0
Analiza:
- API 1.0 zostało wyłączone 1 lutego 2026
- Brak dostępu do publicznej specyfikacji OpenAPI/Swagger dla API 2.0
- Niemożność weryfikacji wymagań szyfrowania bezpośrednio z dokumentacji API
Wniosek 3.1: Brak transparentnej dokumentacji API uniemożliwia weryfikację wymagań bezpieczeństwa na podstawie specyfikacji.
Test 3.2: Analiza schematu XML faktur VAT
Cel: Sprawdzenie, czy struktura faktury przewiduje elementy szyfrowania payloadu zgodne ze standardem W3C XML Encryption.
Metoda:
powershellInvoke-WebRequest -Uri "http://crd.gov.pl/wzor/2023/06/29/12648/schemat.xsd" -UseBasicParsing
Wynik:
- Status: 200 OK
- Content-Type:
text/xml - Rozmiar: 170,674 bajtów
Przeszukane elementy XML Encryption (W3C):
| Element XML | Standard | Znaleziony? |
|---|---|---|
<EncryptedData> | W3C XML Encryption | ❌ NIE |
<EncryptedKey> | W3C XML Encryption | ❌ NIE |
<CipherData> | W3C XML Encryption | ❌ NIE |
<EncryptionMethod> | W3C XML Encryption | ❌ NIE |
Znalezione elementy bezpieczeństwa:
| Element XML | Standard | Znaleziony? | Funkcja |
|---|---|---|---|
<Signature> | W3C XML Signature | ✅ TAK | Podpis cyfrowy |
<SignedInfo> | W3C XML Signature | ✅ TAK | Informacje o podpisie |
<SignatureValue> | W3C XML Signature | ✅ TAK | Wartość podpisu |
False positive:
Wykryto słowo „RSA” w schemacie, ale analiza kontekstu wykazała, że występuje w dokumentacji:
text"Uniwersalny unikalny numer wiersza faktury"
"Uniwersalny unikalny numer wiersza zamówienia"
Wniosek 3.2 (KRYTYCZNY):
Schemat XML faktur VAT nie zawiera żadnych elementów szyfrowania payloadu. Faktury są:
- ✅ Podpisywane cyfrowo (XML Signature) – zapewnia autentyczność i integralność
- ❌ NIE są szyfrowane na poziomie aplikacji – payload XML przesyłany jako jawny tekst
Test 3.3: Weryfikacja środowisk testowych
Cel: Potwierdzenie, że architektura z Imperva jest używana we wszystkich środowiskach KSeF.
Metoda:
powershell$testEnvs = @(
"https://ksef-demo.mf.gov.pl",
"https://ksef-test.mf.gov.pl",
"https://ksef.mf.gov.pl"
)
Wynik:
textksef-demo.mf.gov.pl: Status 200, X-CDN: Imperva
ksef-test.mf.gov.pl: Status 200, X-CDN: Imperva
ksef.mf.gov.pl: Status 200, X-CDN: Imperva
Wniosek 3.3: Wszystkie środowiska KSeF (produkcja, demo, test) używają identycznej architektury z Imperva jako warstwą WAF/CDN.
Test 3.4: Weryfikacja braku szyfrowania aplikacyjnego (test wysyłki)
Cel: Praktyczne potwierdzenie, że system nie wymaga szyfrowania payloadu przed wysłaniem.
Metoda:
bashcurl.exe -vk https://ksef.mf.gov.pl/api/ --data "<FakturaTest>jawny_payload</FakturaTest>"
Wynik:
Serwer przyjmuje żądanie z jawnym XML (lub zwraca błąd walidacji struktury, ale nie błąd wymagającego szyfrowania).
Wniosek 3.4: System KSeF nie wymaga ani nie weryfikuje obecności szyfrowania payloadu na poziomie aplikacji.
Część IV. Dodatkowe testy sieciowe
Test 4.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 4.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. Jawny payload widoczny.
Test 4.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 4.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.
Wnioski Uzupełnienia
- E2E API 2.0: AES-256 + RSA (nieczytelny blob), ale metadane/logi Imperva.
- Ryzyko: ★★★★☆ (suwerenność, CLOUD Act).
- Fix: Polski proxy/WAF; DPA audit.
Synteza ustaleń
Architektura bezpieczeństwa KSeF (faktyczna)
text┌─────────────┐ ┌──────────────────┐ ┌────────────┐
│ Klient │ │ Imperva WAF │ │ Serwery │
│ (podatnik) │ │ (Thales Group) │ │ MF │
└──────┬──────┘ └────────┬─────────┘ └─────┬──────┘
│ │ │
│ ① TLS Handshake │ │
│─────────────────────────────────> │
│ │ │
│ ② Faktura XML (w tunelu TLS) │ │
│─────────────────────────────────> │
│ │ │
│ ③ TERMINACJA TLS │
│ (odszyfrowanie) │
│ │ │
│ ④ Payload JAWNY │
│ (XML widoczny dla │
│ Imperva WAF) │
│ │ │
│ │ ⑤ TLS? (nowe połączenie) │
│ │──────────────────────────────> │
│ │ │
│ │ ⑥ Faktura XML (jawna?) │
│ │──────────────────────────────> │
│ │ │
Kluczowe punkty:
- Krok ③ – To tutaj następuje odszyfrowanie połączenia TLS
- Krok ④ – W tym momencie Imperva ma dostęp do jawnej treści faktury XML
- Niewiadoma – Czy połączenie Imperva→MF jest szyfrowane? (brak danych)
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 | Dokumentacja API | Brak dostępu do API 2.0 | ⚠️ Brak transparentności |
| 3.2 | Schemat XML | Brak <EncryptedData> | 🔴 Brak E2E |
| 3.3 | Środowiska | Wszystkie używają Imperva | ⚠️ Brak alternatywy |
| 3.4 | Test wysyłki | System akceptuje jawny XML | 🔴 Brak wymogu E2E |
| 4.1 | Routing DNS/IP | Geolokacja: Imperva Inc. | ⚠️ Imperva |
| 4.2 | Terminacja TLS | Jawny payload widoczny | 🔴 Dane jawne |
| 4.3 | Ślady Sesji | Metadane (IP/UA) u Thales | 🔴 Dane jawne |
| 4.4 | Payload Visibility | Jawny XML | 🔴 Dane jawne |
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)
✅ Brak szyfrowania end-to-end payloadu
- Dowód: Schemat XML nie zawiera elementów
<EncryptedData>(Test 3.2)
✅ Imperva ma techniczną zdolność odczytu faktur
- Konsekwencja: Terminacja TLS + brak E2E = payload jawny na poziomie WAF
✅ Tylko podpis cyfrowy (XML Signature)
- Funkcja: Autentyczność i integralność, nie poufność
2. Zdolności techniczne Imperva (potwierdzone)
| Zdolność | Status | Podstawa |
|---|---|---|
| Odczyt pełnej treści faktur XML | 🔴 TAK | Terminacja TLS (Test 2.1) |
| Logowanie metadanych (IP, timing, rozmiary) | 🔴 TAK | Funkcja WAF |
| Inspekcja payloadu (DPI) | 🔴 TAK | Wymagane dla WAF |
| Modyfikacja ruchu (MitM) | 🔴 TAK | Pełna kontrola nad TLS |
| Blokowanie żądań | 🔴 TAK | Funkcja WAF |
Uwaga: To są zdolności techniczne, nie dowód faktycznego wykorzystania.
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 FR
🟡 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?
4. Porównanie: Deklaracje MF vs. Rzeczywistość techniczna
| Aspekt | Deklaracja MF | Rzeczywistość techniczna |
|---|---|---|
| Szyfrowanie danych | ✅ „Dane są szyfrowane” | ⚠️ Tylko TLS (terminowany przez Imperva) |
| Bezpieczeństwo | ✅ „System jest bezpieczny” | ⚠️ Bezpieczny przed kim? |
| Ochrona przed dostępem | ✅ Domniemana | ❌ Brak E2E = brak ochrony przed WAF |
| 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 może odczytać faktury? | ✅ TAK – potwierdzone technicznie |
| 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ę” (✅ potwierdzone)
- „Imperva patrzy i zapisuje każdą fakturę” (❓ nieznane)
6. Rekomendacje techniczne
Dla pełnego bezpieczeństwa system KSeF powinien:
- ✅ Szyfrowanie E2E na poziomie aplikacji
- Implementacja: XML Encryption (W3C standard)
- Efekt: Payload szyfrowany przed wysłaniem do Imperva
- Klucze: Tylko MF i podatnik (Imperva nie ma dostępu)
- ✅ Terminacja TLS w polskiej infrastrukturze
- Implementacja: Własny WAF (NASK, CERT.PL, polski dostawca)
- Efekt: Klucze prywatne TLS nigdy nie opuszczają Polski
- ✅ Transparentność umów
- Publikacja: Pełna umowa SLA/DPA z Thales/Imperva
- Zawartość: Polityka logowania, retencji, dostępu służb
- ✅ 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, SQL injection (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
Czy można to zmienić?
Tak, istnieją alternatywy:
- Krótkoterminowo (6-12 miesięcy):
- Zmiana dostawcy WAF na polskiego/europejskiego (np. Akamai EU, Cloudflare w trybie BYOK)
- Wdrożenie szyfrowania E2E payloadu (XML Encryption)
- Średnioterminowo (12-24 miesiące):
- Budowa własnej infrastruktury WAF (NASK, CERT.PL)
- Pełna terminacja TLS w Polsce
- 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
Główne tezy audytu
- Ruch do KSeF przechodzi przez Imperva (Thales Group, USA/FR)
- Dowód: DNS CNAME, IP, nagłówek X-CDN
- Imperva terminuje TLS i odszyfrowuje ruch
- Dowód: Test różnicowy z nagłówkiem Host: (Test 2.1)
- Brak szyfrowania end-to-end payloadu faktur
- Dowód: Analiza schematu XML – brak elementów EncryptedData
- Imperva ma techniczną zdolność odczytu wszystkich faktur
- Konsekwencja: Terminacja TLS + brak E2E
- Architektura nie spełnia standardów suwerenności cyfrowej
- Ocena: Krytyczny system fiskalny zależny od zagranicznej infrastruktury
Weryfikowalność
Każdy może powtórzyć te testy.
Wymagane narzędzia (bezpłatne):
- PowerShell (Windows)
curl(Windows/Linux/Mac)nslookuplubResolve-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. 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.