Row Level Security GGZ: verschil tussen versies

Naar navigatie springen Naar zoeken springen
Geen bewerkingssamenvatting
 
(4 tussenliggende versies door dezelfde gebruiker niet weergegeven)
Regel 38: Regel 38:
De gebruikers autorisatiematrix speelt dus een belangrijke rol voor de beveiliging van data.  
De gebruikers autorisatiematrix speelt dus een belangrijke rol voor de beveiliging van data.  


Tot nu toe is elke implementatie van de gebruikers autorisatiematrix maatwerk geweest, maar enkele veel gebruikte aanpakken staan hieronder:
Tot nu toe is elke implementatie van de gebruikers-autorisatiematrix maatwerk geweest, maar enkele veel gebruikte aanpakken staan hieronder:


* Alle medewerkers mogen alleen hun eigen data zien. Op een whitelist staan de medewerkers die alles mogen zien.
* Alle medewerkers mogen alleen hun eigen data zien. Op een whitelist staan de medewerkers die alles mogen zien.
* Op basis van de functie in het personeelsysteem wordt bepaald welke data ingezien mag worden.
* Op basis van de functie in het personeelsysteem wordt bepaald welke data ingezien mag worden.
** Voorbeeld: Een manager mag bijvoorbeeld data zien van zijn afdeling. Een GZ psycholoog mag alleen zijn eigen data zien. Een stafmedewerker HR mag alle HR data zien.
** Voorbeeld: Een manager mag bijvoorbeeld data zien van zijn afdeling. Een GZ psycholoog mag alleen zijn eigen data zien. Een stafmedewerker HR mag alle HR data zien.
* Op basis van een rol die is gedefinieerd in de Activie Directory wordt RLS toegepast.
* Op basis van een rol die is gedefinieerd in de Active Directory wordt RLS toegepast. De gebruikers/rollen worden uit de AD geëxporteerd en vervolgens gebruikt om automatisch de gebruikers-autorisatiematrix aan te maken.
Een voorbeeld van een gebruikersautorisatiematrix is in de figuur hieronder te vinden. Een uitleg volgt na de figuur.
[[Bestand:VC BI RLS3.png|geen|omkaderd|Autorisatiematrix]]
In deze figuur is aangegeven welke functie welke data mag zien. De functies in de figuur refereren naar een groep van functies. In de uitwerking van de autorisatiematrix zal verwezen worden naar de exacte functiecodes uit het HR systeem. Voor vaststelling met management is echter deze figuur een prima stuk ter besluitvorming.
 
Zo wordt gespecifieerd dat een manager uit de zorg alleen de data van zijn team zien, zowel de zorg data, als de personele en financiële data. De matrix geeft ook aan dat een HR adviseur/controller alle personele data mag zien, maar geen zorg en financiële data.
 
== Data autorisatieschema ==
Ook het data-autorisatieschema speelt een belangrijke rol voor de beveiliging van data. Het data-autorisatieschema kan in het ValueCare portaal ingezien en gewijzigd worden via de beheertabel "Beheer BI: Data autorisatie RLS". In de figuur hieronder staat een voorbeeld. Onder de figuur volgt een uitleg.
[[Bestand:VC BI RLS2.png|geen|omkaderd]]
Voor de dataset "bi_personeel_bezetting" is aangegeven dat het de Module "PER" betreft, het element "OE" en er moeten rollen gemaakt worden voor "Alles", "OE Niv 1 t/m 3" en de "Medewerker". Uitgaande van fictieve namen voor de Organisatieniveau's en de medewerker, betekent dit dat de rollen er bijvoorbeeld zo uit zien voor 1 specifieke datarij:
{| class="wikitable"
|+
!Rol
!Toelichting
|-
|PER-OE-ALL
|rol voor gebruikers die alles mogen zien
|-
|PER-OE-REGIO_UTRECHT
|rol voor gebruikers die behoren bij OE Niv 1 gelijk aan REGIO_UTRECHT
|-
|PER-OE-POLI_UTRECHT
|rol voor gebruikers die behoren bij OE Niv 2 gelijk aan POLI_UTRECHT
|-
|PER-OE-POLI_TEAM_OUDLAAN
|rol voor gebruikers die behoren bij OE Niv 3 gelijk aan POLI_TEAM_OUDLAAN
|-
|PER-MW-12345
|rol voor gebruiker 12345, de datarij gaat over gebruiker 12345
|}
Tabellen krijgen standaard de RLS "Geen toegang". Dat betekent dat geen enkele gebruiker de data mag zien.
 
Als een tabel een vinkje krijgt in de tabel "Geen RLS" betekent dit dat alle gebruikers de data mogen zien.
 
 
 
 


<p style="text-align: center">{{VALUECARE}}</p>
<p style="text-align: center">{{VALUECARE}}</p>