Projektowanie uprawnień i autoryzacji w PHP nie sprowadza się do ekranu, na którym przypisuje się profile. Problem pojawia się, gdy to samo działanie zależy od tego, kto je wykonuje, dla jakiej organizacji pracuje, na jakich danych działa i w jakim stanie znajdują się te dane. Jeśli te warunki są rozproszone między kontrolerami, zapytaniami, szablonami i walidacjami interfejsu, system zaczyna gromadzić wyjątki trudne do przejrzenia.
Celem powinno być, aby każda decyzja była jawna, powtarzalna i weryfikowalna: tożsamość próbuje wykonać operację na zasobie w określonym kontekście, a polityka decyduje, czy jest ona dozwolona. Takie podejście przekształca niejednoznaczne reguły operacyjne w kontrole techniczne, które produkt, operacje i zespoły programistyczne mogą wspólnie przeglądać.
Rozdzielanie tożsamości, autoryzacji i zakresu danych
Uwierzytelnianie odpowiada na pytanie, kim jest użytkownik: sesja, poświadczenia, dostawca tożsamości lub token. Autoryzacja odpowiada na pytanie, co może zrobić ta tożsamość. Nie należy wnioskować o drugim wyłącznie na podstawie pierwszego ani traktować obu jako jednej warstwy.
Rola grupuje obowiązki, takie jak administrator organizacji, agent wsparcia lub zatwierdzający. Uprawnienie reprezentuje konkretną operację, na przykład invoice.read, invoice.approve lub member.invite. Zakres określa, których zasobów dotyczy ta operacja: faktur organizacji, spraw jednostki lub własnych rekordów.
To rozróżnienie zapobiega częstemu błędowi: nadaniu uprawnienia do odczytu faktur i założeniu, że pozwala ono odczytać każdą fakturę. Polityka nadal musi sprawdzić, czy zasób należy do aktywnej organizacji, czy użytkownik ma przypisaną odpowiednią jednostkę oraz czy stan zasobu pozwala na żądane działanie.
Tworzenie macierzy dostępu na podstawie operacji
Przed wyborem klas lub pakietów wymień rzeczywiste zasoby i operacje. Używaj czasowników biznesowych zamiast ogólnikowych etykiet, takich jak „zarządzać”: utworzyć zamówienie, wyświetlić zamówienie, poprawić wersję roboczą, zatwierdzić zamówienie, anulować zamówienie, wyeksportować zamówienia lub modyfikować członków.
Dla każdej operacji uzgodnij z biznesem cztery elementy:
- Zasób i chronione działanie.
- Profile, które mogą o nie wnioskować.
- Obowiązujący zakres danych: organizacja, jednostka, właściciel, portfel lub przypisanie.
- Warunki kontekstu i stanu: aktywna organizacja, obowiązujące delegowanie, godziny pracy lub dokument w wersji roboczej.
Powstała macierz nie jest kodem autoryzacji, lecz specyfikacją podlegającą przeglądowi. Ponadto wymusza wykrycie nierozstrzygniętych decyzji. Jeśli wskazano, że wsparcie może „wyświetlać zamówienia”, należy sprecyzować, czy może widzieć dane osobowe, załączone dokumenty, zamknięte zamówienia lub informacje ze wszystkich organizacji.
Preferowanie małych i stabilnych działań
Zbyt szerokie działanie skupia uprawnienia i utrudnia stosowanie zasady najmniejszych uprawnień. Rozdzielenie order.read od order.export lub user.update od user.assign_role pozwala nadawać dostęp precyzyjnie. Nie należy też tworzyć uprawnienia dla każdego jednostkowego przypadku: jeśli różnica zależy od zasobu, zwykle jest warunkiem polityki, a nie nową rolą.
Wybór między rolami, uprawnieniami, atrybutami i kontekstem
Proste role działają, gdy istnieje niewiele stabilnych profili, a operacje niemal nie zależą od danych. Są dobrym punktem wyjścia, ale stają się kruche, gdy pojawiają się nazwy takie jak manager_con_exportacion lub supervisor_solo_unidad_norte. Takie kombinacje kodują wyjątki jako trwałe profile.
Jawne uprawnienia są odpowiednie do oddzielenia obowiązków od profili oraz do zarządzalnego przypisywania możliwości. Atrybuty sprawdzają się, gdy decyzja zależy od właściwości podmiotu, zasobu lub środowiska: organizacji, jednostki, klasyfikacji, właściciela, kraju lub poziomu ryzyka. Reguły kontekstowe uzupełniają model, gdy występują warunki przejściowe, takie jak aktywne delegowanie lub etap zatwierdzania.
W praktyce model hybrydowy jest zwykle łatwiejszy w utrzymaniu: role nadają podstawowe uprawnienia; polityka ocenia atrybuty użytkownika i zasobu; a kontekst dostarcza wybraną organizację lub kanał operacyjny. Rola nie powinna zastępować analizy danych.
Centralizacja polityk i filtrowanie danych u źródła
Aplikacja PHP potrzebuje spójnego punktu do wyrażania decyzji. Może on być zmaterializowany w klasach polityk, usługach autoryzacji lub równoważnych komponentach wybranego frameworka. Ważne jest, aby kontrolery żądały decyzji, a widoki nie były jedyną barierą.
if (!$authorizer->can($actor, 'order.approve', $order, $context)) {
throw new AccessDeniedException();
}Polityka powinna otrzymywać tylko dane niezbędne do podjęcia decyzji: tożsamość, operację, zasób i kontekst. Unikaj używania zmiennych globalnych lub niejawnego zależenia od bieżącej trasy; utrudnia to testowanie i ponowne użycie reguł.
Indywidualne sprawdzenie nie wystarcza na ekranach list. Jeśli zapytanie zwraca zamówienia z wielu organizacji, a interfejs później ukrywa niektóre z nich, ekspozycja już nastąpiła. Stosuj zakres w repozytorium lub warstwie zapytań: filtruj według autoryzowanej organizacji, dozwolonej jednostki lub przypisanego portfela przed załadowaniem wyników. W przypadku zasobów identyfikowanych przez identyfikator sprawdzaj zarówno operację, jak i przynależność zasobu.
Stany i przejścia jako część polityki
Wrażliwe operacje często zależą od stanu. Osoba zatwierdzająca może zatwierdzić oczekujące zamówienie, ale nie anulowane ani już zatwierdzone. Modeluj dozwolone przejście jawnie i waliduj je ponownie w punkcie, który utrwala zmianę. Interfejs może wyłączyć przycisk, aby wskazać użytkownikowi właściwe działanie, lecz polityka serwera jest skuteczną kontrolą.
Unikanie trwałych wyjątków i ujawniających odmów
Ogólne role, takie jak „administrator”, wymagają jasnych ograniczeń. Administrator organizacji nie powinien automatycznie stawać się administratorem platformy. Podobnie wyjątek taki jak „może edytować ten konkretny rekord” powinien mieć właściciela, powód, datę przeglądu lub wygaśnięcia oraz śledzalność. Jeśli się powtarza, prawdopodobnie brakuje reguły biznesowej lub atrybutu modelu.
Odmowy powinny być użyteczne, nie ujawniając wrażliwych informacji. W przypadku bezpośredniego zapytania o cudzy zasób zwykle lepsza jest odpowiedź nieodróżnialna od odpowiedzi informującej, że zasób nie istnieje. W działaniu na już widocznym zasobie można wskazać brak uprawnień bez ujawniania wewnętrznych reguł, przypisań lub chronionych atrybutów.
Rejestruj dozwolone i odrzucone wrażliwe działania, gdy przynoszą wartość operacyjną: zmiany ról, eksporty, zatwierdzenia, dostępy delegowane i modyfikacje konfiguracji. Audyt powinien obejmować aktora, działanie, zasób, organizację lub kontekst, moment i wynik. Nie rejestruj poświadczeń, tokenów ani niepotrzebnych danych osobowych.
Testowanie autoryzacji jako właściwości produktu
Testy autoryzacji powinny obejmować decyzje dozwolone i odrzucone. Minimalny zestaw obejmuje: użytkownika z uprawnieniem w swojej organizacji; tego samego użytkownika wobec innej organizacji; użytkownika bez uprawnienia; zasób w nieprawidłowym stanie; oraz zmianę kontekstu, taką jak usunięcie przypisania lub zakończenie delegowania.
Testuj polityki bezpośrednio, ponieważ zapewniają precyzyjną diagnostykę, i dodaj testy integracyjne, aby potwierdzić, że trasy, kontrolery, zapytania i operacje zapisu stosują decyzję. Najgroźniejsze regresje dotyczą uprawnień: dodanie roli, trasy lub optymalizacji zapytania, która niezamierzenie rozszerza dostęp.
- Sprawdź, czy lista nie zawiera zasobów spoza zakresu.
- Sprawdź, czy znajomość cudzego identyfikatora nie przyznaje dostępu.
- Sprawdź, czy zmiana stanu wymaga odpowiedniej polityki.
- Sprawdź, czy odebranie uprawnienia unieważnia możliwość w kolejnym żądaniu.
Wdrażanie modelu w aplikacji z rozproszonymi regułami
Nie trzeba przepisywać całego systemu. Zacznij od zinwentaryzowania tras, poleceń, zadań harmonogramu i punktów eksportu, które zmieniają dane lub je ujawniają. Nadaj priorytet działaniom o dużym wpływie oraz zasobom współdzielonym między organizacjami. Wyodrębnij jedną politykę na domenę, pokryj bieżące zachowanie testami i popraw reguły przyznające więcej dostępu, niż przewidziano.
Następnie zastąp rozproszone sprawdzenia wywołaniami usługi autoryzacji i przenieś filtrowanie zakresu do zapytań. Okresowo przeglądaj nieużywane uprawnienia, role o zbyt wielu możliwościach, wygasłe delegowania i aktywne wyjątki. Projektowanie uprawnień i autoryzacji w PHP będzie łatwe w utrzymaniu, gdy nowa funkcjonalność będzie mogła przed rozpoczęciem implementacji odpowiedzieć, kto działa, na jakim zasobie, w jakich warunkach i za pomocą jakich dowodów zostało to sprawdzone.
Lista kontrolna dla każdego nowego modułu
- Czy zdefiniowano operacje biznesowe i ich zasoby?
- Czy macierz rozróżnia uprawnienie, zakres i warunek stanu?
- Czy polityki są stosowane przy odczycie, zapisie, eksporcie i procesach nieinteraktywnych?
- Czy zapytania filtrują dane przed przekazaniem ich do interfejsu?
- Czy istnieją testy dostępu dozwolonego, odrzuconego i między organizacjami?
- Czy wrażliwe działania pozostawiają proporcjonalny i bezpieczny ślad audytowy?
