RBAC właśnie w tym momencie platforma zaczyna się zwracać. W wielodostępnej platformie bankowej dostęp nie może być nieograniczony tylko dlatego, że pracownik jest “wewnętrzny”. Każdy użytkownik potrzebuje własnej matrycy uprawnień. Akceptant, który korzysta wyłącznie z inicjowania płatności, nie powinien mieć dostępu do narzędzi KYC. Pracownik wsparcia technicznego w jednym regionie nie powinien mieć wglądu w ustawienia kart dla innego regionu. Proces, który wymaga jedynie wyjaśnienia salda, nie powinien obejmować przygotowywania przelewów.
Walidacja schematu to kolejny filtr. Brama powinna sprawdzać każde żądanie pod kątem zgodności z zatwierdzonymi specyfikacjami OpenAPI lub równoważnymi umowami. Pozwala to wychwycić nieprawidłowe dane: niewłaściwy format waluty, brak identyfikatora odbiorcy, nieobsługiwany kanał płatności, niemożliwy zakres dat, nieprawidłowo sformułowane żądanie dotyczące statusu KYC. Model może być poprawny, a mimo to generować dane, które system powinien odrzucić.
Procesy zatwierdzania to właśnie tam model bez nadzoru nabiera konkretnego kształtu. Agent może przygotować działanie, ale operacje wysokiego ryzyka wymagają umieszczenia w kolejce – na przykład w przypadku przekroczenia progów kwotowych, nowych beneficjentów, podejrzanego stanu konta, niekompletnej weryfikacji tożsamości (KYC), wzmożonych sygnałów oszustwa lub zasad specyficznych dla danego najemcy. Brama powinna utworzyć pozycję do zatwierdzenia, powiadomić osobę zatwierdzającą, monitorować reguły dotyczące limitów czasowych oraz zwrócić użytkownikowi lub operatorowi jasny status.
Rejestrowanie audytowe musi zostać uwzględnione w ścieżce. Dla każdego żądania brama powinna zapisywać rekord, do którego można dodawać tylko nowe dane. Rekord ten powinien zawierać informacje o dzierżawcy, użytkowniku, kanale, stanie przepływu pracy, narzędziu, parametrach po redakcji, wyniku walidacji, stanie zatwierdzenia, odpowiedzi z dalszego etapu oraz identyfikatorze korelacji. Zespoły ds. zgodności nie potrzebują pięknego zapisu. Potrzebują przejrzystego śladu, który wyjaśnia, dlaczego system zezwolił na daną akcję lub ją zablokował.
Warto od samego początku podkreślić jedną różnicę: dziennik potwierdza, co zostało wykonane, a nie kto miał uprawnienia do tego, by to zrealizować. Ślad może doskonale wykazać, że transfer został zrealizowany z A do B przy użyciu danego tokenu. Sam w sobie nie może jednak wykazać, że działanie zostało autoryzowane przez podmiot, którego obie strony uznają, ani że autoryzacja ta nie została wcześniej cofnięta. W przypadku przepływu danych w środowisku z jednym dzierżawcą luka ta jest niewidoczna, ponieważ dziennik i zapisy dotyczące uprawnień znajdują się w tym samym miejscu. W momencie, gdy spór dotyczy innego dzierżawcy lub kontrahenta, właśnie ta luka staje się głównym problemem. Dlatego zapis powinien uwzględniać uprawnienia: które upoważnienie zezwoliło na wywołanie, w jakim zakresie oraz czy w danym momencie było ono nadal ważne. Kwestię tę omówiłem bardziej szczegółowo w moim artykule Upoważnienie to nie to samo, co sprawowanie rządów.
Wyłączniki automatyczne ma to znaczenie, ponieważ dostawcy usług bankowych zawodzą w banalny sposób – na przykład poprzez przekroczenie limitów czasu, częściowe awarie, powolne odpowiedzi, nieaktualne informacje o statusie oraz ograniczenia szybkości. Bramka powinna wykrywać ten schemat, ponawiać próbę z zachowaniem odstępu czasowego, gdy jest to bezpieczne, zaprzestać powtarzania wywołań, gdy nie jest to bezpieczne, oraz zaproponować użytkownikowi użyteczną alternatywę. Komunikat “Dostawca usług AML jest niedostępny, spróbuj ponownie później” jest lepszym rozwiązaniem niż pozwolenie agentowi na pętlę prób, wymyślanie statusu lub nieustanne wysyłanie żądań do usługi o obniżonej jakości.
Zakres tokenów ogranicza zasięg skutków. Wywołanie narzędzia powinno otrzymywać minimalny zakres uprawnień niezbędny do realizacji konkretnego żądania, dla danego najemcy, użytkownika i stanu przepływu pracy. Krótkotrwałe tokeny o ograniczonym zakresie są znacznie bezpieczniejsze niż długotrwałe poświadczenia serwisowe krążące w warstwie agenta. Jeśli coś pójdzie nie tak, skutki nieudanego żądania powinny być ograniczone.
Zatrudnij nas
O nas