Eilutės lygio sauga: kaip apsaugoti duomenis Power BI ir DB

Eilutės lygio sauga (RLS) apibrėžia, kurias lentelės eilutes gali matyti konkretus vartotojas, ir taikoma tiek Power BI modelio lygmenyje, tiek pačioje duomenų bazėje. Tinkamai suprojektuota, ji leidžia vienoje ataskaitoje saugiai rodyti duomenis skirtingiems padaliniams, klientams ar filialams. Toliau rasite konkrečius diegimo žingsnius Power BI ir SQL/PostgreSQL aplinkose, testavimo tvarką ir BDAR atitikties niuansus.

Trumpai:

Prašymų kaip statinis RLS tinka nedideliam vartotojų skaičiui ir jų priskyrimai retai keičiasi, o dinaminis RLS geriau veikia dažnai kaitančioje organizacijoje.

Power BI diegimuose RLS taisyklės turi būti dėtos ant dimensijos lentelių ir patikrintos per „View as roles“ siekiant užtikrinti veiksmingą duomenų saugumą.

Patikrinus taisyklę ir sujungus vartotojus su Entra ID grupe, tyrimai rodo, kad klaidų dažniausiai kyla dėl netinkamo santykio arba raidžių dydžio neatitikimo taisyklėse.

Duomenų bazės lygmens RLS veikia nepriklausomai nuo naudotojo įrangos, todėl yra tinkamesnė sudėtingesnių sistemų arba kelių įrankių aplinkose.

RLS diegimo ir testavimo procesai turi būti atliekami nuosekliai, naudojant impersonaciją ir auditą, siekiant užtikrinti duomenų apsaugos ir reguliavimo reikalavimų laikymąsi.

Turinys

Kas yra eilutės lygio sauga (RLS): apibrėžimas ir naudojimo atvejai
Statinė ir dinaminė RLS: privalumai, trūkumai ir sprendimo rekomendacijos
RLS Power BI: žingsniai įdiegimui, DAX pavyzdžiai ir dažniausios klaidos
RLS duomenų bazėse (SQL Server, PostgreSQL): kaip tai veikia techniniu lygmeniu
Dizaino gerosios praktikos ir našumo optimizavimas RLS sprendimuose
Testavimas, valdymas ir auditavimas: kontrolinis sąrašas
RLS ir BDAR: ką įtraukti į dokumentaciją, kad parodytumėte atitiktį
Analitika360: kaip mes diegiame RLS Power BI sprendimuose
Redakcijos praktinė perspektyva: kada pradėti nuo RLS ir kada daryti pilotą
Kaip Analitika360 padeda įdiegti eilutės lygio saugą
Šaltiniai

Kas yra eilutės lygio sauga (RLS): apibrėžimas ir naudojimo atvejai

RLS mechanika grindžiama filtro ir blokavimo predikatais: sistema kiekvienam vartotojui automatiškai prideda sąlygą „WHERE“, kuri leidžia matyti tik jam priskirtas eilutes. Vartotojas tos taisyklės nei mato, nei gali pakeisti pats.

Įmonės eilutės lygio kontrolę taikomos šiais atvejais:

Multitenant sistemos — kelios organizacijos naudoja tą pačią ataskaitų platformą, matydamos tik savo duomenis.
Padalinių atskyrimas — regiono vadovas mato savo regiono pardavimus, generalinis direktorius mato visus.
Klientų segmentavimas — partneris ar tiekėjas prieina prie savo užsakymų, bet ne konkurentų duomenų.

Svarbu skirti du lygmenis: modelio RLS (Power BI semantinis modelis) veikia ataskaitos peržiūros metu, o duomenų bazės RLS veikia bet kokiam prisijungimui prie DB, nepaisant to, per kokį įrankį jis vyksta.

Statinė ir dinaminė RLS: privalumai, trūkumai ir sprendimo rekomendacijos

Statinis RLS priskiria konkrečią vertę tiesiai DAX taisyklėje, pavyzdžiui, filtruoja regioną pagal fiksuotą reikšmę „Vilnius“. Tai tinka nedideliam vartotojų skaičiui, kai priskyrimai keičiasi retai.

Dinaminis RLS naudoja funkcijas USERPRINCIPALNAME() arba CUSTOMDATA(), kurios modelyje palygina prisijungusio vartotojo tapatybę su mapping lentele. Tokia lentelė (paprastai pavadinta AppUser) sujungia el. paštą su padaliniu, regionu ar kliento ID, todėl priskyrimai atnaujinami automatiškai, kai keičiasi personalas — dinaminis RLS su mapping lentelėmis ypač naudingas didelės kaitos organizacijose.

Statinis RLS: paprasta, greita, bet reikia rankinio priežiūros augant vartotojų skaičiui.
Dinaminis RLS: skalės geriau, reikalauja tvarkingos mapping lentelės.
Atskiri workspace’ai ar modeliai: pasirenkami, kai grupių yra tik keletas ir joms reikia visiškai skirtingos duomenų struktūros, ne tik filtro.

