Delegowanie poświadczeń

Delegowanie poświadczeń to mechanizm umożliwiający przekazanie danych uwierzytelniających pomiędzy usługami w celu wykonania operacji w imieniu użytkownika.

Delegowanie poświadczeń – czym jest i jak działa

Delegowanie poświadczeń to mechanizm kontroli dostępu, w którym jedna usługa otrzymuje możliwość wykonania określonej operacji w imieniu użytkownika uwierzytelnionego wcześniej w innym systemie. Nie chodzi przy tym o zwykłe przesłanie hasła w wiadomości ani o trwałe przekazanie pełnej kontroli nad kontem. Celem jest utworzenie zaufanej relacji pomiędzy usługą wywołującą, usługą docelową oraz tożsamością użytkownika, tak aby żądanie mogło zostać obsłużone z zachowaniem właściwego kontekstu uprawnień.

Przykładowo aplikacja działająca w środowisku firmowym może przyjąć żądanie użytkownika, a następnie odwołać się do zasobu znajdującego się w innej usłudze. Jeżeli wymagane jest rozpoznanie konkretnej osoby, samo konto aplikacji może okazać się niewystarczające. Delegowanie pozwala wtedy przekazać do kolejnego etapu informację o tożsamości użytkownika albo uzyskać specjalny token potwierdzający, że dana operacja została wykonana za jego zgodą. Zakres przekazanych uprawnień powinien być ograniczony do konkretnej usługi, zasobu i rodzaju działania.

W praktyce poświadczenia nie muszą oznaczać jawnych danych logowania. Mogą mieć postać biletu uwierzytelniającego, tokenu dostępu, tokenu odświeżającego lub innego podpisanego dowodu tożsamości. Ważne jest rozróżnienie pomiędzy delegowaniem uprawnień a podszywaniem się pod użytkownika. W pierwszym przypadku usługa otrzymuje uprawnienie do wykonania określonej czynności w ramach ustalonej polityki, natomiast w drugim może uzyskać szerszą możliwość działania, trudniejszą do ograniczenia i audytowania.

Kontekst techniczny i porównanie mechanizmów - Delegowanie poświadczeń

Delegowanie poświadczeń występuje w kilku modelach. W środowiskach opartych na Kerberos można przekazać usługom bilety pozwalające na dostęp do kolejnych zasobów w imieniu użytkownika. W rozwiązaniach wykorzystujących OAuth 2.0 i OpenID Connect podobną rolę pełnią tokeny zawierające zakresy, odbiorcę oraz czas ważności. W systemach webowych spotyka się także wzorzec przekazywania tokenu użytkownika do następnej usługi, określany jako propagowanie tożsamości. Każdy z tych wariantów różni się sposobem wydawania poświadczeń, ich weryfikacją oraz możliwością odwołania.

Najbezpieczniejszy model zakłada delegowanie ograniczone. Oznacza to, że usługa pośrednia nie powinna otrzymywać nieograniczonego prawa do korzystania z tożsamości użytkownika, lecz wyłącznie uprawnienie potrzebne do wykonania konkretnego zadania. Ograniczenia mogą dotyczyć odbiorcy tokenu, rodzaju operacji, dostępnych zasobów, czasu obowiązywania oraz warunków, w których poświadczenie może zostać użyte. Przy projektowaniu przepływu należy też rozważyć, czy usługa docelowa musi znać użytkownika końcowego, czy wystarczy jej tożsamość aplikacji.

Warto odróżnić delegowanie od uwierzytelniania wieloetapowego, jednokrotnego logowania oraz zwykłego przekazywania sesji. Jednokrotne logowanie upraszcza potwierdzenie tożsamości przy dostępie do wielu usług, ale samo w sobie nie określa, jak jedna usługa ma działać w imieniu użytkownika wobec następnej. Uwierzytelnianie wieloetapowe wzmacnia pewność, że użytkownik jest tym, za kogo się podaje, lecz nie rozwiązuje kwestii zakresu uprawnień przekazywanych pomiędzy aplikacjami. Delegowanie dotyczy przede wszystkim dalszego użycia już potwierdzonej tożsamości.

Istotne znaczenie ma również rozdzielenie delegowania od przechowywania sekretów. Hasło zapisane w konfiguracji aplikacji, klucz API umieszczony w pliku lub długotrwały token pozostawiony bez ochrony nie stanowią prawidłowego modelu delegowania. Takie rozwiązania zwiększają skutki wycieku i utrudniają ustalenie, kto faktycznie wykonał operację. Lepszym podejściem jest stosowanie krótkotrwałych poświadczeń, centralnej kontroli dostępu, bezpiecznego magazynu sekretów oraz rejestrowania użycia tokenów.

