Wat is row-level security met Snowflake?

Betere beslissingen beveiligen

Bedrijfsgegevens kunnen een cruciale rol spelen bij het nemen van belangrijke beslissingen. Op die manier zijn ze heel waardevol. We moeten ze alleen wel verzamelen, ergens opslaan en vervolgens analyseren. Vaak, hebben we daarbij te maken met persoonsgegevens en andere gevoelige gegevens die we niet zomaar met anderen willen delen. Sterker nog, we mogen dat in veel gevallen zelfs niet eens: we zijn gebonden aan wet- en en regelgeving, zoals de Algemene Verordening Gegevensbescherming.

Het niet naleven van deze regels kan enorme (financiële) gevolgen hebben. Daarom is het goed inrichten en beveiligen van de informatievoorziening van een bedrijf essentieel. Enerzijds, heeft het grote (financiële) waarde omdat het hoge kosten kan voorkomen. Anderzijds, is het ook in positieve zin waardevol als belanghebbenden (stakeholders) vertrouwen hebben in hoe wij omgaan met (hun) gegevens!

Bedrijven hebben er veel baat bij om gevoelige persoons- en bedrijfsgegevens goed te beschermen en af te schermen. Daarvoor kunnen we om te beginnen vaststellen wie welke tabellen mag zien, maar dat is niet altijd genoeg. Vaak moet ook bepaald worden welke regels van die tabel iemand wel mag zien en welke niet. Dat heet ook wel row-level security. In deze blog kijken we naar hoe we dat, heel gedetailleerd, kunnen doen met Snowflake (een dataplatform in de cloud).

Bedrijfsgegevens in Snowflake

De informatievoorziening van een bedrijf kan op verschillende manieren ingericht worden. Gegevens kunnen simpelweg opgeslagen worden op een computer (of server). Daarna kunnen de benodigde berekeningen op die computer worden uitgevoerd. Daarnaast kunnen we er ook voor kiezen om opslag en berekeningen in de cloud te regelen.

Dat laatste kan een aantal voordelen hebben, al hangt veel af van welke aanbieder je kiest. Snowflake biedt een plek om gegevens op te slaan, te analyseren en klaar te maken voor datavisualisatie (met bijvoorbeeld Tableau), allemaal in de cloud! Daarmee krijgen we flexibiliteit in hoeveel ruimte we hebben om data op te slaan, maar ook in hoeveel rekenkracht we tot onze beschikking hebben.

Hoe de informatievoorziening ook wordt ingericht, veiligheid is altijd van belang:

• (1) Hoe voorkomen we dat de verkeerde mensen bij onze gegevens komen?

Tegenwoordig, kunnen we bijna niet zonder een goed antwoord op die vraag, maar er is ook een tweede vraag die steeds belangrijker wordt:

• (2) Wie verlenen we welke toegang tot welke gegevens?

Deze tweede vraag verschilt fundamenteel van de eerste. Het gaat om mensen die we wèl toegang willen verlenen, maar waarvan we de toegang eventueel willen beperken. Door af te bakenen welke mensen wat mogen zien, zorgen we er voor dat het op minder plekken fout kan gaan. Tegelijk weten we wie waar verantwoordelijk voor is.

We moeten, kortom, met veel rekening houden. Gelukkig is Snowflake zo ingericht dat veel automatisch al goed geregeld is. Met Snowflake werken, betekent dat we ons kunnen concentreren op wie we toegang willen geven in plaats van hoe we dat (moeten) doen. In andere woorden, we kunnen ons bezighouden met de bedrijfslogica uit de tweede vraag in de vorige alinea, terwijl we de eerste (veiligheids)vraag grotendeels aan Snowflake over kunnen laten.

Toegang op regelniveau (row-level security)

In Snowflake kunnen we globaal regelen wie er überhaupt in het systeem kan. Vervolgens bepalen we wat voor soort toegang deze mensen tot welke securable objects hebben. Zo kunnen we beperken welke tabellen gebruikers kunnen zien. Ook kunnen we ze toestemming geven om die tabellen te veranderen. Dit gebeurt allemaal op het securable object niveau, maar we kunnen het ook specifieker inregelen, namelijk op regelniveau!

Dat wordt ook wel row-level security genoemd. Grofweg houdt dit in dat als gebruikers een tabel bekijken, ze alleen de regels te zien krijgen die ze mogen zien. We kunnen dit ook row-level access control noemen: we regelen namelijk de toegang van gebruiker tot bepaalde regels.

