SCENARIUSZ INTERWENCJI POSELSKIEJ – ARCHITEKTURA I BEZPIECZEŃSTWO KSeF

Grzegorz GPS Świderski, 20.02.2026

Na prośbę posła Włodzimierza Skalika przygotowałem dokument w kwestii KSeF. Jest to 6 szczegółowych technicznych pytań. Dziś wraz z Grzegorzem Braunem i Januszem Korwin Mikke złożyli oni te pytania w Ministerstwie Finansów w ramach interwencji poselskiej. Bardzo im dziękuję za tę pomoc i za to, że podjęli moją inicjatywę i że nagłaśniają moje odkrycia. Ich chwała jest wielka, bo Konfederacja nie chciała się tym zająć.

  Za to, co dziś zrobili Braun i Korwin w kwestii KSeF, za to, że wsparli posła Skalika, który rozdmuchuje moje odkrycia dotyczące afery szpiegowskiej KSeF, za to, że złożyli w Ministerstwie Finansów moje 6 pytań dotyczących tego agenturalnego systemu, wybaczam im wszystkie zastrzeżenia, jakie do nich miałem. Tym samym odpokutowali wszystkie swoje polityczne winy. 

  Ja zawsze ich uważałem za ludzi bardzo mądrych, za wybitnych myślicieli politycznych. Nie na darmo napisali wiele bardzo wartościowych książek, za co im chwała. To wybitni overtoniści, którzy przesuwają od lat okno Overtona na prawo. Miałem do nich tylko o to pretensje, że w swym marketingu politycznym, w tym, jak się zwracają do ciemnego ludu, w tym, że przyciągają do siebie różnej maści szurów, popełniają błędy polityczne. 

  Nadal uważam to za błędy, ale im je wybaczam, zaczynam patrzeć na nie przez palce. Jeszcze nie wiadomo, jakie to przyniesie owoce, może to jest i słuszne, by gromadzić wariatów wokół siebie. To jest kwestia sytuacyjna, taktyczna. Jednak mądrości im odmówić nie można. Za to, co dziś zrobili, mają u mnie tak wielkiego plusa, że przekreśla on wszystkie poprzednie minusy.

SCENARIUSZ INTERWENCJI POSELSKIEJ – ARCHITEKTURA I BEZPIECZEŃSTWO KSeF

