Informacje Lokalne

Czy bramkę bezpieczeństwa WAF systemu KSeF obsługuje zagraniczna firma Imperva w chmurze?

Opublikowano: 13.03.2026 | Autor: Grzegorz GPS Świderski | Ostatnia aktualizacja: 13.03.2026 02:11

AUDYT INFRASTRUKTURY SIECIOWEJ

Bramka WAF systemu KSeF 2.0

api.ksef.mf.gov.pl — środowisko produkcyjne

Przedmiot audytuapi.ksef.mf.gov.pl (KSeF 2.0, produkcja)
MetodaPasywny rekonesans sieciowy (DNS, HTTP, TLS, traceroute, WHOIS/RIPE, DPF)
DataMarzec 2026
Środowisko testowePowerShell 5.1+ / Windows, Play Polska (PL)

1. Pytanie audytowe

Czy bramkę bezpieczeństwa WAF systemu KSeF obsługuje zagraniczna firma Imperva w chmurze, czy on-premises — i czy chodzi tu o obecne, produkcyjne API KSeF 2.0?

Pytanie dotyczy dwóch kwestii: (a) modelu deploymentu ochrony WAF — cloud vs. on-premises, oraz (b) weryfikacji, czy diagnozowane środowisko jest faktycznym środowiskiem produkcyjnym KSeF 2.0. Audyt odpowiada na oba pytania na podstawie twardych śladów infrastrukturalnych zebranych metodami pasywnymi.

2. Metodologia i zakres

Audyt składa się z sześciu kroków pomiarowych, wykonanych niezależnie i sekwencyjnie. Każdy krok dostarcza osobnej warstwy dowodowej, a łącznie tworzą one spójny, wzajemnie weryfikowalny obraz infrastruktury edge KSeF 2.0.

KrokTechnikaCel
1DNS CNAME — multi-resolver (Google, Cloudflare, system) + TTLWeryfikacja delegacji DNS i trwałości rekordu
2Inspekcja certyfikatu TLS (X.509)Identyfikacja terminacji sesji HTTPS
3Traceroute + geolokalizacja IP + ASNFizyczna trasa ruchu i jurysdykcja węzłów
4HTTP headers fingerprinting (GET, HEAD, metody)Identyfikacja warstwy WAF i konfiguracji bezpieczeństwa
5WHOIS / RIPE RDAP — trzy IP trasyPrzynależność blokow IP, podmioty prawne, kraje
6Rejestr EU-US Data Privacy FrameworkOcena zgodności transferu danych z RODO art. 44–46

3. Krok 1 — Wielopunktowa weryfikacja DNS

3.1 Komenda PowerShell

$hostName = „api.ksef.mf.gov.pl”

$resolvers = @{

    „Google (8.8.8.8)”     = „8.8.8.8”

    „Cloudflare (1.1.1.1)” = „1.1.1.1”

    „System (domyślny)”    = $null

}

