RLS – bästa praxis för datakällor och arbetsböcker


Säkerhet på radnivå (RLS) i Tableau begränsar de rader med data som en specifik användare kan se i en arbetsbok. Detta skiljer sig från Tableau-behörigheter som kontrollerar åtkomst till innehåll och funktionaliteter. Behörigheter kontrollerar till exempel om en användare kan kommentera eller redigera en arbetsbok medan säkerhet på radnivå skapar en situation där två användare som tittar på samma instrumentpanel, endast kan se de data som varje användare har behörighet att se.

Det finns flera olika sätt att implementera RLS i Tableau. Du kan till exempel ställa in RLS för varje datakälla eller arbetsbok. Alternativt kan du ställa in RLS på anslutningsnivå med en virtuell anslutning med en datapolicy (kräver Datahantering). Se Översikt över säkerhetsalternativ på radnivå i Tableau för mer information om olika alternativ.

Obs! Det här ämnet fokuserar på bästa praxis gällande RLS för datakällor och arbetsböcker. Se faktabladet Best Practices for Row Level Security with Entitlement Tables(Länken öppnas i ett nytt fönster) (Bästa praxis för säkerhet på radnivå med berättigandetabeller) eller How to Set Up Your Database for Row Level Security in Tableau(Länken öppnas i ett nytt fönster) (Så konfigurerar du din databas för säkerhet på radnivå i Tableau) på bloggen Tableau and Behold för mer djupgående exempel på begreppen som beskrivs i detta ämne.

RLS-arbetsflöde

För direktanslutningar och extrakt av flera olika tabeller är det grundläggande RLS-arbetsflödet som följer:

  1. Användaren identifieras när denne loggar in på Tableau Server eller Tableau Cloud
    • Detta kräver ett specifikt användarnamn per användare och säker enkel inloggning (SSO)
    • Active Directory, LDAP eller Tableau REST API kan användas för att synkronisera användarnamn och fastställa behörigheter
  2. Uppsättningen med databerättigande för användaren erhålls från alla möjliga databerättigande
    • Detta kräver en datastruktur som kan länka berättigande till Tableau-användarnamnet
  3. Data filtreras med hjälp av berättigandet för den användaren
    • Detta kräver ofta att användarfunktioner används i ett beräknat fält
  4. Publicerade och filtrerade data används för att bygga innehåll
    • Att använda en publicerad (snarare än inbäddad) datakälla med ett filter för datakällan säkerställer att RLS inte kan ändras genom att ladda ner eller webbredigera arbetsboken

Hur kopplingarna, de beräknade fälten och filtren konfigureras beror på strukturen på data och hur användarna hanteras.

Berättigandetabeller

Varje unik kombination av attribut som data kan filtreras på är ett berättigande. Vanligtvis finns det separata tabeller för att specificera berättiganden och kartlägga dessa rättigheter till användare eller användarroller. Denormalisering rekommenderas ur prestandasynpunkt då kopplingar är kostsamma åtgärder.

Berättigandevyn, som består av berättiganden kartlagda till användare eller roller, kopplas samman med data. Ett användarbaserat filter för datakällan tillämpas sedan där det fungerar som en WHERE-sats som endast tar in berättiganden – och därmed de lämpliga dataraderna – för den relevanta användaren. (Frågeoptimering bör säkerställa att filtreringen sker innan kopplingen när frågan bearbetas, för att minimera duplicering av data. Se Åtgärdsordning för prestanda och bearbetning för mer information.)

Modeller med berättigandetabeller

Generellt finns det två modeller som representera berättigande:

Fullständig kartläggning till den djupaste nivån av detaljrikedom

  • Berättigande definieras fullständigt för varje kolumn.
  • Det finns en rad i kartläggningstabellen för alla möjliga berättiganden som användaren har.
  • Den här modellen kräver färre kopplingssatser.

Glesa berättiganden

  • Berättiganden definieras för varje nivå på hierarkin där NULL används för att representera ett ”alla”-tillstånd.
  • Det finns en enda rad i kartläggningstabellen för en specifik nivå i berättigandehierarkin. Detta reducerar avsevärt antalet berättiganderader för användare på höga nivåer i en hierarki.
  • Den här modellen kräver mer komplexa kopplingar och filter.

Användare och roller

Kombinationer av berättiganden representeras vanligtvis som roller som sedan länkas till användare i en många-till-många-kartläggningstabell. Detta låter dig enkelt ändra eller ta bort en användare från rollen samtidigt som du bibehåller ett register över rollen och dess berättiganden.