Część I: Definicje pojęć technicznych i architektonicznych

  1. HTTP (Hypertext Transfer Protocol) – podstawowy protokół komunikacji w sieci Internet służący do przesyłania żądań i odpowiedzi pomiędzy klientem a serwerem aplikacyjnym. Treść komunikacji HTTP może zawierać dane aplikacyjne, w tym dokumenty i struktury danych przekazywane do systemu KSeF.
  2. HTTPS (HTTP Secure) – odmiana protokołu HTTP, w której transmisja danych pomiędzy klientem a serwerem jest zabezpieczona kryptograficznie przy użyciu protokołu TLS. HTTPS zapewnia poufność i integralność danych w trakcie transmisji sieciowej, lecz nie oznacza automatycznie szyfrowania danych na poziomie aplikacyjnym.
  3. TLS (Transport Layer Security) – protokół kryptograficzny zapewniający szyfrowanie połączenia sieciowego pomiędzy dwoma punktami komunikacji. Zakończenie połączenia TLS w danym elemencie infrastruktury (tzw. terminacja TLS) powoduje odszyfrowanie transmisji HTTP w tym punkcie i dalsze jej przekazanie w postaci jawnej do kolejnej warstwy systemu.
  4. XML (eXtensible Markup Language) – ustrukturyzowany format zapisu danych w postaci tekstowej, wykorzystywany do reprezentacji pełnej treści faktury elektronicznej w systemie KSeF zgodnie z określonym schematem logicznym. Dokument XML może podlegać dodatkowemu szyfrowaniu aplikacyjnemu, niezależnemu od szyfrowania transportowego TLS.
  5. JSON (JavaScript Object Notation) – tekstowy format struktury danych używany do przekazywania informacji pomiędzy systemami informatycznymi w ramach komunikacji HTTP/HTTPS. W kontekście KSeF JSON zawiera dane identyfikacyjne i operacyjne faktury (metadane), które nie stanowią pełnej treści dokumentu XML.
  6. WAF (Web Application Firewall) – wyspecjalizowany system bezpieczeństwa chroniący aplikacje internetowe poprzez analizę i filtrowanie ruchu HTTP/HTTPS pomiędzy klientem a serwerem. WAF działa w warstwie aplikacyjnej sieci i — w przypadku terminacji TLS — przetwarza odszyfrowaną treść żądań kierowanych do chronionego systemu.
  7. Szyfrowanie end-to-end (E2E) – mechanizm kryptograficzny stosowany na poziomie danych aplikacyjnych, w którym treść danych jest szyfrowana po stronie nadawcy i pozostaje zaszyfrowana w trakcie transmisji oraz w warstwach pośredniczących. Odczyt danych jest możliwy wyłącznie w tych komponentach systemu, które posiadają uprawnienia kryptograficzne do ich odszyfrowania (tj. dostęp do kluczy lub równoważnych mechanizmów). W szczególności, jeżeli element infrastruktury pośredniczącej posiada dostęp do kluczy lub mechanizmów odszyfrowania, może uzyskać dostęp do treści danych mimo zastosowania szyfrowania na poziomie aplikacyjnym.
  8. API (Application Programming Interface) – zestaw zdefiniowanych reguł komunikacji umożliwiających wymianę danych pomiędzy systemami informatycznymi poprzez określone operacje, formaty danych i protokoły sieciowe. W kontekście KSeF API stanowi techniczny interfejs, za pośrednictwem którego systemy podatników przekazują dokumenty i dane faktur do systemu państwowego oraz odbierają odpowiedzi systemowe.
  9. HSM (Hardware Security Module) – wyspecjalizowane, fizyczne urządzenie kryptograficzne przeznaczone do bezpiecznego generowania, przechowywania oraz używania kluczy kryptograficznych. Klucze przechowywane w HSM pozostają chronione przed bezpośrednim odczytem, a operacje kryptograficzne (np. szyfrowanie, deszyfrowanie, podpisywanie) wykonywane są wewnątrz urządzenia. Dostęp do funkcji HSM może być realizowany lokalnie lub zdalnie przez uprawnione systemy, co oznacza, że podmiot posiadający logiczny dostęp do HSM może wykonywać operacje kryptograficzne na chronionych danych bez fizycznego dostępu do samego klucza.
  10. KMS (Key Management System / Key Management Service) – system informatyczny służący do zarządzania cyklem życia kluczy kryptograficznych, obejmującym ich generowanie, dystrybucję, rotację, przechowywanie, unieważnianie oraz kontrolę dostępu. KMS może wykorzystywać sprzętowe moduły HSM lub inne mechanizmy zabezpieczające i często działa jako usługa sieciowa dostępna dla wielu komponentów infrastruktury. Podmiot posiadający uprawnienia administracyjne lub operacyjne do KMS może uzyskać zdolność wykonywania operacji kryptograficznych na danych chronionych tymi kluczami, co w praktyce może umożliwiać odszyfrowanie danych w określonych warunkach systemowych.
  11. Model clearance (model autoryzacyjny) – architektoniczny i prawny model funkcjonowania systemu e-fakturowania (jak polski KSeF), w którym każda faktura, przed wywarciem skutków prawnych i gospodarczych lub przed dostarczeniem jej do nabywcy, musi zostać obowiązkowo przesłana do centralnej platformy państwowej w celu jej walidacji i autoryzacji (np. nadania unikalnego numeru identyfikacyjnego). W modelu tym administracja skarbowa uczestniczy w czasie rzeczywistym w procesie wymiany dokumentów pomiędzy podatnikami. Czyni to system clearance infrastrukturą krytyczną państwa, stanowiącą centralny punkt gromadzenia pełnych danych analitycznych (metadanych i treści) o bieżącym obrocie gospodarczym całego kraju w momencie jego realizacji.

