Przy każdym żądaniu i zadaniu ustalajcie wiarygodny kontekst organizacji, filtrowanie egzekwujcie centralnie w warstwie danych, a ten sam kontekst przenoście do cache, plików, wyszukiwania i kolejek. Administrację, eksport i wsparcie poddawajcie audytowi, a próby dostępu między klientami testujcie automatycznie.
Wielodzierżawcza (multitenant) aplikacja webowa obsługuje wiele organizacji klientów na wspólnej platformie. Najpoważniejszym ryzykiem jest to, że użytkownik lub proces zobaczy albo zmieni dane innego klienta. Błąd nie musi tkwić wyłącznie w zapytaniu do bazy danych. Kontekst może zostać utracony w cache, pliku, eksporcie, indeksie wyszukiwania, kolejce lub narzędziu administracyjnym.
Bezpieczny projekt wymaga jednoznacznej tożsamości najemcy, wymuszenia izolacji we wszystkich warstwach oraz testów scenariuszy negatywnych. Stopień fizycznego rozdzielenia zależy od ryzyka, wymagań umownych, wolumenu i złożoności operacyjnej. Jedna baza danych nie jest automatycznie niebezpieczna, a osobna baza sama w sobie nie usunie błędów w zarządzaniu tożsamością czy administracji.
Wybierz model najemcy i członkostwa
Zdefiniuj, czym jest najemca (tenant): firma, przestrzeń robocza, projekt lub inna granica bezpieczeństwa. Użytkownik może należeć do jednej lub wielu organizacji i mieć w każdej inną rolę. Aktywny kontekst musi być zrozumiały zarówno w interfejsie, jak i na serwerze. Zmiana organizacji nie może pozostawiać starych danych na ekranie ani w cache.
Członkostwo, zaproszenie, dezaktywacja i przeniesienie własności to procesy domenowe objęte audytem. Nie ustalaj najemcy (tenanta) wyłącznie na podstawie ID przesłanego przez klienta. Serwer powiąże go ze zweryfikowaną tożsamością i aktualnym członkostwem. W przypadku własnej domeny lub subdomeny sprawdź, czy routing odpowiada temu samemu bezpiecznemu kontekstowi.
Wymuszaj izolację w warstwie danych
Każdy rekord zawiera tożsamość najemcy (tenanta) lub należy do struktury, z której można ją bezpiecznie wyprowadzić. Zapytania muszą stosować tę granicę centralnie, a nie polegać na pamięci programisty przy każdym endpoincie. Mechanizmy bazodanowe mogą dodać warstwę obronną, ale ich konfiguracja i konta uprzywilejowane wymagają własnych testów.
Przy zapisie proszę sprawdzić, czy wszystkie powiązane obiekty należą do tego samego najemcy. Obcy identyfikator w pozycji zamówienia nie może zostać zaakceptowany tylko dlatego, że użytkownik jest właścicielem samego zamówienia. Unikalne klucze, dopasowywanie i agregacje często wymagają zakresu najemcy. Migracje muszą zachować tożsamość również w przypadku starych rekordów.
- obowiązkowa tożsamość najemcy przy każdym rekordzie
- centralne filtrowanie i autoryzacja
- kontrola relacji między obiektami
- odpowiednia warstwa ochronna bazy danych
Przenieś kontekst do cache, kolejek i plików
Klucz pamięci podręcznej musi uwzględniać najemcę (tenant) i inny istotny zakres. W przeciwnym razie pierwszy klient może zapisać wartość, którą otrzyma drugi. Ta sama zasada dotyczy obliczeń, limitów żądań i wyników wyszukiwania. Przy unieważnianiu należy usuwać wyłącznie właściwą przestrzeń i nie wyprowadzać granicy z niezweryfikowanych danych wejściowych.
Wiadomość w kolejce zawiera najemcę (tenant), tożsamość aktora i bezpieczne uprawnienie do wykonania zadania. Proces roboczy (worker) ponownie weryfikuje kontekst, ponieważ członkostwo mogło się zmienić. Pliki należy przechowywać w odizolowanej ścieżce z autoryzowanym sposobem pobierania. Publicznie możliwy do odgadnięcia URL nie może być jedynym zabezpieczeniem dokumentu.
Proszę chronić administrację, wsparcie i eksporty
Globalna administracja niesie wyższe ryzyko niż zwykłe konto. Ogranicz liczbę uprawnionych osób, stosuj silne uwierzytelnianie i audytuj zmianę aktywnego klienta. Zespół wsparcia powinien otrzymać tylko niezbędny widok i ograniczoną czasowo możliwość działania w imieniu użytkownika. Interfejs wyraźnie oznacza, w którym najemcy wykonywana jest ingerencja.
Eksport, kopia zapasowa i hurtownia analityczna mogą obejść zabezpieczenia ekranów aplikacji. Każdy wynik filtruj według uprawnień i przed wysłaniem sprawdź jego zakres. Dłużej generowany eksport ponownie weryfikuje dostęp przy pobieraniu. Przy zakończeniu współpracy z klientem określ eksport, retencję i usunięcie danych, łącznie z kopiami, zgodnie z umowami i fachową oceną.
Testuj izolację automatycznie i operacyjnie
Zestaw testowy tworzy co najmniej dwie organizacje o podobnych identyfikatorach i sprawdza odczyt, edycję, wyszukiwanie, eksport, załącznik, API oraz kolejkę ponad granicą między nimi. Proszę zmieniać ID w URL, treści żądania, nagłówku i cache. Należy zweryfikować zarówno administratora organizacji, jak i globalne wsparcie. Każda nowa ścieżka danych dodaje test negatywny.
W logach proszę śledzić odrzucone próby i nietypowe przełączanie, bez zapisywania wrażliwej treści. Procedura obsługi incydentów pozwala odizolować najemcę, zabezpieczyć dowody i określić zakres możliwego wycieku. Przy zmianie architektury należy powtórzyć model zagrożeń. Izolacja jest ciągłą właściwością całego systemu, a nie jednorazowym filtrem w bazie danych.
- obce ID w każdym publicznym interfejsie API
- cache wypełniony danymi innego najemcy
- eksport i plik dostępny po zmianie członkostwa
- zadanie asynchroniczne z nieprawidłowym kontekstem organizacji
- globalne wsparcie przełączone na niewłaściwego klienta
Najczęstsze pytania
Czy każdy klient potrzebuje własnej bazy danych?
Nie zawsze. Model zależy od ryzyka, wymagań, wolumenu i sposobu eksploatacji. Wspólna baza danych wymaga konsekwentnej izolacji; osobna baza z kolei – prawidłowego routingu, tożsamości, aktualizacji i monitoringu.
Czy subdomena jest granicą bezpieczeństwa najemcy?
Jest przydatną informacją wejściową do routingu, ale serwer musi powiązać kontekst ze zweryfikowaną tożsamością i członkostwem. Sama nazwa hosta nie zastępuje autoryzacji każdego zasobu.
Jak testować wyciek danych między klientami?
Należy utworzyć dwie odizolowane organizacje i automatycznie testować obce ID we wszystkich interfejsach, w tym w eksporcie, plikach, wyszukiwaniu, cache i zadaniach asynchronicznych, a nie tylko na jednym ekranie.
Źródła i dalsza lektura
Adam Antoni vyvíja weby, aplikácie a softvér na mieru. Prepája firemné systémy, automatizuje procesy a vytvára AI agentov. Pôsobí v Spišskej Novej Vsi a spolupracuje s firmami na celom Slovensku.