Typowe problemy, błędy i skutki błędnej konfiguracji

Jednym z częstszych problemów jest przyznanie usłudze szerszych uprawnień, niż wymaga wykonywane zadanie. Jeżeli aplikacja ma dostęp do wielu zasobów, przejęcie jej konta może pozwolić na nieautoryzowane działania w imieniu licznych użytkowników. Ryzyko rośnie wtedy, gdy delegowanie działa bez ograniczenia odbiorcy, bez kontroli źródła żądania albo bez rozróżnienia operacji odczytu i modyfikacji.

Błędy mogą wynikać również z nieprawidłowego ustawienia nazw usług, adresów odbiorców, zakresów tokenów lub relacji zaufania. Token wystawiony dla jednej usługi nie powinien być automatycznie akceptowany przez inną tylko dlatego, że pochodzi z tego samego systemu uwierzytelniającego. Konieczne jest sprawdzanie podpisu, wystawcy, odbiorcy, czasu ważności oraz wymaganych zakresów. Pominięcie któregokolwiek z tych elementów może prowadzić do zaakceptowania poświadczenia przeznaczonego dla innego kontekstu.

Do problemów operacyjnych należą wygasające tokeny, rozbieżność czasu pomiędzy urządzeniami, nieprawidłowe odświeżanie poświadczeń i blokowanie kont użytkowników bez unieważnienia już wydanych tokenów. W systemach korzystających z wielu usług trudne bywa także ustalenie, w którym miejscu przepływu utracono właściwy kontekst użytkownika. Objawem może być odmowa dostępu mimo poprawnego logowania, dostęp widoczny jako konto techniczne albo działanie wykonywane z uprawnieniami innej osoby.

Niebezpieczne jest przekazywanie tokenów przez parametry adresu, logi aplikacyjne, komunikaty diagnostyczne lub niezaszyfrowane kanały. Poświadczenie może wówczas trafić do historii przeglądarki, systemu monitoringu, plików tymczasowych albo osób nieuprawnionych do jego użycia. Należy ograniczać zakres logowania, maskować sekrety, stosować szyfrowanie transmisji i kontrolować, czy token jest przekazywany wyłącznie do zamierzonego odbiorcy.

Diagnostyka powinna obejmować zarówno konfigurację usługi, jak i rzeczywisty przebieg żądania. Przydatne jest prześledzenie identyfikatora korelacyjnego, podmiotu reprezentowanego przez token, jego odbiorcy, zakresów oraz decyzji podjętej przez usługę docelową. Sam komunikat „brak dostępu” nie wystarcza do ustalenia przyczyny, ponieważ problem może dotyczyć uwierzytelnienia, autoryzacji, wygaśnięcia poświadczenia albo błędnej mapy zaufania.

Kiedy trzeba umówić wizytę serwisową - Delegowanie poświadczeń

Zgłoszenie problemu do serwisu jest uzasadnione, gdy delegowanie przestaje działać po zmianie hasła, odtworzeniu systemu, aktualizacji aplikacji, wymianie urządzenia lub modyfikacji ustawień sieciowych. Warto skorzystać z pomocy także wtedy, gdy użytkownik może zalogować się bezpośrednio, lecz aplikacja nie potrafi pobrać danych z kolejnej usługi, operacje są przypisywane niewłaściwemu kontu albo pojawiają się powtarzające żądania logowania.

W Warszawskim Pogotowiu Komputerowym 24/7 można zlecić analizę konfiguracji systemu, aplikacji oraz przepływu uwierzytelniania, z uwzględnieniem ochrony danych i zasady minimalnych uprawnień. Przed przekazaniem urządzenia lub dostępu warto przygotować opis objawów, moment wystąpienia problemu oraz informacje o ostatnich zmianach. Nie należy wysyłać haseł ani pełnych tokenów w treści zgłoszenia, ponieważ do wstępnej oceny zwykle wystarczają bezpiecznie zanonimizowane komunikaty i fragmenty konfiguracji.

Pomoc serwisowa może obejmować rozpoznanie miejsca, w którym zrywa się przepływ poświadczeń, sprawdzenie certyfikatów i czasu systemowego, ocenę reguł dostępu oraz uporządkowanie zapisów diagnostycznych. W razie podejrzenia ujawnienia sekretu konieczne jest jego unieważnienie lub wymiana, a następnie przejrzenie logów pod kątem nieautoryzowanego użycia. Po zakończeniu prac powinno zostać potwierdzone, że usługa otrzymuje wyłącznie wymagany zakres uprawnień i że operacje można przypisać właściwej tożsamości.