Security

software:

veilig

en

compliant.

Toegangsbeheer met rollen en rechten.

Role-based access control (RBAC) koppelt rechten aan een rol in plaats van aan een persoon. Een nieuwe medewerker krijgt een rol en daarmee in één keer het juiste toegangsniveau. Vertrekt iemand, dan vervalt alles tegelijk. In de praktijk loopt het mis op de uitzonderingen: iemand krijgt tijdelijk extra rechten en houdt die daarna. Een werkende opzet houdt het daarom simpel. Eén rol per gebruiker, een rechtenmatrix die bepaalt wat die rol ziet en mag, en rollen die bij één organisatie horen zodat gegevens niet over die grens heen lekken. Plus een vervalmoment voor tijdelijke rechten en een periodieke controle die iemand ook echt uitvoert. Hoe dat uitpakt zie je in portalen met rollen en rechten.

Single sign-on en multifactor-authenticatie.

Met single sign-on logt een gebruiker één keer in en heeft hij daarna toegang tot alle gekoppelde applicaties, via protocollen als OAuth of SAML. De winst is niet alleen gemak: het aanmaken en intrekken van accounts loopt via één centrale bron, dus een vertrokken medewerker is in één handeling overal weg in plaats van in acht losse applicaties. Wij koppelen aan de provider die je al gebruikt. Microsoft Entra ID draait in productie, net als SAML-koppelingen via eigen Cube-pakketten voor Laravel en SilverStripe, en bij organisaties met AFAS gebruiken we AFAS als identiteitsbron voor portaalgebruikers.

Bij multifactor is de vraag niet óf, maar welke vorm. Een authenticator-app is gratis en werkt altijd, maar niet voor medewerkers die op de werkvloer geen telefoon bij zich hebben. Een hardwaresleutel is phishingbestendig en kost geld per gebruiker. Goedkeuren per e-mail is de zwakste vorm. Een externe identiteitsprovider geeft meer controle en inzicht, tegen maandelijkse kosten. Die afweging maken we per organisatie, niet per standaardadvies.

Audit trails en logging.

Een audit trail legt vast wie wat wanneer heeft gewijzigd, in een vorm die niet achteraf aan te passen is. Dat is iets anders dan logging voor foutopsporing, al worden ze vaak door elkaar gehaald. Technische logs bewaar je meestal kort, bijvoorbeeld dertig dagen. Een audit trail bewaar je zolang je verantwoordingsplicht loopt, en hij moet leesbaar zijn voor iemand zonder technische achtergrond.

Bruikbaar wordt zo'n trail pas als hij ook vastlegt waaróm iets is gewijzigd. In een van de platformen die wij bouwen kan een gebruiker een kritiek veld alleen aanpassen na het ontgrendelen ervan, met een verplichte reden uit een vaste lijst en een onderbouwend document erbij. Dat kost de gebruiker tien seconden en scheelt bij een audit een middag zoekwerk.

Compliance- en auditdashboards.

Een compliancedashboard is het deel van compliance software dat zichtbaar maakt of je aan je eigen beleid voldoet: welke controles lopen, welke zijn achterstallig, welke risico's staan open en wie is eigenaar. De waarde zit in het moment waarop je hem raadpleegt. Zonder dashboard begint een audit met weken verzamelwerk uit losse systemen en spreadsheets. Met dashboard is het een export.

Autorisatie in portalen.

In een portaal waar meerdere organisaties samenkomen is autorisatie de kern van het ontwerp. Een leverancier ziet zijn eigen orders en die van niemand anders. Een dealer ziet zijn eigen marges. Dat lijkt vanzelfsprekend, maar het is de meest voorkomende bron van datalekken in portalen: een gebruiker die via een aangepaste URL of een directe API-aanroep bij data van een andere partij komt. Autorisatie hoort daarom in de back-end te zitten en niet in wat de interface toont.

Dataminimalisatie, encryptie en pseudonimisering.

Data die je niet opslaat kan niet lekken. Dataminimalisatie begint bij de vraag welke velden je proces echt nodig heeft, en dat is een ontwerpbeslissing. Wat je wel opslaat versleutel je onderweg en in rust. Persoonsgegevens die je alleen voor analyse gebruikt pseudonimiseer je, zodat ze niet meer naar een persoon herleidbaar zijn. Voor zorgtoepassingen komt daar het normenkader bij, zie NEN 7510 voor de zorg.

AI-governance en AI-veiligheid.

Zodra een applicatie een large language model of een AI-agent bevat, komen er vragen bij: welke data gaat naar het model, wie mag welke antwoorden zien en hoe leg je vast wat het systeem heeft besloten. De EU AI Act stelt, afhankelijk van de risicocategorie, eisen aan transparantie en menselijk toezicht, en die vertalen zich in concrete functionaliteit: logging van prompts en antwoorden, een duidelijke afbakening van welke data het model mag zien, en een menselijke controlestap bij besluiten met gevolgen. Meer daarover bij AI-veiligheid en governance, en in het blog over AI inzetten zonder de controle over je data te verliezen.