Ar Power BI atitinka BDAR reikalavimus Lietuvoje?

Taip, Power BI galima naudoti laikantis BDAR, bet vien įrankio nepakanka. Reikia trijų dalykų kartu: dokumentuoto rizikos vertinimo pagal VDAI gaires, semantinio modelio teisių plano su row-level security ir workspace valdymu, ir jautrumo žymų su Purview audito seka. Pradėti reikia nuo rizikos vertinimo, nes jis nustato, kokios techninės priemonės organizacijai iš tikrųjų reikalingos.

Trumpai:

• Rizikos vertinimas yra būtinas, nes jis nustato, kokios techninės priemonės iš tikrųjų reikalingos duomenų apsaugai Power BI sprendimuose.
• Row-level security negali apriboti prieigos prie modelio objektų, todėl būtina naudoti papildomas priemones ir tinkamai valdyti workspace teises.
• Sensitivity žymų veiksmai automatiškai registruojami audit log’e, o jų istorija yra svarbi įrodant duomenų klasifikaciją ir atsekamumą.
• Organizacija turi nuolat peržiūrėti prieigos teises ir valdyti workspace rolės nustatymus per Microsoft Entra, siekiant laikytis BDAR principais grindžiamo mažiausių privilegijų principo.
• Audito duomenys ir jautrumo žymų istorija yra pagrindiniai įrodymai pranešant VDAI apie duomenų pažeidimus, kuriuos būtina pranešti per 72 valandas nuo įvykio.

Turinys

• BDAR reikalavimų santrauka ir jų sąsaja su Power BI sprendimais
• Row-level security: techniniai apribojimai ir gerosios praktikos
• Jautrumo žymos ir Microsoft Purview: klasifikavimas ir audito pėdsakas
• Workspace teisių modelis ir Microsoft Entra: kaip apsaugoti prieigą, kad RLS veiktų
• Dokumentavimas, auditas ir pranešimas VDAI apie pažeidimus
• Praktinis pavyzdys: kaip Analitika360 įgyvendina BDAR elementus Power BI sprendimuose
• Įgyvendinimo kontrolinis sąrašas: žingsniai, atsakomybės ir priėmimo kriterijai
• Redakcijos požiūris: BDAR atitiktis yra procesas, ne vienkartinis diegimas
• Analitika360 sprendimai: Power BI ataskaitos su BDAR pagrindu Rivilė ir Finvalda naudotojams
• Šaltiniai
• Dažniausiai užduodami klausimai

BDAR reikalavimų santrauka ir jų sąsaja su Power BI sprendimais

BDAR nenurodo konkrečių technologijų, tačiau reikalauja, kad duomenų valdytojas pats įvertintų riziką ir pasirinktų tinkamas priemones. VDAI gairėse dėl organizacinių ir techninių saugumo priemonių aiškiai nurodyta, kad BDAR 24 ir 32 straipsniai įpareigoja atlikti rizikos vertinimą ir pagrįsti pasirinktų priemonių tinkamumą dokumentais. Tai reiškia, kad Power BI diegimas prasideda ne nuo modelio kūrimo, o nuo klausimo, kokie asmens duomenys tekės į ataskaitas ir kokia grėsmė kyla, jei jie pasiektų netinkamas rankas.

Gairėse pabrėžiama, kad priemonių pasirinkimas turi atsižvelgti į duomenų tvarkymo pobūdį, aprėptį, kontekstą ir tikslus, taip pat į riziką fizinių asmenų teisėms. Praktiškai tai reiškia, kad restorano tinklas, analizuojantis pardavimų duomenis, turi kitokį rizikos profilį nei buhalterinė įmonė, dirbanti su darbuotojų atlyginimų informacija.

Organizacija, kuri diegia Power BI sprendimą, turėtų turėti bent šiuos dokumentus:

• Duomenų saugumo politiką, kurioje aprašyta, kaip tvarkomi asmens duomenys analitikos sistemose.
• Rizikos vertinimo protokolą, pagrindžiantį, kodėl pasirinktos konkrečios techninės priemonės.
• Prieigos valdymo politiką, nustatančią, kas ir kokiu pagrindu gauna prieigą prie ataskaitų.
• Incidentų valdymo procedūrą, apibrėžiančią veiksmus duomenų saugumo pažeidimo atveju.

