Podłączenie rejestru do Social Credit System rzadko polega na wpisaniu adresu REST API i odebraniu JSON-a. Chińska administracja łączy systemy budowane przez ponad trzy dekady: nowoczesne usługi sieciowe, wymianę tabel bazodanowych, pliki wsadowe, portale dostępne tylko z rządowej sieci, klucze USB z certyfikatem, aplikacje mobilne, terminale dziedzinowe i archiwa papierowe.

Już oficjalny opis National Credit Information Sharing Platform z 2016 roku wymieniał podgląd danych, wyszukiwanie, subskrypcje, pobieranie wsadowe i usługi interfejsowe.1 Każda metoda rozwiązuje inny problem. Zapytanie o jedną osobę wymaga małego opóźnienia i ścisłej autoryzacji. Synchronizacja miliona kar potrzebuje wydajnego transferu oraz mechanizmu wznawiania. Akta papierowe wymagają operatora, nie protokołu.

Najważniejsze pytanie nie brzmi zatem „czy jest API?”, lecz: kto może uzyskać jaki zakres, w jakim celu, jaką drogą i z jakim śladem audytowym.

Dostęp ma cztery warstwy

W rozmowach o integracji często miesza się cztery niezależne rzeczy.

Łączność

Określa, czy systemy w ogóle mogą się zobaczyć. Usługa może działać w publicznym Internecie, National E-Government Extranet, sieci resortowej, wydzielonej strefie centrum danych albo środowisku tajnym bez bezpośredniego połączenia.

Uwierzytelnienie

Odpowiada na pytanie, kto lub co nawiązuje sesję. Stosuje się konto operatora, certyfikat osobisty, certyfikat instytucji, certyfikat urządzenia, klucz API, wzajemny TLS lub fizyczny token.

Autoryzacja

Ustala, jakie operacje wolno wykonać. Ten sam urzędnik może sprawdzić jedną osobę w prowadzonej sprawie, ale nie pobrać całej populacji. System może mieć prawo do automatycznej odpowiedzi licencja ważna, lecz nie do odczytu załączników.

Podstawa i cel

Technicznie poprawne zapytanie może być bezprawne. Wniosek o dostęp powinien określać zadanie, zakres, okres, odbiorców i sposób dalszego użycia. Chińskie rozporządzenie o współdzieleniu danych administracyjnych z 2025 roku formalizuje te elementy oraz zakazuje samowolnego rozszerzania celu.2

Bez rozdzielenia warstw administrator może uznać, że użytkownik z poprawnym USBKey ma prawo do wszystkiego, co pokaże mu ekran. To błąd projektu, nie tylko błąd operatora.

Trzy sieci: Internet,政务外网 i 政务内网

Publiczny Internet

Portale Credit China i część lokalnych usług udostępniają jawne informacje osobom oraz firmom. Publiczność danych nie oznacza dowolności masowego pobierania. Portal może ograniczać częstotliwość, wymagać CAPTCHA albo pokazywać węższy zakres niż interfejs między urzędami.

Aplikacje mobilne do punktów miejskich również korzystają z Internetu, lecz ich backend łączy się z chronionymi usługami przez bramy. Telefon obywatela nie otrzymuje bezpośredniego dostępu do platformy urzędowej.

National E-Government Extranet

政务外网 jest państwową siecią administracyjną dla systemów innych niż tajne. Nazwa extranet bywa myląca dla Europejczyka: nie oznacza zwykłego publicznego hostingu. Sieć łączy urzędy centralne, prowincje, miasta i powiaty, zapewniając kontrolowaną przestrzeń dla platform współdzielenia.

W 2015 roku oficjalne dane mówiły o połączeniu 118 jednostek centralnych i około 144 tysięcy jednostek lokalnych oraz o ponad 5000 aplikacji lokalnych działających na tej infrastrukturze.3 Później sieć stała się podstawą krajowej wymiany danych, usług administracyjnych i NCISP.

Adres widoczny tylko z政务外网 nie jest „stroną bez API” w sensie braku cyfryzacji. Może być aplikacją webową o wysokiej funkcjonalności, ale przeznaczoną dla operatora w określonej domenie bezpieczeństwa.

National E-Government Intranet

政务内网 obsługuje dane tajne i systemy o wyższym poziomie ochrony. Dokument z 2022 roku przewiduje kontrolowane kanały importu danych z extranetu do intranetu oraz eksportu informacji odtajnionych w drugą stronę.4