Op regelniveau controleren wat gebruikers kunnen zien is heel nuttig, zeker als het gaat om persoonsgegevens. Zo kunnen we er bijvoorbeeld voor zorgen dat managers alleen de gegevens kunnen zien van medewerkers waaraan ze leiding geven. Door de voorkomen dat ze gegevens van andere medewerkers zien, beperken we het aantal plaatsen waar het fout kan gaan. We geven alleen toegang daar waar dat nodig is en daarbuiten niet!

Gegevens maskeren

We kunnen zelfs nog verder gaan en niet alleen per regel, maar ook per kolom bepalen hoe gegevens getoond worden. Als voorbeeld: misschien willen we dat geboortedatum en naam van een medewerker volledig zichtbaar zijn voor een directe leidinggevende, maar niet voor de managers daarboven. Die mogen alleen zien dat er een naam is en, in plaats van de geboortedatum, wordt misschien alleen 1 januari van het geboortejaar getoond.

Waar we het in eerste instantie hebben over het op regelniveau beveiligen van tabellen, hebben we in het hierboven staande voorbeeld over het maskeren (of masking) van kolommen: we halen de kolommen niet weg maar passen aan wat er te zien is.

Policies in Snowflake

Hoe wordt dit nou allemaal gedaan in Snowflake? In andere woorden, hoe wordt het beleid omtrent gegevens ingeregeld? Daarvoor gebruiken we 2 soorten Snowflake policies:

1. ROW ACCESS POLICY
2. MASKING POLICY

Met de eerste kunnen we bepalen welke regels aan wie getoond worden en met de tweede bepalen we hoe de kolommen in die regels aan de gebruiker getoond worden.

Voorbeeld boekwinkel

Om te zien wat we met bovenstaande kunnen doen is het misschien handig om een voorbeeld te bedenken. Stel voor dat Anna eigenaar is van een boekwinkel. Op maandagochtend zijn 3 boeken verkocht:

1. T. de Pauwissen De kronkelpaden €19.95 (Bert)
2. E. Boering Vervlogen tijden €9.5 (Cynthia)
3. H.J. van Ginsbergen Avond na avond €15 (Dylan)

Bert, Cynthia en Dylan verkopen alle drie boeken in de winkel. Ze mogen in ieder geval zien wat ze zelf verkocht hebben. Bert is daarnaast ook verantwoordelijk voor de inkoop van de boeken. Hij moet weten welke boeken verkocht worden zodat hij beter kan bepalen welke boeken de boekwinkel moet inkopen. Tegelijkertijd hoeft hij niet te weten wie wat verkocht heeft. Alleen eigenaar Anna krijgt dat te zien.

Als we dit in Snowflake regelen met policies, krijgen de personages het volgende te zien:

Eigenaar Anna

Eigenaar Anna mag alles zien.

Boekinkoper en verkoper Bert

In plaats van de namen van de verkopers ziet Bert gemaskeerde waardes: ****. Alleen bij boeken die hij zelf verkocht heeft mag hij de naam van de verkoper zien: Bert.

Verkoper Cynthia

Cynthia ziet alleen het boek dat ze zelf verkocht heeft.

Verkoper Dylan

Dylan ziet alleen het boek dat hij zelf verkocht heeft.

De voorbeelden van Cynthia en Dylan tonen het resultaat van row-level security/access control met een ROW ACCESS POLICY in Snowflake. (We kijken naar screenshots van de Snowsight webinterface van Snowflake.) In het voorbeeld van Bert zien we juist een MASKING POLICY aan het werk: Bert mag niet zien wie wat verkocht heeft, maar wel welk boek verkocht is. Anna mag, als eigenaar, alle regels zien zonder dat er iets gemaskeerd wordt.

Conclusie

Snowflake neemt heel veel zorgen weg als het gaat om de beveiliging van belangrijke bedrijfsgegevens. Daardoor kunnen we ons volledig richten op het bepalen van wie wat moet kunnen zien, in plaats van hoe we daarvoor gaan zorgen. Technisch regelen we dat door 2 soorten policies te schrijven en daar toe te passen waar dat nodig is. Dit alles kan ons helpen om te voldoen aan juridische verplichtingen. Los daarvan, kan het ook heel nuttig zijn wanneer we bedrijfskritische gegevens (ook intern) af willen schermen. Ik hoop dat je wat aan deze blog hebt gehad!

Bekijk ook onze andere blogs over Tableau, Alteryx en Snowflake of werk samen met een van onze consultants. Vragen? Neem contact met ons op!