HSK WEBKDModernizacja kontroli dostępu z bezpieczniejszym rdzeniem domenowym

WebKD działa w operacyjnej warstwie obiektu. Operatorzy pracują z serwerami RCP, kontrolerami i czytnikami TKD, posiadaczami PKD, kartami KAD, harmonogramami, sekwencjami, zdarzeniami, raportami czasu obecności, komunikatami, modułami DOD i pracą zdalną.

Modernizacja zaczyna się więc od mapy domeny, a nie od nowej skórki UI. System musi zachować sposób podejmowania decyzji dostępowych, przeliczania uprawnień, aktualizacji czytników i diagnozowania zdarzeń.

CloudFloo traktuje ten projekt jako oprogramowanie enterprise: wiele modułów, starsze ograniczenia, fizyczne urządzenia, dane operacyjne i ścieżka wdrożenia z wycofaniem zmian oraz kontrolą migracji.

Backend NestJS jest zorganizowany wokół jawnych modułów WebKD: RCP, TKD, PKD, KAD, Uprawnienia, Zdarzenia, Harmonogram, Sekwencja, Grupa, GLC, Kontrola, Komunikat, raporty, access control, licencje, monitoring, job status, kolejki i administracja.

Kontrola dostępu jest modelowana jako uprawnienia funkcjonalne i uprawnienia do danych. Operator może mieć dostęp do funkcji, ale jednocześnie być ograniczony do konkretnych grup, posiadaczy, czytników lub zakresów organizacyjnych.

OpenAPI, kontrolery, DTO, frontendowe klienty API i dokumentacja domenowa dają zespołowi wspólny kontrakt. Celem jest zmiana krytycznego zachowania przez kontrolowane wycinki, nie przez ukryte powiązania.

Runtime to więcej niż jeden proces webowy. Frontendy React i ingress API komunikują się z podami NestJS; backend używa TypeORM/Postgres, Redis query cache, kolejek Bull, adaptera Socket.IO Redis, logowania, throttlingu, guardów, interceptorów i endpointów health.

Komunikacja RCP może działać w backendzie albo przez dedykowany rcp-worker za flagą funkcji. To daje bezpieczną ścieżkę oddzielania komunikacji z urządzeniami od powierzchni API bez przepisywania wszystkiego naraz.

Lokalny development używa Dockera, manifestów Kubernetes, Skaffold, obrazów API-site/mock, Postgresa, Redisa i danych E2E, żeby środowisko deweloperskie było bliżej realnej topologii.

Ścieżka wdrożenia opiera się o Nx affected builds, GitHub Actions, obrazy kontenerowe, Helm i wartości dla każdego środowiska. Staging i produkcja mogą budować tylko zmienione części, uruchamiać testy, publikować obrazy i wdrażać przez chart.

Migracje bazy są bramkami wdrożenia. Helm uruchamia zadanie migracyjne, pody backendu czekają w init-containerze na sukces migracji, a skrypty wdrożeniowe czyszczą zablokowane zadania przed ponowieniem. To zapobiega sytuacji, w której zła migracja po cichu psuje produkcję.

System taki jak WebKD zbiera ryzyko, gdy wiedza żyje tylko w ludziach, starych założeniach lub rozproszonych ścieżkach kodu. Modernizacja zamienia tę wiedzę w moduły, kontrakty, testy, bramki wdrożenia i diagramy, które zespół może analizować.

Wartość nie polega na przepisywaniu dla samego przepisywania. Chodzi o mniej niewiadomych przed zmianą, bezpieczniejsze zachowanie uprawnień, powtarzalne środowiska, jasną odpowiedzialność za wdrożenie i lepszą ścieżkę dla DOD, pracy zdalnej, raportów, monitoringu oraz separacji RCP.