Nie jest to normalny routing IP. Na granicy mogą działać bramy, transfer jednokierunkowy, kontrola plików i proces zatwierdzenia. Integracja „w czasie rzeczywistym” bywa niemożliwa z założenia, bo bezpieczeństwo wymaga bufora oraz weryfikacji.

API do pojedynczego zapytania

Interfejs synchroniczny służy wtedy, gdy aplikacja potrzebuje aktualnej odpowiedzi przed wykonaniem czynności. Typowe operacje to:

  • sprawdzenie, czy CitizenID i nazwisko są zgodne;
  • potwierdzenie, że licencja istnieje i nie wygasła;
  • sprawdzenie aktywnego wpisu na liście;
  • pobranie bieżącego statusu firmy po USCC;
  • uzyskanie wyniku uprawnienia bez pełnych danych źródłowych.

Oficjalny przewodnik usług administracyjnych wymienia dokładne dopasowanie zwracające pojedynczy rekord oraz filtrowane pobieranie zmian. Współczesna platforma rejestruje usługę, zatwierdza ją, opakowuje i udostępnia odbiorcy dopiero po autoryzacji.5

API jest najlepsze dla świeżości i minimalizacji danych, ale tworzy zależność od dostępności źródła. System decyzyjny musi wiedzieć, co zrobić przy przekroczeniu czasu: odmówić, pozwolić warunkowo czy skierować sprawę do człowieka. Brak odpowiedzi nie może być automatycznie utożsamiany z negatywnym wynikiem.

Web Service i współczesne REST

Wiele starszych integracji administracyjnych korzysta z SOAP/Web Service, plików XML i kontraktów WSDL. Oficjalne wytyczne z 2016 roku wprost wymieniały Web Service jako jedną z trzech podstawowych metod wymiany obok tabel i plików.6

Nowsze systemy używają HTTP API, JSON, bram usług i OAuth-podobnych tokenów, ale styl protokołu nie przesądza o jakości. Dobrze opisany SOAP z podpisem, wersją schematu i idempotencją może być bezpieczniejszy niż nieudokumentowany REST zwracający dowolne pola.

Kluczowe są:

  • wersjonowany kontrakt;
  • jednoznaczne kody błędów;
  • identyfikator żądania;
  • ograniczenia zakresu i liczby rekordów;
  • podpis lub wzajemne uwierzytelnienie;
  • rejestrowanie odbiorcy oraz celu;
  • data stanu odpowiedzi.

Wymiana tabel przez serwer pośredni

Chińskie platformy powszechnie stosują front-end database, czyli bazę na serwerze pośrednim. Dostawca zapisuje dane do uzgodnionej tabeli. Platforma wymiany odczytuje je i umieszcza odpowiedzi lub potwierdzenia w innych tabelach.

Model wygląda następująco:

system urzędu → tabela nadawcza → platforma wymiany
system urzędu ← tabela odbiorcza ← platforma wymiany

Nie trzeba wpuszczać integratora do właściwej bazy transakcyjnej. Metoda dobrze obsługuje duże porcje danych i starsze aplikacje, które potrafią wykonywać SQL, ale nie wystawiać API. Lokalna specyfikacja dzielnicy Changning podaje, że taki model nadaje się do wymian liczonych w godzinach i dniach oraz wymaga uzgodnienia instancji, portu, tabel i uprawnień.7

Wady są poważne:

  • odbiorca może nie wiedzieć, czy eksport jest kompletny;
  • zmiana schematu łamie proces po cichu;
  • usunięcia trudno wyrazić bez osobnego znacznika;
  • konto bazodanowe bywa zbyt szerokie;
  • tabele pośrednie stają się trwałą, słabo zarządzaną kopią danych.

Bezpieczny wariant stosuje konto tylko do konkretnych tabel, szyfrowanie kanału, sumy kontrolne paczek, liczniki rekordów, batch_id, znacznik końca i kontrolę zgodności po obu stronach.

Pliki wsadowe

CSV, XML, JSON, arkusz lub skompresowane archiwum nadal są rozsądnym rozwiązaniem dla okresowych danych. Plik może trafić przez zarządzany transfer, kolejkę, bezpieczny katalog albo fizyczny nośnik.

