Umożliwienie jednej osobie wykonywania zadań w imieniu innej może zaspokajać rzeczywistą potrzebę biznesową, ale nie powinno wymagać udostępniania haseł ani przyznawania ogólnego dostępu do konta. W aplikacji PHP bezpieczna delegacja musi jasno określać, kto działa, kogo reprezentuje, do jakich zasobów może uzyskać dostęp i przez jaki czas. Musi też umożliwiać odwołanie i audyt.
Celem jest autoryzowanie konkretnego działania przy zachowaniu tożsamości obu osób. Wymaga to czegoś więcej niż ekranu do przyznawania uprawnień: wpływa na model danych, każdy punkt autoryzacji, operacje asynchroniczne i testy. Projektowanie tych elementów łącznie zmniejsza ryzyko, że delegacja prawidłowa w jednym widoku przez alternatywną ścieżkę stanie się nadmiernym dostępem.
Odróżnij delegację od podszywania się i współdzielonego dostępu
W przypadku delegacji osobą inicjującą operację pozostaje uwierzytelniony użytkownik. Aplikacja dodatkowo zapisuje, że działa on w imieniu innej osoby na podstawie ograniczonego upoważnienia. Osoba reprezentowana nie zalogowała się i nie powinna być wskazywana jako bezpośredni autor żądania.
Podszywanie się zmienia tożsamość, z którą system wiąże żądanie, i może ukrywać, kto wykonał działanie, jeśli nie zostanie wdrożone z odpowiednimi zabezpieczeniami. Współdzielony dostęp, na przykład przez przekazanie danych logowania, zaciera granice między użytkownikami i utrudnia odwoływanie uprawnień oraz przypisywanie działań. W typowym przepływie delegacji żadne z tych podejść nie zastępuje jawnego kontekstu aktora i osoby reprezentowanej.
Warto używać nazw obu ról zarówno w kodzie, jak i w logach. Na przykład actor_id identyfikuje osobę, która wykonała operację, a principal_id osobę, w której imieniu ją wykonano. Unikaj niejednoznacznych nazw, takich jak user_id, w logach, gdzie mogłyby odnosić się do którejkolwiek z tych osób.
Przed wdrożeniem określ zakres, zasoby i okres obowiązywania
Przydatna delegacja precyzyjnie opisuje, co upoważnia wykonać. „Zarządzanie kontem” jest zazwyczaj zbyt szerokim określeniem. Zamiast tego można ograniczyć uprawnienia do takich działań jak przeglądanie zadań, aktualizowanie ich statusu lub odpowiadanie na zgłoszenie. Jeśli działania wiążą się z różnymi konsekwencjami, modeluj oddzielne uprawnienia zamiast łączyć odczyt, edycję, zatwierdzanie i usuwanie w jedną ogólną możliwość.
Określ także zakres zasobów: organizację, projekt, kolejkę zadań lub konkretny zestaw rekordów. Uprawnienie do edycji zadań w jednym projekcie nie powinno umożliwiać odczytu danych z innego projektu tylko dlatego, że ten sam delegowany użytkownik może uzyskać do nich dostęp w ramach innej funkcji.
Okres obowiązywania powinien mieć jasno określony początek i koniec, a także status umożliwiający odwołanie delegacji przed upływem terminu. Zdecyduj, jakiej strefy czasowej używać do prezentowania dat, i zachowaj spójność porównań wewnętrznych. Jeśli polityka wymaga zatwierdzenia lub zabrania delegacji łańcuchowych, określ to jako jawną i weryfikowalną regułę; nie pozostawiaj tego konwencji interfejsu.
Modeluj autoryzację i sprawdzaj ją przy każdej operacji
Relacyjny schemat może opisywać delegację za pomocą pól takich jak identyfikator, upoważniony aktor, osoba reprezentowana, zakres, działania, data rozpoczęcia, data wygaśnięcia, status, osoba tworząca i data odwołania. Dokładna struktura zależy od domeny: działania można przechowywać w powiązanej tabeli lub w innym zweryfikowanym formacie, ale muszą dać się odczytać i sprawdzić bez niejednoznacznych interpretacji.
Autoryzacja powinna oddzielać uprawnienia osoby reprezentowanej od upoważnienia delegowanego aktorowi. W przypadku żądanej operacji sprawdź, czy osoba reprezentowana miałaby zwykły dostęp do zasobu i czy pozwalają na to obowiązujące reguły biznesowe. Następnie zweryfikuj, czy uwierzytelniony aktor jest adresatem delegacji, która pozostaje ważna i nie została odwołana, oraz czy upoważnia ona do danego działania na tym zasobie. Efektywne uprawnienia są ograniczone zarówno dostępem osoby reprezentowanej, jak i zakresem delegacji: delegacja nie może przyznawać aktorowi większej liczby działań lub dostępu do większej liczby zasobów, niż osoba reprezentowana może upoważnić ani niż przewiduje sama delegacja. Nie wymagaj, aby aktor miał również własny dostęp do zasobu; właśnie dzięki delegacji może na nim działać. Stosuj natomiast ograniczenia dotyczące tożsamości aktora, takie jak uwierzytelnienie, przynależność do wymaganego kontekstu lub zabezpieczenia danej operacji.
W praktyce weryfikacja powinna obejmować:
- Uwierzytelnienie aktora i potwierdzenie, że delegacja jest do niego przypisana.
- Sprawdzenie, czy osoba reprezentowana jest właściwa w danym kontekście i ma zwykły dostęp do żądanego zasobu.
- Sprawdzenie, czy delegacja jest aktywna w chwili wykonywania operacji, nie została odwołana i pozostaje w okresie obowiązywania.
- Sprawdzenie, czy żądane działanie i zasób mieszczą się w przyznanym zakresie i nie wykraczają poza uprawnienia osoby reprezentowanej.
- Sprawdzenie, czy spełnione są reguły biznesowe i wymogi bezpieczeństwa dotyczące aktora i operacji.
Skoncentruj tę decyzję w usłudze autoryzacji lub współdzielonej polityce zamiast powielać częściowe warunki w kontrolerach. Mimo to wywołuj ją przy każdej istotnej operacji: chroniony widok nie zabezpiecza automatycznie API, pobierania pliku, operacji zbiorczej ani ścieżki administracyjnej. W PHP kontroler może pobrać uwierzytelnionego aktora, ustalić kontekst delegacji i poprosić usługę o autoryzację działania na konkretnym zasobie. Warstwa domenowa może również egzekwować kluczowe niezmienniki, gdy operacja wiąże się z istotnymi konsekwencjami.
Nie ufaj wartości principal_id przesłanej przez przeglądarkę jako dowodowi uprawnień. Serwer musi weryfikować relację między aktorem, osobą reprezentowaną, delegacją, zasobem i działaniem, korzystając z zaufanych danych. Nie zakładaj też, że ukrycie przycisku w interfejsie uniemożliwia bezpośrednie wywołanie endpointu.
Zachowaj atrybucję działań w audycie i operacjach asynchronicznych
Przydatny log pozwala odtworzyć przebieg zdarzeń bez mylenia tożsamości. Dla każdego istotnego zdarzenia zachowuj aktora, osobę reprezentowaną, działanie, typ i identyfikator zasobu, datę, wynik oraz odwołanie do zastosowanej delegacji. Zależnie od ryzyka zapisuj także powód operacji lub identyfikator korelacji. Unikaj przechowywania w historii sekretów i niepotrzebnych danych osobowych.
Atrybucja działań musi być zachowana także w kolejkach i zadaniach działających w tle. Jeśli delegowane żądanie planuje zadanie, wiadomość powinna przenosić weryfikowalny kontekst obejmujący aktora, osobę reprezentowaną i odwołanie do upoważnienia, zamiast polegać na sesji WWW, która nie będzie już dostępna. Podczas wykonywania zadania zdecyduj, czy ponownie sprawdzać, czy delegacja nadal jest aktywna. W przypadku działania, które można jeszcze anulować, weryfikacja w chwili wykonania zazwyczaj zapobiega sytuacji, w której po odwołaniu delegacji pozostaje oczekujące zadanie z nieaktualnymi uprawnieniami. Jeśli operacja stała się już nieodwracalna, udokumentuj tę granicę i zapisz moment autoryzacji.
Chroń logi przed nieautoryzowanymi modyfikacjami i ogranicz dostęp do nich. Audyt powinien wspierać dochodzenia i rozliczalność, ale nie może prowadzić do bezkrytycznego kopiowania danych operacyjnych.
Uwzględnij wygaśnięcie i odwołanie jako część przepływu
Wygaśnięcie i odwołanie to nie tylko zmiany statusu na ekranie. Sesja zachowująca kontekst delegacji może nadal wyświetlać nieaktualne opcje; dlatego autoryzacja po stronie serwera musi sprawdzać bieżący status przy każdym żądaniu, nawet jeśli interfejs również jest aktualizowany. Jeśli uprawnienia są buforowane, określ sposób unieważniania pamięci podręcznej i maksymalne akceptowane opóźnienie w uzyskaniu skuteczności przez odwołanie.
Przy odwołaniu zapisuj, kto je przeprowadził i kiedy. Jawnie oceń wpływ na aktywne sesje, wydane tokeny, zadania w kolejce i powiązane linki tymczasowe. Nie zakładaj, że zakończenie sesji lub zmiana danych w bazie automatycznie unieważni wszystkie te elementy. Właściwe rozwiązanie zależy od projektu, ale musi być określone przed udostępnieniem przepływu.
Testuj ograniczenia i przypadki, które łatwo przeoczyć
Testy powinny weryfikować zarówno dozwolone, jak i odrzucane działania. Uwzględnij co najmniej delegację, która jeszcze nie weszła w życie, wygasła lub została odwołana; innego aktora niż upoważniony; zasób poza zakresem; nieprzyznane działanie; nieprawidłową osobę reprezentowaną lub brak jej zwykłego dostępu do zasobu; oraz bezpośredni dostęp do endpointów niewidocznych w interfejsie. Dodaj także przypadek pozytywny, w którym aktor nie ma własnego dostępu do zasobu, ale osoba reprezentowana ma do niego dostęp, a delegacja obejmuje dane działanie i zasób. Pozwala to sprawdzić, czy system nie myli własnych uprawnień aktora z uprawnieniami delegowanymi.
Dodaj testy granic czasowych, współbieżnych zmian i skutków pośrednich. Na przykład sprawdź, co dzieje się, gdy delegacja zostaje odwołana w trakcie operacji lub gdy oczekuje zadanie, a także czy działanie dotyczące zadania uruchamia powiadomienia, eksporty lub zmiany wtórne. Sprawdź, czy te skutki zachowują prawidłową atrybucję działań i nie rozszerzają ich zakresu.
Oddziel testy jednostkowe polityki autoryzacji od testów integracyjnych obejmujących trasy, trwałość danych i kolejki. Test sprawdzający wyłącznie metodę podejmującą decyzję nie dowodzi, że wywołują ją wszystkie trasy; test interfejsu również nie potwierdza ochrony po stronie serwera.
Lista kontrolna przed udostępnieniem
- Czy w kodzie, interfejsie i audycie wyraźnie rozróżnia się aktora i osobę reprezentowaną?
- Czy każda delegacja ogranicza działania, zasoby i okres obowiązywania oraz czy nieprawidłowe kombinacje są blokowane?
- Czy polityka sprawdza dostęp osoby reprezentowanej i ogranicza aktora do zakresu delegacji, nie wymagając od niego własnego dostępu do zasobu?
- Czy każda operacja po stronie serwera sprawdza tożsamość, status, czas, zakres i działanie?
- Czy odwołanie wpływa na sesje, tokeny, pamięć podręczną i oczekujące zadania zgodnie z określoną polityką?
- Czy logi pozwalają przypisywać działania bez przechowywania zbędnych informacji?
- Czy testy obejmują odmowy, granice czasowe, prawidłowe delegacje bez własnego dostępu aktora oraz skutki pośrednie?
Delegacja jest bezpieczna, gdy nie myli się jej z dostępem do cudzego konta, a każde działanie można uzasadnić uprawnieniami osoby reprezentowanej oraz aktualną i ograniczoną delegacją. Jeśli zespół nie potrafi precyzyjnie odpowiedzieć, kto działał, w czyim imieniu, na jakim zasobie i na podstawie jakiego uprawnienia, przepływ wymaga dalszego zaprojektowania przed wdrożeniem produkcyjnym.
