Multitenancy

Multitenancy (wielodzierżawczość) to model architektury, w którym jedna instancja oprogramowania i wspólna infrastruktura obsługują wielu niezależnych odbiorców. Tych odbiorców nazywa się tenantami (dzierżawcami) — zwykle to organizacja albo klient. Każdy tenant widzi własne dane i ustawienia tak, jakby były tylko jego, choć w rzeczywistości dzieli moc obliczeniową, pamięć masową i bazy danych z innymi. Rozdział między tenantami pilnuje samo oprogramowanie (warstwa aplikacji i danych), a nie osobne wdrożenie dla każdego klienta. Na tym modelu opiera się większość usług SaaS i chmury publicznej.

Czym jest tenant i na czym polega wielodzierżawczość?

Tenant to jeden, logicznie wydzielony odbiorca systemu — na przykład firma, dział albo konto klienta — razem z jego użytkownikami, danymi i ustawieniami. W modelu wielodzierżawczym wielu takich odbiorców korzysta z tej samej instancji aplikacji. Sercem całego mechanizmu jest kontekst tenanta: identyfikator (tenant_id), który wędruje przez cały system i decyduje, do jakich danych ma dostęp dane żądanie. Każde zapytanie do bazy, każdy odczyt z pamięci i każde wywołanie API musi być ograniczone do zasobów bieżącego tenanta.

Wielodzierżawczości nie należy mylić ze zwykłym współdzieleniem serwera. Wiele aplikacji może działać na jednej maszynie i nadal nie być multitenantowych. O wielodzierżawczości mówimy dopiero wtedy, gdy jedna instancja aplikacji celowo i bezpiecznie obsługuje wielu klientów, trzymając ich dane osobno.

Czym różni się multitenancy od single-tenancy?

W modelu single-tenant każdy klient dostaje własną, oddzielną kopię aplikacji i własny stos zasobów (instancję, bazę danych, czasem całą infrastrukturę). W modelu multi-tenant jedna instancja obsługuje wielu klientów na wspólnych zasobach, a ich dane rozdziela się logicznie.

• Izolacja: single-tenant daje izolację fizyczną, sprzętową; multi-tenant opiera się głównie na izolacji logicznej, którą pilnuje oprogramowanie.
• Wykorzystanie zasobów: w multitenancy jeden stos służy wielu tenantom, więc sprzęt jest lepiej wykorzystany, a koszt na klienta niższy. W single-tenant więcej zasobów stoi bezczynnie.
• Utrzymanie i aktualizacje: w modelu wielodzierżawczym jedna aktualizacja obejmuje od razu wszystkich tenantów. W single-tenant każdą kopię trzeba aktualizować osobno.
• Dostosowanie: single-tenant pozwala mocniej dostosować system (osobne wersje, własny harmonogram aktualizacji). Multitenancy ogranicza zmiany do konfiguracji w obrębie wspólnego kodu.
• Promień rażenia: w single-tenant awaria lub włamanie dotyka jednego klienta. W multi-tenant błąd w izolacji albo awaria wspólnego elementu może dotknąć wielu tenantów naraz.

Jakie są modele izolacji tenantów?

Izolacja to nie jedna technika, lecz całe spektrum — od pełnego współdzielenia po stos w całości dedykowany. Często opisuje się ją trzema poziomami: silo (zasoby przypisane jednemu tenantowi), pool (zasoby wspólne, rozdzielone logicznie) i bridge (model mieszany, w którym część elementów jest wspólna, a część dedykowana).

Izolacja na poziomie bazy danych

W warstwie danych spotyka się trzy główne wzorce. Różnią się siłą izolacji, kosztem i tym, ile pracy wymagają na co dzień:

1. Wspólna baza, wspólny schemat (shared database, shared schema): wszyscy tenanci korzystają z tych samych tabel, a dane rozdziela kolumna tenant_id i filtrowanie zapytań. Najtańszy i najprostszy wariant, ale najbardziej narażony na wyciek danych, gdy ktoś pomyli filtr albo o nim zapomni — oraz na efekt „głośnego sąsiada”.
2. Wspólna baza, osobne schematy (shared database, separate schemas): każdy tenant ma własny schemat w obrębie jednej bazy. Rozdział jest lepszy niż przy wspólnych tabelach, ale każdą zmianę schematu trzeba nanieść osobno dla każdego tenanta, a kopie zapasowe stają się bardziej skomplikowane.
3. Baza na tenanta (database per tenant): każdy tenant dostaje własną bazę danych. Daje to najwyższą izolację i najłatwiej spełnia wymogi co do miejsca przechowywania danych, ale kosztuje najwięcej i jest najtrudniejsze w obsłudze (trzeba ogarnąć setki, a nawet tysiące baz).

Izolacja na poziomie obliczeń i sieci

Przy uruchamianiu kodu tenantów rozdziela się m.in. przez namespace per tenant w Kubernetes, osobne VPC lub podsieci, polityki sieciowe, RBAC oraz wzajemne uwierzytelnianie usług (mTLS) w siatce usług. W modelach mieszanych zwykli klienci współdzielą infrastrukturę, a klienci o ostrzejszych wymaganiach (zgodność, kontrakty enterprise) dostają stos tylko dla siebie.

