RLS vs dedykowana baza danych na projekt

Najbardziej udokumentowany wzorzec dla Postgres z wieloma dzierżawcami składa się z trzech linii: pojedynczej podstawy, kolumny tenant_id w każdej tabeli, polityki RLS, która porównuje tę kolumnę z wartością wyodrębnioną z JWT. Jest ekonomiczne — pula połączeń, diagram, pojedyncza instancja do uruchomienia — i sprawdza się dobrze, gdy najemcy są liczni, mali i mają niski indywidualny udział.

Kompromis jest prawdziwy: granica między dwoma klientami staje się wyrażeniem SQL, ocenianym tabela po tabeli. Zapomniana polityka na nowym stole, połączenie działające z rolą superużytkownika, uruchomiony na żywo skrypt debugowania – każdy z tych incydentów, niezależnie od tego, jak banalny jest w działaniu, może po cichu ujawnić linie wszystkich najemców jednocześnie. Granica bezpieczeństwa i granica techniczna (podstawa) są zatem dokładnie tym samym.

Od czasu niedawnej konsolidacji dostawcy usług (oznaczonego w kodzie jako „Zadanie 12”), aktywny projekt Postgres w Aurabase podlega dokładnie dwóm architekturom - stare modele z bazą faktycznie współdzieloną pomiędzy kilkoma projektami zostały usunięte ze ścieżki udostępniania.

pub enum ProjectInstanceKind {
    /// Klaster CNPG dedykowany TEN JEDYNEmu projektowi (poziom firmy).
    FullyDedicated,

    /// Baza danych o klastrze CNPG projektu ORGANIZACJA —
    /// udostępniony INNYM projektom tej samej organizacji,
    /// nigdy z organizacją zewnętrzną.
    SharedClusterDedicated,
}

Poziom projektu decyduje, który z nich ma zastosowanie — i to kod decyduje, a nie pole zaznaczone na pulpicie nawigacyjnym:

fn should_provision_dedicated(engine: &str, db_url_encrypted: &Option<String>, plan: &str) -> bool {
    matches!(engine, "postgres" | "postgresql")
        && plan == "enterprise"
        && !non_empty(db_url_encrypted)
}

// Should_route_to_fleet(): dowolny poziom niefirmowy (bezpłatny/pro/zespół)
// drogę do klastra CNPG TWOJEJ WŁASNEJ organizacji, nigdy tej jednej
// z innej — patrz migracja 073, konsolidacja do 2 architektur.

W obu architekturach baza lub klaster nigdy nie obsługują dwóch różnych organizacji — więc pytanie nie brzmi „czy dane są izolowane”, ale „czy Twój projekt ma obliczenia CloudNativePG tylko dla siebie, czy też udostępnia je innym projektom w tej samej organizacji”.

Ta konsolidacja dwóch architektur nastąpiła niedawno: kod prowadził wcześniej dwie dodatkowe ścieżki – „wspólny wzorzec”, w którym kilka projektów współistniało w tej samej bazie danych, izolowanych jedynie za pomocą diagramu, oraz wariant postgrest_dedicated_shared_db. Dedykowana migracja usunęła je i zaostrzyła ograniczenie tabeli projects tylko do dwóch pozostałych wartości, właśnie dlatego, że źródłem błędu opisanego poniżej był wspólny model schematu.

Oddzielna baza danych Postgres stanowi granicę na poziomie połączenia, a nie na poziomie wiersza. Rola aplikacji połączona z bazą danych projektu A po prostu nie może wysyłać zapytań do tabel projektu B — nie ma dla niej otwartej sesji. Ta właściwość obowiązuje nawet wtedy, gdy polityka RLS jest źle napisana, nie ma jej w tabeli lub jest pomijana przez dużą rolę: najgorszy przypadek pozostaje zamknięty w jednej bazie danych.

Depozyt ten nosi także ślad prawdziwego błędu, który ilustruje ryzyko odwrotne. W starym modelu schematu współdzielonego (od czasu wycofania) provision_postgres_schema błędnie przyznał GRANT ALL ... TO PUBLIC prawa do każdego schematu projektu - PUBLIC stosując się do wszystkich ról w bazie danych bez warunków członkostwa, login izolowany dla każdego projektu mógł czytać i zapisywać w schemacie innego. Migracja naprawcza (066) usunęła te prawa z istniejących.

Łatka z 23 sierpnia 2026 roku idzie w tym samym kierunku: REVOKE ALL ON SCHEMA public umieszczony bezwarunkowo przez dostawcę usług został uzależniony od topologii, ponieważ zapewniał rzeczywistą izolację tylko na starym modelu współdzielonej bazy danych — w dwóch obecnych architekturach blokował bez korzyści import zrzutów SQL, które jawnie odwołują się do public.<table>.

Żadne z powyższych nie sprawia, że ​​EPIRB jest bezużyteczny — po prostu zmienia piętra. Po wejściu do bazy danych projektu, Aurabase udostępnia dokładnie konwencję PostgREST przyjętą przez Supabase: trzy funkcje SQL, które odczytują oświadczenia JWT ustawione przez bramę w request.jwt.claims.

