Single sign on kan dé oplossing zijn

Transcriptie

1 Whitepaper Single sign on kan dé oplossing zijn door Martijn Bellaard Martijn Bellaard is lead architect bij TriOpSys en expert op het gebied van security. 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 whitepaper wil ik hierop ingaan.

2 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 hun 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 hebben 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. Het is mogelijk een synchronisatie toe te passen op de gebruikersnamen en/of wachtwoorden met een password synchronisatietool. 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 als Tools4Ever hebben een eigen iam-oplossing. Keuze genoeg, maar al deze producten zijn lastig te implementeren. Pagina 2 van 5

3 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 sso 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. Het verschil tussen sso en e-sso is dat sso verwijst naar een werk infrastructurele oplossing. Pagina 3 van 5

4 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 automatisch 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 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, enz. Deze definities worden vervolgens naar de e-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 Postit -probleem op, maar heeft verder geen kennis van de systemen achter de login. 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. Pagina 4 van 5

5 Conclusie Welke type sso het beste past bij een organisatie is afhankelijk van de ictinfrastructuur. 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. Over TriOpSys TriOpSys is gespecialiseerd in het ontwerpen, bouwen en beheren van mission critical IT-systemen, ofwel bedrijfskritische softwaresystemen die nooit uit mogen vallen. Voorbeelden zijn verkeer- en alarmcentrales (te land, ter zee en in de lucht), berichten- en commandocentrales en meldkamers. Onze diensten beslaan 3 expertises: IT Consultancy, Software Ontwikkeling en Mission Critical Services, binnen 3 domeinen: Verkeersmanagement, Defensie & Ruimtevaart en Openbare Orde & Veiligheid en Beveiliging. Als u wilt dat uw Welke type sso het medewerkers het beste past bij een automatiseringsproject serieus organisatie is afhankelijk van de nemen, moet u ict-infrastructuur. duidelijk maken dat de organisatie dit ook doet. Heeft u vragen naar aanleiding van dit whitepaper? Of zoekt u advies? Neem dan contact op voor een vrijblijvende afspraak Pagina 5 van 5