Interpelacja nr 18879 · Sejm X kadencji
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.
Autor: Adam Luboński (Polska2050) i 3 innych posłów. Wpłynęło do Sejmu 27 lipca 2026. Adresat: minister finansów i gospodarki. Odpowiedź w terminie, stan na 30 września 2026.
Sprawdź w Sejmie (rekord w API Sejmu) · pismo na sejm.gov.pl
Adresat i termin odpowiedzi
Adresat ma 21 dni od dnia, w którym dostał pismo od Marszałka Sejmu, i ten termin biegnie u każdego adresata osobno.
| Adresat | Doręczono | Termin | Stan |
|---|---|---|---|
| minister finansów i gospodarki | 29 lipca 2026 | 19 sierpnia 2026 | Odpowiedź 2 dni przed terminem |
Odpowiedzi
-
Odpowiedź z 17 sierpnia 2026, podpis: Podsekretarz stanu Jarosław Neneman
Treść interpelacji
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?
Podpisani posłowie
- Adam Luboński (Polska2050)
- Łukasz Osmalak (Polska2050)
- Ewa Schädler (Polska2050)
- Wioleta Tomczak (Polska2050)
Wszystkie interpelacje kadencji: spis od najnowszego. Pozostałe pisma autora: profil posła.
Metodologia
- Termin liczymy od doręczenia, osobno u każdego adresata. 21 dni biegnie od dnia, w którym Marszałek przekazał pismo adresatowi, a nie od wpływu do Sejmu. Stan liczymy na dzień danych, 30 września 2026.
- Prolongata nie jest odpowiedzią. Pismo liczymy jako odpowiedziane dopiero, gdy przyjdzie odpowiedź, która przedłużeniem terminu nie jest.
- Przy kilku adresatach rozstrzyga licznik Sejmu. Adresat, któremu Sejm dalej nalicza opóźnienie, nie odpowiedział, choćby pod pismem stały odpowiedzi innych. Zanim termin minie, licznik stoi na zerze u wszystkich, więc wtedy piszemy, że rejestr nie mówi, kto już odpisał.
- Treść pochodzi z rejestru Sejmu i jest oczyszczona z formatowania przy nocnym przebiegu. Treści odpowiedzi nie przechowujemy: link prowadzi do rekordu w API Sejmu.
- Źródłem jest API Sejmu RP. Każdą liczbę da się sprawdzić u źródła, a my nie interpretujemy rejestru. Tam, gdzie podejmujemy decyzję redakcyjną, piszemy o tym wprost.
- Coś się nie zgadza? Napisz przyciskiem „Zgłoś błąd” w nagłówku, sam wpisze adres tej strony. Pytania o cały serwis: najczęstsze pytania.