Rizikos vertinimas turi atskleisti konkrečius dalykus: kokie lentelių stulpeliai laikomi asmens duomenimis, kas turi prieigą prie neagreguotų duomenų ir ar ataskaitos eksportuojamos už organizacijos ribų. Tik tada galima pagrįstai spręsti, ar pakanka row-level security, ar reikia papildomai riboti prieigą prie visų modelio objektų.

Row-level security: techniniai apribojimai ir gerosios praktikos

Row-level security, arba RLS, yra pagrindinė Power BI priemonė, ribojanti, kurias eilutes vartotojas gali matyti ataskaitoje. Tačiau Microsoft dokumentacija apie RLS nurodo svarbų apribojimą: RLS filtrai riboja tik eilučių prieigą, jie negali apriboti prieigos prie modelio objektų, tokių kaip lentelės, stulpeliai ar priemonės. Tai reiškia, kad vartotojas, turintis prieigą prie modelio, gali pamatyti struktūrą ir metaduomenis, net jei konkrečios eilutės jam nerodomos.

Šis apribojimas svarbus BDAR požiūriu, nes rizikos vertinime negalima teigti, kad RLS savaime užtikrina visišką prieigos kontrolę. Kai duomenys itin jautrūs, dažnai efektyviau atskirti auditorijas per skirtingus semantinius modelius, pavyzdžiui, vieną modelį vadovams su pilna informacija, kitą operacijų komandai su apribota apimtimi, nei bandyti sukurti vieną sudėtingą taisyklių rinkinį visiems.

Praktinis RLS diegimas paprastai vyksta tokia tvarka:

1. Modelyje sukuriama rolė, priskirianti DAX filtrą konkrečiai lentelei, pavyzdžiui, pagal padalinio ar vartotojo ID.
2. Rolė testuojama naudojant „Test as role“ funkciją Power BI Desktop, kad būtų patikrinta, ar filtras veikia numatytu būdu.
3. Modelis publikuojamas į workspace, o rolėms priskiriami konkretūs vartotojai arba Entra saugumo grupės.
4. Periodiškai tikrinamas našumas su Performance Analyzer, nes sudėtingi RLS filtrai gali sulėtinti ataskaitų atsivėrimą.

Svarbus niuansas: Microsoft Fabric dokumentacija nurodo, kad RLS taikoma tik vartotojams, turintiems Viewer teisę workspace’e. Vartotojams su Admin, Member ar Contributor rolėmis RLS netaikoma, nes jie turi redagavimo teises į semantinį modelį. Tai dažna klaida: RLS taisyklės sukurtos teisingai, bet vartotojai turi per plačias workspace teises, todėl apribojimas praktiškai neveikia.

Profesionalus patarimas: Prieš publikuojant modelį, patikrinkite kiekvieno vartotojo workspace rolę, ne tik RLS taisyklę. Jei vartotojas turi Contributor teises, RLS filtras jam nebus taikomas nepriklausomai nuo taisyklės sudėtingumo.

Jautrumo žymos ir Microsoft Purview: klasifikavimas ir audito pėdsakas

Sensitivity labels, arba jautrumo žymos, leidžia klasifikuoti Power BI turinį pagal jautrumo lygį, pavyzdžiui, „vidinis naudojimas“ ar „konfidencialu“. Microsoft dokumentacija apie sensitivity labels patvirtina, kad žymų taikymo, keitimo ir pašalinimo veiksmai fiksuojami veiklos žurnale, o administravimo portale yra atskira apsaugos metrikų ataskaita, rodanti jautrių duomenų būklę visame organizacijos aplinkoje.

Beveik visi žymos veiksmai automatiškai atsiduria audit log’e, o tai suteikia duomenų valdytojui konkretų įrodymą, kad jautrūs duomenys buvo identifikuoti ir stebimi, kaip patvirtina Microsoft dokumentacija.

