W banku każda operacja, od zalogowania klienta po zmianę limitu przez pracownika, zaczyna się od jednego pytania: kto naprawdę jest po drugiej stronie i do czego ma prawo. To dlatego zarządzanie tożsamością i uwierzytelnianie przestało być warstwą „logowania”, a stało się fundamentem, na którym opiera się reszta zabezpieczeń. Dla dyrektora bezpieczeństwa oznacza to, że IAM w bankowości jest tematem zarządu, a nie tylko działu IT.
Z naszego doświadczenia najtrudniejsze nie jest samo postawienie narzędzia IAM, tylko wpięcie go w dziesiątki istniejących systemów banku bez przerywania usług i bez luk w audycie. Dlatego do takich projektów podchodzimy jak do rozwoju krytycznego oprogramowania, z zespołem, który rozumie zarówno bezpieczeństwo, jak i realia bankowej architektury. Właśnie taki zespół rozwija od 2017 roku systemy, w tym systemy bezpieczeństwa oraz platformy cyfrowe globalnego banku private banking.
Dlaczego tożsamość i uwierzytelnianie to rdzeń bezpieczeństwa banku?
Bo niemal każdy poważny incydent zaczyna się od przejętej tożsamości, a nie od złamanego szyfrowania. Jeśli ktoś podszyje się pod klienta lub pracownika, reszta zabezpieczeń działa już na jego korzyść. Dobrze zaprojektowana tożsamość zawęża to, co atakujący może zrobić nawet po przejęciu jednego konta.
Dla banku stawką jest tu nie tylko strata finansowa, ale też zaufanie klientów i rozliczenie przed regulatorem. Dlatego traktujemy tożsamość jako warstwę, która musi być jednocześnie szczelna, odtwarzalna w audycie i znośna w codziennym użyciu.
Czym jest zarządzanie tożsamością (IAM) w banku?
Najprościej: IAM odpowiada na pytania, kto, do czego i na jakich zasadach ma dostęp, przez cały cykl życia konta. To nie jedno narzędzie, tylko spójny zestaw procesów i mechanizmów. W praktyce składa się na niego kilka obszarów:
- tożsamość klienta (CIAM), czyli rejestracja, logowanie i odzyskiwanie dostępu w kanałach cyfrowych,
- tożsamość pracownika i partnera, od pierwszego dnia pracy po odebranie uprawnień przy odejściu,
- zarządzanie uprawnieniami i rolami, które mówi, co dana osoba może zrobić w systemie,
- tożsamości techniczne, czyli konta usług, API i integracji, często najbardziej zaniedbane.
Spinamy te obszary tak, żeby tworzyły jedną, spójną historię dostępu, a nie zbiór odrębnych wysp logowania w każdym systemie z osobna.
Czym jest silne uwierzytelnianie (SCA, MFA) i czego wymaga PSD2?
Silne uwierzytelnianie opiera się na połączeniu co najmniej dwóch niezależnych czynników z różnych kategorii: coś, co użytkownik wie (hasło, PIN), coś, co ma (telefon, token), i coś, czym jest (biometria). To właśnie kryje się pod skrótami MFA (uwierzytelnianie wieloskładnikowe) i SCA (silne uwierzytelnianie klienta).
W Europie nie jest to już kwestia dobrej woli. Dyrektywa PSD2 nakłada na banki obowiązek SCA przy logowaniu do konta online i przy inicjowaniu płatności, z pewnymi wyjątkami dla transakcji niskiego ryzyka. Projektujemy mechanizmy tak, by spełniały ten wymóg, a jednocześnie nie zamieniały każdej operacji w tor przeszkód. Kluczowe jest tu dynamiczne powiązanie uwierzytelnienia z konkretną kwotą i odbiorcą płatności, bo to ono realnie utrudnia podmianę transakcji.
Jak zarządzać dostępem i uprawnieniami w banku?
Tu najczęściej kryje się największe ryzyko, bo uprawnienia mają tendencję do „puchnięcia” z czasem. Pracownik zmienia dział, dostaje nowe role, a stare zostają. Porządkujemy to, opierając dostęp na jasnych zasadach:
- najmniejszy potrzebny zakres uprawnień zamiast dostępu „na wszelki wypadek”,
- role i grupy powiązane ze stanowiskiem, nie z pojedynczą osobą,
- rozdział obowiązków, by jedna osoba nie kontrolowała całego wrażliwego procesu,
- regularne przeglądy i recertyfikacja dostępu, z automatycznym wygaszaniem tego, co nieużywane.
Dokładamy do tego podwyższoną kontrolę dla kont uprzywilejowanych (administratorzy, konta serwisowe), bo to one są najcenniejszym celem. Dzięki temu nawet udane włamanie na jedno konto nie otwiera atakującemu całego banku.
Jak wpiąć IAM w istniejące systemy banku?
To zwykle najtrudniejsza, a przy tym najmniej widoczna część projektu. Bank nie startuje od zera, tylko ma systemy rdzeniowe, bankowość internetową, aplikacje mobilne i dziesiątki aplikacji wewnętrznych, często z własnymi mechanizmami logowania. Naszym celem jest pojedynczy, spójny punkt prawdy o tożsamości, do którego te systemy się podłączają.
Spinamy je nowoczesnymi standardami, takimi jak OAuth 2.0, OpenID Connect czy SAML, i wprowadzamy pojedyncze logowanie (SSO) tam, gdzie ma to sens. Starsze aplikacje, które nie mówią tym językiem, obejmujemy warstwami pośrednimi, zamiast je od razu przepisywać. Dzięki temu migracja jest stopniowa i odwracalna, a nie ryzykownym przełączeniem wszystkiego w jeden weekend.
Jak zapewnić zgodność i audyt w obszarze tożsamości?
Dla banku samo bezpieczeństwo to za mało, trzeba jeszcze umieć je udowodnić. Dlatego od początku projektujemy pod audyt, a nie dokładamy logowania zdarzeń na końcu. W praktyce oznacza to pełną, niezaprzeczalną ścieżkę audytową, która pokazuje, kto, kiedy i do czego uzyskał dostęp oraz kto mu to przyznał.
Mapujemy mechanizmy na konkretne wymogi, od PSD2 i wytycznych nadzorczych po wewnętrzne polityki banku, tak by w razie kontroli odpowiedź była kwestią raportu, a nie tygodni grzebania w logach. Przy danych osobowych trzymamy się zasad minimalizacji i rozliczalności.
Jakie kompetencje dostarczamy do projektu IAM?
Dobieramy skład pod konkretny etap i architekturę, a nie „na zapas”. W projektach wokół tożsamości i bezpieczeństwa najczęściej obsadzamy role takie jak:
- architekt bezpieczeństwa / IAM, który wyznacza model tożsamości i uprawnień,
- inżynierowie integracji spinający IAM z systemami rdzeniowymi i kanałami cyfrowymi,
- programiści backendu budujący usługi uwierzytelniania, API i mechanizmy SCA,
- specjaliści DevOps i bezpieczeństwa odpowiadający za wdrożenia, hardening i monitoring.
Taki zespół potrafi przejąć odpowiedzialność za cały obszar, od projektu po utrzymanie, albo wzmocnić zespół banku dokładnie tam, gdzie brakuje rąk lub wiedzy.
Jak robimy to w RITS?
Robimy to jako partner nearshore z Polski, z realnym doświadczeniem w pracy przy krytycznych systemach banku. Dla wiodącej globalnej instytucji private banking i asset management rozwijamy od 2017 roku systemy bezpieczeństwa oraz systemy wewnętrzne i platformy cyfrowe, a nasz zaangażowany zespół urósł do blisko 90 specjalistów. Zarządzanie tożsamością i silne uwierzytelnianie traktujemy jako jeden z obszarów w ramach tej kompetencji bezpieczeństwa, a nie jako oderwane narzędzie.
Na tych projektach stawiamy na kilka rzeczy: weryfikujemy kompetencje przed startem, pracujemy w zbliżonej strefie czasowej, więc wchodzimy w przeglądy kodu i spotkania bez długiego rozruchu, i rozwijamy rozwiązania z myślą o audycie od pierwszego dnia. Najczęściej robimy to jako dedykowane oprogramowanie budowane przez nasz zespół, a tam gdzie bank potrzebuje szybko uzupełnić kompetencje, w modelu wzmocnienia zespołu.
Od czego zacząć wdrożenie IAM i silnego uwierzytelniania?
Zacznij od uczciwej inwentaryzacji: jakie tożsamości, systemy i sposoby logowania masz dziś, i gdzie są największe luki wobec PSD2 oraz wewnętrznych polityk. Potem wybierz jeden kanał lub jeden proces o wysokim ryzyku (na przykład logowanie i płatności w bankowości internetowej) i na nim pokaż docelowy model, zamiast przebudowywać wszystko naraz. To wyznaczy architekturę, standardy i role, których potrzebujesz. Różnice między modelami współpracy opisaliśmy w artykule o modelach współpracy IT.
Wdrażasz lub porządkujesz IAM i silne uwierzytelnianie w banku? Porozmawiajmy, dobierzemy zespół i architekturę pod Twoje środowisko i wymogi regulacyjne.