Model wsadowy sprawdza się przy:

  • codziennej liście nowych kar;
  • miesięcznych raportach;
  • migracji historycznej;
  • danych z systemu bez możliwości modyfikacji;
  • przejściu przez granicę sieciową wymagającą inspekcji.

Każda paczka powinna mieć manifest: źródło, wersję schematu, zakres czasu, liczbę rekordów, hash, podpis, identyfikator poprzedniej paczki i informację, czy jest pełna czy przyrostowa. Nazwa export_final2.csv nie jest protokołem.

W 2025 roku nowe rozporządzenie nadal wymienia interfejs usługowy, wymianę wsadową i pobieranie plików jako równoprawne metody. Modernizacja nie oznacza, że wszystko musi stać się synchronicznym API.

Subskrypcja i strumień zdarzeń

Subskrypcja pozwala odbiorcy zapisać się na określone zmiany. Źródło lub platforma wysyła komunikat po wydaniu decyzji, zmianie statusu albo naprawie wpisu. Jest to model lepszy niż ciągłe odpytywanie całej bazy.

W starszych rozwiązaniach subskrypcja może generować plik lub wiadomość w kolejce. W nowszych — zdarzenie w Kafka albo RocketMQ. Niezależnie od technologii trzeba obsłużyć:

  • powtórne dostarczenie tego samego komunikatu;
  • zdarzenia przychodzące poza kolejnością;
  • brakujące fragmenty;
  • ponowienie po awarii;
  • cofnięcie i korektę;
  • odbudowę stanu od wskazanego punktu.

„Dokładnie raz” jest zwykle celem logiki biznesowej, nie gwarancją transportu. Konsument powinien zapisywać event_id i przetwarzać powtórzenie idempotentnie.

UI-only: dostęp tylko przez ekran

Niektóre rejestry pozwalają operatorowi zalogować się, wyszukać osobę i obejrzeć rekord, ale nie oferują zatwierdzonego interfejsu maszynowego. Przyczyny są różne:

  • system powstał jako narzędzie prowadzenia spraw, nie źródło integracji;
  • właściciel obawia się masowego eksportu;
  • licencja wykonawcy nie obejmuje API;
  • proces wymaga oceny dokumentu przez człowieka;
  • dane są zbyt wrażliwe dla automatycznego pobierania;
  • budżet nie przewidział przebudowy.

UI-only nie znaczy publiczny portal. Często aplikacja działa wyłącznie w rządowym extranecie, z białą listą stanowisk i certyfikatem. Przykład Fuzhou pokazuje urząd drukujący raport punktowy z wewnętrznej platformy, zanim jego własny system miał dostać automatyczne ostrzeżenia.

Automatyzacja przeglądarki lub RPA bywa kusząca, ale jest krucha i potrafi ominąć kontrolę przewidzianą dla człowieka. Jeśli ekran ogranicza wyniki do jednej osoby, robot eksportujący populację zmienia model ryzyka. Lepszym rozwiązaniem jest formalny interfejs albo kolejka wniosków.

Internal-UI-only: aplikacja i stanowisko

Jeszcze węższy wariant wymaga konkretnego terminala, segmentu sieci i zainstalowanego klienta. Dostęp może zależeć od:

  • adresu urządzenia i profilu stacji;
  • tunelu VPN;
  • certyfikatu komputera;
  • klienta zgodnego ze starą wersją systemu;
  • czytnika karty lub USBKey;
  • zalogowania do domeny urzędu;
  • zatwierdzenia przez przełożonego.

Taka aplikacja jest niewygodna, ale utrudnia użycie poświadczeń z prywatnego komputera. Problem pojawia się, gdy wspólne stanowisko lub wspólne konto niszczy rozliczalność. Bez imiennego uwierzytelnienia log pokaże „terminal 17”, nie człowieka, który wykonał zapytanie.

USBKey, karta inteligentna i token

W chińskiej administracji fizyczny klucz często przechowuje certyfikat X.509 i klucz prywatny. Użytkownik wkłada urządzenie, uruchamia sterownik, podaje PIN i podpisuje żądanie. Państwowe materiały kryptograficzne opisują USBKey jako nośnik certyfikatu do uwierzytelnienia oraz podpisu, a publiczna usługa SASAC wydaje klucze po weryfikacji dokumentów instytucji i operatora.8

Certyfikaty mogą reprezentować:

  • osobę;
  • stanowisko;
  • instytucję;
  • serwer lub inne urządzenie.

