Cloud doet in veel verschillende vormen zijn intrede in het it-landschap van veel organisaties. Soms gebeurt dat via eindgebruikers die hun eigen clouddiensten meenemen naar het werk. Soms is het de business manager die zelf een clouddienst aanschaft. En soms is dat via een gedegen cloudstrategie die de organisatie heeft ontwikkeld. Zo ontstaan er nieuwe hybride it-landschappen binnen organisaties waarbij lokale it-oplossingen gecombineerd worden met (publieke) clouddiensten als Amazon, Google of Salesforce.
Deze hybride omgevingen werpen nieuwe vraagstukken op voor de CIO. Maar gelukkig zijn er ook antwoorden. In dit artikel komen vier slimme antwoorden aan bod op nieuwe vraagstukken die cloud met zich meebrengt.
Beheer van wachtwoorden
Het gebruik van verschillende SaaS/IaaS-diensten leidt in de praktijk al snel tot een wildgroei aan authenticatie-mechanismen en wachtwoorden. Elke clouddienst heeft meestal naast eigen inloggegevens ook vaak een eigen wachtwoordbeleid met als gevolg dat deze vergeten kunnen raken. Wanneer dat gebeurt zijn de diensten niet optimaal te gebruiken, moeten wachtwoorden telkens worden reset of gaan medewerkers kun wachtwoorden opschrijven. Dit is niet gebruikersvriendelijk en brengt ’beveiligingsrisico’s met zich mee.
Cloud single sign on-oplossingen bieden uitkomst. Hiermee wordt het meermaals inloggen en onthouden van wachtwoorden overbodig. Gebruikers hoeven slechts één gebruikersnaam en wachtwoord te onthouden. Een Identity Provider (IDP) authentiseert gebruikers waardoor zij automatisch bij iedere clouddienst inloggen.
Let op: Kies bij voorkeur een cloud single sign on-oplossing die gebaseerd is op Security Assertion Markup Language (SAML)-authenticatie. Dit is de meest belovende standaard voor dergelijke functionaliteit. Omdat veel SaaS diensten momenteel nog werken aan het SAML gereed maken van hun diensten is het verstandig om nu te kiezen voor een platform dat ook post proxy ondersteuning biedt. Dit geeft je de mogelijkheid om nu al 95 procent van de huidige clouddiensten te koppelen. In de toekomst kun je post proxy dan uitfaseren en de overstap maken naar SAML als de SaaS dienst daar klaar voor is. Eindgebruikers merken dan nauwelijks iets van deze overstap. Het is daarnaast belangrijk om te kijken of de oplossing voldoende integratie mogelijkheden heeft met andere clouddiensten met het oog op toekomstige uitbreiding
De voordelen:
- Tevreden en effectieve eindgebruikers.
- Minder veiligheidsrisico’s omdat wachtwoorden niet meer worden opgeschreven.
- Centraal afdwingen/implementeren van wachtwoord policies mogelijkheden door de rol van IDP.
- Efficiency op de it-afdeling omdat wachtwoord resets tot een minimum worden beperkt.
Beheren user accounts
Adoptie van verschillende clouddiensten leidt er toe dat bij elke clouddienst weer opnieuw user accounts aangemaakt moeten worden. Het aanmaken van accounts bij elke clouddienst afzonderlijk is niet ideaal. Het is arbeidsintensief om steeds weer handmatig een account per dienst aan te maken en te onderhouden. Kijk ook naar het werk dat het provisionen van een account bij meerdere diensten kost, wanneer een nieuwe medewerker start. Ook bestaat het risico dat het overzicht verdwijnt op wie toegang heeft tot welke cloudapplicatie. Dit heeft gevolgen voor de beveiliging van de it-omgeving. Stel je zich eens voor dat oud-medewerkers nog steeds gebruik kunnen maken van de corporate crm-oplossing uit de cloud. Naast de juiste beveiliging dreigt de cloudbelofte ‘pay per use’ verloren te gaan als er slapende accounts bij de diverse SaaS-diensten uitstaan.
Het antwoord hierop zijn Cloud Identity Management (IDM) en provisioningoplossingen. Deze realiseren automatische en centrale (de)provisioning van accounts bij de diverse clouddiensten. Ook bieden ze zicht op welke medewerkers waar toegang tot hebben. Deze oplossingen zijn vaak te koppelen aan bestaande Identity-oplossingen of Active Directory structuren. Dit maakt uitlevering van applicaties net zo eenvoudig en efficiënt als klassiek in huis georganiseerde it. Bijvoorbeeld wanneer een medewerker wordt toegevoegd aan de AD-groep Sales. Het account krijgt dan volledig automatisch toegang to de vooraf toegewezen cloudapplicaties. Cloud IDM wordt veelal in één oplossing geleverd met cloud single sign on.
Let op: nog niet alle clouddiensten zijn hiervoor gereed. Belangrijk is om te weten welke clouddiensten api’s hebben ten behoeve van provisioning. Een echte marktstardaard voor cloudprovisioning ontbreekt nog. Het is daarom raadzaam te vragen naar de visie van de provisioning partij ten aanzien van standaardisatie. KPN IT solutions verwacht bijvoorbeeld veel van de System for Cross-domain Identity Management (SCIM)-standaard die momenteel in ontwikkeling is door het Internet Engineering Task Force (IETF) en waar onder meer Google, Ping en Salesforce in participeren
De voordelen:
- Optimale veiligheid en terug naar de echte Pay Per Use belofte (de-provisioning).
- Centraal inzicht in cloudapplicatie accounts.
- Centraal en efficiënt beheer van accounts door middel van automatische provisioning.
Data tussen (cloud)diensten uitwisselbaar houden
Al jarenlang werken organisaties met verschillende applicaties die de bedrijfsprocessen ondersteunen. Tussen deze applicaties zijn in de loop der tijd vaak integraties gerealiseerd met termen als exports/syncs, masterdata en enterprise service bus. Langzaamaan schuiven panelen van het it-landschap op naar cloudalternatieven. Daarbij kan je je afvragen hoe dat zit met de integratie van data en informatie. Hoe zorg je ervoor dat data uitwisselbaar blijft tussen de verschillende bedrijfsapplicaties?
IPaaS – het data integration platform as a service – doet hier zijn intrede. Businessvragen als ‘Kunnen we Salesforce informatie laten synchroniseren met het bestaande SAP-systeem?’ worden hiermee beantwoord. Hoe meer businessapplicaties naar de cloud verschuiven, hoe groter de behoefte aan een dergelijk integratie platform wordt.
Let op: een IPaaS kun je zelf on premise bouwen of betrekken van een clouddienstverlener op abonnementsbasis (pay per use). Beide opties hebben voordelen. Belangrijk is om daarbij rekening te houden met toekomstige integratie en indien mogelijk, gebruik te maken van standaarden. Uiteraard op basis van een goed zicht op de uitwisselingsbehoefte: welke data wil je synchroniseren, welke wil je bewerken en hoe vaak wil je dat doen?
De voordelen:
- Naadloze integratie en uitwisseling van data tussen verschillende business applicaties.
- Data wordt automatisch bijgewerkt waardoor alle applicaties met up to date informatie werken.
- Integratie projecten hebben, door gebruik te maken van moderne IPaaS oplossingen, een veel kortere implementatietijd dan voorheen.
Abonnementsbeheer en leveranciersmanagement?
Meer clouddiensten leidt ook tot meerdere leveranciers die gemanaged moeten te worden. Op deze trend spelen isv’s in door ‘cloudbroker services’ te leveren. Vanuit één centrale marketplace of appstore kan de it-manager hiermee eenvoudig clouddienstabonnementen aangaan, wijzigen en beëindigen. Optimaal inzicht in de lopende abonnementen en gebruik daarvan voorkomt onnodige abonnementen. Een ander groot voordeel bij cloudbrokering is dat de aanschaf van clouddiensten netjes op één integrated factuur wordt opgeleverd.
Enkele cloudbrokers leveren ook nog een company appstore voor de eindgebruikers, waarbij een organisatie kan kiezen om de aanschaf van clouddiensten, gecontroleerd te beleggen bij eindgebruikers zelf. Voor sommige type clouddiensten, als voorbeeld box.net versus dropbox, kan de keuzevrijheid zo direct bij de eindgebruiker worden belegd. Voordeel hiervan is ook dat alleen betaald hoeft te worden als de eindgebruiker de dienst daadwerkelijk activeert.
Let op: Cloudbrokers marketplaces komen in verschillende soorten en maten voor. Er bestaan varianten met 24/7 support, alleen Nederlandse diensten, met of zonder een single point of contact, met inhoudelijke support op applicaties of met alleen functionele support. Belangrijk is om goed te kijken naar de prijsstructuur en alleen te betalen voor toegevoegde waarde. Diensten binnen de marketstore kunnen niet duurder zijn dan afzonderlijke diensten en leveranciersmanagement hoort inbegrepen te zijn zonder extra kosten.
De voordelen:
- Eén gecombineerde factuur ondanks verschillende leveranciers.
- Vereenvoudigd leveranciersmanagement.
- Sommige clouddiensten werken nog met betalingssystemen uit de consumentenwereld (creditcards, paypall). Door deze via een appstore aan te schaffen kan de betaling plaats vinden via reguliere factuurstromen.
- Via een appstore word je geattendeerd op mogelijke andere interessante clouddiensten
- Eindgebruikers krijgen ‘gecontroleerde’ vrijheid om een eigen pakket aan clouddiensten samen te stellen dat voldoet aan de persoonlijke behoefte om het werk zo efficiënt mogelijk te kunnen uitvoeren.
Gecombineerd antwoord
De genoemde oplossingen worden in de praktijk soms ook gecombineerd in één platform of dienst. Bijvoorbeeld middels cloudaggregatie of cloudbrokerplatformen. Ons advies is om bij de selectie van een oplossing in ieder geval te gaan voor een pay per use gebaseerde oplossing. Zorg dan dat deze toekomstvast is door zoveel mogelijk gebruik te maken van (de facto) industriestandaarden. Wanneer de organisatie een cloudstrategie heeft, zijn daarin vaak aanknopingspunten te vinden die een voorkeur aangeven voor een bepaald type platform en leverancier.
Jeroen Jacobs, manager competence center GRIP KPN IT Solutions en Michiel van Dijk, principal technical consultant KPN IT Solutions
Er worden hier een aantal ‘lego blokjes’ gegeven om een hybride oplossing te maken waarbij terecht opgemerkt wordt dat sommige richtingen veelbelovend zijn maar nog wel uitdagingen kennen in integratie.
Met bijvoorbeeld SSO op basis van wachtwoorden lijkt me hier nog wel wat te verbeteren. En een geintegreerde IdM oplossing kent ook nog wel wat uitdagingen. Want welke persona heb je en welke zijn waar non grata. RBAC is vaak al moeilijk te implementeren in statische omgevingen en vergt in dynamische omgevingen helemaal goede controle.
Ik mis nog een heel belangrijk punt: goede en controleerbare encryptie waarbij de sleutels alleen bij de klant liggen waardoor alleen de klant zelf toegang kan krijgen tot zijn data.
@Johan
Wat wordt er dan versleuteld dan? Het data verkeer of de inhoud van de database zelf? Voor data backup is het technisch heel eenvoudig om client site versleuteling te gebruiken. Voor de wat meer geavanceerde cloud applicaties ism een RDBMS is encryptie op cel-niveau niet echt standaard. En encryptie heeft alleen maar nut als uitgangspunt van de gebruiker als de gebruiker alleen maar versleutelde data over het lijntje stuurt. Versleuteling aan de kant van de cloud zelf betekend dat de beheerder van de cloud relatief eenvoudig bij de onsleutelde inhoud kan.
@Ewout
Klopt dat wachtwoord gebaseerd SSO ook niet onze voorkeur heeft. Gelukkig hebben de grote bekende namen ook vrijwel allemaal SAML ondersteuning.
Echter waar we in de praktijk wel veel tegenaanlopen is dat juist die vaak industrie specifieke Saas diensten die een organisatie veel gebruikt, veelal zo ver nog niet zijn. Zelfs grote namen in bepaalde sectoren.
Om het gemak van SSO voor ook juist die applicaties niet uit te sluiten is de combinatie mooi. Zeker als je parralel de Saas providers gaat pushen om SAML te gaan adopteren. En hier zien we weer dat zeker de kleine spelers zeer snel in staat zijn om SAML in een bestaande Saas applicatie te embedden.
Wat een mooi artikel! Zo iets heb ik al een tijd op deze site gemist.
1- Na het lezen van dit artikel kom ik uit op het punt dat ik al keer op keer heb aangegeven: Cloud is “nog” niet volwassen! Cloud zal de komende tijd veel ontwikkelingen meemaken, standaardisatie in dit verschijnsel zal verder een plek krijgen zodat veel onduidelijkheden veel onduidelijkheden voor klanten niet meer bestaan.Een voorbeeld hiervan is de standaardisatie op het gebied van authenticatie-zaken. Iets zoals SAML is nog verder in ontwikkeling. Dit moet nog door veel providers geadopteerd worden.
2- Zo te zien it orchestration in Cloud is nog niet compleet! Je hebt nog veel tools en ondersteuning nodig om een en andere aan elkaar te koppelen.
3- Steeds meer providers bieden hun IDP of IDaaS aan! Sterker nog dit is zeer belangrijk voor hun dienst en vendor lock-in! Hier zullen de komende tijd veel zaken in veranderen/ontwikkeld worden. De vraag is wie is juridisch gezien verantwoordelijk voor een lek als een IDaaS tussen jou en je provider zit!?
4- Uitwisselen van data zal nog verder gestandaardiseerd worden! Dat komt doordat elke provider de data in zijn eigen vormat mag genereren. Het ligt er aan tot op welk niveau je je data wilt uitwisselen/synchroniseren.
Er zijn nog wat andere punten die in dit kader benoemd mogen worden. Maar laten we eerst deze zaken bespreken!
Ik vraag me af wat uiteindelijk de kosten van all deze tools en hulpmiddelen zijn! Blijf cloud nog zo goedkoop zoals ze het beweren? Ik denk het wel, maar nu niet!
Jeroen,
Implementeer je met SSO uiteindelijk niet een single point of failure door een te grote afhankelijkheid met een bepaalde oplossing?
@Ewout; In zekere zin wel ja… Anderzijds hoe anders is dat in klassieke omgevingen, bijvoorbeeld als een domain controller eruit ligt… en dus dergelijke functies voer je redundant uit in je architectuur.
In de SSO cloud wereld is dus ook een redundante, bij voorkeur multi datacenter gebaseerde oplossing aanbevolen met hoge service levels. Daarnaast voor de echt kritieke applicaties ook nog een noodplan wat te doen bij… Zo ken ik in de praktijk situaties waar daadwerkelijk in de Saas dienst op verzoek bij calamiteiten de SAML authenticatie omgezet kan worden naar klassieke authenticatie.
Jeroen,
Dat SSO ook in traditionele omgevingen nog weleens voor een SPoF zorgt klopt, zeker in de middleware. Maar vaak heb je dan maar met een beperkt aantal partijen te maken wat omschakeling naar plan B makkelijker maakt. In een gedeelde cloud oplossing kan dat dus nog weleens problematisch zijn.
Goed artikel en helder weergave van de problematiek. Geeft ook aan dat er nog gaten in het aanbod zitten en dat er een cloud IAM systeem met SSO zou moeten komen. Gat in de markt lijkt mij. Je ziet ook dat SAAS diensten moeilijk te koppelen zijn en leiden toch spaghetti oplossingen en gedrochten.
De vraag die in dit artikel niet wordt gesteld is of je data in de cloud moet plaatsen. Je zou ook kunnen kiezen voor applicatie servers in de cloud en data in de eigen omgeving, dat maakt de problematiek minder kwetsbaar en beter beheersbaar, helaas niet minder complex.
Je zou ook je eigen IAM omgeving willen beheren en deze eenduidig willen koppelen aan de cloud omgevingen, dat lijkt nog lastig te realiseren omdat iedere provider zijn eigen IAM dienst kiest. Je ziet natuurlijk ook een roep om federaties, dat is echter ook complex in de praktijk.
Kortom een gebied dat nog moet worden ontwikkeld en zich ook zal ontwikkelen.
@Reza,
Dank voor je reactie !
ad 1
Ben ik gedeeltelijk met je eens. Natuurlijk zijn er nog teveel ‘standaarden’ waardoor het onvolwassenheid uit kan stralen. Maar anderzijds zijn er op dit gebied inmiddels een groot aantal beschikbaar en is het een kwestie van het adopteren en implementeren van deze standaarden door zowel de cloud diensten zelf als door de service aggregator (als broker tussen klant en zijn cloud/non-cloud diensten). In de SAAS markt is goed te zien dat ieder op dit moment nog zijn eigen plan trekt en zie ik eigenlijk drie ‘soorten’:
– cloud providers waarvan de cloud dienst inmiddels een grote markt penetratie kent en die dat feit verder uitdiepen door andere diensten op de initiele dienst te gaan leveren. Bv. een SAAS dienst die ook directory services aan gaat bieden. Deze providers zullen eerder investeren om hun eigen dienst breder te maken dan om standaarden te adopteren.
– cloud providers waarvan de cloud dienst een bepaalde nichemarkt bedient. Deze providers zijn over het algemeen minder bereid om te investeren in het volgen van de laatste ontwikkelingen, begrijpelijk want zij hebben meestal een trouw klantenbestand (vaak bij gebrek aan alternatieven).
– cloud providers die het ‘niet volwassen’ zijn onderkennen en daardoor continu aan het innoveren zijn om meerdere standaarden te omarmen, vorm te geven en te implementeren.
Daarom verwacht ik wel een grotere rol voor service aggregators, enerzijds helpen zij de klant ‘ontzorgen’; vanuit klant perspectief wordt de cloud dienst op een standaard manier benaderbaar voor de klant en ligt de complexiteit van billing, provisioning, authenticatie, authorisatie, support etc. bij de aggregator. Dus een klant kan op den duur de keus maken diensten alleen om deze reden al alleen via een aggregator af te willen nemen.
Anderzijds hebben service aggregators er baat bij als zij cloud diensten op een standaard en kosteneffectieve manier snel aan kunnen sluiten op hun platform, dus standaard API’s, berichtenverkeer voor (de)provisioning volgens SCIM, authenticatie volgens SAML etc. dit alles moeten zij kunnen doen zonder een vendor lock-in te creeren voor de klant (dit is alleen te garanderen door een platform te bieden dat zich conformeert aan standaarden). Voldoet een cloud dienst aan de standaarden en is deze dus eenvoudig aan te sluiten op het aggregatie platform, dan is het voordeel voor de dienst dat deze opgenomen kan worden in bv. een company app store. Op deze manier bereik je als dienst natuurlijk een veel groter publiek dan als op zichzelf staande dienst de potentiele klanten te zoeken en te benaderen.
ad 2
Eens, dit wordt dus veelal veroorzaakt door het niet hanteren van standaarden en het beschikbaar zijn van teveel ‘standaarden’. Dit maakt de rol van service aggregator op dit moment nog uitdagender omdat de klant vanuit zijn perspectief wel een standaard manier van cloud diensten ontsluiting verwacht maar aan de service aggregator kant er, richting de cloud dienst zelf, meerdere manieren ondersteund moeten worden om dit ook waarheid te laten zijn.
ad 3
Vandaar de voorkeur voor een echte service aggregator die dat kan leveren ipv een cloud dienst die dat erbij heeft genomen in zijn dienstenaanbod. Op deze manier creeer je in ieder geval een duidelijke scheidingslijn tussen aggregatie en daadwerkelijke cloud dienst.
ad 4
Zoals een service aggregator belangen heeft dat cloud diensten gestandaardiseerd zijn zal een klant vanuit zijn perspectief gaan eisen dat de business data tussen cloud diensten eenvoudig uit te wisselen is.
Of cloud goedkoop is, is een afweging die elke klant voor zich moet maken en is afhankelijk van tal van factoren. Gezien de enorme populariteit van sommige SAAS diensten kan ik me niet voorstellen dat daaronder nooit een valide (financiele) business case ligt. Al ben ik het met je eens dat dat zeker niet altijd het geval zal zijn.