Single Sign On ofwel SSO: het ultieme streven in beveiligingsland. Een enkelvoudige login maakt toegang simpeler, vermindert het aantal wachtwoorden en maakt het mogelijk om sterkere wachtwoord policies in te voeren. Met een enkelvoudig account zijn audits bovendien eenvoudiger uit te voeren en is provisioning en deprovisioning van autorisaties beter te regelen.

De boel wordt veiliger omdat je één wachtwoord gemakkelijker kunt onthouden dan 25. Hierdoor kun je ook sterkere wachtwoorden invoeren. Immers, 25 moeilijke wachtwoorden onthouden, die je eigenlijk ook nog elke maand moet veranderen, dat gaat gewoon niet. Eentje lukt nog wel. Heb je niet eens een Post It op je beeldscherm voor nodig.

Ideaal dus, dat SSO. Maar het is een gepasseerd station. Om verschillende redenen, waarvan de bekendste is: als een user account wordt gekaapt, en dat account geeft toegang tot een stuk of vijftien systemen, dan zijn ze alle vijftien gecompromitteerd. De oplossing die daarvoor aangereikt wordt is sterke authenticatie. Dat heeft slechts een heel enkele organisatie daadwerkelijk ingevoerd, dus met SSO is de veiligheid verminderd.

Maar goed, dit is nog te overzien. Een wezenlijker zwakte ligt besloten in het verschijnsel toegangsbeheer in het algemeen. Toegangsbeveiliging bestaat uit twee afzonderlijke vraagstukken. De eerste is toegang tot informatie gebonden aan een systeem, applicatietoegang dus. De tweede is toegang tot informatie die onafhankelijk is van het systeem: in een bestand, zoals een Excelsheet. Deze twee manieren van toegang vragen ieder een eigen aanpak en een eigen beveiligingstechnologie. Het overgrote deel van de toegangsbeveiligingsmiddelen gaat over applicatietoegang en beschouwt een fileshare ook als een applicatie.

Gegeven dat een Excelsheet op iedere andere willekeurige machine geopend kan worden, is dat een zeer merkwaardige denkfout. En daarmee ook een probleem. Dat al behoorlijk dringend werd met de opkomst van de laptop, maar dat nu, sinds de smartphone, de tablet en de cloud een levensgroot probleem is.

Nu kun je een dergelijke fout pas oplossen als je de oorzaak onderkent – er is geen simpele oplossing want dan zouden we het probleem helemaal niet hebben.