Część II: Pytania merytoryczne

Poniższe pytania dotyczą wyłącznie faktów technicznych możliwych do potwierdzenia w sposób jednoznaczny i nie wymagają ujawniania informacji niejawnych ani wrażliwych z punktu widzenia bezpieczeństwa państwa.

Pytanie 1 – Terminacja TLS na warstwie WAF 

Definicje na potrzeby pytania:

  • „operator WAF” – podmiot zewnętrzny wobec Ministerstwa Finansów, świadczący usługę ochrony aplikacyjnej dla ruchu kierowanego do systemu KSeF.
  • „terminacja TLS” – zakończenie szyfrowanego połączenia HTTPS w danym elemencie infrastruktury, polegające na odszyfrowaniu ruchu i dalszym przekazaniu go w postaci jawnej do kolejnej warstwy systemu.
  • „transmisja HTTPS” – komunikacja sieciowa pomiędzy klientem a systemem KSeF realizowana z użyciem protokołu HTTP zabezpieczonego kryptograficznie protokołem TLS.

Czy Ministerstwo Finansów potwierdza, że połączenie HTTPS kierowane do systemu KSeF ulega terminacji TLS na infrastrukturze zewnętrznego operatora WAF, a tym samym operator ten posiada lub może posiadać, przy standardowym modelu operacyjnym świadczonej usługi, techniczną możliwość przetwarzania odszyfrowanej treści transmisji HTTP przed jej przekazaniem do infrastruktury Ministerstwa Finansów?

Pytanie 2 – Szyfrowanie aplikacyjne E2E faktury XML 

Definicje na potrzeby pytania:

  • „szyfrowanie aplikacyjne end-to-end (E2E)” – mechanizm kryptograficzny, w którym treść komunikatu jest szyfrowana po stronie nadawcy i może zostać odszyfrowana wyłącznie przez końcowy system odbiorcy.
  • „faktura w formacie XML” – ustrukturyzowany dokument elektroniczny zawierający pełną treść faktury ustandaryzowaną w schemacie XML KSeF.

Czy Ministerstwo Finansów potwierdza, że treść faktury przekazywanej do systemu KSeF w formacie XML podlega szyfrowaniu aplikacyjnemu end-to-end, w wyniku czego pozostaje nieczytelna dla podmiotów pośredniczących w transmisji — w tym operatora WAF — nawet po terminacji połączenia TLS, oraz czy jakikolwiek podmiot pośredniczący posiada dostęp do kluczy kryptograficznych lub równoważnych mechanizmów umożliwiających odszyfrowanie tej treści?

Pytanie 3 – Metadane JSON a warstwa WAF 

Definicje na potrzeby pytania:

  • „JSON z metadanymi faktury” – część komunikatu przekazywanego do API KSeF w formacie JSON, zawierająca dane identyfikacyjne i operacyjne faktury, w szczególności: NIP, nazwy podmiotów, kwoty netto, VAT i brutto, walutę, numer faktury, daty operacyjne oraz typ dokumentu.
  • „brak szyfrowania aplikacyjnego E2E” – sytuacja, w której dane te nie są dodatkowo szyfrowane przed wysłaniem do systemu KSeF, a ich poufność wynika wyłącznie z szyfrowania transportowego TLS.

Czy Ministerstwo Finansów potwierdza, że metadane faktury przekazywane do systemu KSeF w strukturze JSON są przesyłane w ramach transmisji HTTPS bez zastosowania szyfrowania aplikacyjnego end-to-end, a zatem — po terminacji TLS — występują w postaci odszyfrowanej w warstwie aplikacyjnej przed przekazaniem do infrastruktury Ministerstwa Finansów?

