Volgens verschillende onderzoeken zullen veel bedrijven in en na 2014 gebruik gaan maken van meerdere SaaS-oplossingen in een hybride cloud-architectuur. Deze stap zal een groot effect hebben op de efficiëntie, beheersbaarheid en beheerbaarheid van je (ondersteunende) bedrijfsprocessen.
De transformatie van traditionele architectuur naar het hybride cloud model is al een feit. Hoe kunnen ict-managers en cio`s deze niet al bekende hervorming beheerst uitvoeren en ook tegelijkertijd de wens van business realiseren?
Uitdagingen
Een aantal effecten van de invoering van SaaS-oplossingen op het ict landschap en architectuur zijn eerder in een artikel besproken. Leveranciers doen ons geloven dat de invoering van hun SaaS-oplossing niks meer is dan de aanschaf daarvan. Misschien is het ook handig om te weten dat:
- De policies die door verschillende SaaS-leveranciers opgelegd worden zorgen voor een toename van gebruikersnamen en wachtwoorden per gebruiker. Een gebruiker draagt in dat geval een dik sleutelbos voor toegang tot zijn/haar applicatieset bij verschillende cloudleveranciers. Het is al bekend dat de gebruikers in de securityketen de zwakste schakel zijn! Dit is voldoende om ons voor te stellen dat de gele post-it velletjes weer op de bureau`s komen liggen.
- Verspreiding, decentralisatie en toename van tooling (per SaaS-leverancier) en beheeractiviteiten rondom gebruikersaccount. Afhankelijk van de SaaS-leverancier zijn hier verschillende manieren voor de provisioning van accounts. De meest gebruikte manieren zijn losse tools van de SaaS-leverancier die informatie uit Active Directory synchroniseerd of (saml) Just-in-time provisioning doen. Als voorbeeld levert Microsoft de tool dirsync die de complete AD + wachtwoorden naar de cloud synchroniseerd. De uitdaging bij sommige leveranciers echter zit hem in de de-provisioning hiervan!
- In het huidige interne applicatielandschap is het zeer normaal dat verschillende applicaties (indien nodig) met elkaar kunnen communiceren. Dit gedrag is niet meer vanzelfsprekend waanneer je deze applicaties vervangt door verschillende SaaS-oplossingen bij verschillende externe cloudleveranciers. In een hybride architectuur heb je een verbindingsbrug nodig!
- Elke SaaS-leverancier bepaalt zijn authenticatie- en autorisatieprotocol voor zijn diensten. Ondanks dat er een standaardisatieslag op het gebied van authenticatieprotocollen gaande is, zien we ook dat de grote spelers deze positieve ontwikkeling niet altijd volledig omarmen of ondersteunen. Deze situatie zorgt voor een incompatibiliteit en belemmering in interoperabiliteit tussen verschillende SaaS-oplossingen bij verschillende leveranciers.
Identity en Access Management (I AM)
Een oplossing die de hierboven benoemde uitdagingen kan verhelpen is Identity en Access Management (I AM). Het voegt een laag aan de architectuur toe die centraal als katalysator en integrator tussen je interne authenticatiedomein en verschillende SaaS-oplossingen werkt. Met een I AM-product kun je naast toegang tot alle SaaS-oplossingen met een gebruikersnaam en wachtwoord (single sign on) ook de centralisatie van verschillende beheerprocessen rondom audit, beveiliging, authenticatie, autorisatie en toegang realiseren. Een I AM-product kun je verder inzetten als communicatie hub tussen verschillende SaaS-oplossingen. Hierdoor voorkomt je een oerwoud van point to point communicatiekanalen tussen verschillende objecten (intern naar extern, extern naar extern, extern naar intern) in je hybride cloud-architecuur.
Wanneer je van plan bent om je interne dienstverlening te optimaliseren met een self-service-portal voor je gebruikers dan heb je in een hybride omgeving een verbindingsbrug nodig voor de orkestratie van verschillende processen die hieraan gerelateerd en gebonden zijn.
De grote SaaS-leveranciers weten al hoe belangrijk de rol van I AM is. Daarom doen ze hun best om de identity provider van de klant te worden door deze mogelijkheid als extra (integrale) dienst aan te bieden. Kijk uit voor een addertje onder het gras! Hierdoor kun je beperkt worden tot SaaS-oplossingen die deze leveranciers ondersteunen (vendor lock-in) en ook de mogelijkheden die hun oplossing ondersteunt. Er zijn cloudleveranciers die alleen deze dienst als hun core-product aanbieden (ID as a Service) Naast een aantal beperkingen van IDaaS zijn er een aantal juridische vraagstukken die het afnemen van deze externe dienst minder interessant maken. Je kunt naast de benoemde mogelijkheden ook deze dienst on-premise realiseren. Uiteraard zijn er hier voor- en nadelen aan gebonden die per situatie bekeken moeten worden.
De plek van de Identity Store
Het veranderen van je architectuur in een hybride mode en het gebruiken van verschillende SaaS-oplossingen kunnen niet alleen grote effecten hebben op je bedrijfsprocessen maar ook op de inrichting van je authenticatiedomain en Identity Store. Onderschat dit niet! Identity en Access Management is het vertrek en de landingsbaan van je hybride omgeving. Waar de plek van je identity store komt (on-premise of als IDaaS bij een tussenpartij of bij SaaS leverancier) heeft effect op de flexibiliteit en verdere inrichting van je architectuur in de toekomst.
Een eigen centrale plek voor Identity & Access Management biedt je de mogelijkheid om altijd de regie te blijven behouden over wie er toegang heeft tot wat en dit aantoonbaar te kunnen maken (audit), centralisatie van provisioning van accounts voor applicaties en bedrijfsprocessen , afdwingen/controle over sterk wachtwoordbeleid en authenticatieprotocollen en nog meer.
Het is de taak van cio`s/ict-managers om deze onzichtbare valkuilen en obstakels op weg naar de toekomstige architectuur (hybride cloud) tijdig inzichtelijk te maken om het Identity-oerwoud en desinvestering in de toekomst te voorkomen.
Bespreek de mogelijkheden, de beperkingen, voor- en nadelen en Identity & Access Management productportfolio met een I AM-expert voordat je architectuur veranderd is in een oerwoud!
Dag Bram,
Dank voor je reactie. Ik heb eerder ergens in mijn reacties aangegeven dat de klant zich goed dient te oriënteren op het product en mogelijkheden. Sommige producten zijn niks anders dan een doos met veel scripts en mooie verpakking! Je bent zeker veel kwijt aan (kosten van)beheer en het product is niet flexibel en kent beperkte (uitbreidings)mogelijkheden en nog meer andere zaken. IAM wordt al veel in de zorg en onderwijs gebruikt. We zien dat IAM producten sinds een paar jaar flink ontwikkel zijn. Daarom zou het niet verkeerd zijn om je productkeuze van toen te herzien. Als je al een IAM hebt dan zou je ook moeten afvragen of dit al een antwoord heeft op verschillende ontwikkelingen en behoeftes vanuit business (cloud, audit, governance etc)voor nu en vooral in de toekomst.
IAM aas lijkt mij een logische stap, zeker als je kijkt naar de mogelijkheden om IAM los te koppelen van fysieke locaties. Het zo mooi zijn als een dergelijk artikel wordt voorzien van een case met een toepassing. Een van de belangrijkste punten lijkt de exit strategie vanuit een IAMAAS aanbieder. Hoe kan je als je ooit deze route bewandeld switchen naar een andere aanbieder.
@Willem;
Leuke reactie, dank!
Ik weet niet of IDaaS een logische stap kan zijn. Ik heb de neiging om mijn Identity Store bij mezelf houden (laten beheren) Deze component is het fundament van mijn ict-landschap, deze zou ik niet zomaar weggeven. Bovendien ik weet niet of de IDaaS-leverancier aan mijn behoeftes kan voldoen als ik over een aantal jaar van SaaS-leveranciers en producten wil veranderen.
Zoals in het artikel aangegeven het buiten de deur zetten van je Identity Store is juridisch gezien geen optie voor veel organisaties. Verder wanneer je van je Identity Store gebruik wil maken om je (interne) processen te automatiseren dan zou je beter deze component binnen de muren van je (interne) architectuur moeten houden.
Ik kom in het volgende artikel terug op de toepassing van Identity Store voor procesautomatisering en federatie.
We zullen binnenkort een case publiceren over de toepassing van IAM.