SSO komt voort uit het traditionele gesloten netwerk, waarbij de bakstenen de belangrijkste laag vormen in de informatiebeveiliging. Toegang is in die werkelijkheid een probleem van het netwerk en van de firewall. In dit Old School denken is de eigen omgeving een gesloten geheel, met een harde buitenkant. De beveiliging is dan ook geconcentreerd op die buitenkant. Toegangsbeveiliging is de beveiliging van de poort. De beveiliging van de binnenkant is in deze opzet veel minder belangrijk, want daar kunnen alleen medewerkers bij en die zijn technisch niet zo slim als de hackers buiten. Dit gedachtegoed wordt wel het kokosnootmodel genoemd (hard van buiten, zacht van binnen), of, meer theoretisch, System High Mode (http://en.wikipedia.org/wiki/System_high_mode).

Nu het gesloten netwerk iets van het verleden is, is het kokosnootmodel dat ook. Met het verdwijnen van de buitenmuren is toegangsbeveiliging niet zo simpel meer. De impact van Jericho is echter bij de meeste mensen nog steeds niet doorgedrongen. Zij zien het grootste gevaar nog altijd in de Post It met het wachtwoord op het beeldscherm. Dat is achterhaald: er zijn veel minder aanvallers die fysiek toegang hebben tot je werkplek om de Post It op het beeldscherm te kunnen lezen, dan er mogelijke aanvallers via het internet zijn.

Dus: liever een heel sterk wachtwoord op een papiertje dan een wat zwakker wachtwoord dat gebruteforced kan worden. Wat de meeste mensen zich niet realiseren is dat het Brute Forcen van een wachtwoord op internet veel beter uitvoerbaar is dan op een LAN en de oplossing van het LAN op het internet niet werkt. Op het internet hebben miljarden mensen toegang tot het loginscherm, en is het hoogst ongebruikelijk een lock-out policy te hebben dat een account afsluit na drie verkeerde wachtwoorden achter elkaar. Dat is immers een instant Denial of Service aanval. Facebook, LinkedIn en Salesforce hebben daarom ook geen lock-out policy. Dus als een organisatie Single Sign On ‘doet’ met een cloudapplicatie, betekent dit effectief het einde van de lock-out policy, ook voor het interne netwerk.

Natuurlijk zouden we helemaal zonder wachtwoorden moeten werken. Want ook na twintig jaar gebruikersopvoeding staan 123456 en password nog bovenaan de keuzelijst (http://nakedsecurity.sophos.com/2012/07/13/yahoo-voices-poor-passwords/). **

Strikt genomen hoort SSO niet onlosmakelijk bij wachtwoordauthenticatie. Maar in de praktijk werkt het wel zo. Een organisatie zou er immers voor kunnen kiezen iedere gebruiker een hardware token te geven. Dat kan, maar als behalve medewerkers ook klanten toegang hebben, wordt het opeens een heel ander verhaal; een kostbaar verhaal vooral. En, nog veel belangrijker: hoe koppel je Dropbox of LinkedIn aan die corporate strong authentication? Bovendien moet dat dan met een technologie die het doet op een iPhone of op die kekke Android tablet. Dream on.

Dat SSO over wachtwoorden gaat en niet voor andere authenticatietypes werkt wordt nog duidelijker als we het PAM (privileged account management) dossier erbij betrekken: vanuit beveiligingsoptiek is het eigenlijk wenselijk dat toegang tot beheerdersaccounts (die zo ongeveer alles mogen) extra beveiligd wordt – dus zeker met sterke authenticatie. We willen ook dat beheerders aparte accounts hebben, omdat ze anders de hele tijd alle rechten hebben en dat vergroot de risico’s.

Wat we zien is iets heel anders: in plaats van een smartcard voor de beheerder hebben we een procedure met een envelop.Want die beheerders moeten op al die dozen aanloggen met lokale accounts. Als we de toegang voor beheerders erbij betrekken dan is de Sign On nooit Single geweest.

In de post-jericho-tijd is dit de realiteit: als organisatie kun je niet de enkelvoudige sterke authenticatie afdwingen op de eigen tablet waarmee de klant toegang zoekt, de medewerker thuiswerkt of op de cloudapplicatie die de gekozen technologie niet ondersteunt. Wil je de toegang gecentraliseerd beheersen (en beheren), zullen hiervoor een andere manier moeten bedenken. En dat kan. Sommige organisaties zijn hier al mee bezig. Hoe ziet zoiets er dan uit?

Je moet het kind natuurlijk niet met het badwater weggooien. Je wilt wel dat gebruikersaccounts zo gecentraliseerd mogelijk zijn, voor auditing en provisioning. Het wordt dus wel een geünificeerde login. Laten we het de Unified Sign On noemen, de USO. Zo’n omgeving zal gebruik maken van directories (je zult de users toch ergens moeten opslaan) en het daarbij gebruikelijke LDAP. Omdat niet alleen medewerkers toegang moeten hebben, maar ook mensen van buiten, zul je verschillende directories inzetten.

De interne directory geeft ook LAN toegang, alle andere gebruikers doe je op een extern gerichte directory die geen Kerberos doet. Beide logins koppel je aan een federatieve login, waarbij je met een trucje die Where Are You From (http://saml.xml.org/blog/saml-20-usability) wegmoffelt. Klein beetje extra werk, een stuk minder sores.

Op de netwerk-laag zal de USO een Multi-protocol voorziening zijn. Dat Multi-protocol komt zo: het klassieke SSO project bevatte onlosmakelijk de term kerberisatie: de aanpak om alle logins koppelen aan de login van AD. Dat is een prima aanpak: Kerberos is een mooi protocol en cryptografisch sterk. Maar het heeft een vervelende beperking; het werkt niet op het internet. Op internet gebruiken we SSL of niets. Nu kunnen we in het netwerk wel SSL gebruiken, maar SSL is zwakker dan Kerberos, met name vanwege de offline rootCA en omdat we het altijd single side gebruiken. Voor dual side moet je continu die certificaten verversen op al die PC’s en zeg nou zelf, daar hebben we toch geen tijd voor?

Internet SSL is bovendien gebonden aan de Internet namespace (de common name in het certificaat bevat de hostname) en dat werkt weer niet binnen een afgesloten namespace. Dus een Unified Sign On die systemen binnen en buiten bestrijkt zal geen technische eenheid zijn; het zal een samengesteld systeem worden dat op de grens tussen binnen en buiten Kerberos tickets omzet in SSL tokens en vice versa.

Bovenstaande Unified Sign On wordt in de praktijk vormgegeven met SAML en WS-FED standaarden, met uitlopers naar specifieke technologieën met andere protocollen. Daar horen producten bij als OpenAM en ADFS. Dergelijke Federatieve producten worden intussen meer en meer uitgebreid met ondersteuning voor sterke authenticatie, zodat de centrale login voorzien kan worden van extra beveiliging. Als deze centrale login alleen voor medewerkers is, dan is het mogelijk hiervoor te kiezen en iedere medewerker een hardware token te geven.

Het is echter opeens veel lastiger als klanten en medewerkers van zakenpartners ook toegang moeten krijgen, of van die lastige mensen met die eigen apparaten. Nu is het mogelijk een tweede centrale login op te stellen die een zwakkere login toestaat, maar dat is dan weer hoogst onlogisch; waarom moeten vertrouwde medewerkers méér moeite doen om ergens bij te komen? Bovendien is een centrale login niet meer centraal als er twee zijn. Waarschijnlijk zal de integratie met wat erachter zit ook losser worden, wat het geheel onveiliger maakt.

De oplossing is differentiatie: verschillende gebruikersgroepen via dezelfde login /andere authenticatiemethodes/ bieden. De logische volgende stap is deze differentiatie ook te gebruiken voor de verschillende device typen. Dit mondt dan uit in een step up systeem waarbij de gekozen applicatie een vereist authenticatiemiddel krijgt, en dat op basis van een aantal variabelen. Zo zal een eigen medewerker die met een beheerd werkstation vanuit het eigen LAN aanlogt met een zwakker authenticatiemiddel toe kunnen dan dezelfde medewerker vanaf een privé tablet thuis. Hiermee komt de identiteit en de locatie van de device in de beveiligingsafweging bovendrijven, als extra variabelen in een Risk Based Access control.

Het plaatje wordt echt mooi als ook binnen een applicatie gedifferentieerd kan worden. Zo zal deze medewerker aanvullend moeten authenticeren als hij een gevoelige transactie wil uitvoeren: als je honderdduizend euro wilt overmaken vanaf je thuis PC, moet je het One Time Password invullen dat op je hardware token verschijnt. Heb je dat al gedaan in een sessie, dan hoeft dat niet nog een keer.

De eerste applicatieservers die dergelijke differentiatie ondersteunen zijn inmiddels beschikbaar, en step up is de ontbrekende schakel in toekomstige toegangsoplossingen. Het wordt dus tijd om de traditionele RBAC matrices uit te breiden met devices en locaties, want de rol van een persoon is al lang niet meer het enig relevante gebruikersattribuut in een toegangssysteem.

Dat probleem van die bestanden – ja dat heb ik dan dus nog steeds niet opgelost. Goed punt.

Door Peter Rietveld, Senior Security consultant bij Traxion - The Identity Management Specialists -

Laatste 10 columns