Jak zabezpieczyć dane wielu firm w jednej aplikacji z PostgreSQL?

Aplikacja abonamentowa obsługująca wielu klientów jest kusząca, bo jedna aplikacja i jedna infrastruktura pracują dla wielu firm. Zamiast utrzymywać osobną bazę dla każdej organizacji, trzymasz dane w tych samych tabelach, zwykle z kolumną identyfikującą firmę. Koszt infrastruktury spada, migracje są prostsze, a wdrażanie funkcji jest szybsze.

Takie podejście ma jednak jedno brutalne ryzyko: wyciek danych między klientami. Jeśli klient A zobaczy faktury, użytkowników, notatki z obsługi klienta albo dokumenty klienta B, problem nie jest "bugiem". To incydent bezpieczeństwa, utrata zaufania, potencjalne konsekwencje prawne i rozmowa z największym klientem, której nikt nie chce prowadzić.

Dlatego w systemach dla klientów firmowych nie wystarczy mówić "nasza aplikacja zawsze dodaje filtr firmy". Wystarczy jeden punkt dostępu, raport, eksport CSV, zadanie w tle, widok administratora albo surowe zapytanie bez filtra. Kontrola dostępu do pojedynczych wierszy w PostgreSQL nie usuwa całego ryzyka, ale przenosi część izolacji z pamięci programisty do silnika bazy.

Oficjalna dokumentacja PostgreSQL opisuje kontrolę dostępu do wierszy jako polityki ograniczające, które wiersze mogą być zwracane, wstawiane, aktualizowane albo usuwane. Po włączeniu tej ochrony normalny dostęp do tabeli musi być dopuszczony przez politykę. Jeśli nie ma polityki, baza domyślnie blokuje dostęp: wiersze nie są widoczne ani modyfikowalne.

Dla aplikacji obsługującej wiele firm oznacza to prostą ideę: tabela `invoices` może mieć politykę porównującą identyfikator firmy w wierszu z kontekstem aktualnej sesji. Aplikacja po uwierzytelnieniu ustawia kontekst sesji, a baza automatycznie dodaje filtr do zapytań. Nawet jeśli kod zapomni `WHERE tenant_id = ...`, normalny użytkownik nie powinien zobaczyć cudzych wierszy.

To brzmi jak magia, ale nią nie jest. Taka polityka działa dla konkretnej tabeli, roli i komendy. Właściciel tabeli oraz role z uprawnieniem omijania tych polityk mogą je ominąć. Dlatego projekt produkcyjny musi obejmować role aplikacyjne, wymuszenie polityk także dla właściciela tabeli, testy migracji oraz jasny podział między połączeniami aplikacji, administratora i utrzymania.

Najczęstszy błąd nie leży w samej polityce bazy, tylko w ustawianiu kontekstu. Zaplecze po autoryzacji musi wiedzieć, która firma wykonuje żądanie, a potem ustawić ją w sesji PostgreSQL. W praktyce używamy kontekstu żądania w NestJS, strażników autoryzacji i warstwy klienta bazy, która nie pozwala wykonać zapytania bez ustawionego kontekstu tam, gdzie jest wymagany.

Przy puli połączeń trzeba uważać: połączenie jest używane ponownie. Dlatego kontekst firmy powinien być ustawiany na czas transakcji lub żądania i resetowany. W PostgreSQL często stosuje się `set_config('app.current_tenant', tenantId, true)` w transakcji, gdzie trzeci argument `true` ogranicza ustawienie do aktualnej transakcji.

Jeżeli używasz Prisma, Drizzle, Kysely albo surowego `pg`, zasada jest ta sama: biblioteka do zapytań nie jest granicą bezpieczeństwa. Pomaga budować zapytania, ale izolacja w PostgreSQL wymaga świadomego cyklu życia połączenia, testów i zabezpieczeń blokujących przypadkowe użycie superużytkownika albo danych dostępowych z prawem omijania polityk.

