Het lijkt erop dat 'de cloud' zich steeds verder uitbreidt binnen het bedrijfsleven. Google Apps, Salesforce.com, GoToMeeting, Office 365, itslearning, Afas Online, Raet Online, et cetera worden al veelvuldig ingezet. Het werken met cloud-applicaties heeft consequenties voor user- en toegangsbeheer. Controle hebben over wie toegang heeft tot welke applicaties en data is met de cloud-applicaties complex.
Leveranciers van cloud oplossingen geven weinig prioriteit aan het ontwikkelen van beter beheer van user accounts en toegangsrechten in hun applicaties. Zij zijn logischerwijs volop bezig met het ontwikkelen van nieuwe (business gerichte) functionaliteiten. User- en toegangsbeheer in cloud applicaties brengt daardoor een aantal uitdagingen met zich mee. In dit artikel zet ik een aantal van deze uitdagingen in de schijnwerper.
Enkel authenticatie
De Active Directory vormt de centrale schakel voor de toegang van gebruikers tot applicaties en systemen. De traditionele lan-gebaseerde applicaties hadden vaak al een bepaalde integratie (ldap) met de centrale user account directory (active directory). Werken met cloud applicaties betekent meerdere authenticatiebronnen; een active directory in het eigen bedrijfsnetwerk en één of meerdere authenticatiebronnen (bijvoorbeeld AD, ldap directory of database) in de cloud. Er zijn slechts enkele mogelijkheden om user accounts te synchroniseren tussen beide authenticatiebronnen (federatie), zoals Adfs van Microsoft en de Saml-standaard.
Eindgebruikers kunnen zo transparant inloggen op de cloud applicatie. Echter, federatie is geen vervanging van provisioning en basis user account beheer. Het onderhouden van autorisaties binnen een cloud applicatie en het koppelen van user accounts aan autorisaties blijft een belangrijke taak waarmee toegang tot specifieke data wordt gereguleerd.
Handmatige acties
Leveranciers die federatie niet ondersteunen (bijvoorbeeld leveranciers van elektronische leeromgevingen en hr-systemen) bieden een webbrowser die beheerders kunnen gebruiken om rechtstreeks op de cloud applicatie beheer uit te voeren. Hier is geen sprake van een geautomatiseerde koppeling (auto provisioning) en dit vraagt nog om een aantal handmatige handelingen. Dit is tijdrovend en foutgevoelig. Ook wanneer het mogelijk is om een basis csv-bestand (comma seperated valuec – kommegescheiden) te importeren in de cloud applicatie, vraagt dit nog steeds om een handmatige actie van de beheerder.
Dat kan veel werk opleveren kijkend naar bijvoorbeeld de ontmantelingprocedure van een user account bij uitstroom van een medewerker. Vaak verloopt deze procedure in fases, waarbij eerst de login wordt afgenomen, vervolgens het account wordt verwijderd en tenslotte nog een e-mail notificatie naar de manager wordt gestuurd. Al deze fases vragen om een nieuwe handmatige actie voor user beheer in de cloud applicatie.
Conventies naamgeving en wachtwoorden
Conventies wat betreft naamgevingstandaarden en wachtwoorden zijn vaak niet gelijk tussen het netwerk en de cloud applicaties. In het netwerk kan een user id bijvoorbeeld gebaseerd zijn op de loginnaam en in de cloud applicatie kan dat het e-mailadres zijn. Dat bemoeilijkt het uitwisselen van user account gegevens tussen beide omgevingen. Dit geldt ook voor wachtwoordconventies.
Wanneer in het bedrijfsnetwerk zeer complexe wachtwoorden zijn vereist, kan het zijn dat cloud applicaties niet om kunnen gaan met dit type wachtwoorden. Wellicht hanteert de cloud applicatie wel een andere termijn voor de verlooptijd van wachtwoorden dan gebruikelijk in het bedrijfsnetwerk. Het synchroniseren van wachtwoorden tussen het netwerk en cloud applicaties is dan lastig.
Ontbreken organisatiestructuur
De organisatiestructuur binnen een organisatie wordt steeds vaker gebruikt om autorisaties toe te kunnen kennen aan medewerkers op basis van hun rol of functie (rbac of rolgebaseerd werken). Deze organisatiestructuur is binnen het bedrijfsnetwerk gevat in bijvoorbeeld een hr-systeem. Cloud applicaties kunnen niet overweg met de organisatiestructuur en de webbrowser die zij bieden kan ook niet gemakkelijk met rollen en autorisaties werken. Natuurlijk is het mogelijk om de gehele organisatiestructuur over te zetten naar de cloud applicatie, maar dat levert een grote hoeveelheid beheerwerkzaamheden op in de cloud applicatie wanneer er iets wijzigt in de hiërarchie.
Wat als connectie wegvalt?
Leveranciers die koppelingen bieden tussen het netwerk en cloud applicaties hanteren vaak event based synchronisatie tussen beide systemen. Echter, zij hebben geen procedure voor wanneer de connectie tijdelijk wordt verbroken. Stel dat men een user account voor een nieuwe medewerker wil aanmaken maar op dat moment de verbinding met de cloud applicatie wordt verbroken, dan gaat het verzoek voor een nieuw user account verloren. Cloud applicaties geven geen garantie of notificatie dat een synchronisatie is gelukt.
Bulk acties
Het doen van bulk acties in cloud applicaties wordt soms geweigerd door de applicatie. Denk bijvoorbeeld aan scholen die in één keer user accounts voor duizenden leerlingen willen aanmaken in een cloud applicatie (bijvoorbeeld elektronische leeromgeving). Er zijn cloud applicaties die beperkingen opleggen aan de hoeveelheid acties die uitgevoerd kunnen worden of zelfs eisen dat tijdens werkuren geen beheerwerkzaamheden worden gedaan om zo overbelasting op hun netwerk te voorkomen.
Conclusie
Werken met cloud applicaties betekent over het algemeen dat organisaties het user- en toegangsbeheer niet meer in eigen handen hebben en dat de regels en SLA's van de leverancier van de cloud applicatie gelden. User- en toegangsbeheer zijn voor hen van secundair belang. Wil je wel controle hebben over user- en toegangsbeheer dan zijn er derden die software bieden die jouw organisatie daarbij kan ondersteunen.
Arnout van der Vorst, technical consultant bij Tools4ever
Arnout,
Als je het niet met de SLA van leverancier eens bent dan ga je de dienst niet afnemen! Dat geldt niet voor alleen ICT en Cloud maar ook voor alles! Trouwens de Cloud-leveranciers zijn ook niet zo stug dat ze alleen naar hun diensten en belang kijken en de behoeftes en wensen van jou als klant negeren.
Bovendien naar Cloud gaan vereist o.a. een visie en aanpak. Volgens je aanpak zou je tot het punt komen dat je voor deze verandering een aantal hulpmiddelen nodig hebt, zoals VMware Horizon, Citrix Cloud-Gateway, OpenStack of DeltaCloud etc. Deze zijn tools die veel zaken rondom Hybride Cloud opgelost hebben.
Zomaar gebruik gaan maken van een dienst buiten de deuren van mijn bedrijf voordat ik het van alle kanten goed bestudeerd heb(business case voor maken), zou ik zeker niet doen!
Arnout,
Leuk stuk waar voor dank. Ik deel je mening dat er vaak extra tooling benodigd is om alles inzichtelijker te maken.
@ Reza,
Op zich heb je een punt. Ben je het niet eens met de SLA dan neem je de dienst niet af. En natuurlijk valt er bij veel Cloud-leveranciers wel over te praten.
Het grote verschil zit in het Cloud leveringsmodel waar je gebruik van gaat maken. In IAAS en PAAS omgevingen valt er vaak nog wel over te praten.
In de SAAS omgevingen van de door Arnout aangehaalde voorbeelden ( Google Apps, Salesforce.com, GoToMeeting, Office 365, itslearning, AFAS Online, RAET Online)is het toch vaak een andere zaak. Je kan daar kiezen uit een aantal voor gedefinieerde smaken en that’s it. Maatwerk zal daar veel minder voorkomen.
Een serie terechte en relevante punten die geadresseerd moeten worden. Governance op clouddiensten kan heel uitdagend worden, zeker als men zich hier niet goed bewust van is.
Het is ook iets wat vaak organische groeit, of door de tijd heen ontstaat. Eerst is er die ene handige dienst, dan komt er eentje bij, en zo verder.
Qua security is dit ook een uitdaging, het wordt steeds lastiger de gevolgen te overzien als diensten aan elkaar geknoopt worden.
Een organisatie zal dus ook bewust om moeten gaan met het aansluiten van diensten, of bewust een beleid moeten kiezen van “eigen verantwoordelijkheid”. Door bijvoorbeeld de gratis variant van Yammer te gebruiken heb je wel een interne social media, zonder dat de organisatie expliciet het beheer op zich neemt.
De onweerlegbaarheid aantonen kan hierdoor weleens moeilijker worden omdat impersonisatie niet alleen door Internet criminelen gedaan wordt. Niet zelden worden, mede door genoemde beperkingen afdelingsaccounts gebruikt omdat RBAC niet eenvoudig is aan te brengen. Vergeet ook de audit (de C in RBAC) niet die hierbij hoort omdat procedures alleen niet genoeg zijn.