Microsoft Purview papildo šią sistemą kitu būdu: jis skenuoja Power BI turinį ir renka metaduomenis bei lineage informaciją, tai yra, parodo, iš kur duomenys atkeliavo ir kaip jie transformuoti kelyje iki ataskaitos. Microsoft Purview dokumentacija nurodo, kad po tenant’o registracijos skenavimui reikėtų palaukti apie 15 minučių prieš testuojant ryšį, nes konfigūracijos pakeitimai sklinda sistemoje ne akimirksniu.

Praktinė nauda BDAR dokumentacijai yra tiesioginė:

• Lineage informacija leidžia parodyti, kad asmens duomenys iš Rivilė ar Finvalda apskaitos sistemos pasiekė konkrečią ataskaitą per aiškų, atsekamą kelią.
• Sensitivity label istorija tampa įrodymu, kad organizacija sistemingai klasifikuoja jautrius duomenis, ne tik deklaruoja tai politikoje.
• Protection metrics report leidžia duomenų apsaugos pareigūnui reguliariai matyti bendrą jautrių duomenų būklę be rankinio audito.

Workspace teisių modelis ir Microsoft Entra: kaip apsaugoti prieigą, kad RLS veiktų

RLS taisyklė yra tik pusė sprendimo, jei workspace teisės suteiktos neatsargiai. Power BI aplinkoje egzistuoja keturios pagrindinės workspace rolės: Admin, Member, Contributor ir Viewer. Kaip minėta anksčiau, Microsoft Fabric dokumentacija patvirtina, kad RLS taikoma tik Viewer rolei, todėl bet kokia platesnė teisė praktiškai atveria pilną prieigą prie duomenų.

Tai reiškia, kad organizacija, siekianti BDAR atitikties, turi valdyti ne tik RLS taisykles, bet ir tai, kas gauna kiekvieną rolę:

• Vartotojų priskyrimas prie rolių turėtų vykti per Microsoft Entra saugumo grupes, ne pavieniui, nes tai leidžia centralizuotai valdyti prieigą ir greitai atšaukti ją, kai darbuotojas palieka pareigas.
• Contributor ir Member rolės turėtų būti skirtos tik asmenims, kurie iš tikrųjų kuria ar redaguoja ataskaitas, ne tiems, kurie jas peržiūri.
• Periodinė teisių peržiūra, pavyzdžiui, kas ketvirtį, padeda nustatyti, ar prieigos nebuvo suteiktos per plačiai laikinam projektui, o tada pamirštos.
• Duomenų saugojimo (retention) politika turėtų nustatyti, kiek laiko istoriniai audit log įrašai laikomi prieinami, kad juos būtų galima pateikti VDAI patikrinimo atveju.

Šis principas, žinomas kaip mažiausių privilegijų suteikimas, nėra vien IT saugumo rekomendacija. Rizikos vertinimo dokumentuose jis turėtų būti aiškiai užfiksuotas kaip organizacinė priemonė, papildanti techninį RLS sprendimą.

Dokumentavimas, auditas ir pranešimas VDAI apie pažeidimus

Kai techninės priemonės įdiegtos, organizacijai reikia sistemos, kaip fiksuoti jų veikimą ir reaguoti, jei kas nutrūksta. Power BI aplinkoje audito informacija renkama iš kelių šaltinių, o kiekvienas jų turi savo vietą BDAR dokumentacijoje.

1. Power BI audit log fiksuoja vartotojų veiksmus, tokius kaip ataskaitų peržiūra, eksportavimas ar bendrinimas, ir yra pagrindinis įrodymų šaltinis vidiniam auditui.
2. Sensitivity label veiklos žurnalas rodo, kada žyma buvo pritaikyta, pakeista ar pašalinta konkrečiam turiniui, kaip patvirtina Microsoft dokumentacija.
3. Protection metrics report suteikia bendrą vaizdą apie jautrių duomenų paskirstymą organizacijoje per tam tikrą laikotarpį.
4. Šie įrašai turėtų būti saugomi pagal iš anksto nustatytą retention politiką, kad prireikus juos būtų galima pateikti per trumpą laiką.

Jei įvyksta duomenų saugumo pažeidimas, pavyzdžiui, netinkamai suteikta prieiga leidžia pamatyti jautrius duomenis, VDAI reikalauja pranešti apie tai per 72 valandas nuo sužinojimo momento. Pranešime būtina nurodyti pažeidimo pobūdį, tikėtinas pasekmes ir priemones, kurių imtasi ar planuojama imtis. Todėl audit log ir sensitivity label istorija tampa ne tik techniniu įrankiu, bet ir tiesioginiu šaltiniu, leidžiančiu greitai surinkti VDAI reikalaujamą informaciją.

Praktinis pavyzdys: kaip Analitika360 įgyvendina BDAR elementus Power BI sprendimuose

Kai kurie Power BI ataskaitų sprendimai sujungia duomenis iš apskaitos programų su papildomais šaltiniais, tokiais kaip SharePoint ir Excel. Šie sprendimai sukurti taip, kad ataskaitos atsinaujintų automatiškai ir sumažintų rankinio duomenų perkėlimo poreikį.

Techniniame lygyje sprendimo architektūra derina keletą aprašytų elementų kartu. Semantiniame modelyje diegiama row-level security, pritaikyta pagal padalinį ar restorano tinklo filialą, o prieiga prie workspace valdoma per Microsoft Entra saugumo grupes, ne pavienius vartotojus. Jautriems duomenų segmentams, tokiems kaip darbuotojų atlyginimai ar kliento kontaktinė informacija, taikomos sensitivity labels, kurios leidžia sekti, kas ir kada peržiūrėjo konkretų turinį.

Automatizuotos ataskaitos, kurios atsinaujina be papildomo vartotojo įsikišimo, leidžia komandai sutelkti dėmesį į sprendimų priėmimą, ne duomenų perkėlimą.

— Analitika360

Įgyvendinimo kontrolinis sąrašas: žingsniai, atsakomybės ir priėmimo kriterijai

Sėkmingas BDAR ir Power BI derinimas vyksta nuosekliai, ne visais frontais vienu metu.

1. Atlikti rizikos vertinimą, dokumentuojant, kokie asmens duomenys pateks į modelį ir kas prie jų turės prieigą.
2. Suprojektuoti sprendimo architektūrą, nusprendžiant, ar pakanka vieno modelio su RLS, ar reikia atskirų modelių skirtingoms auditorijoms.
3. Įdiegti RLS taisykles ir sensitivity labels, pritaikytas pagal rizikos vertinimo išvadas.
4. Sukonfigūruoti Microsoft Entra saugumo grupes ir priskirti jas workspace rolėms, laikantis mažiausių privilegijų principo.
5. Testuoti sprendimą naudojant „Test as role“ funkciją ir patikrinti, ar audit log įrašai prieinami atsakingam asmeniui.

Kiekvienas etapas turi turėti atsakingą asmenį: rizikos vertinimą tvirtina duomenų apsaugos pareigūnas, architektūrą projektuoja IT ar analitikos komanda, o galutinį priėmimą patvirtina modelio savininkas, patikrinęs, kad testavimo rezultatai atitinka planą ir kad audito įrašai yra pasiekiami peržiūrai.

Redakcijos požiūris: BDAR atitiktis yra procesas, ne vienkartinis diegimas

Dažna klaida yra manyti, kad BDAR atitiktis baigiasi, kai RLS taisyklė sukonfigūruota ir sensitivity label pritaikyta. Realybėje tai yra pradžios taškas, ne pabaiga. Teisės keičiasi, darbuotojai ateina ir išeina, o duomenų šaltiniai auga, todėl vienkartinis rizikos vertinimas per metus nuvertėja greičiau, nei tikimasi.

Organizacijoms verta įtraukti duomenų apsaugos pareigūną ir IT saugumo atsakingą asmenį jau projektavimo etape, ne tik po diegimo patikrinimui. Tai leidžia rizikos vertinimą laikyti gyvu dokumentu, ne formalumu.

— Analitika360

Analitika360 sprendimai: Power BI ataskaitos su BDAR pagrindu Rivilė ir Finvalda naudotojams