Najprostsza polityka porównująca identyfikator firmy jest tylko początkiem. Produkcyjny produkt abonamentowy potrzebuje osobnych zasad dla odczytu, tworzenia, zmiany i usuwania danych, bo widoczność wiersza i prawo do jego utworzenia lub zmiany to nie to samo. PostgreSQL pozwala używać `USING` dla dostępu i `WITH CHECK` dla danych zapisywanych.

Przykład: użytkownik może widzieć faktury swojej firmy, ale nie może zmienić identyfikatora firmy na fakturze przez dane wysłane w formularzu lub żądaniu. `WITH CHECK` powinien wymusić, że nowy lub zaktualizowany wiersz nadal należy do aktualnego klienta. Dla tabel wspólnych, jak plany subskrypcji, przełączniki funkcji albo katalog publiczny, polityka może być inna albo izolacja na poziomie wierszy nie jest właściwą granicą.

Ważne są też role. Aplikacja produkcyjna nie powinna łączyć się jako właściciel tabel ani superużytkownik. Osobne role dla działania aplikacji, migracji, raportów tylko do odczytu i awaryjnego administratora zmniejszają ryzyko, że jedna biblioteka lub skrypt wyłączy całą izolację.

Izolacja w bazie musi mieć testy negatywne. Nie wystarczy sprawdzić, że klient A widzi swoje faktury. Trzeba sprawdzić, że klient A nie widzi faktur B, nie może wstawić wiersza należącego do B, nie może przepisać swojego wiersza na B i nie dostaje danych przez relację, widok, funkcję SQL, eksport, wyszukiwarkę albo zadanie w tle.

Dobre testy tworzą dwóch klientów, dwóch użytkowników, dane o podobnym kształcie i uruchamiają scenariusze przez aplikację oraz bezpośrednio na warstwie komunikacji z bazą. Warto testować też migracje: nowa tabela z danymi klientów nie może wejść na produkcję bez polityki dostępu i indeksu po identyfikatorze firmy.

Supabase przypomina, że kontrola dostępu do wierszy jest mocna, ale trzeba ją włączyć. PostgreSQL przypomina, że jeśli ochrona jest włączona, a brak polityki, baza domyślnie blokuje dostęp. To dobre zabezpieczenie, pod warunkiem że proces przeglądu wykrywa tabele bez polityk, zanim klienci odkryją brak danych albo cudze dane po wdrożeniu.

Najczęstsze pytanie dyrektora technologii brzmi: czy polityki wierszy spowolnią bazę? Odpowiedź brzmi: mogą, jeśli są złożone, odwołują się do innych tabel bez indeksów albo wymagają funkcji wykonywanych dla każdego wiersza. Prosta polityka po `tenant_id` na dobrze indeksowanych tabelach jest zwykle dużo mniej problematyczna niż ręczne filtry rozsiane po całym kodzie.

Projektuj izolację od początku: `tenant_id` jako podstawowa kolumna w tabelach należących do klienta, indeksy z `tenant_id`, świadome ograniczenia unikalności, partycjonowanie dopiero po pomiarach, osobne ścieżki dla tabel globalnych i unikanie polityk, które robią ciężkie podzapytania dla każdego wiersza.

Warto też pamiętać, że izolacja w PostgreSQL nie rozwiązuje wszystkich problemów danych. Analityka, hurtownie, zdarzenia, indeks wyszukiwarki i pamięć podręczna muszą mieć własną izolację klientów. Jeżeli Elasticsearch albo Redis dostają klucz bez prefiksu klienta, ochrona w PostgreSQL nie uratuje danych poza bazą.

Polityki wierszy są mocnym zabezpieczeniem procesu, ale nie są strategią bezpieczeństwa samą w sobie. Jeżeli klient wymaga osobnego regionu danych, osobnego tworzenia i odtwarzania kopii zapasowych, dedykowanego klucza szyfrowania, własnych okien utrzymaniowych albo certyfikacji, wspólne tabele z politykami wierszy mogą nie wystarczyć. Wtedy potrzebujesz osobnej bazy albo podejścia mieszanego.