Profesionalus patarimas: jei planuojate daug skirtingų rolių, dinaminis RLS su viena mapping lentele bus lengviau prižiūrimas nei daugybė statinių taisyklių.

RLS Power BI: žingsniai įdiegimui, DAX pavyzdžiai ir dažniausios klaidos

Eilutės lygio sauga Power BI aplinkoje diegiama per modelio rolių sistemą. Procesas atkartojamas beveik identiškai kiekviename projekte:

Sukurkite rolę Power BI Desktop skiltyje „Modeling“ → „Manage roles“.
Parašykite DAX filtro taisyklę dimensijos lentelėje, pavyzdžiui: [Regionas] = "Vilnius" arba dinamiškai [Email] = USERPRINCIPALNAME().
Sumodeliuokite AppUser lentelę su stulpeliais vartotojo el. paštas ir atitinkama grupė, susieta santykiu su faktų lentele per dimensiją.
Patikrinkite taisyklę naudodami „View as roles“ Power BI Desktop viduje.
Publikuokite ir priskirkite roles Power BI servise, skiltyje „Security“, geriausia per Entra ID grupes, ne pavienius vartotojus.

Testavimas negali apsiriboti vienu peržiūros veiksmu servise. RLS filtrai taikomi DAX užklausoms ir gali sulėtinti ataskaitą, todėl kiekvieną rolę reikia patikrinti tiek per „View as“, tiek per impersonaciją realiu vartotojo profiliu.

Dažniausios klaidos: taisyklė uždėta ant faktų lentelės (ne dimensijos), pamirštas dvipusis santykio filtravimas, arba rolė priskirta el. paštu, kuris nesutampa raidžių dydžiu su Entra ID įrašu. Pastarasis dažnai lieka nepastebėtas kelias savaites, kol vartotojas praneša, kad mato „per daug“ arba „per mažai“ duomenų.

RLS duomenų bazėse (SQL Server, PostgreSQL): kaip tai veikia techniniu lygmeniu

Duomenų bazės lygmens RLS veikia nepriklausomai nuo to, per kokį klientą prisijungiama, ir tai jos didžiausias pranašumas prieš modelio RLS.

SQL Server naudoja inline table valued function, kuri grąžina 1 arba 0 pagal vartotojo kontekstą, ir tą funkciją prijungia per CREATE SECURITY POLICY su filtro (SELECT) arba blokavimo (INSERT/UPDATE/DELETE) predikatu. SQL Server RLS veikia per filtro ir blokavimo predikatus, pridedamus be pačios lentelės struktūros keitimo, tačiau politikos sukūrimas dažnai reikalauja SCHEMABINDING, kas apribos tolimesnius lentelės keitimus.

PostgreSQL sprendimas šiek tiek kitoks:

Politika kuriama komanda CREATE POLICY ir gali būti permissive (bet kuri sutampanti politika leidžia prieigą) arba restrictive (visos turi sutapti).
PostgreSQL CREATE POLICY leidžia lanksčiai kombinuoti kelias taisykles vienai lentelei.
Superuser vartotojai ir rolės su atributu BYPASSRLS visada apeina politiką, nepaisant jos taisyklių.

DB lygmens RLS rekomenduojama, kai prie duomenų jungiasi keli įrankiai (ne tik Power BI), arba kai reikalinga garantija, kad net administratorius per SQL klientą negalės apeiti taisyklės atsitiktinai.

Dizaino gerosios praktikos ir našumo optimizavimas RLS sprendimuose

Modelio architektūra nulemia, ar RLS veiks greitai, ar sulėtins kiekvieną ataskaitos atidarymą. Kelios taisyklės čia neišvengiamos.

Taisyklę dėkite ant dimensijos, ne fakto. Filtras propaguojasi per santykį į faktų lentelę automatiškai, jei santykis aktyvus ir vienos kryptimi.
Venkite LOOKUPVALUE() DAX taisyklėse. Geriausios praktikos rekomenduoja taikyti RLS ant dimensijų ir naudoti santykius, nes LOOKUPVALUE skenuoja visą lentelę kiekvienai užklausai.
Indeksuokite predikato stulpelius DB lygmenyje. Security policy funkcija kviečiama kiekvienai eilutei, todėl neindeksuotas stulpelis reiškia pilną lentelės skenavimą.
Profiliuokite užklausas. DAX Studio ar Performance Analyzer parodo, kur RLS filtras realiai lėtina užklausą.

Praktikoje pasitvirtina trys pasikartojantys šablonai: grupėmis pagrįstas priskyrimas (vartotojas priklauso Entra ID grupei, grupė susieta su regionu), hierarchinis priskyrimas (kelių lygių padaliniai per parent-child struktūrą) ir daugiaklientis (tenant ID kaip privalomas stulpelis kiekvienoje faktų lentelėje).

Profesionalus patarimas: skaidri žvaigždės schema su aiškiais santykiais pagerina filtro propagaciją labiau nei bet kokia DAX optimizacija — pradėkite nuo modelio, ne nuo taisyklės.