To rozróżnienie powinno znaleźć się w logach. Podpis instytucji dowodzi, że żądanie pochodzi z urzędu, ale nie zawsze wskazuje pracownika. Najsilniejszy model łączy certyfikat urządzenia, certyfikat użytkownika, PIN i kontekst sprawy.

Klucz fizyczny nie chroni przed nadużyciem przez uprawnionego operatora. Może za to zapewnić, że nie da się skopiować sekretu z pliku konfiguracyjnego, a podpisane działanie jest trudniejsze do wyparcia. Trzeba obsługiwać zgubienie, unieważnienie, rotację, zmianę pracownika i awaryjny dostęp.

Aplikacje mobilne

Aplikacje występują w trzech rolach. Obywatel sprawdza własny raport, udziela zgody lub używa miejskich korzyści. Inspektor terenowy skanuje dokument, rejestruje kontrolę i dołącza dowód. Kierownik zatwierdza operację albo odpowiada na alert.

Telefon jest wygodny i ryzykowny. Kamera, lokalizacja, pamięć podręczna oraz powiadomienia mogą ujawnić dane. Bezpieczna aplikacja używa zarządzanego urządzenia, uwierzytelnienia sprzętowego, krótkiego tokenu, szyfrowania i zdalnego wymazania. Powinna pobierać minimalny zakres, nie kopiować całych rejestrów „na wypadek braku zasięgu”.

Tryb offline wymaga jawnej polityki: jak długo dane pozostają na urządzeniu, które operacje wolno wykonać bez serwera i jak rozwiązać konflikt po synchronizacji.

Papier i dostęp pośredni

Najstarszy rejestr może istnieć tylko jako teczka. Dostęp oznacza wtedy formalny wniosek, odnalezienie dokumentu, sporządzenie kopii albo wpisanie danych przez operatora. Papier nie ma API, ale ma własne zabezpieczenia: sygnaturę, ewidencję wypożyczeń, pieczęć i podpis.

Digitalizacja powinna zachować tę proweniencję. Rekord utworzony z dokumentu potrzebuje:

  • identyfikatora archiwalnego;
  • obrazu źródłowego;
  • osoby przepisującej;
  • osoby zatwierdzającej;
  • daty odczytu;
  • poziomu pewności OCR;
  • historii poprawek.

Jeśli dokument jest niejednoznaczny, wynik nie może wyglądać jak informacja natywna z rejestru. System powinien odróżniać machine_verified, human_transcribed i unverified_extraction.

Model pull, push i query

Techniczne sposoby można uporządkować według kierunku.

Pull

Odbiorca cyklicznie pobiera zmiany. Jest prosty, ale obciąża źródło i zwiększa opóźnienie. Potrzebuje stabilnego kursora, nie wyłącznie filtra updated_at > last_run, ponieważ zegary i transakcje mogą się rozminąć.

Push

Źródło wysyła paczkę albo zdarzenie. Aktualizacja jest szybsza, lecz odbiorca musi przyjmować powtórzenia i sygnalizować braki.

Query

Odbiorca pyta dopiero w chwili potrzeby. Minimalizuje kopie i daje świeżą odpowiedź, ale każda decyzja zależy od dostępności usług.

Najlepszy system łączy metody. Lokalny indeks zawiera ograniczony status potrzebny do wyszukiwania, zapytanie źródłowe potwierdza go przed ważną decyzją, a subskrypcja szybko propaguje uchylenie.

Autoryzacja według roli i atrybutów

RBAC przyznaje uprawnienia rolom, na przykład „inspektor rynku” albo „operator sądowy”. ABAC dodaje warunki: region, rodzaj sprawy, czas, cel, klasę danych i relację operatora z podmiotem.

Przykładowa polityka może brzmieć:

permit if
  role = MARKET_INSPECTOR
  and case.status = OPEN
  and subject.region in operator.jurisdiction
  and requested_fields subset_of case.allowed_fields
  and device.trust_level >= MANAGED

Lista ról bez kontekstu skaluje się źle. Urzędnik z ogólnym prawem READ_PERSON może przeglądać rodzinę, sąsiadów i celebrytów. Powiązanie zapytania ze sprawą tworzy barierę i materiał do późniejszego audytu.

Zasada czterech oczu

