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.

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: