Izolacja najemców dla MSP: identyfikator tenanta lub login to nie autoryzacja

Identyfikator tenanta podany przez klienta, nagłówek X-Tenant-ID, działający login, zasada dostępu warunkowego (Conditional Access) czy połączenie SSO — każdy z nich mówi coś użytecznego, ale żaden z osobna nie dowodzi, że wywołujący ma prawo zobaczyć dane danego klienta. Ten przewodnik jest dla dostawców MSP i zespołów IT, które prowadzą lub kupują platformy wielonajemcze: pokazuje, mechanizm po mechanizmie, gdzie faktycznie musi znajdować się kontrola autoryzacji po stronie serwera — od pierwszego żądania po dzień, w którym konto jest wyłączane.

Identyfikator tenanta tylko wybiera klienta, nie autoryzuje go

Identyfikator tenanta podany przez klienta — w treści żądania, w parametrze zapytania albo odczytany z subdomeny — jest selektorem. Mówi aplikacji, który kontekst klienta otworzyć. OWASP Multi-Tenant Security Cheat Sheet określa podstawową zasadę: każde żądanie należy powiązać z uwierzytelnionym podmiotem, jego przynależność do tenanta odczytać ze stanu po stronie serwera, egzekwować kontrole na poziomie obiektów wewnątrz tenanta i trzymać ścieżki administracyjne lub awaryjne oddzielnie od zwykłego dostępu do tenanta. Ta kontrola musi działać wszędzie tam, gdzie granica tenanta ma znaczenie, nie tylko przy wejściu do API: przy odczytach i zapisach, przy działaniach administracyjnych i przy zadaniach w tle, które przejmują pracę po zakończeniu pierwotnego żądania. Zadanie uruchamiane przez kolejkę, które dziedziczy identyfikator tenanta z wiadomości bez ponownej weryfikacji, otwiera dokładnie tę samą lukę, którą miała zamknąć pierwotna kontrola.

Nagłówek X-Tenant-ID lub pole w treści żądania kryją tę samą pułapkę

Ten sam błąd wraca pod postacią nagłówka. Interfejsy API wielonajemcze często przyjmują nagłówek X-Tenant-ID lub pole tenant w treści żądania, aby wybrać dane którego klienta ma dotyczyć wywołanie, i kusi, by uznać tę wartość za wystarczającą, gdy tylko zostanie poprawnie odczytana. Wytyczne OWASP wskazują dwie powiązane pułapki: zakładanie, że identyfikator tenanta jest bezpieczny, bo jest długi lub trudny do odgadnięcia, zamiast przeprowadzenia faktycznej kontroli autoryzacji; oraz dopuszczenie, by ścieżka kodu ograniczona zwykle do tenanta po cichu przechodziła na zapytanie bez ograniczeń, gdy oczekiwana wartość jest nieobecna lub błędna. Każdy z tych błędów pozwala uwierzytelnionemu wywołującemu, który nie należy do żądanego tenanta, dotrzeć do cudzych danych.

Login dowodzi, kim ktoś jest — nie którego tenanta może dotknąć

Uwierzytelnianie odpowiada na inne pytanie niż izolacja. NIST Special Publication 800-210, dotycząca kontroli dostępu dla systemów chmurowych, traktuje izolację tenantów jako właściwość, którą sama platforma musi egzekwować na każdej ścieżce API i danych, gdy jedna instancja oprogramowania obsługuje wielu tenantów — bo klient korzystający z usługi nie kontroluje infrastruktury bazowej. Well-Architected SaaS Lens od AWS opisuje dwa sposoby, w jakie dostawcy to budują: w modelu „silo” każdy tenant ma dedykowane zasoby i ograniczoną rolę wykonawczą — prościej to zrozumieć, trudniej prowadzić na dużą skalę; w modelu „pool” tenanci dzielą infrastrukturę, a izolację trzeba egzekwować wewnątrz logiki aplikacji przy każdym żądaniu. Żaden z modeli nie jest z natury bezpieczniejszy. Liczy się to, czy dostawca potrafi konkretnie pokazać, jak żądanie zostaje powiązane z tenantem wywołującego, zanim dotknięte zostaną jakiekolwiek dane — a nie to, że wywołujący ma działający login.

Dostęp warunkowy zabezpiecza logowanie, nie ścieżkę danych

Microsoft opisuje dostęp warunkowy jako silnik zasad Zero Trust oparty na logice jeżeli-to: jeśli użytkownik, a coraz częściej agent AI, próbuje dotrzeć do zasobu, wcześniej musi zostać spełniony warunek, taki jak zgodność urządzenia, ryzyko logowania czy lokalizacja. To naprawdę użyteczna brama — może powstrzymać skompromitowane poświadczenie przed rozpoczęciem sesji albo przerwać sesję, która zaczyna zachowywać się podejrzanie. Nie ma jednak wglądu w to, jak backend aplikacji decyduje, gdy sesja już istnieje, które rekordy którego klienta dane wywołanie API może odczytać lub zapisać. Jeśli platforma opiera tę decyzję na wartości tenanta podanej przez klienta, dostęp warunkowy zdążył już wykonać swoje zadanie — skutecznie i bez znaczenia dla błędu — zanim decyzja zapadnie. Dobrze skonfigurowana brama logowania przed źle izolowanym API powoduje ten sam wyciek danych, co bez tej bramy. Licencjonowanie Agent 365 od Microsoft rozszerza dostęp warunkowy na agentów AI, ale to samo rozróżnienie między logowaniem a dostępem do danych będzie tam obowiązywać.

SSO wpuszcza ludzi; tylko SCIM wypuszcza odchodzących

Federacja odpowiada na pytanie „kto może się teraz zalogować?”. System for Cross-domain Identity Management, ustandaryzowany jako RFC 7644, odpowiada na inne pytanie: które konta w ogóle powinny nadal istnieć. Dokumentacja provisioningu SCIM od Microsoft opisuje typowy przebieg: miękkie usunięcie u dostawcy tożsamości ustawia atrybut active zasobu użytkownika na false, a odbierająca aplikacja powinna w odpowiedzi wyłączyć lub zarchiwizować to miejsce. Bez integracji SCIM logowanie jednokrotne odchodzącej osoby przestaje działać, ale jej miejsce — i wszelki pozostały dostęp API z nim związany — może pozostać nietknięte. Strona provisioningu też potrzebuje własnego zakresu: token bearer SCIM powinien być wydawany osobno dla każdego tenanta klienta i akceptowany wyłącznie na własnym punkcie końcowym SCIM tego tenanta. Współdzielenie jednego wielotenantowego sekretu SCIM między klientami zamienia jeden wyciekły token w ryzyko deprowizjonowania i przejęcia konta między różnymi klientami.

Wyłączenie konta nie kończy sesji ani tokena

Gdy ktoś odchodzi, a administrator wyłącza jego konto u dostawcy tożsamości, łatwo założyć, że zadanie zostało wykonane. Własne wytyczne Microsoft dotyczące odwoływania dostępu mówią co innego: wyłączenie konta blokuje nowe logowania, ale nie unieważnia automatycznie już wydanych tokenów odświeżania, aktywnych sesji ani ciasteczek przeglądarki. Aby naprawdę odciąć dostęp, trzeba osobno odwołać sesje i tokeny oraz wyczyścić poświadczenia z pamięci podręcznej — a tam, gdzie jest dostępna, Continuous Access Evaluation egzekwuje odcięcie szybciej niż czekanie na naturalne wygaśnięcie tokena. Projekt wytycznych NIST dotyczących zarządzania sesją zwraca uwagę na powiązaną kwestię: posiadanie ważnego tokena dostępu nie dowodzi, że sesja jest wciąż zgodnie z prawem otwarta, a sesje u dostawcy tożsamości i w aplikacji są od siebie niezależne — zakończenie jednej nie kończy automatycznie drugiej. Dlatego OWASP Session Management Cheat Sheet wymaga unieważniania sesji po stronie serwera z limitami czasu zarówno bezczynności, jak i bezwzględnymi, zamiast polegać na tym, że klient odrzuci poświadczenia.

Niektórzy dostawcy MSP wolą powierzyć tę pracę warstwy kontrolnej wyspecjalizowanemu dostawcy, zamiast budować ją i audytować samodzielnie; Auris to europejska platforma IAM-as-a-Service oferująca adaptacyjne MFA, sfederowane SSO i niezmienne dzienniki audytu.

Co zrobić

• Ustalaj przynależność do tenanta na podstawie danych tożsamości po stronie serwera przy każdym żądaniu; nigdy nie ufaj wyłącznie identyfikatorowi, nagłówkowi ani polu treści podanemu przez klienta.
• Egzekwuj tę kontrolę na każdej ścieżce, w której liczy się granica tenanta: odczytach, zapisach, działaniach administracyjnych oraz zadaniach w tle lub uruchamianych przez kolejkę.
• Odrzucaj każdy selektor tenanta, który nie został potwierdzony wobec rzeczywistych przynależności uwierzytelnionego wywołującego, zamiast zakładać, że długi identyfikator jest bezpieczny.
• Traktuj dostęp warunkowy, SSO i wiązanie z tenantem jako oddzielne kontrole z oddzielnymi trybami awarii i testuj je osobno.
• Wdróż SCIM obok SSO, ogranicz każdy token SCIM do jednego tenanta i potwierdzaj, że konto odchodzącej osoby jest wyłączane także w systemie źródłowym, nie tylko u dostawcy tożsamości.
• Przy offboardingu jawnie odwołuj sesje i tokeny odświeżania we wszystkich aplikacjach, z których dana osoba korzystała, zamiast poprzestawać na „koncie wyłączonym”.

Źródła: OWASP Multi Tenant Security Cheat Sheet, NIST SP 800-210, AWS Well-Architected SaaS Lens, Microsoft Learn — omówienie dostępu warunkowego, Microsoft Learn — Use SCIM to provision users and groups, OWASP Session Management Cheat Sheet.