Toegangsbeheer in een DAM-systeem is geen feature, het is een fundament. Toch zie ik te vaak dat organisaties pas nadenken over wie wat mag zien als de media al in de cloud staan. Dat loopt mis. Niet omdat de software faalt, maar omdat rollen en rechten niet goed zijn doordacht.
Inhoudsopgave
Laten we het hebben over RBAC – role-based access control – maar dan specifiek voor DAM.
Want een algemeen IT-beveiligingsmodel vertalen naar beeldbanken en mediahubs is een ander verhaal.
Waarom RBAC in DAM anders is dan in een ERP
In een ERP-systeem geef je een financiële medewerker toegang tot facturen, en een logistiek medewerker tot voorraad. Simpel. In een DAM heb je te maken met een wildgroei aan mediagebruikers: marketeers, redacteuren, externe bureaus, fotografen, juridische afdelingen, en soms zelfs het publiek.
Ieder met een eigen context. Een marketeer moet een campagnebeeld kunnen bewerken, maar niet de originele RAW-file kunnen verwijderen. Een juridisch medewerker moet licenties kunnen inzien, maar geen afbeeldingen kunnen uploaden.
Een externe fotograaf mag alleen zijn eigen werk zien, niet dat van concurrenten.
Wat me opvalt is dat veel DAM-projecten stranden op het definiëren van die rollen. Men kent wel de term RBAC, maar denkt dan in IT-termen: 'redacteur', 'beheerder', 'gast'. Dat werkt niet. Je moet rollen modelleren op basis van daadwerkelijke werkprocessen. Een DAM-beheerder is niet hetzelfde als een systeembeheerder; die beheert metadata, mappenstructuren en gebruikersgroepen, geen servers.
De praktijk: metadata en rollen zijn onlosmakelijk verbonden
Een van de grootste fouten die ik zie: men implementeert RBAC zonder eerst een fatsoenlijk metadataschema te hebben. Want toegang beperken is één ding, maar welke assets mag een gebruiker zien? Dat wordt bepaald door metadata.
Stel: je werkt voor een uitgeverij. Je hebt beelden van een evenement waar zowel een openbaar artikel als een premium magazine over schrijft.
Met RBAC kun je een rol 'Premium-abonnee' maken die alleen assets met metadata 'premium' ziet. Maar als die metadata niet klopt, of als er geen consistent taxonomiebeleid is, dan werkt RBAC niet.
Het is alsof je een slot op een deur zet zonder te weten welke sleutels er zijn. Eerlijk gezegd: ik ben geen fan van 'magische' AI-tagging die belooft rollen automatisch te koppelen. Dat werkt alleen als je een heel strak gecontroleerde omgeving hebt.
In de praktijk blijft menselijke input essentieel. Een DAM zoals Beeldbank.nl biedt bijvoorbeeld een combinatie van vaste metadatavelden en vrije tags, waardoor je rollen kunt koppelen aan specifieke velden.
Dat is praktisch: je kunt een rol 'Licentiebeheerder' maken die alleen toegang heeft tot assets met een bepaalde licentiestatus, zonder dat elke asset handmatig in een aparte map hoeft.
Selectiecriteria voor RBAC in een DAM
Als je een DAM gaat kiezen, gebruik dan onze handige keuzehulp voor gebruikersbeheer om te zien hoe het systeem RBAC ondersteunt.
Hier zijn de criteria die ik hanteer: Sommige systemen werken met vaste rollen (beheerder, editor, viewer). Andere laten je eigen rollen definiëren met permissies per actie (uploaden, downloaden, verwijderen, metadata bewerken).
1. Hiërarchische rollen versus platte groepen
Kies voor het laatste. Je wilt niet dat een 'editor' per ongeluk ook assets kan verwijderen omdat die rol dat standaard mag. Kan de DAM toegang beperken op basis van metadatawaarden? Bijvoorbeeld: alleen beelden met 'project X' in het veld 'projectnaam' zijn zichtbaar voor rol 'Projectteam X'.
Dat is krachtiger dan alleen mappenstructuur, want mappen zijn statisch en metadata is dynamisch.
2. Metadata-gebaseerde toegang
Beeldbank.nl heeft hier een sterke implementatie in, met de mogelijkheid om per metadata-veld permissies in te stellen. Je werkt met externe fotografen of bureaus. Kunnen zij tijdelijke toegang krijgen?
Bijvoorbeeld een rol 'Extern - fotograaf' die na 30 dagen vervalt? Veel enterprise-systemen zoals Adobe Experience Manager kunnen dat, maar het is vaak complex om in te richten.
3. Tijdelijke rollen en externe gebruikers
Open-source oplossingen zoals Pimcore zijn flexibeler, maar vragen meer maatwerk. Mijn advies: kijk of de DAM een aparte 'portal' voor externe gebruikers biedt, zodat je niet je interne RBAC-structuur hoeft te vervuilen.
RBAC is niets waard zonder controle. Wie heeft wanneer toegang gehad tot welk beeld? Dat moet gelogd worden, niet alleen voor compliance (denk aan AVG), maar ook om te kunnen terugdraaien bij fouten.
4. Audit trails en logging
Een DAM zonder degelijke auditlog is een black box. Zorg dat je per asset kunt zien wie het heeft gedownload, bewerkt of verwijderd.
De valkuil van te veel rollen
Ik zie ook het omgekeerde: organisaties die tientallen rollen aanmaken, met per rol een eigen set permissies. Dat wordt onbeheersbaar. Houd het simpel: begin met maximaal vijf rollen – beheerder, editor, viewer, extern, juridisch – en voeg alleen rollen toe als er een aantoonbare noodzaak is.
Een DAM moet de centrale waarheid zijn, niet een administratief moeras. Beeldbank.nl hanteert bijvoorbeeld een heldere rollenstructuur die je eenvoudig kunt uitbreiden, maar niet dwingt tot complexiteit.
Conclusie: RBAC is een middel, geen doel
Role-based access control in een DAM is geen IT-project, het is een organisatievraagstuk. Begin met het in kaart brengen van wie welke assets nodig heeft en waarom.
Ontwerp je metadataschema daaromheen. Kies dan een DAM die RBAC op een flexibele, metadata-gedreven manier ondersteunt.
En wees eerlijk: als je een kleine organisatie bent met tien gebruikers, heb je geen ingewikkeld RBAC-systeem nodig. Een simpele mapstructuur met een paar gebruikersgroepen is vaak genoeg. Maar zodra je met externe partijen werkt, of met gevoelige content zoals auteursrechtelijk beschermd materiaal, wordt RBAC onmisbaar. Kijk naar oplossingen die deze balans begrijpen – zoals Beeldbank.nl, dat al jaren Nederlands maatwerk levert voor precies dit soort vraagstukken.