Jak zaczęła się praca nad usługą Zastrzeż PESEL i Rejestrem zastrzeżeń numerów PESEL?
– Usługę, dzięki której możemy zastrzec numer PESEL tak, jak inne produkty w COI, stworzyliśmy na zlecenie Ministerstwa Cyfryzacji. Już od początku mieliśmy wpływ na proces jej powstawania. Za bardzo wartościowy uważam czas konsultacji ustawodawcy z nami, jako wykonawcą, bo to właśnie dzięki niemu mogliśmy przedstawić naszą perspektywę, czasem związaną z UX, czasem z pewnymi ograniczeniami technologicznymi jeszcze na etapie projektu ustawy. Zanim trafiła ona na obrady sejmu. Mieliśmy więc możliwość zapoznania się z nią, przeprowadzenia konsultacji i wprowadzenia do niej istotnych z naszej perspektywy aspektów w zakresie koncepcji i realizacji zadania. Właśnie na tym etapie udało się wprowadzić między innymi to wymaganie, aby możliwość weryfikacji statusu zastrzeżenia była niezależna od dostępności rejestru PESEL.
Ustawa była także szeroko konsultowana z instytucjami, które zostały nią objęte.
– Największą z nich był Związek Banków Polskich, który koordynował etap konsultacji. One dały nam okazję do tego, żebyśmy wszyscy razem omówili różne przypadki czy odpowiedzieli na pytania pojawiające się w związku z usługą. To z kolei pozwoliło na to, że ustawa w ostatecznym kształcie mogła uwzględnić także przypadki brzegowe i odpowiedzieć na potrzeby instytucji finansowych tak, żeby proces weryfikacji zastrzeżenia numeru PESEL był możliwy i akceptowalny w zakresie ich działania.
Wspomniałeś o ograniczeniach technologicznych, które pojawiły się już na etapie pracy z projektem ustawy.
– Chodzi o ograniczenia związane głównie z czasem realizacji zadania narzuconym przez ustawę i z tym, jak bardzo dane rozwiązanie jest skomplikowane. Pewne wymagania funkcjonalne, które wynikają właśnie z ustawy mogą albo ułatwić pracę i później utrzymanie całego systemu albo być bardziej czasochłonne dla całego projektu i sprawić, że taki system dodatkowo może być potem trudniejszy, zarówno w utrzymaniu jak i w rozwijaniu. Na szczęście udało nam się wspólnie wypracować taki kompromis, dzięki któremu zmieściliśmy się w założonym budżecie i czasie realizacji.
Ile zespołów pracowało nad tą usługą?
– W pracach brały udział 4 główne zespoły. Pierwszy realizował zadania w zakresie serca rejestru, czyli mechaniki komponentu centralnego i API do integracji. Drugi zespół pracował nad zmianami w aplikacji Źródło, z której korzystają pracownicy urzędów. Dzięki nim obywatel może przyjść do urzędu i poprosić o zmianę statusu zastrzeżenia czy o wydruk z historii swoich zastrzeżeń. Trzeci zespół realizował prace po stronie aplikacji webowej mObywatel.gov.pl, gdzie mamy możliwość skorzystania z możliwości podglądu swoich danych dotyczących zastrzeżeń i wglądu do historii weryfikacji przez inne instytucje oraz oczywiście możemy zastrzec numer PESEL jak i cofnąć zastrzeżenie. Te same zadania były analogicznie realizowane przez czwarty zespół, który wprowadzał te możliwości do aplikacji mobilnej mObywatel, dzięki której zastrzeżemy PESEL za pomocą telefonu.
Taka usługa wymaga integracji wielu systemów i pracy wielu zespołów, żebyśmy mogli korzystać z niej w zaledwie kilka sekund.
– Tak. Może się wydawać, że Zastrzeż PESEL i Rejestr zastrzeżeń numerów PESEL to bardzo prosty system, w którym mamy numer PESEL, jakąś osobę i przypisany do niej atrybut, który informuje nas o tym, czy ten PESEL jest zastrzeżony czy nie i umożliwia weryfikowanie jego statusu przez instytucje. Natomiast trzeba pamiętać także o tym, że w tym projekcie mieliśmy dodatkowe wymagania Ministerstwa Cyfryzacji, takie jak to, żeby obywatel mógł cofnąć zastrzeżenie numeru PESEL z automatyczną możliwością ustawienia ponownego zastrzeżenia. Co w praktyce oznacza, że możemy cofnąć zastrzeżenie, a potem automatycznie ustawić sobie konkretną datę i godzinę ponownego zastrzeżenia. Drugi ważny aspekt, o który musieliśmy zadbać, to silna rozliczalność, czyli to, żeby obywatel miał dostęp do informacji, które instytucje sprawdzały status jego numeru PESEL i jakie informacje na ten temat uzyskały. Skupiliśmy się tutaj również na tym, żeby powiadomienia dotyczące weryfikacji statusu PESEL trafiały także do tych osób, których nie ma w rejestrze zastrzeżeń, ale które mają zainstalowaną aplikację mObywatel lub dodały swoje dane kontaktowe takie jak numer telefonu czy adres e-mail do Rejestru Danych Kontaktowych (RDK). W takiej sytuacji, jeśli dodaliśmy swój numer telefonu do RDK i jakaś instytucja sprawdzi status naszego numer PESEL, mimo że nie byliśmy nigdy w Rejestrze zastrzeżeń, to i tak dostaniemy powiadomienie o tym, kto i kiedy to robił. Mamy więc system szybkiego reagowania, dzięki któremu obywatel zyskuje bezpieczeństwo, które było dla nas najważniejszym czynnikiem podczas projektowania tych usług.
I o tym bezpieczeństwie trzeba było pamiętać na każdym etapie ich tworzenia, podczas wielu wdrożeń. Zastosowaliście liczne rozwiązania, aby móc choćby przeprowadzić bezproblemową integrację instytucji z systemem.
– Kluczową datą dla nas był 1 czerwca 2024, bo właśnie od początku czerwca instytucje finansowe mają obowiązek sprawdzać status PESEL przed udzieleniem np. kredytu. W grudniu 2023 roku uruchomiliśmy rejestr zastrzeżeń numerów PESEL tak, aby obywatele mogli już wcześniej zastrzec swój numer PESEL.
Takie zastrzeżenie nie miało wówczas jeszcze mocy prawnej.
– Zgadza się, ale ten zabieg służył po pierwsze temu, aby rozłożyć w czasie możliwość skorzystania z usługi i zminimalizować tym samym ryzyko obciążenia systemu. Po drugie, żeby spopularyzować usługę wśród obywateli tak, aby mieli oni pół roku na to, by się z tematem zapoznać. Żeby wiedzieli, że istnieje coś takiego jak Rejestr zastrzeżeń numerów PESEL i że można zastrzec numer PESEL z wyprzedzeniem, jeszcze przed 1 czerwca. Cały ten czas ściśle współpracowaliśmy z instytucjami, które podłączały się do naszego API. Dzięki temu mogliśmy nie tylko na bieżąco udoskonalać API, ale także tworzyć wysokiej jakości szczegółową dokumentację dla nich. Podczas przygotowywania API wybraliśmy podejście Consumer Driven Contract (CDC) i użyliśmy biblioteki https://github.com/spring-cloud/spring-cloud-contract. Ciekawostką jest to, że w ramach framework’a Spring Cloud biblioteka ta jest rozwijana i utrzymywana przez naszych rodaków, Marcina Grzejszczaka i Olgę Maciaszek: https://github.com/marcingrzejszczak i https://github.com/OlgaMaciaszek, których pozdrawiamy. Dzięki niej zostały wygenerowane “zaślepki” usług, które udostępniliśmy integratorom, zanim jeszcze środowisko integracyjne było gotowe, co umożliwiło szybkie rozpoczęcie prac po stronie instytucji. Przygotowaliśmy także testy automatyczne, generujące przykłady żądań i odpowiedzi API, które następnie były umieszczane w automatycznie generowanej dokumentacji. Takie podejście zagwarantowało nam spójność dokumentacji z implementacją usługi, łatwiejszą integrację nowych instytucji oraz ograniczenie pracy po naszej stronie, bo instytucji, które zintegrowały się z API w ramach usługi było około 10.000.
A jak zbudowaliście sam Rejestr zastrzeżeń numerów PESEL?
– Przy pomocy frameworka Spring Boot 3.2.x. To jedna z pierwszych aplikacji w COI oparta o java 21 z użyciem wirtualnych wątków. Dzięki temu przy mniejszym zużyciu zasobów udało się osiągnąć większą przepustowość operacji. System został rozbity na dwa mikroserwisy, czyli obsługujący zapytania o weryfikację statusu zastrzeżenia – API dostępne z internetu oraz drugi, który obsługuje zapytania w sieci wydzielonej. Jako komponentu uwierzytelniającego zapytania w sieci wydzielonej użyliśmy Keycloaka. Wykonaliśmy także integrację z dwoma systemami utrzymywanymi przez COI, czyli z aplikacją webową mobywatel.gov.pl oraz z aplikacją mobilną mObywatel 2.0.
Co było największym wyzwaniem, lekcją podczas powstawania tych usług?
– Tych lekcji było kilka w różnych obszarach. Pierwszy z nich to sprawna obsługa integratorów, co przy takiej ilości instytucji, czyli, jak już wspominałem, około 10.000 nie było proste. Dodatkowo wiele z nich składało wnioski o dostęp dopiero na dwa tygodnie przed wejściem w życie ustawy. Dlatego, podczas projektowania systemu zależało nam, aby proces integracji był jak najprostszy. Kolejnym wyzwaniem, któremu sprostaliśmy, była wydajność systemu. Według informacji, które zebraliśmy na etapie konsultacji z instytucjami, mieliśmy być gotowi na nawet 10 mln weryfikacji dziennie. W związku z tym zaprojektowaliśmy system w sposób, który umożliwia jego łatwe skalowanie. Podczas testów wydajnościowych na środowisku testowym osiągnęliśmy 2400 operacji na sekundę. Mimo udostępnienia usług weryfikacji przed 1 czerwca większość instytucji czekała na włączenie integracji na produkcji do 1 czerwca. To powodowało niepewność, jaka będzie skala ruchu.
Dlatego mimo, że 1 czerwca w tym roku wypadł w dzień wolny od pracy, Wasz zespół był w gotowości?
Przez cały weekend obserwowaliśmy metryki i byliśmy gotowi do ewentualnej reakcji. Na szczęście okazało się, że uruchomienie przebiegło bezpiecznie i bez problemów.