Įmonėms, naudojančioms apskaitos sistemas, gali būti naudingi paruošti Power BI ataskaitų paketai, kurie integruoti su šiomis sistemomis ir atsinaujina automatiškai, be papildomo darbo jūsų komandai.

Pasiūlyme yra keturi standartiniai paketai ir individualių projektų galimybė sudėtingesniems atvejams, kai reikia sujungti papildomus šaltinius, tokius kaip CRM ar logistikos sistemas.

• Rivilė Basic ir Finvalda Basic paketai tinka įmonėms, norinčioms pradėti nuo pagrindinių finansinių rodiklių ataskaitų.
• Rivilė PRO ir Finvalda PRO paketai suteikia platesnę ataskaitų aprėptį ir daugiau integracijos galimybių.
• Individualūs projektai įkainojami valandinio darbo pagrindu, skirti sprendimams, pritaikytiems konkrečios įmonės procesams ir IT sistemoms.

Kiekvienas paketas apima duomenų atnaujinimo automatizavimą, todėl komanda nebeturi rankiniu būdu eksportuoti ar perkelti failų tarp sistemų. Norėdami pasirinkti tinkamą paketą savo verslui, apsilankykite kainodaros puslapyje arba susipažinkite su Rivilė Basic ir Finvalda PRO sprendimais detaliau.

Šaltiniai

Norintys giliau susipažinti su teisiniu ir techniniu pagrindu, rasite naudingos medžiagos šiuose šaltiniuose: VDAI saugumo priemonių gairėse aprašytas rizikos vertinimo pagrindas pagal BDAR 24 ir 32 straipsnius, Microsoft RLS dokumentacijoje rasite techninius apribojimus ir konfigūravimo žingsnius, o Purview dokumentacija paaiškina, kaip skenuoti Power BI turinį ir gauti lineage informaciją. Finansinių duomenų atskaitomybės kontekste naudingas ir partnerio straipsnis apie valiutų rinkos analizę.

This article is general information, not a substitute for advice from a qualified lawyer. Consult a qualified legal professional about your own circumstances before acting on anything here.

• Tinkamų organizacinių ir techninių duomenų saugumo priemonių įgyvendinimo gairės
• Row-level security (RLS) with Power BI - Microsoft Fabric

Dažniausiai užduodami klausimai

Ar Power BI savaime atitinka BDAR reikalavimus?

Ne, Power BI yra įrankis, o atitiktis priklauso nuo to, kaip jis sukonfigūruotas ir kokie procesai jį palaiko. Reikia rizikos vertinimo, row-level security taisyklių, workspace teisių valdymo ir sensitivity labels kartu, kaip nurodyta VDAI gairėse.

Kodėl RLS taisyklė kartais neapsaugo duomenų, nors sukonfigūruota teisingai?

Dažniausia priežastis yra ta, kad vartotojas turi Admin, Member ar Contributor teises workspace’e, o RLS taikoma tik Viewer rolei. Todėl būtina patikrinti ne tik DAX filtrą, bet ir kiekvieno vartotojo workspace rolę.

Kiek laiko turime pranešti VDAI apie duomenų saugumo pažeidimą?

VDAI reikalauja pranešti per 72 valandas nuo sužinojimo apie pažeidimą momento. Pranešime būtina nurodyti pažeidimo pobūdį, galimas pasekmes ir priemones, kurių imtasi.

Ką fiksuoja Power BI, kai naudojamos sensitivity labels?

Sensitivity label taikymo, pakeitimo ir pašalinimo veiksmai automatiškai patenka į veiklos žurnalą, kaip aprašyta Microsoft dokumentacijoje. Administravimo portale papildomai prieinama apsaugos metrikų ataskaita, rodanti bendrą jautrių duomenų būklę.

Ar Analitika360 sprendimai padeda įgyvendinti BDAR reikalavimus?

Analitika360 paketai, tokie kaip Rivilė PRO ar Finvalda PRO, integruoti su automatiniu duomenų atnaujinimu, kuris sumažina rankinio duomenų perkėlimo riziką. Konkrečias RLS ir sensitivity label konfigūracijas rekomenduojama derinti su individualiu projektu, atsižvelgiant į jūsų įmonės rizikos vertinimą.