Jak zabezpieczyć dane w architekturze Multi-Tenant SaaS? (PostgreSQL RLS w 2026)
TL;DR - Szybkie podsumowanie
- Koszmar SaaS: Największe ryzyko B2B to wyciek krzyżowy (klient A widzi dane B). Samo filtrowanie w kodzie backendu to częsta przyczyna.
- Silnik bazy: PostgreSQL Row-Level Security (RLS) tnie dostęp do wierszy w bazie - przy złym zapytaniu inny tenant nie wypływa.
- Stack GMI: SaaS i CRM skalujemy na Node.js, NestJS i PostgreSQL - gotowość na duży ruch.
- Inwestycja: DDT przed kodem; GMI Software jako jedyny polski software house w tej formule daje gwarancję ceny stałej na wdrożenie.
Problem: Wyciek danych niszczy reputację SaaS w 24 godziny
Pewnego dnia na produkcję trafia aktualizacja. Junior zapomina warunku WHERE tenant_id = … w jednym zapytaniu. Kluczowy klient po zalogowaniu widzi listę płac, faktury i kontakty największej konkurencji.
To utrata zaufania rynku i ryzyko kar RODO. W GMI Software, software house z Gdańska z ponad 16-letnim doświadczeniem w systemach B2B, wiemy, że w architekturze multi-tenant bezpieczeństwo nie może opierać się na pamięci programisty. Musi być wbudowane w fundament bazy danych.
Multi-tenant vs single-tenant - co wybrać w SaaS?
Zanim polityki RLS, decyzja architektoniczna:
- Single-tenant (osobna baza na klienta): Maksymalna izolacja, ale kosztowne utrzymanie i migracje schematu N razy. Kiedy? Nisza regulowana (bankowość, wojsko).
- Multi-tenant (wspólna baza): Jeden PostgreSQL, rozróżnienie przez `tenant_id`, niższy koszt AWS RDS i jedna migracja schematu dla wszystkich. Ryzyko: pomylenie danych przy filtrowaniu tylko w aplikacji.
Rozwiązanie GMI: Multi-tenant z RLS w silniku PostgreSQL - ekonomia skali bez polegania wyłącznie na ORM.
Czym jest PostgreSQL RLS i dlaczego to standard w 2026?
Row-Level Security to polityki w PostgreSQL. Zamiast wierzyć, że backend zawsze doda filtr, reguły siedzą w bazie.
Po logowaniu backend otwiera sesję i ustawia kontekst (np. `SET app.current_tenant = 'XYZ'`). Każde `SELECT` dostaje niewidzialny filtr - nawet awaryjne `SELECT * FROM invoices` zwraca tylko wiersze tenanta XYZ.
Sprawdza się w systemach wielopodmiotowych, m.in. Berg System CRM.
Ile kosztuje i jak długo trwa backend pod SaaS?
Architektura to jednorazowy koszt, który chroni wycenę firmy:
- Budżet: Backend NestJS + PostgreSQL RLS + płatności (np. Stripe) - MVP zwykle 160 000-240 000 PLN; zaawansowany SaaS 250 000-350 000 PLN.
- Time-to-market: Rdzeń API + podstawowy panel (Next.js lub React Native) typowo 3-6 miesięcy.
Zamiast palić budżet na nieograniczone R&D - DDT, schemat bazy i polityki RLS, potem gwarancja ceny stałej. Po opłaceniu etapów: 100% praw do repo, zero vendor lock-in.
Najczęściej zadawane pytania
- Czym jest architektura Multi-Tenant w aplikacjach SaaS?
- To podejście, w którym jedna instancja aplikacji i jedna fizyczna baza danych (np. PostgreSQL) obsługuje wielu różnych klientów (tzw. tenants). Dane są rozróżniane zazwyczaj za pomocą klucza obcego (np. tenant_id). Jest to najbardziej opłacalny i skalowalny model biznesowy na rynku.
- Dlaczego filtrowanie danych SaaS w kodzie backendu jest niebezpieczne?
- Filtrowanie w kodzie aplikacji (np. poprzez narzędzia ORM w Node.js) wymaga od programisty dyscypliny, aby do każdego zapytania w systemie dopisać warunek sprawdzający identyfikator klienta. Jeden ludzki błąd w tysiącach linii kodu prowadzi do katastrofalnego w skutkach wycieku danych między firmami.
- Jak działa PostgreSQL RLS (Row-Level Security)?
- RLS to wbudowana funkcja silnika bazy danych PostgreSQL. Pozwala zdefiniować na poziomie samej bazy sztywne reguły (polityki), które automatycznie filtrują wiersze na podstawie aktualnego kontekstu sesji użytkownika. Aplikacja nie może w żaden sposób obejść tego zabezpieczenia.
- Z jakim stackiem technologicznym GMI Software łączy PostgreSQL?
- Najwyższą wydajność dla aplikacji B2B i SaaS uzyskujemy łącząc PostgreSQL z frameworkiem backendowym NestJS (uruchamianym w środowisku Node.js). Usługi pakujemy w kontenery Docker i hostujemy w chmurach o wysokiej dostępności (np. AWS ECS), aby zapewnić skalowalność.
- Ile czasu zajmuje zaprojektowanie architektury SaaS w procesie DDT?
- Warsztaty DDT (Discovery, Design & Technology) w GMI Software zajmują zazwyczaj od 3 do 5 tygodni. W tym czasie analitycy biznesowi i architekci systemowi tworzą schematy baz danych, definiują polityki bezpieczeństwa RLS oraz projektują makiety (UX/UI), co kończy się wydaniem gwarancji ceny stałej.
Treść zaktualizowano: 31 marca 2026