Pytanie 4 – Klucze E2E 

Czy jakikolwiek podmiot zewnętrzny wobec Ministerstwa Finansów (w tym operator WAF) posiada, może posiadać lub może uzyskać bezpośrednio lub pośrednio w ramach standardowego modelu operacyjnego usługi dostęp do kluczy, tokenów, modułów HSM/KMS lub innych mechanizmów umożliwiających odszyfrowanie treści faktury przekazywanej w formacie XML w ramach KSeF, w jakimkolwiek punkcie przed jej przetworzeniem przez systemy pozostające pod bezpośrednią administracją Ministerstwa Finansów?

Pytanie 5 – Model architektoniczny KSeF i tryb wprowadzenia komponentów bezpieczeństwa

System centralnego fakturowania elektronicznego w modelu clearance stanowi element infrastruktury krytycznej państwa, obejmujący dane o całości obrotu gospodarczego. W publicznie dostępnych analizach wdrożeń analogicznych systemów w innych państwach rozwiniętych wskazuje się na szczególne znaczenie suwerenności infrastrukturalnej warstwy brzegowej, w tym komponentów odpowiedzialnych za analizę ruchu aplikacyjnego (WAF) oraz terminację połączeń TLS. W związku z zastosowaniem w systemie KSeF rozwiązań technologicznych pochodzących od podmiotów zagranicznych proszę o jednoznaczne wyjaśnienie:

  • 5.a. Na jakiej podstawie prawnej oraz w ramach jakiego konkretnego postępowania zakupowego wprowadzono do architektury KSeF komponenty bezpieczeństwa realizujące funkcje WAF i terminacji TLS?
  • 5.b. Czy komponenty te były przedmiotem odrębnego postępowania, czy też zostały pozyskane pośrednio w ramach szerszego zamówienia lub łańcucha dostaw?
  • 5.c. Czy przed podjęciem decyzji przeprowadzono formalną analizę wariantów architektonicznych, obejmującą rozwiązania: 
    • 5.c.1. krajowe, 
    • 5.c.2. unijne, 
    • 5.c.3. dostarczane przez podmioty spoza UE?
  • 5.d. Czy istnieje dokument analizy ryzyka suwerennościowego dotyczący powierzenia warstwy brzegowej KSeF podmiotowi zagranicznemu, a jeżeli tak – czy może on zostać ujawniony w części jawnej?

Pytanie 6 – Ryzyko jurysdykcyjne a techniczne mechanizmy ochrony danych 

W przypadku korzystania z usług podmiotów zagranicznych dla elementów infrastruktury przetwarzających odszyfrowany ruch sieciowy, kluczowe znaczenie ma ryzyko jurysdykcyjne wynikające z możliwości wydania wobec takiego podmiotu nakazów prawnych na podstawie przepisów państw trzecich, w tym regulacji o charakterze ekstraterytorialnym (np. CLOUD Act, FISA 702). Certyfikaty bezpieczeństwa informacji (np. ISO 27001, SOC 2 czy deklaracje zgodności z RODO) regulują standardy organizacyjne i cywilnoprawne, nie stanowią natomiast same w sobie technicznej bariery uniemożliwiającej wykonanie prawnie wiążącego nakazu udostępnienia danych przez dostawcę usługi. W związku z powyższym proszę o jednoznaczne wskazanie:

  • 6.a. Czy w architekturze KSeF wdrożono techniczne mechanizmy kryptograficzne lub infrastrukturalne, które uniemożliwiają dostawcy usługi WAF: 
    • 6.a.1. dostęp do odszyfrowanych metadanych, 
    • 6.a.2. ich pozyskanie na żądanie podmiotów trzecich, 
    • 6.a.3. wykonanie nakazu prawnego bez wiedzy i udziału organów państwa polskiego?
  • 6.b. Jeżeli takie mechanizmy istnieją – jakiego są rodzaju (np. separacja kluczy, krajowe HSM, brak dostępu operacyjnego do treści po terminacji TLS, architektura zero-knowledge itp.)?
  • 6.c. Jeżeli nie istnieją – czy przeprowadzono formalną analizę ryzyka prawno-jurysdykcyjnego związanego z możliwością pozyskania metadanych KSeF przez organy państw trzecich za pośrednictwem dostawcy infrastruktury?

Część III: Instrukcje wewnętrzne (spodziewane uniki i riposty)

Unik 1: Zasłanianie się Polityką Bezpieczeństwa (Security by Obscurity)

  • Spodziewana taktyka MF: Szczegóły architektury zabezpieczeń, w tym konfiguracja WAF, stanowią informacje wrażliwe dla bezpieczeństwa systemu państwowego i nie mogą być ujawnione.
  • Riposta: Panie Ministrze/Dyrektorze, nie pytam o adresy IP, reguły filtrowania czy nazwy dostawców. Pytam o sam model architektoniczny i fakt istnienia lub braku terminacji TLS oraz szyfrowania E2E, co jest powszechnym standardem transparentności w systemach klasy enterprise. Potwierdzenie tego faktu nie ułatwia zadania cyberprzestępcom, ale uspokaja polskich przedsiębiorców.

Unik 2: Zasłanianie się umowami NDA/Prawnymi

  • Spodziewana taktyka MF: Nawet jeśli operator zewnętrzny przetwarza ruch, chronią nas rygorystyczne umowy prawne, kary umowne i audyty bezpieczeństwa, które uniemożliwiają mu wgląd w dane.
  • Riposta: Panie Ministrze/Dyrektorze, żadna umowa cywilnoprawna, klauzule poufności (NDA) czy certyfikaty nie mają nadrzędności nad prawem federalnym USA. Jeśli infrastruktura KSeF, w tym warstwa WAF, opiera się na technologii amerykańskiego dostawcy chmurowego, dostawca ten podlega amerykańskim ustawom takim jak CLOUD Act czy FISA. Oznacza to legalny dostęp amerykańskich służb do tych danych, przed którym polskie umowy nas nie obronią. Umowa nie chroni też przed fizycznym wyciekiem z infrastruktury operatora czy cyberatakiem na jego systemy. Dlatego pytam o twardą, fizyczną i architektoniczną niemożliwość odczytu tych danych (kto ma fizyczny dostęp do kluczy i jawnego ruchu), a nie o prawne obietnice zapisane na papierze.

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

PS1. A tu wszystkie części mojej serii o KSeF, w których dokładnie tłumaczę, jakie są skutki wprowadzenia tego szpiegowskiego systemu:

PS2. A tu wszystkie audyty techniczne, które do tej pory przeprowadziłem:

Apel do ekspertów cyberbezpieczeństwa: Apel do ekspertów cyberbezpieczeństwa i architektury systemów informatycznych w sprawie KSeF

Odpowiedzi wirtualnych ekspertów cyberbezpieczeństwa:

Tagi: gps65, KSeF, JPK, finanse, gospodarka, podatki, biznes, państwo, wywiad.

u2

u2

20.02.2026 17:50

Amerykanie udostępniają światu technologię, więc Amerykanie mają nad nią kontrolę. Ewentualnie chcą mieć nad nią kontrolę. Bo świat nigdy nie śpi i wymyśla nowe pułapki na naiwnych.

PS Grzegorz Braun ma opaskę, tą razą, na lewym oku. A czy wcześniej nie miał jej na prawym oku? Co mu jest?

u2

"Braun ma opaskę cały czas na tym samym, lewym oku" 

To mi się dwoi w moim prawym oku. Czas na wizytę u okulisty :)

PS Te chińskie mocarstwowe zapędy skończą się zapewne światową wojną, przed którą ostrzegam bezskutecznie na NB :)