Testavimas, valdymas ir auditavimas: kontrolinis sąrašas

Nepatikrinta taisyklė yra tolygu jos nebuvimui. Prieš publikavimą ir periodiškai po jo verta laikytis fiksuotos tvarkos.

Priskirkite roles per Entra ID grupes, ne pavienius vartotojus — tai leidžia valdyti prieigą centralizuotai per personalo pasikeitimus.
Patikrinkite kiekvieną rolę „View as“ režimu Power BI Desktop aplinkoje prieš publikavimą.
Atlikite impersonaciją realiais scenarijais naudodami Tabular Editor arba DAX Studio, kad patikrintumėte ne tik vieną, bet kelias sudėtingas užklausas vienu metu.
Fiksuokite audito žurnalą — kas priskyrė rolę, kada, ir kokia taisyklė buvo pakeista.
Kartokite testus po kiekvieno modelio pakeitimo, nes naujas stulpelis ar santykis gali netyčia atverti kelią aplink senąją taisyklę.

Šis testavimo ir dokumentavimo ciklas yra praktiškiausia priemonė prieš pavojingas eilutės situacijas — atvejus, kai vartotojas per klaidą pamato svetimus finansinius ar asmeninius duomenis.

RLS ir BDAR: ką įtraukti į dokumentaciją, kad parodytumėte atitiktį

RLS yra viena iš tinkamų techninių priemonių, minimų BDAR 32 straipsnyje, nes ji riboja prieigą prie asmens duomenų iki minimaliai reikalingos apimties. RLS yra veiksminga BDAR atitikties demonstravimo dalis, bet tik jei ji dokumentuota ir centralizuota, o ne palikta atsitiktiniams pakeitimams kiekviename modelyje.

Dokumentacijoje verta laikyti:

Rolių ir vartotojų priskyrimo žurnalą su datomis.
Testų rezultatus prieš kiekvieną naujos versijos publikavimą.
Audito įrašus apie taisyklių pakeitimus.

RLS savaime neišsprendžia visų saugumo reikalavimų. Ji turi veikti su duomenų saugos politika apimančia prieigos valdymą, šifravimą ir vartotojų autentifikaciją kaip vienu sluoksniu iš kelių.

Analitika360: kaip mes diegiame RLS Power BI sprendimuose

Analitika360 projektuoja modelį taip, kad RLS taisyklė nuo pat pradžių dedama ant dimensijos lentelės, o vartotojo priskyrimas eina per mapping lentelę, susietą su Entra ID grupe. Ataskaitų vartotojams paprastai suteikiama tik skaitymo teisė į semantinį modelį — mažiausių privilegijų principas taikomas be išimčių, net administravimo aplinkoje.

Klientai, tokie kaip restoranų tinklai su keliais padaliniais ar buhalterinės įmonės, valdančios kelių verslo klientų duomenis, gauna automatizuotas ataskaitas, kuriose kiekvienas vadovas mato tik savo apimtį. Diegimo pavyzdžius rasite Power BI ataskaitų pavyzdžių puslapyje, o duomenų tvarkymo principai aprašyti privatumo politikoje.

Redakcijos praktinė perspektyva: kada pradėti nuo RLS ir kada daryti pilotą

Dauguma įmonių pradeda RLS diegimą pernelyg vėlai, kai ataskaita jau naudojama keliuose padaliniuose. Verta pradėti nuo mažo piloto su vienu regionu ir aiškiu mapping lentelės planu, ne nuo galutinės architektūros. Jei organizacijoje jau yra daugiau nei penkios rolės arba jautrūs finansiniai duomenys, verta kreiptis į specialistus, kurie RLS integruoja su platesne saugumo strategija, ne kaip pavienę DAX taisyklę. Pirmas žingsnis visada tas pats: sudarykite vartotojų ir duomenų prieigos inventorizaciją, tada mapping lentelę ir SaaS strategiją.

— Analitika360

Kaip Analitika360 padeda įdiegti eilutės lygio saugą

Analitika360 pasiūlymas skiriasi nuo bendro Power BI konsultanto tuo, kad RLS projektuojamas kartu su jau parengtais ataskaitų paketais Rivilė ir Finvalda duomenims, todėl saugos taisyklė pritaikoma prie jau egzistuojančio modelio, ne kuriama nuo nulio.

Analitika360

Paslauga apima modelio dizainą su RLS ant dimensijų lentelių, rolių priskyrimą per Entra ID grupes, testavimą naudojant „View as“ scenarijus ir dokumentaciją, kurią galima pateikti kaip BDAR techninių priemonių įrodymą. Klientas gauna automatizuotai atsinaujinančias ataskaitas, kuriose kiekvienas padalinys, filialas ar klientas mato tik jam priskirtus duomenis, be papildomo rankinio filtravimo. Jei valdote kelis padalinius ar norite, kad RLS taisyklės būtų dokumentuotos audito reikalams, apžvelkite verslo analitikos sprendimus pagal veiklos sritį ir susisiekite dėl RLS diegimo plano jūsų Power BI aplinkai.