}

User- en toegangsbeheer in cloud applicaties: een uitdaging

Cloud applicaties als Google Apps, Salesforce.com, GoToMeeting, Office 365, itslearning, AFAS Online en RAET Online worden steeds meer ingezet in het bedrijfsleven. Bij cloud applicaties is het lastiger om exact te weten wie toegang heeft tot welke applicaties en data. Leveranciers van cloud oplossingen geven helaas weinig prioriteit aan het ontwikkelen van beter beheer van user accounts en toegangsrechten in hun applicaties. Het werken met cloud applicaties levert daardoor een aantal uitdagingen ten aanzien van user- en toegangsbeheer:

  1. Federatie geen vervanging voor provisioning
    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 enkele mogelijkheden om user accounts te synchroniseren tussen beide authenticatiebronnen (federatie), zoals ADFS van Microsoft en de SAML-standaard. Eindgebruikers Echter, federatie is geen vervanging van provisioning en basis user account beheer.
  2. Te veel handmatige handelingen
    Leveranciers die federatie niet ondersteunen bieden een webbrowser die beheerders kunnen gebruiken om rechtstreeks op de cloud applicatie beheer uit te voeren. Dit vraagt nog om een aantal handmatige handelingen en dat is tijdrovend en foutgevoelig. Ook wanneer het mogelijk is om een basis CSV bestand te importeren in de cloud applicatie, vraagt dit nog steeds om een handmatige actie van de beheerder.
  3. Verschillende conventies voor 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.
  4. Ontbreken van 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.
  5. 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. Daarnaast geven zij geen garantie of notificatie dat een synchronisatie is gelukt.
  6. Weigeren van bulk acties
    Het doen van bulk acties in cloud applicaties wordt soms geweigerd door de applicatie. 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.

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. Wilt u wel controle hebben over user- en toegangsbeheer dan zijn kunt u terecht bij Tools4ever. Tools4ever heeft vroeg onderkend dat het verplaatsen van applicaties naar de cloud nieuwe uitdagingen oplevert ten aanzien van het user- en toegangsbeheer. Tools4ever heeft hiervoor koppelingen ontwikkeld die het volgende bieden:

  • Synchronisatie van wachtwoorden. Indien het wachtwoord in de Active Directory wijzigt, wordt dit automatisch doorgezet (gesynchroniseerd) naar de cloud applicatie;
  • Auto provisioning van user accounts gekoppeld aan het bedrijfsinterne user account beheersproces van UMRA. Hierbij worden loondienst medewerkers vanuit het HR/PZ-systeem gesynchroniseerd, evenals aangebrachte wijzigingen door de helpdesk, managers en zelfs eindgebruikers. User accounts worden volledig automatisch aangemaakt, bijgewerkt, dis/enabled, verwijderd, etc.;
  • Geïntegreerd toegangsbeheer van eindgebruikers tot de cloud applicatie. Toegang tot verschillende delen van cloud applicatie wordt toegekend/verwijderd op basis van de rol die de eindgebruiker heeft binnen de organisatie. UMRA biedt een geavanceerde RBAC module waarbij toegang tot de cloud applicatie gereguleerd wordt via afdeling/functie in het HR-systeem en de keuze die een manager voor haar/zijn medewerkers maakt;
  • Gecentraliseerd dashboard voor IT met een overzicht van de gebruikte cloud applicaties per gebruiker voor de controle op licentiekosten en voor logging en rapportage;
  • Single Sign On van alle cloud- en webapplicaties op basis van bestaande AD credentials, waardoor gebruikers niet langer een veelvoud aan gebruikersnamen en wachtwoorden moeten onthouden.

SAP koppeling met Active Directory

Bij 1 van grootste ziekenhuizen van Nederland heb ik recentelijk een SAP koppeling naar Active Directory opgeleverd met behulp van UMRA van Tools4ever. Het scenario is dat SAP elke x minuten een feed aanleverde in CSV formaat met alle wijzigingen, die vervolgens in Active Directory verwerkt moeten worden. Met behulp van specifieke codes voor bepaalde mutaties (instroom, doorstroom, uitstroom) weet de UMRA engine welke business logica uitgevoerd moet worden.

Lees meer

De vooroordelen van Single Sign On

Veel IT managers en Security Officers zijn terughoudend als het gaat om het implementeren van een Single Sign On (SSO) oplossing, hoewel de voordelen van SSO duidelijk zijn. Namelijk onder andere gebruikersgemak voor de eindgebruiker en minder wachtwoord reset calls naar de helpdesk. De terughoudendheid ten aanzien van SSO wordt in de hand gewerkt door een aantal vooroordelen over SSO.

Lees meer

RBAC: sleutelrol, beheer en evolutie

Veel organisaties zijn bezig met RBAC in meer of mindere vorm; verkenning, project, implementatie, vulling of beheer. We zien dat dit gestuurd wordt door normen als NEN7510, waarin voornamelijk staat beschreven dat je moet kunnen aantonen waarom iemand een autorisatie nodig heeft en hoe deze tot stand is gekomen. Inmiddels weten we dat RBAC niet een heilige graal is, maar dat veel implementaties stuk lopen door de te grote scope en complexiteit.

Lees meer

Single Sign On met terminal emulatie (VAX64, AS/400, Linux, SSH)

We zien dat veel organisaties steeds bewuster bezig zijn met security, waarschijnlijk mede ingegeven door regelgeving zoals NEN7510 en ICT-audit trajecten. Naast het autorisatiebeheer binnen applicaties, waar we al verschillende oplossingen voor bieden zijn we ook actief op het authenticatie-vlak, namelijk met een Single Sign On (SSO) oplossing.

Lees meer

Afas koppeling met Lotus Notes adresboek

Met UMRA doen we veel met koppelingen vanuit HRM-systemen naar de Active Directory om zo het user account beheer te automatiseren. UMRA is in staat om met 1 van de 130+ connectors gegevens te verzamelen die belangrijk zijn voor het aanmaken, muteren en uitschakelen van user accounts. We kunnen bijvoorbeeld uit een HRM systeem lezen welke gebruikers nieuw in dienst zijn of nog gaan komen, wijzigingen in functies, overplaatsingen naar andere afdelingen en alle andere gegevens die aan een dienstverband zijn gekoppeld.

Lees meer