KSeF a ryzyka poufności danych: dlaczego architektura połączeń ma znaczenie
W przestrzeni publicznej pojawiają się sygnały, że (co najmniej w środowisku testowym) komunikacja z API KSeF może być realizowana z wykorzystaniem zewnętrznej infrastruktury bezpieczeństwa typu WAF/CDN. W przytoczonej analizie technicznej wskazano m.in. na rekordy DNS dla api-demo.ksef.mf.gov.pl, które mają prowadzić do domen i adresów IP kojarzonych z usługą Imperva (powiązaną z grupą Thales). Autor tej analizy formułuje na tej podstawie tezę o „krytycznym problemie bezpieczeństwa” i potencjalnym ujawnieniu danych.
Niezależnie od tego, czy wszystkie wnioski z takiej analizy są trafne, sama kategoria ryzyka jest realna: w systemach, które centralizują ogrom wrażliwych danych fakturowych, kluczowe jest to gdzie kończy się szyfrowanie (TLS), kto widzi treść zapytań oraz jak chronione są tokeny/klucze autoryzacyjne.
Poniżej wyjaśniamy, co może oznaczać taki scenariusz dla bezpieczeństwa i zgodności prawnej.
dig ksef.mf.gov.pl
; <<>> DiG 9.20.15-1~deb13u1-Debian <<>> ksef.mf.gov.pl
;; global options: +cmd
;; Got answer:
;; ->>HEADER<<- opcode: QUERY, status: NOERROR, id: 30454
;; flags: qr rd ra; QUERY: 1, ANSWER: 2, AUTHORITY: 0, ADDITIONAL: 1
;; OPT PSEUDOSECTION:
; EDNS: version: 0, flags:; udp: 1232
;; QUESTION SECTION:
;ksef.mf.gov.pl. IN A
;; ANSWER SECTION:
ksef.mf.gov.pl. 300 IN CNAME nudnsjz.ng.impervadns.net.
nudnsjz.ng.impervadns.net. 60 IN A 45.60.74.103
;; Query time: 20 msec
;; SERVER: 2a01:4ff:ff00::add:2#53(2a01:4ff:ff00::add:2) (UDP)
;; WHEN: Fri Jan 23 07:54:49 UTC 2026
;; MSG SIZE rcvd: 98
1) Co sugerują rekordy DNS i dlaczego to budzi pytania
Wskazane w materiale rekordy (CNAME do domeny dostawcy usług ochrony ruchu i adres IP po stronie dostawcy) mogą oznaczać, że przed właściwą infrastrukturą KSeF działa tzw. warstwa brzegowa (reverse proxy / WAF), która:
-
filtruje i blokuje ataki (DDoS, boty, próby włamań),
-
stabilizuje dostępność,
-
często terminuję połączenie TLS (w praktyce: „rozszyfrowuje” ruch na brzegu i ponownie szyfruje do systemu docelowego).
To ostatnie jest kluczowe: jeżeli TLS jest terminowany po stronie dostawcy WAF, to dostawca — w zależności od modelu wdrożenia — może mieć techniczną możliwość wglądu w treść żądań (np. endpoint, parametry, nagłówki) oraz w elementy uwierzytelnienia przesyłane w komunikacji.
Nie zawsze oznacza to automatycznie „pełny dostęp do danych”. Istnieją wdrożenia, które ograniczają taki wgląd (np. ścisłe HSM, mTLS do origin, restrykcje administracyjne, logowanie minimalne, szyfrowanie aplikacyjne). Natomiast to jest obszar wymagający transparentności i audytu, bo konsekwencje ewentualnych błędów są poważne.
2) Jakie dane są potencjalnie „najbardziej wrażliwe” w kontekście KSeF
W fakturach i metadanych systemowych znajdują się informacje, które mają wysoką wartość biznesową i prywatnościową, m.in.:
-
relacje handlowe (kto komu wystawia faktury),
-
wartości i częstotliwość transakcji,
-
dane identyfikujące podmioty, czasem dane osobowe (np. jednoosobowe działalności),
-
informacje o uprawnieniach/rolach użytkowników (kto ma dostęp, jakie pełnomocnictwa).
Materiał na obrazie wprost wskazuje dwa przykłady ryzyk: możliwość ustalenia „kto komu i na jakie kwoty wystawia faktury” oraz wgląd w „uprawnienia co do KSeF”. To trafnie opisuje, jakiego typu informacje mogłyby zostać narażone, gdyby warstwa pośrednia była skonfigurowana lub zarządzana w sposób nieadekwatny do wagi danych.
3) Najpoważniejsze ryzyka bezpieczeństwa w takim modelu
Jeżeli architektura dopuszcza przetwarzanie ruchu przez podmiot trzeci (WAF/CDN), ryzyka zwykle dzielą się na cztery grupy:
A. Poufność (confidentiality)
Możliwy wgląd w treść zapytań i odpowiedzi (albo w ich metadane, które i tak bywają bardzo „mówiące”).
B. Integralność (integrity)
Gdy w komunikacji występują tokeny/klucze autoryzacyjne, krytyczne jest, czy mogą zostać przechwycone, odtworzone albo nadużyte. Autor materiału sugeruje możliwość wykonywania zapytań „w tle” w imieniu użytkownika — to scenariusz skrajny, ale warto go traktować jako model zagrożeń, który powinien być jednoznacznie wykluczony technicznie (m.in. poprzez silne mechanizmy uwierzytelnienia, ograniczanie tokenów, podpisywanie żądań, ścisłe logowanie i segregację dostępu).
C. Transfer danych poza EOG
W obrazie wskazano, że ruch może iść przez serwery w USA. Jeżeli to prawda (lub jeśli dostawca ma tam zasoby/administrację), pojawia się problem transferów do państw trzecich.
D. Dostępność (availability) i koncentracja ryzyka
Zależność od jednego dostawcy brzegowego zwiększa ryzyko awarii systemowej oraz ryzyko „single point of failure”.
4) Konsekwencje prawne: RODO i obowiązki transparentności
Z perspektywy zgodności prawnej kluczowe są pytania:
-
Kto jest administratorem danych, a kto podmiotem przetwarzającym?
W praktyce MF (operator KSeF) działa jako administrator w zakresie realizacji ustawowych zadań, a dostawcy infrastruktury (np. WAF/CDN) zazwyczaj występują jako procesorzy lub podprocesorzy. -
Czy istnieje podstawa i dokumentacja powierzenia przetwarzania (art. 28 RODO)?
Wymagane są umowy, opis środków technicznych i organizacyjnych, zasady retencji logów, zasady dostępu administracyjnego, audyty. -
Czy dochodzi do transferu do państwa trzeciego (rozdz. V RODO)?
Jeżeli dane (lub dostęp administracyjny do nich) mogą trafiać poza EOG, potrzebne są mechanizmy legalizujące transfer (np. standardowe klauzule umowne) oraz ocena ryzyk (tzw. TIA). W realiach po wyroku Schrems II ocena „praktycznej ochrony” danych jest szczególnie istotna.
W systemie powszechnym i obowiązkowym — jak KSeF — ciężar zapewnienia zgodności i bezpieczeństwa spoczywa przede wszystkim na instytucji publicznej. Jednak przedsiębiorcy, jako użytkownicy systemu, również mają interes prawny i biznesowy w tym, aby wiedzieć, gdzie i jak ich dane są przetwarzane.
5) Co powinno zostać publicznie wyjaśnione przez operatora KSeF
Jeżeli w systemie wykorzystywana jest zewnętrzna warstwa WAF/CDN, standardem w systemach o krytycznym znaczeniu powinny być co najmniej:
-
jasna informacja, czy i gdzie terminowany jest TLS,
-
opis, czy dostawca ma jakikolwiek dostęp do treści żądań i jak jest to ograniczane,
-
polityka logowania i retencji (co jest logowane, jak długo, gdzie),
-
informacje o ewentualnych transferach poza EOG i podstawach prawnych,
-
wyniki niezależnych audytów bezpieczeństwa (choćby w formie streszczeń).