create function auth.uid() returns uuid
    language sql stable security definer
    set search_path to 'pg_catalog', 'pg_temp'
    as $$
    select nullif(nullif(current_setting('request.jwt.claims', true), '')::json->>'sub', '')::uuid
$$;

Pomocnicy ci są wykorzystywani w rzeczywistych politykach samego Aurabase — nie tylko udokumentowanych dla Ciebie. Oto polityka, która chroni storage_objects, gdy jest umieszczona w repozytorium (przeformatowana w kilku wierszach do odczytu):

alter table storage_objects enable row level security;

create policy storage_objects_select on storage_objects
  for select using (
    (owner_id = auth.uid())
    or (
      exists (
        select 1 from storage_buckets b
        where (b.name = storage_objects.bucket_name and b.public)
      )
    )
  );

W Twoim własnym schemacie project_<uuid>, tym, który zawiera tabele aplikacji, Aurabase celowo nie umieszcza żadnych polityk w Twoim imieniu — kod dokumentuje to jako „model Supabase”: za RLS Twoich tabel pozostaje Twoja odpowiedzialność, z tymi samymi funkcjami i tą samą składnią.

Postgres natywnie oferuje atrybut roli , BYPASSRLS, który ignoruje wszystkie zasady. Aurabase dobrowolnie używa go w dwóch rodzinach ról: aura_service_role (rola serwera, nigdy nie ujawniana po stronie przeglądarki) i rola administracyjna specyficzna dla każdego projektu, używana podczas operacji DDL, takich jak ALTER SCHEMA ... OWNER TO.

create role aura_service_role nologin bypassrls;
-- Rola serwera: nigdy nie ujawniana po stronie przeglądarki, nigdy członek
-- role z innego projektu.

Rola obsługująca Twoje żądania anon/authenticated — tenant_<uuid> — nie ma żadnego BYPASSRLS: RLS ma do niej zastosowanie normalnie, bez wyjątku. Jako bonus, diagramy systemu specyficzne dla każdego projektu (_auth, _storage, _platform) otrzymują aktywowany RLS bez polityki — zatem domyślnie całkowita odmowa dla jakiejkolwiek roli nieobejściowej, dogłębna obrona na wypadek, gdyby ścieżka aplikacji pewnego dnia przez pomyłkę uzyskała do niej dostęp.

Ta rola serwera jest częścią szerszej sytuacji — wstępnie zdefiniowanych ról, niestandardowego RBAC, dzienników inspekcji — szczegółowo opisano na stronie Bezpieczeństwo i RBAC.

Na poziomie SharedClusterDedicatedkilka projektów tej samej organizacji współistnieje w jednym klastrze CNPG. Fizyczna baza danych oddziela już projekty od siebie, ale role PostgreSQL — one — są obiektami globalnymi dla klastra, a nie dla bazy danych. Dlatego Aurabase dodaje warstwę: oddzielny login PostgreSQL dla każdego projektu.

pub fn project_authenticator_role(project_id: &str) -> String {
    format!("project_{}_authenticator", project_id.replace('-', '_'))
}

// Domyślnie aktywne (F013_PER_PROJECT_AUTHENTICATOR), można dezaktywować
// wyraźnie jako ucieczka awaryjna.

Każdy projekt łączy się za pomocą własnego loginu i jest członkiem tylko swoich ról tenant_<uuid> / tenant_<uuid>_admin — nigdy ról innego projektu w tym samym klastrze. Baza danych już izoluje dane; Ten login dla projektu izoluje również tożsamość, która się z nim łączy, więc incydent w projekcie nie powoduje, że jego login może odziedziczyć inny.

Wybór Aurabase nie jest uniwersalną zasadą – jest to kompromis w konkretnym przypadku: izolowanie od siebie klientów, potencjalnie mających różne wymagania zgodności, na platformie, nad którą nie mają kontroli. Jeśli budujesz własny SaaS, pojawia się to samo pytanie, w innej skali.

• RLS z tenant_id we wspólnej bazie — istotne, gdy twoi najemcy są liczni, indywidualnie o niskiej stawce, a koszt bazy na dzierżawcę byłby nieproporcjonalny. Przetestuj każdą zasadę za pomocą pg_provew każdej tabeli, bez wyjątku.
• Dedykowana baza lub diagram — ma zastosowanie w przypadku, gdy najemca ma własne problemy związane ze zgodnością (zdrowie, HR, sektor publiczny), wolumen uzasadniający izolację wydajności lub koszt wycieku pomiędzy dwoma konkretnymi klientami byłby nieproporcjonalny do kosztu dodatkowej infrastruktury.

Poziom cenowy Aurabase stosuje ten sam arbitraż do swoich własnych klientów: domyślnie współdzielona baza dla organizacji, dedykowany klaster, gdy uzasadnia to wyzwanie związane z projektem. W przypadku wzorców RLS we własnej bazie danych — własność, wielu dzierżawców według organizacji, hierarchia ról — przewodnik RLS w środowisku produkcyjnym szczegółowo opisuje trzy przypadki z testami pgTAP. A jeśli automatycznie wygenerowany interfejs API na Twoim diagramie interesuje Cię poza REST, porównanie pg_graphql z Hasurą i PostGraphile obejmuje drugą połowę powierzchni Postgres odsłoniętej przez Aurabase.