Izolacja w bazie nie zastępuje też autoryzacji biznesowej. To, że użytkownik należy do organizacji klienta, nie znaczy, że może widzieć listę płac, eksportować wszystkie faktury albo usuwać projekt. Uprawnienia ról, plan subskrypcji, przełączniki funkcji i status konta nadal muszą być obsłużone w aplikacji i często odzwierciedlone w politykach.

Nie używaj izolacji w bazie jako pretekstu do pominięcia analizy zagrożeń. Trzeba przeanalizować administratorów, obsługę klienta, połączenia z innymi systemami, zdarzenia zewnętrzne, zadania w tle, kopie zapasowe, narzędzia analityczne, audyt, logi i narzędzia diagnostyczne. Wyciek może przyjść nie tylko z publicznego punktu dostępu aplikacji, ale też z "pomocnego" eksportu dla działu obsługi klienta.

Część serwerowa aplikacji dla wielu klientów z NestJS, izolacją w PostgreSQL, autoryzacją, podstawowym panelem i płatnościami zwykle zaczyna się od 160 000-300 000 PLN za sensowną pierwszą wersję. Zaawansowany produkt dla klientów firmowych z procesami, audytem, rozliczeniami, połączeniami z innymi systemami, importami danych i raportowaniem może iść wyżej. Sama polityka w bazie nie jest droga. Droga jest pewność, że nikt jej nie obejdzie.

Największe składniki kosztu to struktura danych, role i zasady uprawnień, migracje, testy izolacji, pula połączeń, połączenia z innymi systemami, audyt logów, narzędzia administracyjne i narzędzia obsługi klienta, import istniejących danych oraz monitorowanie działania. Jeżeli produkt ma funkcje AI lub wyszukiwanie w dokumentach, trzeba też rozwiązać izolację klientów w wektorach, wyszukiwaniu kontekstu i pamięci podręcznej.

GMI daje wstępną wycenę w 48h, ale stałą cenę dopiero po rozpoznaniu biznesu, projektu i technologii. W tym rozpoznaniu ustalamy sposób izolacji klientów, mapę danych, analizę zagrożeń, zakres pierwszej wersji, polityki dostępu w bazie, testy i ryzyka utrzymania. To uczciwsze niż obietnica "bezpiecznej aplikacji" na podstawie samego stosu technologicznego.

Zaczynamy od rozpoznania biznesu, projektu i technologii: mapujemy klientów, role, dane, połączenia z innymi systemami, rozliczenia, operacje administracyjne i ryzyka bezpieczeństwa. Dopiero potem decydujemy, czy system ma używać wspólnych tabel z politykami wierszy, osobnych baz, podejścia mieszanego czy kilku wariantów naraz. To ważne, bo zła decyzja o izolacji potrafi wymusić drogą migrację po pierwszych dużych klientach.

Technicznie najczęściej używamy NestJS, PostgreSQL, Prisma lub innej typowanej biblioteki do zapytań, Redis tam, gdzie potrzebna jest pamięć podręczna albo kolejka, Next.js dla panelu i React Native, jeśli produkt ma część mobilną. Kontrola dostępu w PostgreSQL jest częścią większej architektury: autoryzacja, dziennik audytu, monitorowanie działania, testy kontraktów oraz bezpieczne narzędzia obsługi klienta.

Biznesowo klient dostaje własność kodu źródłowego, brak uzależnienia od dostawcy, stałą cenę po rozpoznaniu projektu i jasny sposób utrzymania. To szczególnie ważne w produkcie abonamentowym, bo bezpieczeństwo nie jest jednorazową funkcją. Każda nowa tabela, połączenie z systemem i funkcja AI musi dalej respektować granicę klienta.