Jan Vlietland van Nederlands Instituut voor de Software Industrie over de drie A’s van applicatiebeveiliging

“Over authenticatie, autorisatie en accountability valt heel veel te vertellen. Maar laten we voor de goede orde beginnen met vast te stellen wat we eigenlijk onder deze drie termen verstaan”, zegt Jan Vlietland van het NISI.

• Authenticatie is het proces van het verifiëren van de identiteit van een gebruiker. Dit kan een persoon zijn, maar natuurlijk ook een – zeg maar – apparaat, een applicatie of een microservice. Dit gebeurt bij voorkeur in realtime.
• Autorisatie is de procedure die wordt gehanteerd om vast te stellen wat een bepaalde geautoriseerde gebruiker mag doen. Zeg maar: welke rechten heeft die gebruiker?
• Accountability geeft aan dat we willen vaststellen wie of wat verantwoordelijk is voor een actie en hoe we deze gebruiker daarvoor aansprakelijk kunnen houden.

Vormen van authenticatie

Er zijn meerdere manieren om het proces van authenticatie te realiseren. De eerste is single factor authentication. Hierbij wordt slechts één factor (zeg maar: hulpmiddel) gebruikt om de identiteit van een gebruiker vast te stellen. Veelal gaat het dan om een wachtwoord. Daarmee is meteen duidelijk dat single factor authentication in feite een zwakke beveiligingsaanpak is. Er zijn tal van methoden om hier omheen te werken. Passwords kunnen geraden worden. Ze kunnen via malware gestolen worden, via social engineering of sniffing afhandig worden gemaakt, noem maar op. “Dan kennen we multi-factor authentication, wat al beduidend veiliger is dan de single-variant”, aldus Vlietland. In dit geval dient de gebruiker zich via twee verschillende hulpmiddelen te identificeren. Denk aan een combinatie van een wachtwoord en een PIN, een smartcard of een token, een vingerafdruk of een irisscan.” Maar het is ook mogelijk om bijvoorbeeld gedragskenmerken toe te passen of locatie-specifieke info. Of denk aan een identificatie via het te gebruiken apparaat of een tijdstip.

Continuous authentication

Een derde vorm is wat we wel noemen: continuous authentication. Hierbij wordt de identiteit van een gebruiker voortdurend vastgesteld. Na een initiële log-in procedure wordt aan de hand van biometrische factoren, contextinformatie of bijvoorbeeld gegevens over het gebruikte apparaat continu gekeken wie de gebruiker is. Denk bij contextuele gegevens bijvoorbeeld aan een locatie (via bijvoorbeeld GPS-data) of een tijdstip. “Bij toepassing van continuous authentication wordt het voor een cybercrimineel veel lastiger om een sessie over te nemen of om met een gestolen apparaat toegang tot een applicatie of tot data te verkrijgen.”

OAuth

Dan kennen wij uiteraard nog open authentication (OAuth). Vlietland: “Dit is een specificatie die het mogelijk maakt om toegang tot resources te verkrijgen zonder dat hierbij het gebruikte wachtwoord of andere vertrouwelijke gegevens bekend worden gemaakt. In plaats daarvan wordt een token gebruikt die alle relevante gegevens bevat.” OAuth is veel makkelijker te implementeren dan Security Assertion Markup Language (SAML), vertelt Vlietland. Het is ook beter geschikt voor de mobiele wereld. Er wordt gewerkt met RESTful API’s. “Daarnaast geldt dat OAuth gebruikt kan worden voor zowel authenticatie als autorisatie.”

Autorisatie

Er bestaan meerdere autorisatiemethoden. Denk onder andere aan:

• Mandatory Access Control of MAC waarbij gewerkt wordt met security labels
• Discretionary Access Control (DAC) waarbij de toegang tot de relevante informatie beheerd wordt door de eigenaar van die info
• Role-based Access Control (RBAC), waarbij de toegang tot informatie geregeld is op basis van de rol die een gebruiker vervult
• Attribute-based Access Control (ABAC), waarbij een attribuut dan bijvoorbeeld een locatie of een tijdstip kan zijn

“Er zijn dus tal van methoden, met ieder hun voor- en nadelen. Belangrijker hier is echter om vast te stellen dat in de praktijk het gebruik van deze access control-methoden nog regelmatig mis gaat.” Bekende problemen zijn het niet goed toepassen van het fenomeen ‘scheiding van taken’ (segregation of duties). Ook gebeurt het regelmatig dat de ‘least privilege’ en ‘need to know’ (zie deel 1 van deze serie) niet goed zijn geïmplementeerd. “Soms zijn de modellen die gebruikt worden voor het definiëren van rollen te complex of worden gast- en test-accounts verkeerd gebruikt. Of wordt onvoldoende aandacht besteed aan de manier waarop ‘events’ behandeld, gelogd en onderzocht worden. En zo zijn er nog meer punten die mis kunnen gaan – een account database die bijvoorbeeld niet up-to-date is.”

RBAC

Laten we nog even nader kijken naar de methode van RBAC ofwel role-based access control. “RBAC vormt in feite een reeks van autorisaties die is gebaseerd op enerzijds de organisatiestructuur van de gebruiker, zijn business processen en een aantal policies en regels. Daarmee heeft deze manier van werken het in zich om het hele proces rond autorisatie transparanter te maken. Dat is dus een belangrijk pluspunt”, meent Vlietland. “Daar staat echter wel tegenover dat het implementeren van RBAC soms erg complex kan zijn en – mede daardoor – relatief veel tijd kost.”

Duidelijke voordelen

Toch zijn de voordelen van role-based autorisaties evident, meent hij. “Met RBAC is het toekennen, veranderen of intrekken van autorisaties veel efficiënter geregeld dan bij andere methoden. Is het eenmaal goed geïmplementeerd, dan zijn de autorisaties veel transparanter. Dat geldt met name voor de functionarissen die deze autorisaties moeten begrijpen: business managers, auditors en eindgebruikers.” Bovendien kunnen de principes die ten grondslag liggen aan een goede autorisatie veel gemakkelijker worden afgedwongen, stelt Vlietland. “Dat zijn dus: need-to-know, least privilege en segregation of duties.”

Deze bijdrage is geschreven door Robbert Hoeffnagel, hoofdredacteur van CloudWorks en Infosecurity Magazine, en verscheen eerder op https://www.infosecuritymagazine.nl/2018/07/06/jan-vlietland-van-nederlands-instituut-voor-de-software-industrie-over-de-drie-as-van-applicatiebeveiliging.