Alternativt kan en många-till-många-kartläggningstabell skapas som istället direkt tilldelar användare berättiganden i stället för att gå igenom kopplingen i en rolltabell. Det kräver dock att värdena hanteras mer direkt i tabellen men utesluter en koppling.

Obs! Användarvärdena som är länkade till en roll eller ett berättigande måste matcha användarnamnet eller det fullständiga namnet på Tableau-platsen för att kunna nyttja användarfunktionerna i Tableau Desktop.

Kopplingar

Oavsett vilken modell som används för att representera berättiganden är det klokt att koppla alla rättigheter och kartläggningstabeller till en enda denormaliserad berättigandevy. Detta kan till en början orsaka en ”blowup” (mycket duplicerad) version av berättiganden. Datakällans filter på användaren kommer dock att reducera den igen. Du vill också ha den här vyn om du planerar att använda ett extrakt.

Metoden med mest detaljrikedom kan ha en prestandafördel när allt är hierarkiskt – du behöver endast göra en enda koppling på den lägsta nivån i hierarkin. Detta fungerar endast om alla attribut på den lägsta nivån är distinkta. Om det finns en chans för duplicering (till exempel en central underregion i mer än en region) måste du koppla alla kolumner för att uppnå effekten av ett distinkt nyckelvärde.

De faktiska detaljerna och deras prestanda är beroende av datasystemet och kräver tester. Att använda en enda nyckel kan till exempel potentiellt förbättra prestandan då kopplingen endast körs på en kolumn. Korrekt indexering av alla kolumner kan dock erbjuda samma prestanda när andra faktorer tas i beaktande.

Implementera säkerhet på radnivå

Deepeste detaljrikedomen

Efter att den denormaliserade vyn av kartlagda berättiganden har skapats, skapas även en inre koppling mellan vyn och data i dialogrutan Tableau-dataanslutning. Data kan finnas kvar i ett traditionellt stjärnschema. Alternativt kan dimensions- och faktatabellerna materialiseras tillsammans i två vyer. Flertabellextrakt skapar extrakttabeller för att matcha kopplingarna. Att skapa de två vyerna förenklar därför det resulterande extraktet. SQL följer detta grundläggande mönster:

SELECT * 
FROM data d INNER JOIN entitlements e ON
d.attribute_a = e.attribute_a AND 
d.attribute_b = e.attribute_b AND ... 
WHERE e.username = USERNAME()

Glesa berättiganden

Om dina berättiganden liknar modellen för glesa berättiganden mer skulle den anpassade SQL-koden för att koppla data till rättigheterna vara lite mer komplex på grund av NULL-värdena. Konceptuellt skulle det se ut så här: 

