Praktyka
Cyberbezpieczeństwo i tożsamość cyfrowa
Bezpieczeństwo rzadko przegrywa na braku narzędzi, częściej na granicach, których nikt nie narysował. Projektujemy tożsamość i kontrolę dostępu jako element architektury systemu, nie jako warstwę dokładaną na końcu.
Jak na to patrzymy
Pytanie o to, czy mamy uwierzytelnianie, jest mniej istotne niż pytanie, gdzie przebiega granica zaufania i co się dzieje, gdy klient jest niezaufany. Systemy, które projektujemy, zakładają, że wszystko po stronie użytkownika może być sfałszowane, dlatego serwer odtwarza i waliduje operacje własnym silnikiem, zamiast przyjmować wynik na słowo. Ta sama logika obejmuje dostawcę modelu językowego: dane osobowe są redagowane, zanim opuszczą organizację. I obejmuje nas samych: kontrola, której nie wymusza baza danych albo pipeline, jest tylko dobrą intencją.
Co zbudowaliśmy
Napisaliśmy własne rozszerzenia SPI dla Keycloak 26, authenticator i credential provider dla logowania podpisem kryptograficznym w standardzie EIP-191, z jednorazowym nonce o ograniczonym czasie życia przeciw atakom powtórzeniowym, OTP jako drugim czynnikiem i passkeys na webauthn4j; drugi, niezależny system ma osobne SPI, więc to metoda pracy, nie jednorazowy wyczyn. W aplikacjach mobilnych: Authorization Code z PKCE S256 i magazyn kluczy systemu. W systemach wielodostępnych izolację wymusza baza, Row-Level Security i kontrola atrybutowa per podmiot, a ślad audytowy jest łańcuchem haszy SHA-256 w tabeli tylko do dopisywania, z triggerem blokującym modyfikację i usunięcie; ten wzorzec działa u nas w trzech systemach. Każdy upload przechodzi skan antywirusowy w trybie fail-closed i białą listę typów. W CI: skan zależności, analiza statyczna, SBOM w formacie CycloneDX i podpisy artefaktów. W publicznej arenie gier serwer odtwarza każdą rankingową rozgrywkę własnym silnikiem i odrzuca nielegalne ruchy oraz niemożliwe czasy, a to, że klucz API użytkownika nie opuszcza przeglądarki, jest pilnowane testem. Granice bywają też fizyczne: jeden z produktów ma dedykowaną instancję serwera tożsamości i odizolowaną sieć, żeby dwa systemy nie widziały nawzajem swoich zasobów nawet po błędzie w konfiguracji.
Co z tego wynika
Kontrola dostępu wraca z rozproszenia po kodzie aplikacji do miejsc, które da się audytować: dostawcy tożsamości, bazy danych, pipeline. Zmiana polityki bezpieczeństwa staje się zmianą konfiguracji, a nie przeglądem kilkunastu repozytoriów. A gdy audytor pyta o ślad, ślad istnieje i nie dało się go poprawić po fakcie.