Twee methoden vergeleken: metadata versus ontologie
Er zijn verschillende implementatiescenario’s mogelijk voor Ontology Driven Authorization, oftewel autorisatie op basis van de inhoud van een document. Dit artikel beschrijft een Ontology Driven scenario, middels een zogenaamd Data Lake.
In veel organisaties hebben systeembeheerders een dagtaak aan de autorisatie van medewerkers tot data. Zij bekijken, soms in opdracht van de compliance officer, per systeem welke medewerkers toegang krijgen tot welke data in de database al dan niet via een applicatie user interface. Voor medewerkers met dezelfde functies worden vaak gegroepeerde autorisatierollen gedefinieerd, waaraan de toegang tot de data wordt opgehangen. Aan zo’n rol zitten grote hoeveelheden regels, waarin is vastgelegd, welke rechten een rol heeft op documenten en tabellen. Uiteindelijk ontstaat een complexe autorisatiematrix per rol per systeem, waarin de leesrechten, schrijfrechten en creëerrechten zijn opgenomen. We noemen dit proces: autorisatie op basis van metadata (Metadata Driven Authorization).
Uitdagingen
Dit is een gebruikelijke manier van autoriseren, maar het kent een aantal beperkingen. Bovendien dienen organisaties voorzorgsmaatregelen te nemen voor wet en regelgeving, zoals GDPR en de Wet Meldplicht Datalekken. Dientengevolge ontstaan de volgende uitdagingen:
- De inhoudelijke data kan afwijken van de metadata-omschrijvingen.
- Hoe kun je delen van de data in een document of tabel autoriseren?
- Hoe voorkom je dat er bij het combineren van geautoriseerde data nieuwe data ontstaat die een specifieke rol niet mag zien?
- Hoe zorg je ervoor, dat de autorisatie op de inhoud van een document is gebaseerd in plaats van metadata over dat document?
- Wat als een document inhoudelijk wordt gewijzigd en daardoor de initieel opgelegde autorisatie niet meer geldig is?
- Hoe kun je achteraf controleren dat een medewerker data heeft bekeken, waar hij/zij vanuit zijn/haar rol niet bij mocht in het kader van de Wet Meldplicht Datalekken?
- Wat als in het kader van de GDPR een klant vraagt om inzage in wat de organisatie allemaal over hem of haar heeft vastgelegd in de ict-systemen?
- Wat als in het kader van de GDPR een klant vraagt om vergeten te worden en hij/zij eist dat alle betreffende data wordt verwijderd uit de ict-systemen?
Toekomstmuziek
Stelt u bent de Compliance Officer van een beursgenoteerde onderneming en u moet aan uw toezichthouders aantonen dat u in controle bent over wie er waar wanneer toegang heeft tot uw bedrijfsdata. Stelt u zich voor dat de business u dan vraagt om toegang tot grote hoeveelheden data die zij graag willen analyseren door data scientists, om efficiënter en effectiever te worden in de bedrijfsvoering. U wordt onder druk gezet om de business te faciliteren, maar u wilt ook voldoen aan opgelegde data-governance-eisen. Een oplossing hiervoor lijkt toekomstmuziek, maar is dichterbij, dan u denkt.
De MarkLogic methode
Het Data Lake scenario is schematisch weergegeven in de illustratie. Dit scenario begint met Big Data Capture. Hierbij wordt data, in de vorm van bedrijfsdocumenten en bedrijfsdatabases, door MarkLogic ingelezen en weggeschreven naar XML-documenten in het Data Lake. MarkLogic heeft zeer veel adapters, om verschillende bestandtypen automatisch te detecteren en deze vervolgens ‘as is’ te converteren naar XML-documenten. Omdat MarkLogic een semantische database is, kan alle ingelezen data automatisch verrijkt worden met ontologieën, zoals language packs, branche georiënteerde thesaurussen en een specifieke autorisatie ontologie.
Vervolgens begint het bedenken van de juiste data-autorisatie behorend bij de rollen per gebruikersgroep. Welke data mag bijvoorbeeld de rol Finance nu wel en niet zien? Wat heeft de rol Marketing minimaal nodig aan data om de taken goed te kunnen uitvoeren? We noemen dit principe ook wel need-to-know basis.
Controle
Om deze methode te kunnen implementeren moeten we de data in het Data Lake classificeren door het toevoegen van tag-elementen in de data zelf. We verrijken hierbij alle documenten in het Data Lake met extra autorisatie classificatiegegevens op basis van de inhoud. Denk hierbij bijvoorbeeld aan de volgende classificatie-tags: ADRES, PERSOON_MEDISCH, NAAM_ORGANISATIE, PERSOON_NAAM, TELEFOONNUMMER EN EMAILADRES. Per classificatie-tag zorgt een text mining algoritme per document of een document deze classificatie-tag krijgt.
Mag de rol Marketing documenten zien met de combinatie PERSOON_NAAM en PERSOON_MEDISCH?
De autorisatie ontologie bevat uiteindelijk alle geautoriseerde combinaties van classificatie-tags per rol. Deze autorisatie ontologie ontwikkelen is niet altijd eenvoudig, maar het is een horde die iedere organisatie moet nemen, om controle te verkrijgen op data autorisatie.
Naast het Data Lake scenario kan Ontology Driven Authorization ook worden toegepast via een API binnen een service architectuur.
Wegpoetsen
Het is in MarkLogic mogelijk om delen van een document te voorzien van classificatie-tags. Hierdoor kun je er bijvoorbeeld voor zorgen dat een recruiter een compleet CV mag zien, een secretaresse alleen de personaliasectie en een klant het CV juist zonder de personaliasectie. Ook is het mogelijk om woorden en zinnen in een document te maskeren. Zo kun je een document volledig tonen, maar alle telefoonnummers, BSN-nummers, emailadressen en alles wat lijkt op een naam wegpoetsen.
Een standaard feature van MarkLogic is de Security Log. Hierin wordt iedere actie per gebruiker op een document gelogd. Zo is achteraf altijd te bepalen, wie, wanneer, welk document, of deel van een document, heeft geraadpleegd of gewijzigd. Dat maakt het mogelijk om datalekken door een niet goed ontwikkelde autorisatie ontologie te constateren.
Wanneer de inhoud van een document is gewijzigd, wordt het document opnieuw geautoriseerd. Het is namelijk mogelijk dat door het wijzigen van de inhoud van het document, de autorisatie moet worden aangepast. Als de autorisatie ontologie inderdaad wordt gewijzigd, moeten alle documenten opnieuw worden voorzien van de juiste autorisatie.
DIKW en MarkLogic
DIKW is een toonaangevende full-service Intelligence dienstverlener. DIKW is implementatiepartner van MarkLogic.
MarkLogic is een NoSQL softwareproduct dat zich qua functionaliteit kan meten met het complete ecosysteem van alle Hadoop NoSQL producten. Een groot voordeel van MarkLogic is de integratiemogelijkheid van alle features als: zeer ver doorgevoerde autorisatiemogelijkheden, gebruiker monitoring, ACID compliant, Alerting op streaming data, Scale-Out architectuur tot Petabytes aan data en de performance-by-design filosofie. Ook heeft MarkLogic bijvoorbeeld een plug-in op MS SharePoint. Hierdoor is MarkLogic eenvoudig in staat om alle documenten die in SharePoint zijn opgeslagen, te transformeren naar XML, te verrijken met autorisatie ontologieën en te laden in het Data Lake.
Kortom: MarkLogic is uitermate geschikt om Ontology Driven Authorization toe te passen.
Vragen over dit onderwerp? Neem contact op met: michael.doves@dikw.com