Is dat telkens opnieuw inloggen echt wel nodig?

Wikipedia zegt: “authenticatie is het proces waarbij iemand nagaat of een gebruiker, een andere computer of applicatie daadwerkelijk is wie hij beweert te zijn.” Een authenticatievoorbeeld die wij allemaal wel kennen is het inloggen op de website van je bank. Na het intoetsen van je inloggegevens (gebruikersnaam en wachtwoord) ontvang je in de bank-app op je mobiel de vraag om de toegang te bevestigen. Die app heb je eerst geopend met een pincode die (hopelijk) alleen jij weet. Bevestig je de inlog op de website in je app, dan weet de bank dat die inlog daadwerkelijk wordt gedaan door iemand met een mobiele bank-app die je initieel aan je bankaccount hebt gekoppeld. Deze vorm van authenticatie noemen we ‘multi factor authentication’. Je bank doet dit omdat zij het risico groot acht dat een derde jouw inloggegevens weet en omdat zij geen controle heeft over jouw mobiele apparaat. Het is een zgn. ‘unmanaged device’.

In deze blog is de ‘iemand’ in de definitie van Wikipedia de Azure Active Directory (AD) van Microsoft. In die AD kun je op verschillende manieren de authenticatie inregelen voor SaaS applicaties. Maar waarom zou je dat eigenlijk willen?

Zoals dat bankvoorbeeld al min of meer aangeeft bepalen de risico’s welke manier het beste is, ofwel welke authenticatiemanier minimaliseert de risico’s. Een paar voorbeelden:

• Je logt in via een browser op je privélaptop. De Azure Active Directory (AD) kent die laptop niet en heeft ook geen idee of jij dat bent. Als je eenmaal ingelogd bent, heb je toegang tot de bedrijfsdata. Dit lijkt op het bankvoorbeeld en de beste keuze hier is ‘multi factor authentication’ (MFA).
• Je logt in op je e-mail via een browser op een apparaat dat bekend is in de AD en daar wordt beheerd. Dat apparaat is te vertrouwen en het is aannemelijk dat jij de persoon bent die dat apparaat gebruikt, bijvoorbeeld via de laptop van je bedrijf. Je hebt bij het opstarten van het apparaat toegang gekregen door in te loggen. Hier zou verder inloggen op een applicatie achterwege kunnen blijven (‘single sign-on’).
• Nu hetzelfde voorbeeld, maar je zoekt toegang tot een applicatie in een McDonald’s restaurant. Je locatie wijzigt naar ‘onveilig’. Om het risico van malafide toegang verder te verminderen zou je hier gebruikersnaam, wachtwoord en MFA moeten activeren.

In diverse applicaties kun je na het inloggen aangeven dat je ‘ingelogd wil blijven’. Je wordt dan niet elke keer om de inloggegevens gevraagd als je de applicatie opstart. Erg handig, maar dit brengt ook risico’s met zich mee, want wie zegt mij dat jij de persoon bent die een dag later op die privélaptop inlogt. Een inlog vanaf dit ‘unmanaged device’ zou het eerder zetten van ‘ingelogd blijven’ overruled moeten worden. Dit overrulen hoeft niet als het device onder controle van de AD is gebracht, hoewel het best verstandig is om ook dan na een bepaalde periode het opnieuw authentiseren af te dwingen.

In de Active Directory kun je verschillende authenticatiewijzen specificeren en kun je deels zelf bepalen wanneer wel, wanneer niet en binnen welke periode opnieuw moet worden geauthentiseerd. Voor een gegeven situatie moet een optimale mix (scenario) gevonden worden, want als er bijvoorbeeld te veel wordt gevraagd om te authentiseren gaan gebruikers makkelijke wachtwoorden gebruiken omdat ze snel er vanaf willen. En te weinig vragen geeft ook risico’s.

Je moet dus afhankelijk van de analyse van de risico’s het beste scenario vaststellen.

In de blog van Kenneth wordt uitgelegd welke mogelijkheden er zijn, want begrijpen hoe het opnieuw authentiseren binnen een Azure Active Directory-omgeving werkt, is cruciaal als je een solide implementatie wil op basis van de risicoanalyse. Kennis van het gebruik van de Azure AD is nodig bij het lezen van de blog.

Met onze Risk Assessment Informatiebeveiliging ben je zeker van een business-vriendelijke risicoanalyse. Met onze oplossing voor Workplace Security helpen we de juiste keuzes te maken en is de implementatie sluitend.