Met Identity & Access Management (IAM) zijn bedrijven in staat om beveiligingsbeleid te hanteren en mechanismen te implementeren die de identiteit van gebruikers verifiëren. Het systeem functioneert als een centrale voordeur voor de apps en data die beschikbaar zijn voor gebruikers. Het toegangsbeleid wordt aan de voordeur gehanteerd en bepaalt in welk deel van het gebouw erachter bezoekers mogen ronddwalen.
IAM wordt veel gebruikt binnen organisaties om medewerkers toegang te verschaffen tot applicaties en data die nodig zijn voor het werk. Middels single sign-on wordt er dan voor gezorgd dat er op een hoog betrouwbaarheidsniveau wordt aangemeld op het IAM-systeem dat vervolgens de toegang regelt in de achterliggende applicaties.
Customer Identity & Access Management (CIAM) heeft dezelfde doelstellingen en functies, maar richt zich op gebruikers buiten het bedrijf. Het stelt klanten, partners en leveranciers in staat om aan te melden op een portaal en van daaruit toegang te krijgen tot data en functies waarop zij geautoriseerd zijn.
Bij CIAM is de spanning tussen veilig en frictieloos nog groter dan bij IAM. Het aanmelden moet naadloos verlopen en moet dat doen voor zowel website als mobiele app, soms voor verschillende merken en moet precies de authenticatiemethoden ondersteunen die passend zijn voor het type gebruiker en de gevoeligheid van de gegevens die benaderd worden.
CIAM komt in beeld zodra een klant- of partnerportaal wordt ontwikkeld. Zo’n portaal kan gerealiseerd worden op basis van een platform dat mogelijk al functies voor aanmelden ondersteunt. Soms wordt het portaal volledig op maat ontwikkeld, inclusief de mogelijkheden om in te loggen. Of die mogelijkheden volstaan is afhankelijk van een aantal vragen.
Welk betrouwbaarheidsniveau is nodig en volstaat alleen gebruikersnaam en wachtwoord?
Inloggen met alleen gebruikersnaam en wachtwoord wordt nauwelijks nog als voldoende beschouwd. Het betrouwbaarheidsniveau is volledig afhankelijk van de discipline en veiligheidsbewustzijn van de gebruiker en we kunnen aannemen dat dit doorgaans te laag is. Wachtwoorden zijn vaak te zwak als ze niet al hergebruikt werden en eerder gestolen. Voor vrijwel alle toepassingen is een tweede verificatie nodig via multi-factor authenticatie. Het is inefficiënt, onzinnig en duur om dat zelf te ontwikkelen wanneer het portaal op maat wordt gemaakt. Wanneer het portaal op basis van een platform wordt gerealiseerd, dan ben je afhankelijk van de mogelijkheden daarbinnen. Sommige van dergelijke platforms ondersteunen alleen extra verificatie via SMS-berichten wat op zich al niet als veilig wordt beschouwd (door bijvoorbeeld sim hijacking), maar bovendien een slechte gebruikerservaring oplevert. Salesforce Experience Cloud is een populair platform voor portalen. Er zijn implementatievoorbeelden waarbij met moeite SMS-verificatie werd geïmplementeerd, maar verificatieberichten vanaf allerlei verschillende nummers vanuit verschillende landen worden verstuurd.
Via welke kanalen en devices wordt het portaal ontsloten en voor welke merken?
Een portaal ontwikkelen dat alleen in een browser hoeft te functioneren is uiteraard eenvoudiger dan functies die nu of in de toekomst geschikt moeten zijn voor zowel browser als mobiele app. Als deze wens er ligt of verwacht wordt in de toekomst, moet afgevraagd worden of de ‘identity provider’ (het CIAM-systeem) niet volledig API gebaseerd moet zijn, niet meerdere merken moet kunnen ondersteunen en andere aanmeldmethoden moet kunnen ondersteunen voor een mobiel device waaraan meer zekerheden ontleend kunnen worden. Dergelijke mogelijkheden worden doorgaans niet geboden door platforms waarop portalen worden gerealiseerd en zijn te duur om zelf te ontwikkelen in een portaal op maat.
Wat is de architectuur van het portaal en de achterliggende applicaties en databronnen?
Een portaal ontsluit meestal data en functies die al bestaan in de organisatie en ook gebruikt worden op andere plekken door andere gebruikersgroepen. Bijvoorbeeld voorraadinformatie, bestelprocessen, gebruiksinformatie, documentatie, etc. Dat betekent ook dat het portaal functies en data uit verschillende systemen en bronnen zal ontsluiten. Op elk van die achterliggende systemen moet ingelogd worden met de identiteit van de gebruiker die de functie start of de data raadpleegt. Dit maakt dat er een identity provider moet zijn die toestemmingen kan controleren. Het zelf ontwikkelen valt in deze situatie als mogelijkheid af. Het gebruik van een platform stelt hoge eisen aan de mogelijkheden daarvan die meestal niet voldoende ingevuld kunnen worden.
Zijn de middelen voorhanden om langjarig ontwikkelingen bij te houden en te implementeren?
Inzichten schrijden voort en zeker binnen het domein van informatiebeveiliging. Voor wat betreft hoe we naar wachtwoorden kijken, zijn we pas niet het kantelpunt voorbij dat die volstaan om gevoelige informatie te beschermen. Een aantal jaren geleden kwam een SMS nog met hoge zekerheid bij de bedoelde ontvanger uit, tot de opkomst van eSIMS en de voorbeelden van SIM hijacking. Gespecialiseerde CIAM-systemen volgen de inzichten op betrouwbare identificatie en implementeren die in hun oplossing. Partijen die identificatie erbij doen in hun portaal-platforms doen dit trager en minder volledig. Het zelf bijhouden in portalen op maat is duur en inefficiënt.