Radnivåsäkerhet för datamappningar: vad det är och när du behöver det
Du har en enda kundtabell. Säljteamet i EU ska bara se kunderna i EU. Teamet i USA ska bara se kunderna i USA. Styrelsen ser allt.
Det finns två sätt att lösa det. Antingen gör du tre kopior av tabellen, eller så använder du radnivåsäkerhet. De flesta team börjar med kopior. De flesta ångrar sig inom ett kvartal.
Vad radnivåsäkerhet egentligen är
Radnivåsäkerhet (RLS) är en regel som avgör vilka rader i en tabell en användare får se, utifrån vem användaren är och egenskaper hos själva raden. Datan finns på ett ställe. Filtreringen sker automatiskt när datan läses, utan att applikationen behöver be om det.
I Postgres heter det CREATE POLICY. I andra databaser är det vyer, filter i applikationslagret eller en inbyggd funktion i plattformen. Tekniken skiljer sig åt, men principen är densamma: samma data, olika vyer, och systemet ser till att reglerna följs.
Därför är kopior sämre än de verkar
EU-teamet får customers_eu. USA-teamet får customers_us. Styrelsen får customers_all. Första dagen fungerar det.
| Problem | Dag ett | Sex månader senare |
|---|---|---|
| En enda ändring | ”Jag uppdaterar alla tre” | Tabellerna säger emot varandra och ingen vet vilken som gäller |
| Ny region | ”Kopiera bara tabellen” | Kopians schema börjar avvika och rapporter går sönder |
| Användare byter team | ”Jag justerar behörigheterna” | Behörigheterna finns på tre ställen |
| Granskning | ”Jag kan köra frågor mot varje tabell” | Varje tabell har sin egen logg och helheten kräver en join |
Med RLS slipper du allt i tabellen ovan. En enda sanningskälla. Behörigheterna blir policyer i stället för separata dataset.
Där RLS gör skäl för sig
Några fall där RLS är rätt lösning:
- Team i flera regioner eller avdelningar. Samma kund- eller produktlista, sedd på olika sätt av personer i olika länder eller affärsområden.
- Kundåtkomst i nivåer. En B2B-dataprodukt där kunder med gratis-, betal- och enterprise-abonnemang ser olika rader. En tabell, tre policyer.
- Partnerportaler. Flera partner läser samma register, och var och en ser bara sina egna leveranser eller affärer. Inga filexporter.
- Överlappande interna vyer. Ekonomi ser kunden med betalningsvillkor. Sälj ser var affären ligger i säljtratten. Marknad ser kampanjtaggar. Samma rad, olika synliga kolumner.
Så brukar RLS byggas
| Metod | Vad det är | Passar bäst för | Nackdel |
|---|---|---|---|
Postgres CREATE POLICY |
Regel i databaslagret | De flesta Postgres-miljöer | Bara Postgres |
| Vyer per roll | Handskrivna vyer | Andra databaser | Blir snabbt många |
| Filtrering i applikationen | WHERE i koden |
Största möjliga flexibilitet | Lätt att glömma någon gång |
| Inbyggt i plattformen | En funktion i verktyget | Enkel drift | Låst till den plattformen |
RLS ska ligga så nära datan som möjligt. Filtrering i applikationslagret fungerar när du själv styr över allt som läser datan. En enda bortglömd fråga är en läcka.
Så gör gridmap
gridmap har RLS på dataregister. Du kopplar behörigheter till enskilda kolumnvärden eller till användargrupper, och Lookup API returnerar bara de rader som anroparen får se. Behörigheterna kan du sköta i gridmap eller hämta från en tabell i datalagret med schemalagd synk, vilket är praktiskt om det redan står någon annanstans vem som hör till vilket team. Samma register kan användas av en analytiker i USA, en partner i EU och styrelsen, utan kopior.
Vanliga fallgropar
- Prestanda. En policy som filtrerar på en kolumn utan index läser fler rader än du vill. Lägg till samma index som du skulle ha lagt till för en
WHEREsom körs ofta. - Lucka i granskningen. ”Vem såg vad” är inte samma sak som ”vem ändrade vad”. Behöver du en logg över läsningar får du lägga till den separat.
- Vägar förbi. Backuper, ETL-jobb och analysrepliker körs ofta som superuser och går förbi RLS. Följ datans hela väg innan du litar på policyn.
- Tomma resultat som förvirrar. En användare utan tillåtna rader får en tom lista, som ser precis ut som ”det finns ingen data”. Visa ett meddelande när filtret har tömt vyn.
När RLS är fel verktyg
RLS löser problemet ”samma data, olika synlighet”. Det löser inte:
- Olika scheman per kund. Det är multi-tenancy.
- Strikta krav på var datan får lagras. Det kräver regionala databaser.
- Skrivningar som bara ska påverka en användares del. RLS styr läsningar. Skrivningar behöver en egen policy.
Vanliga frågor
Är RLS samma sak som multi-tenancy? Nej. Multi-tenancy skiljer en kunds data från en annans. RLS filtrerar en gemensam datamängd per användare. Ofta behövs båda, i lager ovanpå varandra.
Kan vi lägga till RLS på befintliga tabeller utan driftstopp? I Postgres går det. Koppla först på en tillåtande policy (som inte ändrar något), kontrollera och skärp den sedan. Ta det i steg: ”tillåt som standard”, ”policy kopplad”, ”neka som standard”.
Hur testar vi att RLS fungerar? Anslut som varje roll och kontrollera antalet rader mot data du känner till. Automatisera testet och kör det vid varje schemaändring.