Supabase RLS: ruční audit, nebo skenování?

Zabezpečení na úrovni řádků je linií mezi projektem Supabase, který chrání svá data, a projektem, který je tiše odhaluje. Když je RLS dobře nakonfigurován, vaše databáze vynucuje pravidla přístupu na úrovni řádků pro role podléhající RLS. Privilegované role, včetně role služby, mohou tato pravidla obejít. Když je nakonfigurován špatně, tabulky vypadají chráněně, zatímco zásady propouštějí více, než jste zamýšleli.

Tento článek porovnává dva způsoby, jak spustit kontrolu zabezpečení Supabase RLS: ruční ověření zásad a spuštění automatického auditu RLS. Oba mají své místo. Vědět, kde se jednotlivé položky porouchají, je způsob, jak ověřit, že vaše zásady přístupu k databázi fungují tak, jak mají.

RLS je funkce Postgres, kterou Supabase odhaluje na stole. Jakmile je povolena, tabulka odepře přístup k řádkům rolím podléhajícím RLS, pokud to zásady nepovolují; vlastníci tabulek a role s oprávněními k vynechání jsou výjimkou. Zásady se vyhodnocují vůči aktuálnímu uživateli, jeho nárokům a spuštěnému dotazu. The auth.uid() funkce je obvykle kotva: politika jako using (auth.uid() = user_id) omezuje přístup k vlastním databázovým řádkům přihlášeného uživatele.

Model je čistý. Selhání nejsou, protože jen zřídka vypadají jako selhání.

Několik vzorů odpovídá za většinu problémů RLS:

• RLS povoleno na některých stolech, ne na všech. Nová tabulka přidaná po spuštění nebo vytvořená migrací se může dodávat s vypnutým RLS. Každý řádek je pak čitelný pro jakoukoli roli s přístupem k tabulce.

• Politika, která je širší, než zní. using (true) na zásadě výběru znamená, že je viditelný každý řádek. Je snadné přidat během vývoje pro ladění a zapomenout odebrat.

• Servisní role převzata všude. Kód na straně serveru, který používá klíč role služby, zcela obchází RLS. Pokud požadavky na uživatele probíhají přes tento klíč, zásady se nikdy nepoužijí.

• Zásady, které kontrolují nesprávný sloupec. auth.uid() = id na stole kde id je primární klíč řádku, nikoli vlastník, nikdy nebude odpovídat záměru. Zásada existuje, vrací chybu nebo prázdnou sadu a povrch se stále chová.

• Aktualizace a mazání databáze bez příslušných řízení přístupu. Vývojáři často důkladně zajistí výběr a ponechávají zásady zápisu volné. Absolvování kontroly čtení neříká nic o tom, kdo může upravit řádek jako další.

Žádný z nich se neoznámí. Každý z nich udržuje aplikaci funkční, což je přesně důvod, proč přežívají do výroby.

Manuální audit je přímý a nevyžaduje žádné nové nástroje. Postupujete přes samotné zásady, tabulku po tabulce.

Začněte tím, že vypíšete všechny tabulky a potvrdíte, že je u každé povoleno RLS. Poté pro každou tabulku vyjmenujte zásady a namapujte je na zamýšlený přístup: kdo by měl číst, kdo by měl psát a kdo by se jí nikdy neměl dotýkat. Přečtěte si každý výraz zásad se sloupcem, který porovnává. Ujistěte se, že výběr, vložení, aktualizace a odstranění mají zásady, které odpovídají zamýšlené roli.

Dále zkontrolujte cestu kódu. Zjistěte, který klíč vaše aplikace skutečně používá pro požadavky na uživatele a zda některý z nich prochází rolí služby. Poté napište testovací dotazy jako různí uživatelé a potvrďte, že výsledky odpovídají očekávání: uživatel by měl číst své vlastní řádky a řádky nikoho jiného a neměl by mít možnost aktualizovat řádek, který nevlastní.

Manuální kontrola se vyplatí a hodně se toho chytne. Má také předvídatelná slepá místa.