SELECT *
FROM data d 
INNER JOIN entitlements e ON
(e.region_id = d.region_id OR ISNULL(e.region_id) AND
(e.sub_region_id = d.sub_region_id OR ISNULL(e.sub_region_id) AND
(e.country_id = d.country_id OR ISNULL(e.country_id)

Utan att använda anpassad SQL kan detta utföras med en korskoppling och ytterligare filter i Tableau Desktop. Skapa en kopplingsberäkning på båda sidor av dialogrutan koppling som helt enkelt består av heltalet 1 och ställ in dem till att vara lika. Detta kopplar samman varje rad i datatabellen med varje rad i berättigandetabellen.

Du behöver sedan en beräkning (eller individuella beräkningar) för att redogöra för nivåerna i hierarkin. Du kan till exempel ha flera beräkningar som följer detta format: [region_id] = [region_id (Entitlements View)] OR ISNULL([region_id (Entitlements View)]

Alternativt kan du ha en kombinerad beräkning för alla nivåer i ett:

([region_id] = [region_id (Entitlements View)] OR ISNULL([region_id (Entitlements View)])
AND
([sub_region_id] = [sub_region_id (Entitlements View)] OR ISNULL([sub_region_id (Entitlements View)])
AND
([country_id] = [country_id (Entitlements View)] OR ISNULL([country_id (Entitlements View)])

Funktionen ISNULL matchar valfri berättigandekolumn med alla objekt i den andra kolumnen. Som alltid med RLS bör dessa beräkningar läggas till som filter för datakällan.

Filter för datakällor

För båda tillvägagångssätten måste ett filter konfigureras för att begränsa data för en specifik användare när berättiganden är korrekt kopplade med data. Ett beräknat fält ska skapas med en användarfunktion. Till exempel en enkel boolesk jämförelse av huruvida användaren, som anges i fältet Användarnamn, är samma som användarnamnet för personen som är inloggad på Tableau-platsen: [Username] = USERNAME()

Den här beräkningen ska användas som ett filter för datakällan (med TRUE valt).

Om datakällan är inbäddad och en användare har behörigheter att webbredigera eller ladda ner arbetsboken är RLS icke-existerande då filtren som upprätthåller den enkelt kan tas bort. Tableau-datakällan bör publiceras separat i stället för att vara inbäddad i arbetsboken.

Fullständig åtkomst med den lägsta detaljrikedomen

Det finns även ett vanligt scenario med två åtkomstnivåer inom organisationen: personer som kan se allt (”fullständig åtkomst”) eller personer med en rimligt definierbar delmängd av berättiganden. Detta används oftast för inbäddade applikationer – organisationen som är värd för datan kan se allt men klienter kan endast se sina egna data. I det här fallet behövs ett sätt att returnera alla data för användare med ”fullständig åtkomst” samtidigt som kopplingarna med den lägsta detaljrikedomen bibehålls för alla andra användare.

För den här tekniken används Tableau-grupper för att skapa en åsidosättning med hjälp av en beräkning i kopplingsvillkoret.

  1. Skapa en grupp för användare som ska se alla data (fullständig åtkomst) 
  2. Skapa en vänsterkoppling med två kopplingsvillkor i faktavyn
    • Det första kopplingsvillkoret ska finnas i kolumnen som representerar nivån med den lägsta detaljrikedomen
    • Det andra kopplingsvillkoret bör vara två beräkningar:
      • Ange True för beräkningen, på vänster sida (faktavyn)
      • På höger sida (vyn för berättiganden) ska beräkningen vara: IF ISMEMBEROF('All Access') THEN False ELSE True END
  3. Skapa en beräkning strukturerad såsom [Username] = USERNAME() OR ISMEMBEROF(['All Access'] ([Entitlements View)]) på ett blad
  4. Skapa ett filter för datakällan på användarnamnets beräkning

Om en användare är medlem i gruppen Fullständig åtkomst blir kopplingen en vänsterkoppling på True = False. Detta innebär att det inte finns några matchningar i berättigandevyn. Hela faktavyn returneras därför med NULL-värden för kolumnerna från berättigandevyn (noll duplicering). I fallet där användaren inte är en del av gruppen Fullständig åtkomst ändras inte kopplingen av villkoret True = True och den fungerar som förväntat.

Användarberäkningen som används som filter för datakällan är sann för alla rader när gruppens åsidosättning fungerar. Alternativt kommer den att filtrera ner till endast användarens lägsta detaljrikedom i hierarkin.

Åtgärdsordning för prestanda och bearbetning

När en visualisering ses i Tableau Desktop, Tableu Server eller Tableau Cloud), skickar Tableau en optimerad fråga till RDBMS som sedan bearbetar den och skickar tillbaka resultaten till Tableau som kan återge visualiseringen med resulterande data. Åtgärdsordningen för när kopplingar, beräkningar och filter utförs beror på frågeoptimeraren och hur frågan körs.

Liveanslutningar

När en liveanslutning används för en datakälla i Tableau är prestandan på frågan som körs beroende av frågeoptimeraren som översätter inkommande SQL till en effektiv plan för att erhålla data.

Det finns två sätt att bearbeta frågan:

  1. Filtrera berättiganderaderna till användaren och sedan koppla samman med faktatabellen
  2. Koppla rättigheterna till faktatabellen och sedan filtrera till användarens rader

I en perfekt situation säkerställer frågeoptimeraren att databasen bearbetar frågan genom att filtrera och sedan koppla. Om en användare är berättigad till allt innebär det att det maximala antalet rader som bearbetas är antalet rader i datatabellen.

Om databasen bearbetar frågan genom att koppla och sedan filtrera kan det förekomma duplicering av data. Det maximala antalet rader som bearbetas är antalet användare som har rätt att se den specifika raden gånger varje rad i datatabellen.

Det är uppenbart om det andra scenariot inträffar: dina frågor tar en lång tid att slutföra, du får tillbaka fel eller en indikation på prestandaproblem dyker upp i databasen. Den totala datavolymen expanderar exponentiellt vilket kan orsaka orimlig systembelastning på servern.

Extrakt

När datakällan i Tableau är en liveanslutning skickar Tableau varje fråga som är nödvändig för att återge ett specifikt namn eller instrumentpanel till RDBMS. När datakällan är ett extrakt sker processen, att fråga efter data från den underliggande datakällan, endast vid skapandet och uppdateringen av extrakt. Alla individuella frågor för visualiseringar besvaras av extraktmotorn från extraktfilen.

Samma problem med åtgärdsordningen uppstår när man skapar enstaka tabellextrakt. En ”blowup” sker dock både på den underliggande datakällan och i själva extraktet.

Överväganden med extrakt

Från och med Tableau 2018.3 kan datamotorn skapa ett extrakt med flera tabeller och RLS kan implementeras enligt beskrivningen ovan. Att använda flera tabellextrakt reducerar tiden det tar att generera ett extrakt med många-till-många-relationer genom att inte materialisera kopplingen.

Extraktet bör skapas med ett dataobjekt och ett berättigandeobjekt. Detta är den enklaste lagringen i extraktet och erbjuder bästa prestanda.

  • Dataobjektet är tabellen, vyn eller en anpassad SQL-fråga som representerar den denormaliserade kombinationen av fakta och nödvändiga dimensionstabeller
  • Berättigandeobjektet är en denormaliserad tabell, vy eller anpassad SQL-fråga för alla berättiganden som är nödvändiga för att filtrera data på den mest detaljrika nivån, vilket kräver:
    • En kolumn för användarnamn som matchar de exakta användarnamnen i Tableau Server eller Tableau Cloud
    • En rad för var och en av de mest detaljerade berättigandena till dataobjektet.

Det här formatet anges som metoden med den lägsta detaljrikedomen ovan. Extrakt med flera tabeller använder samma metod, med förbehållet att endast två dataobjekt kopplas och eventuell fältspecifik filtrering redan tillämpas inom objektet.

Då flera tabellextrakt har extraktfilter inaktiverade kan du filtrera antingen per vyerna eller tabellerna du ansluter till i datakällan. Alternativt filtren definieras i anpassade SQL-objekt i dialogrutan Tableau-dataanslutning.

Obs! För liveanslutningar gäller samma principer. Om datakällan är inbäddad och en användare har behörigheter att webbredigera eller ladda ner arbetsboken är RLS icke-existerande då filtren som upprätthåller den enkelt kan tas bort. Extraktet bör publiceras separat i stället för att vara inbäddat i arbetsboken.

Enkla tabellextrakt

Följande metod rekommenderas endast när en version före Tableau 2018.3 används – flera tabellextrakt är att föredra om de är tillgängliga.

Enkla tabellextrakt materialiserar alla kopplingar du bygger när du konstruerar Tableau-datakällan och lagrar allt som en enda tabell via en fråga. Resultat omvandlas sedan till en enda tabell i extraktfilen. Denna denormalisering medför risken att orsaka massiv duplicering av data. Detta sker då varje rad som tilldelats mer än ett berättigande eller användare dupliceras som ett resultat av många-till-många-relationen.

För att förhindra denna duplicering:

  1. Skapa ett fält med säkerhetsanvändare som innehåller användarnamnen för berättigandet
    • ett värde kan till exempel vara ”bhowell|mosterheld|rdugger”
  2. Använd funktionen CONTAINS() i Tableau för att korrekt identifiera enskilda användare
    • Exempel: CONTAINS([Security Users Field], USERNAME())

Den här metod har uppenbarligen förbehåll. Den kräver att du går från berättigande i rader till en enda kolumn som separeras korrekt med SQL. Den kolumnen kan dessutom endast innehålla ett begränsat antal tecken. Partiella matchningar kan skapa problem och du måste använda separatorer som aldrig kommer att vara giltiga i ID:n. Även om den fungerar inom Tableau Data Engine kommer den att vara mycket långsam som en strängberäkning för de flesta databaser. Detta begränsar dina möjligheter att byta tillbaka till en liveanslutning.

Alternativt kan du ta olika extrakt per ”roll” eller berättigandenivå vilket innebär att endast data som är lämpliga för den personen eller nivån finns i extrakt Detta kräver dock processer för att på lämpligt sätt tillåta och nyttja mallpublicering inom Tableau Server, vanligtvis via API:erna.

Använd inbyggd säkerhet på radnivå i en databas

Många databaser har inbyggda mekanismer för RLS. Om din organisation redan har byggt säkerhet på radnivå i en databas kanske du kan nyttja din befintliga RLS. Det är inte nödvändigtvis lättare eller bättre att implementera en inbyggd RLS-modell jämfört med att bygga den med Tableau i åtanke. Dessa tekniker nyttjas i allmänhet när en organisation redan har investerat i dem och vill dra fördel av investeringen. Den största fördelen med att använda inbyggd RLS är att administratörer kan implementera och styra sina datasäkerhetsprinciper på ett och samma ställe: sina databaser. Se Säkerhet på radnivå i databasen för mer information.

Tillbaka till toppen
Tack för din feedback!Din feedback har skickats in. Tack!