Interpelacja w sprawie uruchomienia Centralnego Rejestru Umów Jednostek Sektora Finansów Publicznych (CRU JSFP) oraz obowiązku udostępniania w nim informacji o umowach zawieranych od dnia 1 lipca 2026 r.
Treść wystąpienia poselskiego
Interpelacja nr 18879
do ministra finansów i gospodarki
w sprawie uruchomienia Centralnego Rejestru Umów Jednostek Sektora Finansów Publicznych (CRU JSFP) oraz obowiązku udostępniania w nim informacji o umowach zawieranych od dnia 1 lipca 2026 r.
Zgłaszający: Łukasz Osmalak, Adam Luboński, Ewa Schädler, Wioleta Tomczak
Data wpływu: 27-07-2026
Szanowny Panie Ministrze,
w związku z uruchomieniem Centralnego Rejestru Umów Jednostek Sektora Finansów Publicznych (CRU JSFP) oraz obowiązkiem udostępniania w nim informacji o umowach zawieranych od dnia 1 lipca 2026 r. zwracam uwagę na problemy związane z zasadami uwierzytelniania systemów teleinformatycznych zintegrowanych z rejestrem.
Zgodnie z dokumentacją integracyjną opublikowaną przez Ministerstwo Finansów każde wywołanie API CRU JSFP wymaga użycia klucza przekazywanego w nagłówku `X-API-KEY`. Klucz ten może wygenerować użytkownik posiadający rolę „Publikującego” i zachowuje on ważność przez sześć miesięcy.
Przyjęte rozwiązanie powoduje dwa zasadnicze problemy.
Pierwszym z nich jest krótki okres ważności klucza API. Konieczność jego wymiany co sześć miesięcy nakłada na jednostki obowiązek stałego monitorowania terminów, ponownego generowania kluczy oraz aktualizowania ich w systemach finansowo-księgowych, systemach elektronicznego zarządzania dokumentacją i innych systemach dziedzinowych.
Każda taka operacja wiąże się z ryzykiem błędu albo przerwania automatycznego przekazywania danych. Jest to szczególnie istotne w przypadku procesów, które powinny działać w sposób ciągły i możliwie bezobsługowy.
W Krajowym Systemie e-Faktur Ministerstwo Finansów przyjęło rozwiązanie znacznie lepiej dostosowane do integracji systemowej. Certyfikat KSeF służący do uwierzytelniania może zachowywać ważność przez okres do dwóch lat. Może on zostać wydany nie tylko osobie fizycznej, lecz również podmiotowi niebędącemu osobą fizyczną, po jego uwierzytelnieniu za pomocą kwalifikowanej pieczęci elektronicznej.
Brak jest przekonującego uzasadnienia, dlaczego poświadczenie wykorzystywane do integracji z CRU JSFP zachowuje ważność jedynie przez sześć miesięcy, skoro w innym systemie teleinformatycznym Ministerstwa Finansów dopuszczono dwuletni okres ważności certyfikatu.
Drugim, poważniejszym problemem jest przypisanie klucza API do konta konkretnego użytkownika posiadającego rolę „Publikującego”. W konsekwencji operacje wykonywane automatycznie przez system zewnętrzny są identyfikowane jako czynności użytkownika, który wygenerował klucz, niezależnie od tego, który pracownik faktycznie wprowadził, zatwierdził lub skierował dane do publikacji przy wykorzystaniu integracji systemu poprzez klucz API.
Rozwiązanie to nie odpowiada rzeczywistemu sposobowi działania systemów teleinformatycznych w urzędach.
Jeżeli z systemu finansowo-księgowego albo systemu EZD korzysta przykładowo czterdziestu pracowników uprawnionych do przygotowywania lub publikowania informacji o umowach, jednostka staje przed wyborem pomiędzy dwoma nieprawidłowymi wariantami.
Pierwszy wariant wymagałby, aby każdy pracownik wygenerował własny klucz API, a system urzędu przechowywał i obsługiwał kilkadziesiąt kluczy, kontrolował ich ważność, a służby informatyczne dokonywały ich wymiany co sześć miesięcy. W przypadku coraz częstszego powstawania Centrów Usług Wspólnych w zakresie obsługi informatycznej, gdzie jednostek obsługiwanych często jest kilkadziesiąt tworzy to ogrom problemów logistycznych, które są zupełnie niepotrzebne.
Drugi wariant polegałby na wykorzystywaniu przez cały system jednego klucza wygenerowanego przez wybranego pracownika. W takim przypadku wszystkie operacje byłyby formalnie przypisywane tej osobie i to na nim ciążyłaby cała odpowiedzialność, mimo że faktycznie inicjowali je różni użytkownicy systemu. W mojej ocenie jest to absolutnie niedopuszczalne, gdyż często za obsługę kluczy API i integracji odpowiada informatyk i często to on je generuje i to de facto na nim spoczywałaby cała odpowiedzialność za to co i jak jest publikowane, gdyż to on w CRUJSFP widnieje jako osoba dokonująca zapisu. Integracja system–system powinna być oparta na uwierzytelnieniu jednostki sektora finansów publicznych, a nie jednego z jej pracowników.
Rozwiązaniem mogłoby być zastosowanie modelu wzorowanego na mechanizmach certyfikatowych KSeF. Jednostka uwierzytelniałaby się za pomocą kwalifikowanej pieczęci elektronicznej, a następnie uzyskiwała certyfikat przeznaczony do współpracy jej systemu teleinformatycznego z CRU JSFP. Certyfikat byłby przypisany do jednostki albo wskazanego systemu, a nie do konkretnego pracownika. Podobnie działa system uwierzytelniania w zakresie e-Doręczeń czy ePUAP.
Dane identyfikujące osobę, która w systemie urzędu faktycznie wprowadziła, zatwierdziła lub skierowała informację do publikacji, powinny być przekazywane w strukturze logicznej żądania API. System CRU JSFP otrzymywałby wówczas jednocześnie:
- wiarygodne potwierdzenie, z jakiej jednostki i z którego uprawnionego systemu pochodzą dane;
- informację o pracowniku, który faktycznie zainicjował daną czynność;
- dane niezbędne do ustalenia czasu, rodzaju oraz zakresu wykonanej operacji.
Integralność całego komunikatu, w tym danych identyfikujących publikującego, byłaby zabezpieczona za pomocą certyfikatu podmiotowego wydanego na podstawie kwalifikowanej pieczęci elektronicznej jednostki, podobnie jak ma to miejsce w ramach integracji systemów z KSeF.
W związku z powyższym zwracam się do Pana Ministra z następującymi pytaniami:
Jakimi względami technicznymi, organizacyjnymi lub związanymi z bezpieczeństwem uzasadniono ustalenie sześciomiesięcznego okresu ważności klucza API CRU JSFP?
W jaki sposób - w przypadku korzystania z jednego systemu finansowo-księgowego lub EZD przez wielu pracowników - jednostka ma zapewnić zgodność pomiędzy użytkownikiem, który wygenerował klucz API, a osobą faktycznie inicjującą publikację? Czy Ministerstwo Finansów analizowało ryzyko przypisywania wszystkich operacji właścicielowi jednego klucza albo konieczności przechowywania i cyklicznej wymiany odrębnych kluczy kilkudziesięciu użytkowników?
Czy Ministerstwo Finansów planuje zastąpienie kluczy API przypisanych do poszczególnych użytkowników certyfikatem instytucjonalnym, wydawanym jednostce sektora finansów publicznych albo jej zarejestrowanemu systemowi teleinformatycznemu po uwierzytelnieniu jednostki za pomocą kwalifikowanej pieczęci elektronicznej, analogicznie do rozwiązania zastosowanego w KSeF? Jeżeli tak, w jakim terminie?
Podsekretarz stanu Jarosław Neneman
Odpowiedź wysoce rzeczowa – zawiera liczne dane twarde, kwoty, daty lub bezpośrednie odniesienie do zadanych pytań.
- Wymienia precyzyjne daty lub terminy (3)
- Resort odnosi się punkt po punkcie do pytań posła
Pełna treść wyekstrahowana z załącznika PDF (odpowiedź urzędowa)
5540 znakówfax: +48 22 694 36 84 00-916 Warszawa
gov.pl/finanse
e-mail: kancelaria@mf.gov.pl
1/3
Warszawa, 17 sierpnia 2026 roku
Sprawa: Interpelacja nr 18879 posłów: Łukasza Osmalaka, Adama
Lubońskiego, Ewy Schädler , Wiolety Tomczak w sprawie
uruchomienia Centralnego Rejestru Umów Jednostek Sektora
Finansów Publicznych (CRU JSFP) oraz obowiązku udostępnienia w
nim informacji o umowach zawieranych od dnia 1 lipca 2026 r.
Znak sprawy: BZP4.054.2.2026
Kontakt: Kancelaria MF
tel.: +48 22 694 55 55
e-mail: kancelaria@mf.gov.pl
Pan
Włodzimierz Czarzasty
Marszałek Sejmu
Rzeczypospolitej Polskiej
Szanowny Panie Marszałku,
odpowiadając na interpelację numer 18879 Posłów na Sejm Rzeczypospolitej
Polskiej: Łukasza Osmalaka, Adama Lubońskiego, Ewy Schädler i Wiolety
Tomczak, w sprawie uruchomienia Centralnego Rejestru Umów Jednostek Sektora
Finansów Publicznych (CRU JSFP) oraz obowiązku udostępnienia w nim informacji
o umowach zawieranych od dnia 1 lipca 2026 r., Minister Finansów i Gospodarki
uprzejmie informuje, co następuje.
1. Jakimi względami technicznymi, organizacyjnymi lub związanymi z
bezpieczeństwem uzasadniono ustalenie sześciomiesięcznego okresu ważności
klucza API CRU JSFP?
Ustalony w ramach systemu CRU JSFP termin ważności klucza API CRU JSFP
podyktowany jest koniecznością zapewnienia wysokiego poziomu
cyberbezpieczeństwa oraz wynika z dobrych praktyk związanych z zapewnieniem
bezpieczeństwa.
Decyzja ta opiera się na trzech filarach:
-- 1 of 3 --
2/3
1. Zasada rotacji kluczy (Key Rotation): Regularna wymiana kluczy (co 6
miesięcy) jest fundamentalnym mechanizmem bezpieczeństwa. Zmniejsza
ona ryzyko długotrwałej eksploatacji skompromitowanych poświadczeń.
W przypadku potencjalnego wycieku klucza, ograniczony czas jego
ważności drastycznie zawęża okno czasowe dla atakującego, minimalizując
potencjalne szkody.
2. Zgodność ze standardami bezpieczeństwa: Podejście to jest spójne z
wytycznymi organizacji takich jak NIST (National Institute of Standards and
Technology) oraz OWASP, które rekomendują okresową rotację tajnych
kluczy i certyfikatów. Jest to również odpowiedź na globalny trend
skracania okresów ważności w infrastrukturze krytycznej (np. redukcja
ważności certyfikatów https://cabforum.org/2025/04/11/ballot-sc081v3-
introduce-schedule-of-reducing-validity-and-data-reuse-periods/ ), co w
przypadku kluczy API o wysokich uprawnieniach uzasadnia jeszcze krótszy
cykl życia.
3. Aspekty organizacyjne i audytowe: Sześciomiesięczny cykl wymusza
regularny przegląd procesów integracyjnych przez zespoły techniczne.
Zapobiega to utrzymaniu "martwych" lub niepotwierdzonych połączeń
w systemie i zapewnia, że wszystkie integracje są aktywnie monitorowane
i zgodne z aktualną polityką bezpieczeństwa instytucji.
W sektorze IT zauważalna jest tendencja do skracania terminów ważności narzędzi
związanych z komunikacją między systemami.
2. W jaki sposób – w przypadku korzystania z jednego systemu finansowo
księgowego lub EZD przez wielu pracowników – jednostka ma zapewnić
zgodność pomiędzy użytkownikiem, który wygenerował klucz API, a osobą
faktycznie inicjującą publikację? Czy Ministerstwo Finansów analizowało ryzyko
przypisywania wszystkich operacji właścicielowi jednego klucza albo
konieczności przechowywania i cyklicznej wymiany odrębnych kluczy
kilkudziesięciu użytkowników?
Korzystanie z przesyłania informacji o umowach za pośrednictwem API jest
efektem decyzji podejmowanych przez kierowników jsfp. Korzystanie z tego
narzędzia zakłada, że znaczna większość obowiązku dotyczącego CRU JSFP
realizowana jest poza systemem CRU JSFP. W ramach systemu CRU JSFP
realizowana jest wyłącznie czynność techniczna związana z udostępnianiem
publicznym w tym narzędziu informacji o umowach.
Rozwiązanie takie zostało przyjęte m.in. w ministerstwie. Rozliczalność
odpowiedzialności jest zapewniona w ramach systemu zintegrowanego z CRU
JSFP. Zostało to umocowane w regulacjach wewnętrznych. Dlatego nie jest
konieczne zapewnianie takiej rozliczalności również w ramach systemu CRU JSFP.
Działanie takie bowiem podważałoby sens integracji systemów.
A zatem to w systemie, który został zintegrowany z CRU JSFP należy zapewnić
taką realizację zadań, która zniweluje ewentualne wątpliwości pracowników. Z
-- 2 of 3 --
3/3
punktu widzenia realizacji obowiązku CRU JSFP, nie ma znaczenia czy wszystkie
operacje będą zapisane pod danymi jednego użytkownika. Każdy użytkownik
systemu CRU JSFP działa w imieniu i na rzecz kierownika jsfp. Odpowiedzialność
za prawidłową organizację wykonywania tego obowiązku ponosi kierownik jsfp.
3. Czy Ministerstwo Finansów planuje zastąpienie kluczy API przypisanych do
poszczególnych użytkowników certyfikatem instytucjonalnym, wydawanym
jednostce sektora finansów publicznych albo jej zarejestrowanemu systemowi
teleinformatycznemu po uwierzytelnieniu jednostki za pomocą kwalifikowanej
pieczęci elektronicznej, analogicznie do rozwiązania zastosowanego w KSeF?
Jeżeli tak, w jakim terminie?
Na obecnym etapie nie planujemy zastąpienia klucza API certyfikatem
instytucjonalnym. Rozwiązanie takie wydaje się nie być właściwe w przypadku CRU
JSFP. Warto bowiem zauważyć, że obowiązek CRU JSFP jest powiązany z realizacją
zadania publicznego. Obowiązek ten został nałożony na kierownika jsfp, a nie na
jednostki. Jest to kluczowa różnica w stosunku m.in. do obowiązku występującego
w ramach KSeF.
Z wyrazami szacunku
Z upoważnienia Ministra Finansów i Gospodarki
Jarosław Neneman
Podsekretarz Stanu
w Ministerstwie Finansów
-- 3 of 3 --