Pobranie dużego eksportu, ujawnienie pełnego CitizenID lub rozwiązanie tokenu do osoby powinno wymagać drugiej zgody. Drugi operator sprawdza zakres i cel, a system podpisuje decyzję obu osób.

Nie należy wymagać dwóch kliknięć dla każdej rutynowej weryfikacji — wtedy kontrola zamienia się w dekorację. Zasada czterech oczu ma sens dla operacji o wysokiej sile rażenia: masowego eksportu, zmiany katalogu sankcji, dostępu do danych szczególnie wrażliwych oraz awaryjnego ominięcia polityki.

Audyt dostępu

Log powinien obejmować nie tylko logowanie, ale całą decyzję dostępową:

request_id, operator_id, institution_id, device_id
purpose, case_id, subject_id, fields, query_shape
policy_version, decision, approver_id
records_returned, export_size, timestamp, source

Szczególnie podejrzane są:

  • zapytania o osoby niezwiązane ze sprawami operatora;
  • dostęp poza normalnymi godzinami;
  • nagły wzrost liczby rekordów;
  • sekwencyjne przeglądanie CitizenID;
  • powtarzające się wyszukiwanie po słabych kryteriach;
  • eksport tuż przed odejściem pracownika;
  • użycie konta z nowego urządzenia lub regionu.

Logi powinny być append-only i wysyłane do oddzielnej domeny bezpieczeństwa. Administrator systemu źródłowego nie może usuwać śladu własnego nadużycia.

Co zmieniło rozporządzenie z 2025 roku

Regulacja nr 809 wprowadziła wspólną procedurę dla danych rządowych. Katalog określa dostępność i warunki. Dla danych bezwarunkowych urząd ma odpowiedzieć na wniosek w jeden dzień roboczy; dla warunkowych — zasadniczo w dziesięć. Po zgodzie dane mają zostać udostępnione w ciągu dwudziestu dni. Metodą może być interfejs, wymiana wsadowa albo plik.

Odbiorca musi wskazać podstawę, scenariusz, zakres, sposób i czas użycia. Nie wolno przekazać danych dalej ani zmienić celu bez zgody źródła. Rejestry wykorzystania powinny być przechowywane przez co najmniej trzy lata. Przewidziano także procedurę korekty i możliwość odebrania dostępu po nadużyciu.

To na szczęście przesuwa integrację z obszaru nieformalnych uzgodnień w stronę zarządzanej usługi. Nie usuwa starszych interfejsów, lecz nakłada na nie wspólny porządek.

Jaką metodę wybrać

Potrzeba Najlepszy punkt wyjścia Główne ryzyko
pojedyncza aktualna weryfikacja API/query niedostępność źródła
miliony zmian dziennie strumień zdarzeń duplikaty i kolejność
duży eksport okresowy podpisany plik lub tabela pośrednia niepełna paczka
wrażliwa sprawa wymagająca oceny UI z kontekstem sprawy nadużycie operatora
system bez możliwości modyfikacji adapter lub kontrolowane RPA kruchość i obejście limitów
papier transkrypcja z podwójną kontrolą pomyłka i utrata kontekstu
granica sieci tajnej kontrolowany transfer wsadowy opóźnienie i niespójność

Nie istnieje jedna technika najlepsza dla każdego rejestru. Zmuszenie całej administracji do synchronicznego REST może być równie nierozsądne jak pozostawienie wszystkiego w ręcznych portalach.

Lekcja dla Polski

Polski system projektowany od zera powinien być API-first, ale nie API-only. Już w fazie syntetycznej warto zasymulować pięć klas źródeł: nowoczesne API, strumień, plik wsadowy, portal operatora i dokument. Dzięki temu architektura uczy się prawdziwych ograniczeń przed podłączeniem rejestrów produkcyjnych.

Najważniejszym kontraktem nie jest format JSON. Jest nim związek między celem, tożsamością operatora, zakresem i logiem. Jeśli system potrafi odpowiedzieć, kto poznał fakt, dlaczego, z jakiego źródła i co zrobił dalej, można bezpiecznie zwiększać jego możliwości.

Chiny pokazują, że gigantyczna federacja może działać mimo mieszanki technologii. Pokazują też cenę wieloletnich kompromisów: ręczne ekrany, tabele pośrednie i urządzenia fizyczne pozostają obok chmury oraz streamingu. Polska ma szansę zacząć czyściej, lecz nadal musi umieć przyjąć dane z systemu, którego nie da się po prostu przepisać.