Multi-tenancy to model ownership
Pierwszym błędem w multi-tenant SaaS jest traktowanie tenancy jak kolumny w bazie. Prawdziwy problem to decyzja kto posiada każdy zasób, jaki organization context obowiązuje i jak access jest egzekwowany na każdej granicy.
1. Modeluj organizations i memberships
Użytkownik może należeć do jednej lub wielu organizacji. Membership niesie role, status i ewentualną konfigurację specyficzną dla organization. Zasoby powinny jawnie wskazywać tenant boundary.
2. Świadomie wybierz isolation model
Typowe modele to shared database z tenant-scoped records, schema/database isolation dla mocniejszych granic oraz hybrid dla wybranych klientów. Decyzja powinna wynikać z ryzyka, skali, operations i data residency.
3. Authorization musi być tenant-aware
Każda chroniona akcja powinna odpowiadać na dwa pytania: czy actor może wykonać akcję oraz czy target resource należy do aktywnego organization context?
4. Dodaj defense in depth tam, gdzie uzasadnia je ryzyko
Application authorization pozostaje główną bramą domain. Database-level controls, np. PostgreSQL Row-Level Security, mogą dodać kolejną granicę w wybranych architekturach, ale nie zastępują spójnego modelu authorization produktu.
5. Tenant context wpływa na więcej niż dane
Billing, entitlements, feature flags, notification preferences, branding, integrations, audit logs i support workflows często zależą od organization context.
Pytania operacyjne przed launch
- Jak tworzone i usuwane są organizations?
- Jak działają invitations i transfer ownership?
- Co dzieje się przy zmianie organizacji przez usera?
- Jak background jobs są scoped do tenantów?
- Jak support może inspectować tenant bez omijania audytu?