Jak działa izolacja i dlaczego nie wystarczy uwierzytelnianie?

Izolacja tenantów to co innego niż uwierzytelnianie i autoryzacja. To, że użytkownik jest zalogowany i ma odpowiednią rolę, wcale nie znaczy, że nie sięgnie po dane innego tenanta — zwykłe logowanie i uprawnienia w ogóle nie znają pojęcia „granicy tenanta”. Izolacja to dodatkowa warstwa, która na podstawie kontekstu tenanta ogranicza dostęp do zasobów wszystkim użytkownikom danego tenanta. W praktyce robi się to przez:

• przekazywanie tenant_id z tokenu (np. z pola w JWT) przez całą ścieżkę żądania;
• obowiązkowe zawężanie zapytań do bieżącego tenanta — najlepiej przez row-level security w bazie, a nie tylko filtr WHERE w kodzie aplikacji;
• polityki dostępu (IAM, RBAC) i reguły sieciowe, które wiążą zasoby z tenantem;
• osobne klucze szyfrujące lub sekrety na tenanta tam, gdzie wymaga tego model zagrożeń.

Jakie ryzyka bezpieczeństwa wiążą się z wielodzierżawczością?

Współdzielenie zasobów kumuluje ryzyko: jedna luka w izolacji może dotknąć wielu tenantów. Najważniejsze zagrożenia to:

• Wyciek między tenantami (cross-tenant leakage): dane jednego tenanta stają się dostępne dla innego — przez brak filtra tenant_id, błąd w autoryzacji, pomyłkę w mapowaniu kontekstu albo podatność typu IDOR.
• Eskalacja i ucieczka z izolacji: próby przekroczenia granicy tenanta przez podmianę identyfikatorów, luki we wspólnej warstwie (cache, kolejki, wspólna baza) lub błędy konfiguracji namespace czy VPC.
• Efekt głośnego sąsiada (noisy neighbor): jeden tenant zużywa nieproporcjonalnie dużo wspólnych zasobów (CPU, operacje I/O, połączenia do bazy) i psuje wydajność lub dostępność pozostałym. Łagodzi się to limitami zasobów, kwotami i ograniczaniem tempa zapytań (rate limiting).
• Wspólny promień rażenia: awaria lub włamanie do wspólnego elementu (baza, węzeł, klaster) może objąć wielu tenantów naraz.
• Zgodność i miejsce przechowywania danych: reżimy takie jak PCI DSS, HIPAA czy wymogi co do lokalizacji danych mogą wymuszać mocniejszą izolację (osobny schemat, osobną bazę albo dedykowany stos) dla wybranych tenantów.

Dlaczego multitenancy jest istotne dla monitorowania i wykrywania zagrożeń?

W środowisku wielodzierżawczym widoczność i telemetria muszą wiedzieć, do którego tenanta należą. Dla zespołów SOC, monitoringu sieci i systemów klasy NDR oznacza to kilka konkretnych wyzwań:

• Przypisanie do tenanta: logi, metryki, przepływy sieciowe (np. NetFlow/IPFIX) i zdarzenia bezpieczeństwa powinny nieść kontekst tenanta. Dzięki temu incydent da się przypisać właściwemu odbiorcy i przeanalizować w oderwaniu od reszty.
• Wykrywanie ruchu poprzecznego: komunikacja przekraczająca granicę tenanta tam, gdzie nie powinna (albo nietypowy dostęp do wspólnej bazy), to sygnał możliwego wycieku między tenantami lub naruszenia izolacji.
• Wykrywanie głośnego sąsiada: nagłe skoki w zużyciu wspólnych zasobów przez jednego tenanta mogą oznaczać nadużycie, błędną konfigurację albo atak (np. DoS na wspólny element).
• Rozdział widoczności: raporty i pulpity muszą pilnować, żeby jeden tenant nie zobaczył telemetrii innego — izolacja obowiązuje także w warstwie monitoringu, nie tylko w danych produkcyjnych.
• Higiena konfiguracji: stałe sprawdzanie polityk sieciowych, reguł RBAC i granic namespace/VPC zmniejsza ryzyko, że błąd konfiguracji otworzy ścieżkę między tenantami.

Dowiedz się więcej

• Zaawansowane metody ochrony przed atakami DDoS w firmach — W multitenancy trzeba wykrywać ataki DDoS osobno dla każdego najemcy i izolować ich skutki.
• Architektura Zero Trust – rola widoczności sieci i mikrosegmentacji w bezpieczeństwie — Zero Trust wspiera multitenancy przez ścisłą segmentację i kontrolę dostępu między najemcami.
• Multitenancy w Sycope — Artykuł opisuje model multitenancy, czyli współdzielenie jednej platformy przez wielu odseparowanych klientów.
• Monitoring sieci i network visibility – analiza ruchu sieciowego jako podstawa visibility cybersecurity — Widoczność ruchu pomaga przypisać aktywność i incydenty do właściwego najemcy.
• Błędy konfiguracji sieci – jak unikać network configuration errors i poprawić konfigurację routera — Błędy konfiguracji mogą naruszyć izolację między najemcami w środowisku multitenant.
• Compliance i regulacje z Sycope — Compliance w multitenancy obejmuje rozdzielne dane, dostępy i audyt dla każdego najemcy.