De doorsnee ict-omgeving is langzaam gegroeid naar een omgeving met meerdere applicaties. Security is daarnaast belangrijker geworden, dus steeds meer applicaties vragen om een gebruikersnaam en wachtwoord. Hierdoor wordt een doorsnee gebruiker geconfronteerd met meerdere gebruikersnamen en wachtwoorden en elk systeem heeft zo zijn eigen gebruikersnaam- en wachtwoordbeleid. Een gebruiker moet deze dus allemaal onthouden, wat lastig is.
We zien dan ook dat gebruikersnamen en wachtwoorden worden opgeschreven op een post-it. Dit ‘systeem’ doet de beveiliging teniet, aangezien alle informatie nu door iedereen eenvoudig gelezen kan worden. Het ‘post-it’-probleem is niet nieuw. Met een single sign on is dit op te lossen, maar er is wel het één en ander veranderd op het sso-speelveld. In dit artikel wil ik hierop ingaan.
De ideale oplossing
De ideale oplossing bestaat uit één centrale authenticatiebron. Elke applicatie en systeem maken gebruik van deze centrale authenticatiebron. Een gebruiker logt aan op zijn werkplek en op basis van deze credentials krijgt hij toegang tot de overige systemen.
Binnen een Microsoft only-omgeving zie je dit al terug. Als centrale authenticatiebron wordt gebruik gemaakt van Active Directory. Systemen als Windows File Server, Exchange en/of Sharepoint kunnen je vervolgens ‘automatisch’ laten aanloggen op basis van het Active Directory account.
Deze ondersteuning kan worden uitgebreid naar systemen die de technieken ondersteunen om gekoppeld te worden aan Active Directory. Hierbij wordt gebruik gemaakt van Kerberos , LDAP, ADFS of SAML. Voor systemen die dit niet ondersteunen, zou een add-on, zoals Quest Authentication Services, een goede keuze kunnen zijn.
One user, one password
Niet elk systeem maakt gebruik van deze principes, dus zijn er nog een heleboel applicaties waarbij de gebruiker een andere gebruikersnaam en wachtwoord moet gebruiken. In dat geval is het mogelijk een synchronisatie toe te passen op de gebruikersnamen en/of wachtwoorden. De gebruiker heeft dan dezelfde gebruikersnaam en wachtwoord voor elk systeem en hoeft geen verschillende meer te onthouden.
Dit is eenvoudig te regelen met een password synchronisatietool. Hierbij wordt het wachtwoord tussen de verschillende systemen gelijk getrokken. Tools4Ever heeft een dergelijke oplossing, maar het is een relatief eenvoudige. Het wordt complexer als je gaat werken met een identity manager. In dat geval wordt niet alleen het wachtwoord gelijk getrokken, maar ook de gebruikersnaam.
Er zijn meerdere spelers op de markt die een idm (identity management) of iam (identity access management) oplossing brengen. Grote spelers als Microsoft, Oracle en IBM hebben een iam-oplossing. Maar ook kleinere spelers hebben zijn eigen iam-oplossing. Keuze genoeg, maar al deze producten zijn lastig te implementeren.
Elke applicatie heeft zijn eigen regels als het gaat over gebruikersnaam en wachtwoord, die moeten eerst gelijk getrokken worden, voordat je kunt beginnen met een iam. Daarnaast moet bekeken worden of de iam gekoppeld kan worden aan de verschillende systemen. Welke drivers moeten ontwikkeld worden om binnen een systeem een gebruikersnaam en wachtwoord op te voeren? Ook wachtwoordveranderingen of andere aanpassingen moeten in alle systemen verwerkt worden. De iam moet per actie, per applicatie geprogrammeerd worden, bijvoorbeeld de producers voor in-dienst, uit-dienst en functieaanpassing.
Een iam neemt niet weg dat een gebruiker opnieuw moet inloggen op elke applicatie, maar zorgt er wel voor dat de gegevens overal gelijk zijn. Een gebruiker hoeft nu minder te onthouden en zal dus minder snel zijn gegevens ergens opschrijven.
E-sso
Bij iam/idm geldt dat je binnen elk systeem het recht moet hebben om te lezen en te schrijven. Nu is dit niet per definitie mogelijk. Het kan technisch niet mogelijk zijn, maar vaker is het een rechten kwestie. Als je gebruik maakt van een authenticatiesysteem dat door een andere organisatie beheerd wordt, heb je niet per definitie schrijfrecht in dat systeem. In dat geval werkt een iam dus niet.
Hiervoor kun je gebruik maken van een enterprise single sign on-oplossing (e-sso). Het verschil tussen sso en e-sso is dat eerstgenoemde verwijst naar een werk infrastructurele oplossing. Sso gaat over het gebruiken van één gebruikersnaam en wachtwoord om tot alle informatiebronnen toegang te hebben. Sso zegt niet direct wat over de techniek die gebruikt wordt. Bij een e-sso draait er op de werkplek van de gebruiker een client die ingrijpt als er een verzoek komt om een gebruikersnaam en wachtwoord. De e-sso client vult dan de gevraagde informatie in. E-sso is dus een speciale techniek om sso te bereiken. In de praktijk worden deze twee afkortingen door elkaar gebruikt, het is dus zaak altijd goed te kijken wat iemand bedoeld als het over sso gaat.
E-sso draait dus als een client-software bij de gebruiker op de desktop. Hierbij is er geen verschil tussen een fat client, Citrix server of vdi. De eerste keer dat een applicatie opstart zal de e-sso-client de gebruikersnaam en wachtwoord monitoren en opslaan. Elke keer dat de applicatie daarna opstart zal de e-sso-client de gebruikersnaam en wachtwoord automatische invullen en op enter drukken. Op het moment dat er een aanpassing op een wachtwoord gedaan moet worden kan de e-sso dit doen. Het nadeel hiervan is dat de gebruiker niet langer zijn wachtwoord weet. Het voordeel is dat er nu gewerkt kan worden met complexere wachtwoorden. De e-sso zal een random wachtwoord aanmaken. Als beheerder kun je dan de regels voor het aanmaken van het wachtwoord bepalen.
Bekende e-sso-oplossingen zijn Securelogin van NetIQ, sso van Imprivata, e-ssom van Tools4Ever, sso van Citrix en e-sso van Quest. Al deze tools werken in de basis hetzelfde. Op een centrale console definieert de beheerder de verschillende applicaties. Hierbij geeft hij aan wat de aanlog velden zijn, de velden voor het aanpassen van een wachtwoord, et cetera. Deze definities worden vervolgens naar de Ee-sso-client gedistribueerd. Elke oplossing heeft zo zijn eigen extra functionaliteiten die aanvullend zijn op deze oplossingen.
Sso is veilig!?
Sso verhoogt de beveiliging, omdat gebruikers niet langer geconfronteerd worden met een heleboel wachtwoorden. Een gebruiker hoeft nu nog maar één wachtwoord te onthouden, dat van zijn primaire login account. Hierin zit dan ook gelijk de zwakte van sso. Als ik de informatie weet van zijn primaire login, kan ik inloggen op alle systemen waartoe hij recht heeft. Het is dan ook verstandig om bij sso gebruik te gaan maken van two factor authentication.
Sso lost het ‘post-it’-probleem op, maar heeft verder geen kennis van de systemen achter de login. Op het moment dat de gebruiker voorbij de login is, zal de sso verder niets meer doen. Een gebruiker kan nog steeds informatie in het systeem kopiëren en verspreiden. Sso is een onderdeel van het informatie security beleid en kan de beveiliging verhogen, mits het juist wordt ingezet.
Conclusie
Welke type sso het beste past bij een organisatie is afhankelijk van de ict-infrastructuur. Zijn alle applicaties van één leverancier, dan is het mogelijk om met één centrale authenticatiebron te gaan werken. Dit verhaal zal voor de meeste organisaties niet opgaan en moet er dus worden gekeken of de verschillende bronnen aan elkaar gekoppeld kunnen worden. Hierbij is het dus vooral belangrijk om te kijken welke toegangsmethodieken er zijn tot de verschillende bronnen. Is het mogelijk om gebruikersnamen en wachtwoorden overal gelijk te trekken door het inzetten van een iam? Een iam zorgt ervoor dat alle gebruikersnamen en wachtwoorden overal gelijk zijn en dat aanpassingen op een gebruikersaccount overal wordt aangepast. De implementatie van een iam kan echter complex en duur zijn en is niet snel gedaan. Een e-sso-oplossing is vooral een mooie oplossing in omgevingen, waarbij de verschillende authenticatiebronnen niet gekoppeld kunnen worden.
Single Sign On OK?
Hm, en hoe zit dat dan met Single Sign Off?
Daar hoor ik de security experts nu nooit over.
Is dat wel meegenomen in het ontwerp?
In deze context gaan de verhalen enkel over MicroSoft omgevingen.
Laat ik daar nou net wel heel weinig van tegen komen.
Juist bij wisselende infra en platformen is authentificatie een uitdaging.
Niet dat ik er een issue mee heb hoor.
KeePass is ook een oplossing.
Beste Cordny
Je heb 100% gelijk en sommige oplossing doen dat ook, zoals Imprivata. Als je gebruik maakt van hun pas systeem wordt een gebruiker uitgelogd als hij wegloopt van zijn werkplek.
Beste Pascal
Een ESSO maakt gebruik van een client applicatie, deze draaien meestal op een Microsoft platform. Maar dat is niet per definitie noodzakelijk (http://www.centos.org/docs/5/html/Deployment_Guide-en-US/sso-ov.html). In mijn artikel praat ik over technieken die je kunt gebruiken om SSO te implementeren.
Waarom SSO?
Als het enkel en alleen is omdat gebruikers geen wachtwoorden kunnen onthouden dan lijkt het me meer symptoom bestrijding dan een oplossing. Het idee dat SSO veilig is lijkt me dan een nogal domzinnig argument, het is al gauw de meest onveilige oplossing omdat bewustzijn over de noodzaak voor beveiling afneemt en toevoegen van 2FA vergroot dit nog eens. Probleem bij veel IAM oplossingen is dan ook dat het maar het topje van de ijsberg is, net zoals DigiNotar zijn het vooral service providers die maar een stukje techniek invullen en daardoor dus gaten laten vallen.
De vraag moet dan ook niet zijn welke SSO het beste past bij de infrastructuur maar bij de gebruikers, het technische deel is tenslotte altijd wel in te vullen. Desnoods met wachtwoorden van 24 karakters die om de maand gewijzigd moeten worden, gebruikers een ezelsbruggetje leren om deze te onthouden is namelijk al een goede stap in de richting van wat bewustzijn voor beveiliging.
Beste Marijn,
Leuk artikel heb je geschreven. En eveneens leuk dat je ons, Tools4ever, daarin noemt met PSM (http://www.tools4ever.nl/software/password-synchronization-manager/). Het synchroniseren van wachtwoorden is overigens technisch complex, maar qua functionaliteit inderdaad eenvoudig. De volgende stap die je noemt, IAM, bieden wij ook. Om zo’n project behapbaar te houde, bouwen wij dit gefaseerd op.
Tools4ever biedt het hele spectrum, van eenvoudig (wachtwoord sync bij gelijke inlognaam) naar complexer (IAM waarbij we de lifecycle van users in systemen beheren) en uiteraard op E-SSO.
Martijn,
IAM bevat nog meer onderwerpen en aspecten waar je goed over moet nadenken voordat je eraan begint. SSO of e-SSO zijn onderwerpen die pas later in dat kader besproken kunnen worden. Cloud, als een aspect van IAM heb ik twee weken geleden in dit artikel besproken:
https://www.computable.nl/artikel/opinie/infrastructuur/5029849/2379248/i-am-in-de-cloud.html
De inrichting van je identity store en de flexibiliteit en mogelijkheden die dit aan je services biedt zullen de komende jaren zeer belangrijk worden voor je ict-landschap. In dit kader kun je denken aan informatie uitwisseling en samenwerking tussen verschillende partners in de keten die d.m.v. federatie mogelijk worden gemaakt. Federatie in de zorgketen (huisartsen-ziekenhuizen-zorgverleners-verzekeraars etc) of samenwerking tussen verschillende overheidsorganen zijn voorbeelden van dit onderwerp.
Daarom raad ik onze klanten aan om hun identity store eerst op een holistische wijze te bekijken.
Later als je dit in een FO inzichtelijk hebt gemaakt kun je naar de producten en de mogelijkheden kijken. Gebruik voor je IAM zaken een degelijk product en niet een mooie box met veel scriptjes erin!
Volgende week kom ik met een artikel over de belang van federatie voor je ict in de toekomst.
Beste Martijn,
Mooi artikel, maar er zijn wat punten waar ik het niet helemaal mee eens ben. Als je je Active Directory gebruikt als centrale authenticatiebron (als verzamelplaats voor al je identiteiten) loop je op een gegeven moment vast. Veel beter is om een onafhankelijk Centraal Identiteiten register (CIR) te gebruiken. Dit maakt je minder afhankelijk van één leverancier en het biedt mogelijkheden voor het bouwen van een modulair systeem. En ja, je Active Directory is hiermee uiteraard ook gekoppeld, dus alle bestaande koppelingen blijven onveranderd. Met deze opzet ben je klaar voor groei en uitbouwen in de toekomst.
Verder geef je al aan dat het gebruik van SSO ook een groot nadeel heeft: als je de primaire login kent, kan je vervolgens inloggen op alle systemen waar de gebruiker recht op heeft. Helemaal nu steeds meer werknemers in toenemende mate gebruik maken van (cloud) apps, en het aantal devices waarop alles toegankelijk moet worden groeit, staat de veiligheid enorm onder druk. De risico’s worden steeds groter, kranten staan er vol van… Daarom is naast inzetten van SSO met directe koppelingen tussen AD en alle (cloud) apllicaties een degelijk stuk zgn. Access Management wenselijk. Dit fungeert dan als ‘poortwachter’ voor alle te benaderen applicaties en er is geen directe (login)verbinding met de apps.. Alleen gebruik van SSO ( ook al combineer je het met two factor authentication) is niet de ideale oplossing. Dat wordt het pas wanneer je de gehele identiteiten stroom goed kunt managen, en daarvoor heb je een degelijk -op standaarden gebaseerd- framework nodig waar je bijvoorbeeld ook makkelijk workflows in kunt vastleggen, en naar hartenlust applicaties aan kunt toevoegen! Alle logica zit immers in het Centrale Identiteiten Register (CIR) en de SSO oplossing (en de Access Manager) is daar direct aan gekoppeld. Dit maakt je onafhankelijk en flexibel, en dat is waar je als bedrijf uiteindelijk naar streeft. Plug and play !