• Testuje to, co si zapamatujete testovat. Pokud si nemyslíte, že byste se pokusili o odstranění jako druhý uživatel, může vám uniknout příliš široká zásada odstraňování. Když je RLS povoleno, žádná platná zásada mazání znamená, že je mazání zamítnuto.

• To stárne. Zásady se mění s přidáváním funkcí. Kontrola, která byla v minulém čtvrtletí důkladná, neříká nic o tabulce, kterou jste přidali minulý týden.

• Záleží na stejné osobě, která konfigurovala zásady. Tvůrce, který politiku napsal, je nejméně pravděpodobné, že si všimne svého vlastního předpokladu.

• Potřebuje zaznamenané důkazy. „Zkontroloval jsem to a vypadalo to správně“ po sobě nic nezanechá: žádný důkaz, žádný rozsah, žádný artefakt, který byste mohli později znovu naskenovat.

Manuální audit odpovídá na otázku "odpovídá to mému mentálnímu modelu systému?" Sama o sobě neprokazuje, co databáze skutečně vrátí.

Z opačného směru funguje automatizovaná bezpečnostní kontrola Supabase RLS. Procvičuje projekt tak, jak by to udělal útočník nebo špatně nakonfigurovaný klient, a hlásí, co vlastně datová vrstva umožňuje.

Tento posun je důležitý ze tří důvodů. Za prvé, škáluje minulou paměť: skenování opakuje kontroly napříč tabulkami a koncovými body dostupnými v jeho nakonfigurovaném rozsahu. Externí kontrola nemůže zkontrolovat každou politiku bez vhodného přístupu. Za druhé, poskytuje důkazy, na základě kterých můžete jednat: nález pojmenovává tabulku, stav politiky a podmínku, díky které je dosažitelný, takže víte, co změnit a proč. Za třetí, je to opakovatelné. Kontrola, kterou můžete spustit znovu, změní jednorázovou kontrolu na průběžnou kontrolu.

VICE skenuje webové aplikace a konfigurace Supabase/RLS, poté hlásí nálezy s důkazy, které se za nimi skrývají, a pokyny pro opravy, ze kterých lze pracovat. Můžete označit opravu a požádat o novou kontrolu, ale pouze srovnatelné opětovné skenování potvrdí, že problém je vyřešen: oprava je ověřena ve stejném rozsahu, nikoli převzata z úpravy. Naplánované kontroly a výstrahy podporují průběžné monitorování, takže tabulka přidaná příští měsíc mezeru v tichosti znovu nezavádí.

Dělba práce je přímočará. Spusťte automatickou kontrolu a zjistěte, co vaše ruční kontrola vynechala, a poté použijte ruční povolení k potvrzení záměru každé zásady, kterou kontrola označí. Automatizace vám řekne, co databáze umožňuje; vy rozhodnete, zda to povolení bylo záměrné.

Skóre z jakéhokoli skenování popisuje testovaný rozsah, nezaručuje, že je projekt plně bezpečný. Berte to jako signál, kde hledat, ne jako certifikát.

Pokud nasazujete produkt vytvořený pomocí Supabase a nikdy jste své zásady neauditovali, upřímná odpověď je obojí, v pořádku. Začněte s automatickou kontrolou RLS, abyste měli aktuální a důkazy podložený obrázek o tom, co vaše tabulky umožňují. Poté ručně projděte zjištění, potvrďte záměr každé zásady a opravte ty, které se posunuly. Zařaďte automatickou kontrolu do plánu, aby se novým tabulkám a novým zásadám dostalo stejné kontroly jako těm původním.

Přeskočením kteréhokoli přístupu můžete zanechat zásadu přístupu k databázi, která vypadá, že chrání data, ale stále umožňuje neoprávněný přístup.

Spusťte bezplatné skenování na vice-platform.com a zkontrolujte své veřejné webové stránky, než se zaregistrujete. Specializovaný sken Supabase vyžaduje ověřenou doménu a placené předplatné nebo zakoupený kredit; jeho pokrytí závisí na nakonfigurovaném přístupu.