Jeżeli w Waszej firmie ktoś pyta, po co jeszcze stoi Microsoft Active Directory, odpowiedź zwykle sprowadza się do jednego zdania: bo inaczej nie zadziała pojedyncze logowanie do SAP. Tożsamość pracowników przenieśliście do chmury lata temu, katalog lokalny miał zniknąć razem z ostatnią aplikacją, która go potrzebowała, a potem okazało się, że tą aplikacją jest SAP GUI. Kerberos wymaga kontrolera domeny, kontroler domeny wymaga lasu, las wymaga utrzymania, i tak przez dwadzieścia lat.
Trzeciego września 2026 SecurityBridge opublikował wydanie TrustBroker 5.1.0, w którym OpenID Connect jest wbudowany w bibliotekę SNC. To brzmi jak przypis w informacji o wersji, a jest zdjęciem jednej z przyczyn, dla których programy modernizacji tożsamości kończą się w osiemdziesięciu procentach.
W skrócie:
1/ pojedyncze logowanie i uwierzytelnianie wieloskładnikowe do SAP GUI działają bez Active Directory pośrodku, natywnie z Microsoft Entra ID, Oktą, PingID, Keycloakiem i SAP Cloud Identity Services,
2/ Kerberos nie znika, zostaje wspierany w tej samej bibliotece, więc przechodzicie system po systemie, we własnym tempie,
3/ logowanie do SAP GUI można teraz chronić uwierzytelnianiem odpornym na phishing - Windows Hello for Business, passkeys, tokeny FIDO2,
4/ ruch między SAP GUI a systemem SAP jest szyfrowany wymianą kluczy odporną na komputery kwantowe.
Zależność, której nikt świadomie nie wybierał
Pojedyncze logowanie do SAP GUI opiera się o warstwę SNC, czyli Secure Network Communications - interfejs, przez który SAP przyjmuje uwierzytelnienie wykonane na zewnątrz jądra. Biblioteka SNC podstawiona pod ten interfejs mówiła dotąd jednym językiem: Kerberos. A Kerberos w praktyce korporacyjnej znaczy Active Directory.
Dla zespołu bezpieczeństwa wynikają z tego dwa fakty, które warto trzymać osobno. Pierwszy jest organizacyjny: katalog, który miał być wygaszany, musi żyć, być łatany i audytowany, bo trzyma logowanie do systemu księgującego. Drugi jest architektoniczny i mniej oczywisty - skoro dostęp do ERP wisi na Kerberosie, to przejęcie konta w domenie jest równoznaczne z wejściem do SAP, a dodatkowe warstwy kontroli tożsamości, które zbudowaliście w chmurze, po prostu w tej ścieżce nie występują. Pisaliśmy o tym szerzej przy okazji budowania Zero Trust dla tożsamości w świecie SAP - zasada „nigdy nie ufaj, zawsze weryfikuj” zatrzymuje się tam, gdzie kończy się bilet Kerberosa.
Co dokładnie zmieniło się w bibliotece SNC
TrustBroker 5.1.0 wnosi OpenID Connect do samej biblioteki SNC. Użytkownik loguje się do SAP GUI, a uwierzytelnienie leci do dostawcy tożsamości, którego już macie - producent wymienia Microsoft Entra ID, Oktę, PingID, Keycloaka i SAP Cloud Identity Services, dawniej IAS. Active Directory nie jest w tej ścieżce potrzebne.
Istotny jest szczegół wdrożeniowy, bo to on decyduje, czy temat w ogóle przejdzie przez architekturę. Uwierzytelnianie działa wewnątrz serwerów aplikacyjnych SAP. Producent pisze wprost, że nie dochodzi nowa infrastruktura ani zewnętrzne komponenty do łatania i utrzymania. Dla zespołu Basis oznacza to brak kolejnego serwera pośredniczącego w krytycznej ścieżce logowania, a dla zespołu bezpieczeństwa brak kolejnej powierzchni, którą trzeba objąć zarządzaniem podatnościami.
Kerberos nie odchodzi, więc migracja jest etapowa
To zdanie z materiału producenta warto przeczytać dwa razy, bo rozstrzyga o kształcie projektu: Kerberos zostaje w pełni wspierany w bibliotece SNC. Nie ma daty wyłączenia, nie ma trybu przejściowego z terminem, nie ma sytuacji, w której podnosicie wersję i tracicie działające logowanie.
W praktyce znaczy to, że przechodzicie system po systemie. Zaczynacie od jednego środowiska, najlepiej takiego, w którym awaria logowania nie zatrzymuje księgowania, potwierdzacie zachowanie klienta SAP GUI i polityki, a dopiero potem ruszacie produkcję. Program, w którym odłączenie Active Directory jest jedną wielką zmianą w jeden weekend, jest programem, którego nie trzeba planować w ten sposób.
Uwierzytelnianie odporne na phishing wchodzi do SAP GUI
Druga zmiana jest dla CISO ważniejsza niż pierwsza. Logowanie do SAP GUI można chronić metodami bezhasłowymi: Windows Hello for Business, passkeys i tokenami FIDO2.
Różnica wobec kodu jednorazowego nie jest kosmetyczna. Kod z aplikacji albo z wiadomości SMS użytkownik potrafi przepisać do okna, które wygląda jak Wasze, ale nim nie jest, a atakujący przepisze go dalej do prawdziwego logowania. Uwierzytelnianie odporne na phishing wiąże poświadczenie z konkretną domeną i konkretnym urządzeniem, więc nie ma czego przepisać. Jak wygląda atak, który omija drugi składnik bez łamania kryptografii, opisywaliśmy przy kampanii Kali365 nadużywającej przepływu OAuth device code - tam ofiara sama oddawała dostęp, mając włączone MFA.
Dotąd rozmowa o silnym uwierzytelnianiu w SAP zwykle kończyła się na Fiori i na dostępie z przeglądarki, bo tam dało się to zrobić bez przebudowy. SAP GUI zostawał na boku, chociaż to w nim siedzą transakcje o największej wadze finansowej i to z niego korzystają administratorzy. Ta asymetria właśnie się domyka.
Klucze przygotowane na erę komputerów kwantowych
Trzecia zmiana dotyczy warstwy sieciowej: ruch między SAP GUI a systemami SAP jest chroniony wymianą kluczy odporną na komputery kwantowe. Chodzi o scenariusz „zbierz teraz, odszyfruj później”, w którym ktoś nagrywa dziś sesję, a odszyfrowuje ją za lat kilkanaście, kiedy dzisiejsze szyfrowanie przestanie być barierą. Dla danych kadrowych, cenników i warunków kontraktów okres poufności bywa dłuższy niż horyzont, który zwykle zakładamy.
To temat, który wraca w naszych rozmowach coraz częściej i który rozwijaliśmy w tekście o szyfrowaniu w erze komputerów kwantowych. Tutaj wystarczy uwaga praktyczna: producent nazywa mechanizm „quantum-safe key exchange” i nie podaje ani algorytmu, ani tego, czy tryb jest hybrydowy. Jeżeli macie własną politykę kryptograficzną, to jest pierwsze pytanie do zadania przed pilotażem.
To nie jest wyłącznie logowanie
TrustBroker sam w sobie nie jest nowością, nowe jest wydanie. Warto o tym pamiętać, bo produkt robi coś więcej, niż wpuszcza użytkownika do systemu. Polityki uwierzytelniania leżą na każdym systemie SAP osobno i to administrator po Waszej stronie decyduje, kiedy polityka jest sprawdzana i jaka metoda wystarcza.
Stąd bierze się mechanizm, który w rozmowach z CFO broni się najlepiej: podniesienie wymagań już po zalogowaniu. Użytkownik wchodzi przez pojedyncze logowanie, pracuje normalnie, a kiedy otwiera wrażliwą transakcję albo dane, których nie otwiera na co dzień, system prosi o mocniejsze potwierdzenie tożsamości. Producent wymienia wśród warunków między innymi nietypową porę dostępu, inne urządzenie lub lokalizację oraz historię aktywności użytkownika, a w połączeniu z platformą SecurityBridge także alerty z wykrywania zagrożeń.
Gdzie to działa
Producent wymienia serwery aplikacyjne SAP: RISE with SAP S/4HANA Cloud Private Cloud Edition, SAP S/4HANA w instalacji własnej, SAP NetWeaver AS for ABAP, SAP BW/4HANA, SAP NetWeaver AS for Java oraz SAP BusinessObjects BI Platform. Wydanie 5.1.0 działa na serwerach Linux i Windows oraz na stacjach roboczych macOS i Windows; pozostałe platformy Unix, w tym AIX, mają trafić do późniejszego wydania. Doszło wsparcie dla Red Hat Enterprise Linux 10, SUSE Linux Enterprise Server 16 i SAP GUI 8.10, jest też certyfikacja Citrix Ready, więc sesje w Citrix Virtual Apps and Desktops korzystają z tego samego przepływu.
Dla klientów w modelu RISE ważne jest jedno zdanie: producent deklaruje, że rozwiązanie jest dopuszczone dla RISE with SAP. To argument, który zdejmuje pierwszą obiekcję, jaka pada przy każdym pomyśle dołożenia czegokolwiek do systemu utrzymywanego przez SAP.
Czego w materiale producenta nie ma
Piszemy o tym osobno, bo lista rzeczy niepotwierdzonych jest częścią rzetelnej oceny produktu, a nie przypisem.
Deklaracje o certyfikacji SAP i o dopuszczeniu dla RISE with SAP pochodzą ze strony producenta. Nie znaleźliśmy publicznego dokumentu SAP, który potwierdza je niezależnie, i przed decyzją poprosimy o numer scenariusza integracyjnego. Materiał nie mówi też, które przepływy OpenID Connect są obsługiwane ani jak rozwiązanie zachowuje się przy odświeżaniu tokenu w długiej sesji SAP GUI. Opisany jest klient SAP GUI dla Windows w wersji 8.10, więc zachowania dla SAP GUI for Java i dla SAP Business Client trzeba potwierdzić osobno. Nie ma publicznego cennika ani informacji o minimalnym poziomie jądra po stronie systemu SAP. Warto też wiedzieć, że strona produktowa jest starsza niż samo wydanie i nadal opisuje przepływ oparty o Active Directory - lista dostawców tożsamości jest na niej aktualna, narracja nie.
Sześć pytań przed pilotażem
1/ Który system bierzecie pierwszy i co się dzieje, gdy logowanie w nim przestanie działać w środę rano
2/ Kto po Waszej stronie jest właścicielem polityki uwierzytelniania na poziomie systemu SAP, skoro polityka leży na każdym systemie osobno
3/ Jakie metody bezhasłowe macie już wdrożone dla pozostałych aplikacji i czy SAP wejdzie w ten sam schemat rejestracji urządzeń
4/ Które transakcje uznajecie za wrażliwe na tyle, żeby wymagały potwierdzenia tożsamości po zalogowaniu, i kto to zatwierdza
5/ Co zostaje w Active Directory po odłączeniu SAP i jaki jest wtedy harmonogram wygaszania katalogu
6/ Jak wygląda ścieżka awaryjna dla administratora, kiedy dostawca tożsamości jest niedostępny, a system produkcyjny wymaga interwencji
Pytanie szóste w większości rozmów zostaje bez odpowiedzi dłużej niż pozostałe pięć razem wzięte, a to ono decyduje o tym, czy projekt jest gotowy do produkcji.
Jak podchodzimy do tego w SNOK
SecurityBridge jest naszym partnerem technologicznym, wdrażamy i utrzymujemy tę platformę u klientów, i mówimy o tym wprost, zanim padnie pierwsza rekomendacja. Nie twierdzimy przy tym, że TrustBroker jest jedynym rozwiązaniem tego problemu - pojedyncze logowanie i uwierzytelnianie wieloskładnikowe do SAP da się zbudować także inaczej, a wybór zależy od tego, gdzie trzymacie tożsamość, jak wygląda Wasz krajobraz i co już działa.
To, co wnosi wydanie 5.1, jest natomiast zmianą w warunkach zadania, a nie w ofercie jednego dostawcy. Jeżeli Active Directory zostało u Was przy życiu głównie dla SAP, macie teraz argument, żeby wrócić do tej rozmowy z architektem tożsamości. Jeżeli chcecie, żebyśmy przeszli przez sześć pytań powyżej na Waszym krajobrazie, odezwijcie się do nas - zaczynamy od przeglądu obecnej ścieżki logowania, nie od demonstracji produktu.
Materiał opisuje stan wiedzy na 14 września 2026 i opiera się o informacje opublikowane przez producenta. Zakres wsparcia, certyfikacje i warunki licencyjne potwierdzajcie w dokumentacji SecurityBridge oraz w swojej umowie przed podjęciem decyzji.