Regelmatig kom ik bij identity & access management (I&AM) projecten de vanzelfsprekende eis voor het opnemen van een single sign-on voorziening tegen. Vanuit een beveiligingsblik bekeken vind ik single sign-on geen automatisme. Ik kan me bijvoorbeeld niet herinneren dat ik het zelf ooit als maatregel voorgesteld heb vanuit een risicoanalyse.
Single sign-on is natuurlijk een heerlijke beleving voor de gebruiker. 's Morgens een keer inloggen, en dan gelijk overal toegang hebben. Maar is dat dan toegangsbeveiliging? Het vergroot de impact van het risico. Voorvechters vangen dit meteen op door sterke authenticatie te eisen. Terecht, als je dan toch single sign-on wilt, doe het dan goed. Het 'sign-on' gedeelte van de naam gaat inderdaad over beveiliging.
Maar wat dan te doen met het andere deel van de naam? 'Single', de belofte de drempel van authenticatie slechts eenmaal toe te passen… We groeien hier toch naartoe. Vandaag de dag voer je authenticatie uit in de infrastructuur, niet in de applicatie. Een tiental jaren geleden was dat zeker niet zo. Een single sign-on functie die voor de gebruiker transparant aanlogt in oude applicaties houdt in dat de functie het wachtwoord moet kennen. Vanuit een beveiligingsblik bekeken is dit een no-no. Voor aanloggen aan een Windows-domein, nog steeds het netwerkbesturingssysteem in de meeste bedrijven, is ook geen hulp nodig. De enige single sign-on functionaliteit die dan nog enigszins zinvol is is die voor webgebaseerde single sign-on. Echter, vele bedrijven zijn er nog helemaal niet aan toe om deze vorm zinvol te gebruiken.
En dan zien we een nieuwe trend: een gebruiker zich laten authenticeren wanneer een functie waar een hoog misbruikrisico aan kleeft wordt uitgevoerd. Windows noemt dit UAC (user account control). Gebruikers vinden dit lastig, maar het is een zinvol beveiligingsmechanisme. Het is echter het tegenovergestelde van single sign-on.
Vanuit beveiliging zien we veel liever een 'single point of administration'. De grote onderhoudslast en beveiligingsrisico's worden gelopen doordat toegangsadministratie zo verspreid geïmplementeerd moet worden. En dat is nou juist wat een goede I&AM-tool nou wel kan bieden!
Is alles koppelen aan Windows Active Directory geen vorm van SSO dan? Ik log nu één keer in ’s ochtends, en het gros van mijn inloggen wordt geregeld vanuit het AD domein.
Maar in dit artikel wordt helaas slechts gekeken naar symptoombestrijding.
De vraag die men zich eens zou moeten stellen is waarom ik (en met mij vele anderen) zo ongelofelijk veel verschillende userid’s en bijbehorende wachtwoorden (liefst allen met een eigen lifecycle) nodig heb om mijn werk te kunnen doen.
Gevolg: mensen gaan zelf lijstjes bijhouden, die dan in de kast of onder het toestenbord liggen, of ze onthouden alleen hun windowspassword en hebben een lijstje op hun harde schijf staan.
Een SSO-applicatie is een beter alternatief dan zo’n lijstje lijkt me.
Om je een idee te geven: voor mijn dagelijkse werk heb ik zo’n 10 verschillende accounts nodig
En dan zijn er nog twee verschillende werelden, het eigen bedrijf en de klanten. Binnen ons bedrijf is het userid, op enkele uitzonderingen na, altijd gelijk. Maar de password rules willen nog wel eens verschillen. Maar bij de klantomgevingen is het nog veel lastiger omdat elke klant zijn eigen userid regels heeft met evenzoveel varianten op password rules. En oja, die tientallen exotische userid’s en passwords die ik heb mogen natuurlijk nooit ergens genoteerd staan.
Het is zeker de trend dat steeds meer applicaties (via LDAP) geïntegreerd worden met de primaire aanlog service (bijv. Active Directory). Ik kom ook steeds meer organisaties tegen waarbij LDAP integratie een harde eis is voordat een applicatie toegelaten wordt tot het netwerk. Over een aantal jaar zal daarmee SSO gemeengoed gaan worden. Het oplossen van een mogelijk beveiligingissue mbt SSO zal daarmee vroeg-of-laat op de agenda komen van de beveiligingsverantwoordelijken.
Met de huidige SSO-oplossingen is het mogelijk om de eindgebruiker nu al te verlichten van de verschillende usernames/wachtwoorden én om de beveiligingsrisico’s te minimaliseren. Denk bijvoorbeeld aan: integraal toegang ontnemen van een gebruiker tot het applicatielandschap via 1 enkele account disable in de Active Directory, de SSO-applicatie kan om een wachtwoord/PIN-code vragen voordat toegang tot een applicatie wordt verleend (wachtwoord/PIN-code is uniform voor alle applicaties), integraal beeld van aan/aflogacties door een gebruiker, etc.
Eenvoudiger aanloggen op het netwerk is absoluut de trend, al-dan-niet via een 3rd party SSO-oplossing of LDAP/Windows authenticatie. Afhankelijk van de specifieke netwerksituatie zijn er volgens mij een scala van mogelijkheden om hier op een veilige manier mee om te gaan.
PaVaKe: Windows AD is een vorm van SSO, met een single point of administration. Dat deel is dus goed voor elkaar. Alleen bestaat nog steeds de mogelijkheid dat gebruikers risicovol veel rechten tegelijk actief hebben.
Verder ben ik het er mee eens dat aanlogfunctionaliteit buiten de applicatie een goed idee is. Ik richt me ook op ‘symptoombestrijding’, omdat het huidige landschap binnen bedrijven hierom vraagt.
Berry: Ik zou graag zien dat de verschillende werelden in elkaar zouden overvloeien.`
Tjeerd: Ik ben het er mee eens dat huidige SSO-oplossingen de gebruiker verlichten, de vraag is of dat ook veilig is. Zonder single point of administration vind ik van niet.
Lex moet wel goed onderscheid maken tussen Identity Management en Access Management. Voor Identity Management zou het inderdaad prima zijn, zelf security technisch goed als er één adminsitratie is. Die zorgt ook voor single sign-on. Die zorgt voor de authenticatie.
Maar toegangsadministratie (access) is wel degelijk een verantwoordelijkheid van de eigenaar van een informatiesysteem, applicatie, IV dienst, informatiedomein e.a. objecten. Als je eigenaarschap decentraal implementeerd, is dus ook access management decentraal. Alleen de eigenaar (eventueel gemandateerd) kan bepalen wie (al geauthenticeerd) onder welke omstandigheden welke toegang krijgt. Ik zie niet wat de toegevoegde waarde is om dat te centraliseren. Wat interessant is, is om, wanneer een medewerker van functie wijzigt of de werkgever verlaat, de rol-medewerker koppeling worden aangepast, zodat de access control niet wijzigt, de single sign-on niet wijzigt en de rollen/regels voor autorisatie niet wijzigt.
Dus single sign-on is wel degelijk een securitymechanisme. Het borgt de kwaliteit van de identiteit.
JR, als je het onderscheid wilt maken, dan is SSO een identity management mechanisme. Het kan zeker toegevoegde waarde hebben, alleen zie ik het niet grote risico’s wegnemen. Een verschil van mening, laten we het daarbij houden.
Of je nu voor access management wel of geen centrale administratie moet willen hebben, hangt er vanaf. We dwalen hier wel van de kern van de stelling af, maar ik reageer wel graag op het punt dat je maakt.
Bij bedrijven die meer dan zo’n 150 medewerkers hebben kun je er niet van uitgaan dat verantwoordelijke managers alle geautoriseerde gebruikers kennen. Je gaat dan met abstracties werken, een autorisatiemodel. Je hint naar rollen, RBAC (role-based access control) is inderdaad zo’n model.
Als je dan gaat kijken naar de verschillende belangen die daarbij spelen, dan zijn dat er veel meer dan die van de “eigenaar”. Denk aan de lijnmanager die moet zorgen dat zijn team de juiste autorisaties heeft om het werk te doen, securitymensen die het autorisatiemodel beheren, de CIO of risk manager die de invulling van het model moeten toetsen en de IAD, externe auditor, toezichthouder die het geheel willen beoordelen.
Bij een klein bedrijf zonder toezichthouders vind je de decentrale autorisatieadministraties wel. Bij grotere bedrijven is dat anders: Als je al die belangenhebbenden confronteert met een decentraal versnipperde autorisatieadministratie kom je er al snel achter dat het matig bruikbaar is, en niet beheersbaar noch controleerbaar. Met als resultaat een ontevreden auditor en toezichthouder. En daar wil uiteindelijk geen manager binnen het bedrijf mee te maken hebben.