Autoryzacja sprawdzona przy wejściu

Przykład fikcyjny. Nie opisuje konkretnej organizacji ani incydentu.

Sytuacja

Brama API weryfikuje token i przekazuje żądanie do usług. Zespoły uznają, że „użytkownik jest już autoryzowany”. Serwis raportów odczytuje zasób po identyfikatorze, cache nie zawiera identyfikatora klienta, a worker eksportu ufa identyfikatorowi z komunikatu. Każdy element działa zgodnie ze swoją lokalną instrukcją. Cała ścieżka nie zapewnia jednak jednej granicy dostępu.

Objawy

• testy sprawdzają token nieważny i ważny, ale nie próbują odczytu cudzego zasobu przez poprawnie zalogowanego użytkownika;
• role typu admin nie są związane z konkretnym klientem lub zakresem;
• trafienie w cache, eksport albo wyszukiwanie omija kontrolę wykonywaną przy zapytaniu do bazy;
• identyfikator klienta jest pobierany z parametru żądania albo wiadomości bez związania z zaufaną tożsamością;
• przegląd bezpieczeństwa kończy się na diagramie bramy.

Konsekwencje

Poprawnie uwierzytelniony użytkownik może zobaczyć lub zmienić dane innego klienta. Problem bywa trudny do wykrycia, bo logi pokazują ważny token i odpowiedź 200. Centralna brama daje wtedy poczucie kontroli, lecz nie zna semantyki każdego raportu, pliku ani zadania.

Lepsza decyzja

1. Zdefiniuj zaufany kontekst klienta i operacji. Wiąż role z zakresem, a decyzję o dostępie podejmuj dla konkretnego zasobu.
2. Wymuszaj zakres w każdej ścieżce danych: zapisie, odczycie, cache, indeksie, eksporcie i komunikacie. Dodaj niezależną barierę w warstwie danych tam, gdzie ryzyko to uzasadnia.
3. Stosuj zasadę odmowy domyślnej. Brak kontekstu lub niejednoznaczność to powód do zatrzymania operacji, nie do użycia „domyślnego klienta”.
4. Testuj kolizje identyfikatorów, zmianę roli, opóźnione zadania i rozgrzany cache. Obserwuj decyzje o dostępie bez kopiowania chronionej treści do logów.
5. Po zmianie mechanizmu zaplanuj migrację: unieważnij stare sesje i cache, sprawdź zaległe wiadomości oraz ustal zakres możliwego wcześniejszego ujawnienia.

Centralna polityka może ograniczyć rozjazd, ale musi być dostępna, wersjonowana i zrozumiała dla usług. Lokalna kontrola bywa prostsza, lecz wymaga wspólnego kontraktu oraz testów. W obu wariantach zdanie „gateway już to sprawdził” nie jest dowodem.

Uwierzytelnienie otwiera drzwi do systemu. Nie daje automatycznie klucza do każdego pokoju.