Supabase RLS: Zabezpečte své AI aplikace správně

Row Level Security (RLS) v Supabase představuje klíčový bezpečnostní mechanismus pro AI aplikace pracující s citlivými uživatelskými daty. Tento podrobný tutoriál vás provede od úplných základů po pokročilé implementační vzory pro multi-tenant a role-based architektury s důrazem na praktické příklady.

Proč je RLS absolutně kritický pro AI aplikace

Moderní AI aplikace pracují s mimořádně citlivými daty - uživatelské dokumenty, konverzační historie, business informace a osobní údaje. Bez správně nakonfigurovaného Row Level Security může jediné neautorizované API volání odhalit data všech uživatelů v systému. RLS zajišťuje, že každý databázový dotaz je automaticky filtrován podle oprávnění aktuálně přihlášeného uživatele, bez ohledu na to, jak je dotaz formulován na frontendové straně aplikace.

Typické bezpečnostní zranitelnosti bez RLS

IDOR (Insecure Direct Object Reference) je zranitelnost umožňující útočníkovi přístup k cizím datům pouhou změnou ID v URL nebo API requestu. Privilege escalation nastává, když běžný uživatel získá administrátorská práva manipulací s parametry. Data leakage představuje situaci, kdy API vrací více dat než by mělo na základě oprávnění uživatele. RLS elegantně řeší všechny tyto problémy přímo na databázové úrovni, kde je nelze obejít z aplikačního kódu.

Základy Row Level Security v Supabase

Vytvoření tabulky a povolení RLS

Prvním krokem je vytvoření tabulky s vhodnou strukturou. Typická tabulka documents obsahuje id jako UUID s automatickým generováním, user_id jako cizí klíč na auth.users tabulku, title a content pro vlastní data, a created_at timestamp. Po vytvoření tabulky je kritické ihned povolit RLS pomocí příkazu ALTER TABLE documents ENABLE ROW LEVEL SECURITY. Bez tohoto příkazu jsou data veřejně přístupná přes Supabase API.

Základní bezpečnostní politiky

Pro kompletní zabezpečení potřebujete definovat politiky pro všechny CRUD operace. Politika pro SELECT operaci používá USING klauzuli s podmínkou auth.uid() = user_id, která zajistí, že uživatel vidí pouze své vlastní dokumenty. INSERT politika využívá WITH CHECK klauzuli ověřující, že nový záznam patří aktuálnímu uživateli. UPDATE politika kombinuje USING pro filtrování editovatelných záznamů a WITH CHECK pro validaci nových hodnot. DELETE politika používá USING pro omezení mazání pouze na vlastní záznamy.

Pokročilé RLS vzory pro enterprise aplikace

Multi-tenant architektura pro SaaS aplikace

Pro SaaS aplikace s více organizacemi potřebujete komplexnější strukturu. Tabulka organizations obsahuje základní informace o organizacích. Tabulka org_members definuje členství uživatelů v organizacích s rolemi owner, admin a member. Dokumenty v tabulce org_documents patří organizaci místo jednotlivému uživateli. Helper funkce is_org_member přijímá org_id a kontroluje existenci členství aktuálního uživatele v dané organizaci. RLS politika pak používá tuto funkci pro kontrolu přístupu.

Role-based access control (RBAC) implementace

Pro granulární kontrolu přístupu implementujte RBAC pomocí helper funkce has_org_role, která přijímá org_id a required_role parametry. Funkce kontroluje hierarchii rolí - owner má všechna oprávnění, admin má oprávnění admina i membera, member má pouze základní oprávnění. Politiky pak mohou vyžadovat specifickou roli pro různé operace - například pouze admins mohou upravovat dokumenty, ale všichni members je mohou číst.

Testování RLS politik - manuální i automatizované

Manuální testování v SQL konzoli

Pro manuální testování můžete simulovat konkrétního uživatele pomocí SET request.jwt.claims s JSON objektem obsahujícím sub claim s UUID uživatele. Následně spusťte testovací SELECT dotazy a ověřte, že vracejí pouze očekávaná data. Testujte také INSERT s cizím user_id - měl by selhat s chybou violating row-level security policy.

Automatizované testy v TypeScript

Pro kontinuální testování implementujte automatizované testy s Supabase client knihovnou. V beforeEach hooku se přihlaste jako testovací uživatel. Test user can only see own documents ověří, že všechny vrácené dokumenty patří aktuálnímu uživateli. Test user cannot insert for other user ověří, že INSERT s cizím user_id vrací error. Tyto testy spouštějte v CI/CD pipeline při každé změně RLS politik.

Debugging a troubleshooting RLS problémů

Nejčastější problémy a jejich řešení

Prázdné výsledky dotazu často znamenají, že RLS blokuje všechna data - zkontrolujte, zda auth.uid() vrací očekávanou hodnotu a zda existují záznamy splňující podmínky politiky. Infinite recursion nastává, když politika volá sama sebe - řešením je použití SECURITY DEFINER atributu na helper funkcích. Pomalé dotazy mohou být způsobeny absencí indexů na sloupcích používaných v RLS politikách - přidejte vhodné indexy.

Debugging pomocí EXPLAIN ANALYZE

Pro analýzu výkonu RLS politik použijte EXPLAIN s parametry ANALYZE a BUFFERS. Výstup ukáže, jak PostgreSQL vyhodnocuje RLS podmínky a zda efektivně využívá indexy. Hledejte Seq Scan na velkých tabulkách - to indikuje potřebu přidat index. Filter rows removed metrika ukazuje, kolik řádků RLS odfiltrovala.

Performance optimalizace RLS politik

Indexování pro RLS

Vždy vytvořte indexy na sloupcích používaných v RLS politikách. Pro multi-tenant aplikace vytvořte composite index na org_members(user_id, org_id) pro rychlé lookup členství. Pro dokumenty vytvořte index na user_id nebo org_id podle vaší architektury. Partial indexes mohou dále optimalizovat specifické query patterns.

SECURITY DEFINER funkce

Helper funkce pro RLS by měly používat SECURITY DEFINER atribut, který zajistí, že funkce běží s právy jejího tvůrce (typicky superuser) místo aktuálního uživatele. To zabrání rekurzivnímu vyhodnocování RLS při volání funkce z politiky a výrazně zlepší performance.

Materialized views pro komplexní permissions

Pro velmi komplexní permission modely zvažte použití materialized views, které pre-computují přístupová práva. View se refreshuje při změnách v permission struktuře a RLS politiky pak pouze kontrolují jednoduchou podmínku proti této view.

Závěr a doporučení pro implementaci

Row Level Security je naprosto nezbytný bezpečnostní mechanismus pro každou AI aplikaci pracující s uživatelskými daty. Investujte čas do správného návrhu RLS politik od samého začátku projektu - přidávání RLS do existující aplikace bez něj je výrazně náročnější a rizikovější. Důkladně testujte všechny politiky manuálně i automatizovaně, monitorujte performance pomocí EXPLAIN ANALYZE, a pravidelně auditujte bezpečnostní konfiguraci. Pamatujte, že RLS je silná vrstva obrany, ale měla by být součástí defense-in-depth strategie zahrnující také validaci na backendu, rate limiting a input sanitizaci.