Bezpečnosť na úrovni riadkov, zvyčajne označovaná skratkou RLS, presúva časť rozhodovania o prístupe priamo do databázy. Bezpečnostná politika filtruje alebo odmieta riadky na základe aktuálnej identity v databáze, kontextu relácie, požadovanej operácie a hodnôt v samotnom riadku. Táto politika sa uplatňuje aj vtedy, keď aplikačný kód odošle širší dopyt.
Čo kontroluje politika RLS
Operáciám čítania a zápisu je potrebné venovať osobitnú pozornosť. Databázové pravidlá môžu obmedziť, ktoré riadky sú viditeľné, no stále môžu povoliť vloženie nového riadku s identifikátorom iného tenanta. Aktualizácie môžu tiež vyžadovať jedno pravidlo na výber existujúceho riadku a iné na overenie jeho nových hodnôt.
| Operácia | Otázka pre bezpečnostné pravidlá | Následok chýbajúcej kontroly |
|---|---|---|
| Select | Ktoré riadky môžu byť vrátené? | Zobrazia sa dáta z iného rozsahu |
| Insert | Ktoré nové riadky môžu byť vytvorené? | Odosielateľ priradí neoprávneného vlastníka alebo tenanta |
| Update | Ktoré riadky a nové hodnoty sú povolené? | Riadok sa presunie cez chránenú hranicu |
| Delete | Ktoré riadky môžu byť odstránené? | Široký dopyt vymaže dáta z iného rozsahu |
Databáza potrebuje spoľahlivý kontext na zodpovedanie týchto otázok. Tento kontext môže pochádzať z databázovej roly, lokálnej hodnoty transakcie alebo overených claimov odovzdaných dôveryhodnou službou. Hodnota skopírovaná z neoverenej požiadavky oslabuje pravidlá, aj keď je samotné SQL napísané správne.
Kde môže zlyhať uistenie o RLS
Audit softvéru vytvoreného pomocou AI analyzuje povolené politiky a zároveň sleduje spôsob, akým sa aplikácia pripája. Pravidlo, ktoré funguje v lokálnej konzole, sa nemusí vzťahovať na privilegovanú rolu používanú v produkcii. Migračné skripty, administratívne nástroje, workeri na pozadí a pooly pripojení môžu využívať rôzne cesty.
Audit preveruje:
- Pokrytie pravidlami: Každá tabuľka vlastnená tenantom a každá operácia majú určené pravidlo.
- Správanie rolí: Rola používaná za behu neočakávane neobchádza vynucovanie pravidiel.
- Životný cyklus kontextu: Pooling pripojení nemôže znova použiť kontext tenanta z predchádzajúcej požiadavky.
- Validácia zápisu: Vkladané a aktualizované hodnoty zostávajú v rámci povolenej hranice.
- Privilegované cesty: Prístup pre údržbu a podporu je explicitný a samostatne kontrolovaný.
- Realistickosť testov: Testy sa pripájajú s rovnakou rolou a kontextom ako samotná aplikácia.
RLS v rámci širších hraníc
Izolácia tenantov zahŕňa viac než len relačné riadky. Súbory, objektové úložiská, cache, vyhľadávacie indexy, fronty, analytické systémy a externé služby vyžadujú vlastné bezpečnostné mechanizmy. RLS chráni iba databázové operácie pokryté jeho pravidlami, nesleduje však dáta po tom, čo ich aplikácia skopíruje inam.
RLS zároveň dopĺňa autorizáciu na úrovni objektov. Aplikácia môže urobiť jasné rozhodnutie o pravidlách a vrátiť kontrolované zamietnutie, zatiaľ čo databáza poskytuje druhý bod vynucovania proti príliš širokému dopytu. Obe vrstvy by mali vyjadrovať rovnaké pravidlá vlastníctva a tenanta.
Dôkaz, že politiky sú účinné
Užitočná sada testov vytvára riadky pre viacero identít alebo tenantov a potom testuje každú operáciu prostredníctvom produkčnej databázovej roly. Overuje povolené riadky, zamietnuté riadky, zápisy, zmeny vlastníctva, hromadné operácie a privilegované cesty údržby. Testy by mali tiež opakovane využívať poolované pripojenia na odhalenie úniku kontextu.
Výstup auditu zaznamenáva každú chránenú tabuľku, pravidlo, rolu za behu, zdroj kontextu a cesty obchádzania. Tieto dôkazy patria do produkčnej kontroly vygenerovaného softvéru, pretože samotná prítomnosť pravidla RLS nedokazuje, že spustená aplikácia mu skutočne podlieha.