foreach ($label in $resolvers.Keys) {

    Write-Host „`n=== DNS CNAME via $label ===”

    $params = @{ Name = $hostName; Type = „CNAME” }

    if ($resolvers[$label]) { $params[„Server”] = $resolvers[$label] }

    Resolve-DnsName @params | Select-Object Name, Type, TTL, NameHost | Format-Table

}

3.2 Wynik

=== DNS CNAME via Google (8.8.8.8) ===

Name                Type TTL NameHost

api.ksef.mf.gov.pl CNAME  55 hju8yoo.ng.impervadns.net

=== DNS CNAME via System (domyślny) ===

Name                Type TTL NameHost

api.ksef.mf.gov.pl CNAME  55 hju8yoo.ng.impervadns.net

=== DNS CNAME via Cloudflare (1.1.1.1) ===

Name                Type TTL NameHost

api.ksef.mf.gov.pl CNAME  60 hju8yoo.ng.impervadns.net

3.3 Interpretacja

Wszystkie trzy niezależne resolvery zwracają identyczny cel CNAME: hju8yoo.ng.impervadns.net. Wyklucza to scenariusz tymczasowego lub lokalnego przekierowania — rekord jest globalnie spójny.

ObserwacjaWartośćWniosek
Cel CNAMEhju8yoo.ng.impervadns.netDomena impervadns.net należy wyłącznie do Imperva Cloud WAF
Spójność resolverów3/3 identyczneBrak tymczasowego/lokalnego przekierowania
TTL55–60 sekundBardzo niski TTL — charakterystyczny dla cloud CDN/WAF, nie on-premises
Segment ng.Next GenerationNowsza generacja sieci Impervy — wyższy throughput, więcej PoP

Kluczowe: w modelu on-premises (SecureSphere / WAF Gateway) DNS wskazuje na własny adres IP klienta (MF). Delegacja do impervadns.net jest fizycznie niemożliwa bez przepuszczania ruchu przez infrastrukturę Impervy.

4. Krok 2 — Inspekcja certyfikatu TLS

4.1 Komenda PowerShell

Add-Type @”

using System.Net; using System.Net.Security;

using System.Security.Cryptography.X509Certificates;

public class CertGrabber {

    public static X509Certificate2 GetCert(string host) {

        X509Certificate2 captured = null;

        var req = (HttpWebRequest)WebRequest.Create(„https://” + host + „/”);

        req.ServerCertificateValidationCallback = (s, cert, chain, err) => {

            captured = new X509Certificate2(cert); return true; };

        try { req.GetResponse().Close(); } catch {}

        return captured; } }

„@

$cert = [CertGrabber]::GetCert(„api.ksef.mf.gov.pl”)

„Subject: {0}” -f $cert.Subject

„Issuer:  {0}” -f $cert.Issuer

„Valid:   {0} – {1}” -f $cert.NotBefore, $cert.NotAfter

4.2 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

Valid From: 08.12.2025 01:00:00

Valid To:   08.12.2026 00:59:59

Thumbprint: 6AF8575E9149E4B62C04027912951BFF43A75DEE

4.3 Interpretacja

Certyfikat jest wystawiony na Ministerstwo Finansów (wildcard *.ksef.mf.gov.pl). Nie oznacza to jednak, że TLS terminuje na serwerach MF. Imperva Cloud WAF oferuje tryb Custom Certificate — klient wgrywa swój certyfikat z kluczem prywatnym do platformy Impervy, która używa go do terminacji TLS na własnych węzłach edge.

IMPLIKACJA KRYTYCZNA: Imperva posiada klucz prywatny certyfikatu *.ksef.mf.gov.pl (lub dostęp do niego w HSM platformy) i używa go do odszyfrowywania całego ruchu HTTPS przed jego przekazaniem do backendu MF. Treść dokumentów XML e-faktur jest widoczna dla infrastruktury Impervy w formie plaintext.

5. Krok 3 — Geolokalizacja PoP i trasa ruchu

5.1 Komenda PowerShell

$hostName = „api.ksef.mf.gov.pl”

$resolved  = Resolve-DnsName $hostName -Type A -Server 8.8.8.8

$targetIP  = ($resolved | Where-Object { $_.Type -eq „A” } | Select -First 1).IPAddress

„Docelowy IP: $targetIP”

tracert -h 20 -w 1000 $hostName

$geo = Invoke-RestMethod „http://ip-api.com/json/$targetIP”

„IP: $($geo.query) | Kraj: $($geo.country) | ASN: $($geo.as)”

5.2 Wynik

=== ROZWIĄZANIE IP DOCELOWEGO ===

Docelowy IP: 45.60.74.103

=== TRACEROUTE (max 20 hopów) ===

Tracing route to hju8yoo.ng.impervadns.net [45.60.74.103]

  1   <1ms   192.168.1.1

  2    8ms   10.161.192.1

  3    7ms   89-75-3-8.infra.play.pl [89.75.3.8]

  4   25ms   pl-waw10a-rc1_ae48.0.as9141.pl [185.182.246.0]

  5    9ms   pl-waw26c-ri1_ae2.0.as9141.pl [185.182.244.29]

  6   13ms   war-b8-link.ip.twelve99.net [62.115.182.116]

  7   24ms   hbg-bb2-link.ip.twelve99.net [62.115.141.150]

  8   29ms   ddf-b3-link.ip.twelve99.net [62.115.135.155]

  9   27ms   imperva-ic-379643.ip.twelve99-cust.net [213.248.77.211]

 10   29ms   131.125.134.75

 11   28ms   45.60.74.103

=== GEOLOKALIZACJA IP (Imperva edge) ===

IP:      45.60.74.103

Kraj:    United States (US) — ARTEFAKT BAZY ARIN, NIE RZECZYWISTA LOKALIZACJA

ISP/Org: Incapsula Inc

ASN:     AS19551 Incapsula Inc

5.3 Interpretacja

Wynik geolokalizacji 'Miami, Florida’ jest artefaktem bazy ARIN — blok IP 45.60.0.0/16 jest zarejestrowany w USA (ARIN), ale fizycznie serwer stoi w Europie. Dowód: latencja 27–31 ms z Polski jest fizycznie niemożliwa dla trasy transatlantyckiej (typowo 110–130 ms).

HopWęzełJurysdykcja / Operator
389.75.3.8 (infra.play.pl)Polska — sieć szkieletowa Play
4–5pl-waw10a, pl-waw26c (AS9141)Polska — węzły Play w Warszawie
6war-b8-link.ip.twelve99.netUE / Szwecja — Arelion/Telia, węzeł Warszawa
7hbg-bb2-link.ip.twelve99.netUE / Szwecja — Arelion/Telia, węzeł Hamburg
8ddf-b3-link.ip.twelve99.netUE / Szwecja — Arelion/Telia, węzeł Düsseldorf
9imperva-ic-379643.ip.twelve99-cust.netPunkt styku Arelion ↔ Imperva — blok Imperva Ltd. (Izrael)
10–11131.125.134.75 → 45.60.74.103Sieć wewnętrzna Impervy → PoP docelowy (fizycznie UE)

Rzeczywisty PoP Impervy obsługujący ruch z Polski to najprawdopodobniej Amsterdam lub Frankfurt — co jest zgodne z trasą przez Hamburg i Düsseldorf oraz z architekturą sieci Impervy w Europie.

6. Krok 4 — Pełna analiza nagłówków HTTP

6.1 Wynik

StatusCode: 302 (Redirect → /docs/v2)

Connection:               keep-alive

Content-Length:           0

Server:                   Kestrel

Strict-Transport-Security: max-age=31536000

X-CDN:                    Imperva

X-Iinfo:                  62-59611270-59597222 pNNN RT(1773355916122 62) q(0 0 0 5) r(0 0) U11

Set-Cookie:               visid_incap_3296082=…; HttpOnly; Secure; SameSite=None

                          incap_ses_1855_3296082=…; Secure; SameSite=None

=== METODY HTTP ===

GET     → 302 (Redirect)

POST    → 405 (MethodNotAllowed)

OPTIONS → 405 (MethodNotAllowed)  ← PROBLEM

TRACE   → 405 (MethodNotAllowed)  ← poprawne

PUT / DELETE / PATCH → 405

6.2 Interpretacja — dekodowanie X-Iinfo

Pole X-IinfoWartośćZnaczenie
PoP ID62Identyfikator węzła edge Impervy — zgodny z lokalizacją AMS/FRA
Request ID59611270-59597222Wewnętrzny identyfikator żądania w systemie Impervy
Cache statuspNNN (pass)Ruch nie był cachowany — przeszedł do originu MF
RT62 msCzas przetwarzania przez edge Impervy
U11Klasyfikacja sesji użytkownika przez WAF Impervy

6.3 Ocena nagłówków bezpieczeństwa

NagłówekStatusRyzyko / Uwaga
Strict-Transport-Security⚠ NIEPEŁNYBrak includeSubDomains i preload
Content-Security-Policy✗ BRAKBrak ochrony przed XSS i injection
X-Frame-Options✗ BRAKPodatność na clickjacking
X-Content-Type-Options✗ BRAKMIME sniffing możliwy
Referrer-Policy✗ BRAKWyciek URL w nagłówku Referer
Permissions-Policy✗ BRAKBrak kontroli API przeglądarki
Server: Kestrel✗ OBECNYWyciek stosu: backend to ASP.NET Core
OPTIONS → 405⚠ PROBLEMCORS preflight zablokowany — problem dla integracji webowych
SameSite=None (ciasteczka WAF)⚠ OBNIŻONECiasteczka WAF wysyłane cross-site — obniżona ochrona CSRF

7. Krok 5 — ASN / WHOIS / RIPE RDAP

7.1 Wynik RDAP dla trzech adresów IP trasy

IPBlok CIDRNazwa RIPEPodmiot prawnyKraj
213.248.77.211213.248.64.0/19ARELIONTwelve99 / Arelion (Telia Carrier)UE / SE
131.125.134.75131.125.128.0/17IL-IMPERVA-19881117Imperva Ltd.Izrael (IL)
45.60.74.10345.60.0.0/16INCAPSULA-NETIncapsula IncUSA

7.2 Dodatkowe odkrycie z RIPE — Imperva B.V. (Holandia)

Zapytanie RIPE ujawniło trzeci podmiot Impervy niewidoczny wcześniej: Imperva B.V. z siedzibą przy Kingsfordweg 151, Amsterdam (Teleport Towers). Jest to holenderska spółka-córka grupy Imperva, zarejestrowana w UE. Możliwe, że europejski ruch KSeF jest formalnie przetwarzany przez Imperva B.V. (co poprawiałoby sytuację z RODO), jednak wymaga to weryfikacji w umowie Data Processing Agreement między MF a Impervą — dokumentu niedostępnego publicznie.

8. Krok 6 — Rejestr EU-US Data Privacy Framework

8.1 Wynik — weryfikacja ręczna na dataprivacyframework.gov

Ręczna weryfikacja w oficjalnym rejestrze EU-US Data Privacy Framework (dataprivacyframework.gov) z zapytaniem 'Imperva’ i filtrem Status: Active zwróciła:

„Sorry, no results found for 'Imperva'”

Analogicznie brak wyników dla zapytania 'Incapsula’. Wynik jest jednoznaczny i definitywny — żaden podmiot z grupy Imperva/Incapsula nie posiada aktywnej certyfikacji DPF na dzień audytu.

8.2 Konsekwencje prawne

Reżim prawnyPodmiotPodstawaSkutek dla KSeF
US Cloud ActIncapsula Inc (USA)18 U.S.C. § 2713Władze USA mogą żądać danych bez procedury MLAT
FISA 702Incapsula Inc (USA)50 U.S.C. § 1881aNSA/FBI — dostęp do danych bez nakazu sądowego
Prawo izraelskieImperva Ltd. (IL)Ustawa o niejawności informacji 5741-1981Izraelskie służby mogą żądać dostępu od Impervy Ltd.
RODO art. 44–46Incapsula Inc (USA)Brak decyzji adekwatności + brak DPFBrak legalnej podstawy transferu danych do USA

9. Zestawienie wszystkich dowodów infrastrukturalnych

#DowódWartośćZnaczenie
1CNAMEhju8yoo.ng.impervadns.netRuch DNS delegowany wyłącznie do chmury Impervy
2TTL DNS55–60 s — spójny na 3 resolverachCloud WAF, nie on-premises (on-prem: TTL 300–3600 s)
3X-CDNImpervaJawna identyfikacja warstwy edge — deterministyczny fingerprint
4Set-Cookievisid_incap_3296082 / incap_ses_*Site ID 3296082 = konto w Imperva Cloud WAF
5Certyfikat TLSCN=*.ksef.mf.gov.pl, O=MINISTERSTWO FINANSÓWMF wgrało własny certyfikat do platformy Impervy
6TraceroutePL → Arelion → Imperva edge (27–31 ms)Fizyczna trasa potwierdza routing przez infrastrukturę Impervy w EU
7Latencja27–31 ms z Polski do edgeWyklucza USA jako fizyczną lokalizację PoP
8ASN edgeAS19551 Incapsula Inc (USA)Operator węzła końcowego — spółka amerykańska
9Blok tranzytowy131.125.128.0/17 — Imperva Ltd. (IL)Sieć tranzytowa = spółka izraelska
10Server: KestrelNagłówek HTTP odpowiedziWyciek stosu: backend ASP.NET Core (MF)
11DPFBrak wyników — ręczna weryfikacjaImperva/Incapsula bez aktywnej certyfikacji EU-US DPF
12RIPE Imperva B.V.Kingsfordweg 151, Amsterdam (NL)Holenderska spółka-córka Impervy — potencjalny podmiot kontraktowy

10. Podsumowanie i wnioski końcowe

10.1 Odpowiedź na pytanie audytowe

TAK — bramkę bezpieczeństwa WAF przed api.ksef.mf.gov.pl, czyli obecnym produkcyjnym API KSeF 2.0, obsługuje Imperva w modelu chmurowym (cloud reverse proxy / cloud WAF edge), a nie on-premises. Backend KSeF może stać w infrastrukturze MF, ale publiczna warstwa wejściowa WAF/CDN jest chmurową warstwą edge Impervy.

Dowody są deterministyczne, nie probabilistyczne — trzy niezależne ślady (CNAME do impervadns.net, nagłówek X-CDN: Imperva, ciasteczka Incapsula z site_id) wzajemnie się potwierdzają i nie mają alternatywnej interpretacji. Potwierdzenie, że chodzi o środowisko produkcyjne KSeF 2.0, wynika z oficjalnej dokumentacji MF: api.ksef.mf.gov.pl jest domeną produkcyjną (w odróżnieniu od api-test.ksef.mf.gov.pl i api-demo.ksef.mf.gov.pl), a środowisko produkcyjne KSeF 2.0 zostało udostępnione 1 lutego 2026 r.

10.2 Mapa architektury przepływu danych

[Podatnik / System ERP]

        │ HTTPS — TLS terminowany przez Impervę

        ▼

[Play Polska — sieć szkieletowa PL]

        │

        ▼

[Arelion/Telia — Warszawa → Hamburg → Düsseldorf]  ← Jurysdykcja: UE/SE

        │

        ▼

[Imperva Ltd. — sieć tranzytowa 131.125.128.0/17]  ← Jurysdykcja: IZRAEL

        │  terminacja TLS / inspekcja WAF (plaintext e-faktur widoczny)

        ▼

[Incapsula Inc — edge PoP 45.60.74.103, AS19551]   ← Jurysdykcja: USA

        │  filtracja, ciasteczka, nagłówki

        ▼

[Backend KSeF — ASP.NET Core / Kestrel]             ← Jurysdykcja: PL/MF

10.3 Kwestie wymagające pilnego wyjaśnienia przez MF

  • Podstawa prawna transferu danych do USA (art. 46 RODO) — Imperva/Incapsula nie jest uczestnikiem DPF; jeśli podstawą są SCC, umowa powinna być ujawniona w rejestrze UODO.
  • Zakres danych widocznych dla Impervy po terminacji TLS — metadane żądań vs. pełna treść XML e-faktur (dane podatników, NIP, wartości transakcji).
  • Data Processing Agreement — umowa procesora danych między MF a Impervą (art. 28 RODO) powinna istnieć i być dostępna na żądanie UODO.
  • Rola Imperva B.V. (Holandia) — czy europejski ruch jest formalnie przetwarzany przez holenderską spółkę-córkę, co poprawiłoby sytuację z RODO.
  • Szyfrowanie payload — czy MF zastosowało szyfrowanie treści e-faktur na poziomie aplikacji (ponad TLS), niezależne od Impervy.

10.4 Rekomendacje techniczne

  • Nagłówki bezpieczeństwa: dodać X-Content-Type-Options: nosniff, X-Frame-Options: DENY, Content-Security-Policy, Referrer-Policy: strict-origin-when-cross-origin.
  • HSTS: uzupełnić o includeSubDomains; preload i zgłosić domenę do listy preload przeglądarek.
  • Nagłówek Server: usunąć lub zamaskować (nie ujawniać 'Kestrel’).
  • OPTIONS (CORS preflight): skonfigurować poprawną obsługę na ścieżkach API — aktualny 405 blokuje integracje webowe.
  • SameSite: zmienić na SameSite=Strict dla ciasteczek WAF.
  • Szyfrowanie end-to-end: rozważyć dodatkowe szyfrowanie payload e-faktur niezależne od TLS.

10.5 Granice audytu

Audyt obejmuje wyłącznie publicznie dostępną warstwę edge infrastruktury KSeF, zbadaną metodami pasywnego rekonesansu sieciowego (DNS, HTTP, TLS, traceroute, WHOIS/RIPE, rejestr DPF). Audyt nie weryfikuje: architektury wewnętrznej backendu MF, konfiguracji firewalla origin, treści umów kontraktowych z Impervą, faktycznej zawartości przetwarzanych danych ani wewnętrznych polityk bezpieczeństwa MF. Wszystkie wnioski opierają się wyłącznie na dowodach zebranych z publicznie dostępnych źródeł sieciowych.

Wykonanie audytu: Grzegorz GPS Świderski. Sformatowanie tekstu: Sonnet 4.6 Extended.

Dodaj komentarz: