SCENARIUSZ INTERWENCJI POSELSKIEJ — ARCHITEKTURA I BEZPIECZEŃSTWO KSeF

Na proś­bę po­sła Wło­dzi­mie­rza Ska­li­ka przy­go­to­wa­łem do­ku­ment w kwe­stii KSeF. Je­st to 6 szcze­gó­ło­wy­ch tech­nicz­ny­ch py­tań. Dziś wraz z Grze­go­rzem Brau­nem i Ja­nu­szem Kor­win Mik­ke zło­ży­li oni te py­ta­nia w Mi­ni­ster­stwie Fi­nan­sów w ra­ma­ch in­ter­wen­cji po­sel­skiej. Bar­dzo im dzię­ku­ję za tę po­moc i za to, że pod­ję­li mo­ją ini­cja­ty­wę i że na­gła­śnia­ją mo­je od­kry­cia. Ich chwa­ła je­st wiel­ka, bo Kon­fe­de­ra­cja nie chcia­ła się tym za­jąć.

  Za to, co dziś zro­bi­li Braun i Kor­win w kwe­stii KSeF, za to, że wspar­li po­sła Ska­li­ka, któ­ry roz­dmu­chu­je mo­je od­kry­cia do­ty­czą­ce afe­ry szpie­gow­skiej KSeF, za to, że zło­ży­li w Mi­ni­ster­stwie Fi­nan­sów mo­je 6 py­tań do­ty­czą­cy­ch te­go agen­tu­ral­ne­go sys­te­mu, wy­ba­czam im wszyst­kie za­strze­że­nia, ja­kie do ni­ch mia­łem. Tym sa­mym od­po­ku­to­wa­li wszyst­kie swo­je po­li­tycz­ne wi­ny.

  Ja za­wsze ich uwa­ża­łem za lu­dzi bar­dzo mą­dry­ch, za wy­bit­ny­ch my­śli­cie­li po­li­tycz­ny­ch. Nie na dar­mo na­pi­sa­li wie­le bar­dzo war­to­ścio­wy­ch ksią­żek, za co im chwa­ła. To wy­bit­ni over­to­ni­ści, któ­rzy prze­su­wa­ją od lat okno Over­to­na na pra­wo. Mia­łem do ni­ch tyl­ko o to pre­ten­sje, że w swym mar­ke­tin­gu po­li­tycz­nym, w tym, jak się zwra­ca­ją do ciem­ne­go lu­du, w tym, że przy­cią­ga­ją do sie­bie róż­nej ma­ści szu­rów, po­peł­nia­ją błę­dy po­li­tycz­ne. 

  Na­dal uwa­żam to za błę­dy, ale im je wy­ba­czam, za­czy­nam pa­trzeć na nie przez pal­ce. Jesz­cze nie wia­do­mo, ja­kie to przy­nie­sie owo­ce, mo­że to je­st i słusz­ne, by gro­ma­dzić wa­ria­tów wo­kół sie­bie. To je­st kwe­stia sy­tu­acyj­na, tak­tycz­na. Jed­nak mą­dro­ści im od­mó­wić nie moż­na. Za to, co dziś zro­bi­li, ma­ją u mnie tak wiel­kie­go plu­sa, że prze­kre­śla on wszyst­kie po­przed­nie mi­nu­sy.

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:

• Czę­ść I. KSeF nie po­sze­rza in­wi­gi­la­cji. KSeF zwięk­sza roz­dziel­czo­ść.
• Czę­ść II. Prak­ty­ka KSeF: Hurt­Pol kon­tra Ko­wal­ski i Sy­no­wie.
• Czę­ść III. Ad­mi­ni­stra­tor KSeF. Czy­li gdzie na­praw­dę le­ży wła­dza.
• Czę­ść IV. Tech­no­lo­gia KSeF — su­we­ren­no­ść koń­czy się tam, gdzie koń­czy się ka­bel!
• Część V. Część V. KSeF i ciągłość decyzji. Imperva, czyli suwerenność sprzedana na raty!
• Część VI. KSeF — wyjaśnienie technicznych i praktyczne przykłady
• Część VII. Jakie metadane widzi Imperva?
• Część VIII. Co jeszcze widzi Imperva?
• Część IX. Ludzkość odrywa się od terytorium i zaczyna bujać w obłokach!
• Cześć X. Imperva w Polsce jest unikatowa

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

• ✅ Francja Audyt techniczny. Francja
• ✅ Węgry Audyt techniczny. Węgry
• ✅ Włochy Audyt techniczny. Włochy
• ✅ Rumunia Audyt techniczny. Rumunia
• ✅ Hiszpania Audyt techniczny. Hiszpania
• ✅ Albania Audyt techniczny. Albania
• ✅ Turcja Audyt techniczny. Turcja
• ✅ Rosja Audyt techniczny. Rosja
• ✅ Ukraina Audyt techniczny. Ukraina
• ✅ Argentyna Audyt techniczny. Argentyna
• ✅ Kolumbia Audyt techniczny. Kolumbia
• ✅ Chile Audyt techniczny. Chile
• ✅ Meksyk Audyt techniczny. Meksyk
• ✅ Brazylia Audyt techniczny. Brazylia
• ❌ Polska Audyt techniczny. Polska
• ❌ Polska Audyt techniczny KFeF. Raport pełny
• ❌ Polska Raport techniczn KSeF - uzupełniający
• ❌ Polska Audyt techniczny. Jawność metadanych JSON w KSeF przy terminacji TLS przez Imperva

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:

• ✅ deepseek: Odpowiedź eksperta cyberbezpieczeństwa deepseek
• ✅ Perplexity Pro Sonar: Odpowiedź eksperta cyberbezpieczeństwa Perplexity Pro Sonar
• ✅ Grok 4.1 Thinking: Odpowiedź eksperta cyberbezpieczeństwa Grok 4.1
• ✅ Gemini 3 Pro: Odpowiedź eksperta cyberbezpieczeństwa Gemini 3 Pro
• ✅ Claude Sonnet 4.6: Odpowiedź eksperta cyberbezpieczeństwa Claude Sonnet 4.6

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