Met de Broker in de Aanval tegen de Cloud-Anarchie

Cloud-Anarchie & Spaghettiarchitectuur

Zowel ondernemingen als overheidsdiensten hebben moeite om om te gaan met de relatief recente situatie waarbij de werknemers en delen van het (overheids)bedrijf zonder toelating gebruik maken van allerlei diensten in de publieke cloud voor professionele doeleinden. Op het eerste zicht is een dergelijke oplossing snel en goedkoop, maar toch krijgen we al gauw een onoverzichtelijk kluwen, zoals geïllustreerd in onderstaande figuur, wat ook wel een spaghettiarchitectuur genoemd wordt.

spaghetti

In een dergelijke situatie verliest het bedrijf alle overzicht en controle en is er bijgevolg een verzwakking van de veiligheid door verschillende aspecten, zoals hieronder beschreven.

  • Het bedrijf weet niet meer waar overal in de wereld haar potentieel gevoelige data zich bevinden (geografische fragmentering). Bovendien kan voor eenzelfde behoefte gebruik gemaakt worden van heel wat verschillende diensten. De ene medewerker gebruikt Dropbox, de andere OneDrive en nog een andere Box (proliferatie diensten).
  • De authenticatiemethodes die door het bedrijf opgelegd worden, worden omzeild. In de plaats maakt de medewerker gebruik van een zelf gekozen en dus potentieel zwak paswoord om toegang te krijgen tot de cloud-dienst.
  • Wanneer een dergelijke account vervolgens gehackt wordt, is de kans groot dat het bedrijf niet op de hoogte zal zijn dat haar gevoelige gegevens gestolen werden of op straat liggen. Misschien moet het dit wel vernemen via de pers. Een degelijke escalatie (procedure na het vaststellen van een security-incident) is dan ook bijzonder moeilijk.
  • Wanneer een werknemer het bedrijf verlaat, heeft het mogelijks nog steeds toegang tot gevoelige bedrijfsgegevens. Misschien loopt de werknemer wel over naar de concurrentie of wil hij op een andere manier wraak nemen voor zijn ontslag.

De Cloud Services Broker

De vraag is dan ook hoe bedrijven en overheden met een dergelijke situatie om kunnen gaan en hoe ze deze cloud-anarchie kunnen ontwapenen. Simpelweg een verbod d.m.v. policies of technologie is natuurlijk een mogelijke aanpak, maar daarmee zijn de behoeften die in het bedrijf wel aanwezig zijn natuurlijk nog niet verdwenen. En het inrichten van een eigen private cloud of community cloud is omwille van praktische en budgetaire redenen dan weer niet steeds mogelijk.

Een mogelijke aanpak is om gebruik te maken van een cloud services broker (CSB), kortweg een broker, wat dus een intermediaire partij is tussen aanbieders van de clouddiensten enerzijds en afnemers van clouddiensten anderzijds. Deze CSB kan in principe beheerd worden door het bedrijf zelf of door een externe partij.

Hierna worden zes verschillende manieren beschreven waarop een dergelijke CSB een positieve impact kan hebben op de security binnen het bedrijf en waarbij nog steeds gebruik gemaakt kan worden van cloud diensten die zich mogelijks in de publieke cloud bevinden.

  • Catalogus. Het bedrijf kan aan haar medewerker via een gekende URL een gebruiksvriendelijke catalogus aanbieden waarop de door het bedrijf ondersteunde diensten opgelijst en beschreven worden. De gebruiker kan vervolgens na een paar kliks gebruikmaken van een ondersteunde dienst. Zo wordt geografische fragmentering tegengegaan, alsook de proliferatie van diensten en wordt compliancy met de security policies van het bedrijf gestimuleerd.
  • (De)provisioning. Een CSB kan instaan voor de provisioning en deprovisioning van gebruikers en diensten. Dit wil zeggen dat de CSB ervoor zorgt dat een nieuwe medewerker direct toegang heeft tot alle cloud-diensten waar hij toegang toe hoort te hebben en dat omgekeerd alle accounts bij de verschillende cloud-diensten onmiddellijk opgeschort worden wanneer een medewerker het bedrijf verlaat, wat de kans op compromitteren van data verkleint.
  • Single sign-on. Een CSB kan single sign-on (SSO) aanbieden zodat de werknemer zich maar één keer hoeft te authenticeren en vervolgens toegang heeft tot alle ondersteunde cloud-diensten, waardoor de werknemer ook sneller geneigd zal zijn om een dergelijke ondersteunde dienst te gebruiken. In combinatie daarmee kan de CSB zorgen voor compliancy met de bedrijfspolicy en voor integratie met de bestaande (LDAP, SAML, etc.) systemen, waardoor een sterke(re) authenticatie en een beter user management mogelijk worden.
  • Archivering. In de context van de sociale zekerheid moeten persoonsgerelateerde gegevens vaak vele tientallen later nog steeds beschikbaar zijn. Een clouddienst biedt typisch geen garanties op een dergelijke termijn. Bovendien kan een cloud-dienst ophouden te bestaan, bijvoorbeeld bij een failissement. In dergelijke gevallen willen we uiteraard onze gegevens niet verliezen. Een CSB is als intermediaire partij ideaal geplaats om een kopie van dergelijke gegevens indien nodig te archiveren, bijvoorbeeld gebruikmakend van opslag binnen het bedrijf zelf. Zo kan een CSB dus de beschikbaarheid van gegevens op lange termijn garanderen.
  • Vercijfering. Misschien wil een bedrijf enerzijds wel gebruik maken van een publieke clouddienst maar wil ze anderzijds toch de confidentialiteit van haar gegevens garanderen. In sommige gevallen kan de CSB instaan voor de encryptie van data vooralleer de data naar de publieke cloud gaat en kan ze in de andere richting zorgen voor de decryptie. Er bestaan oplossingen voor file sync en share diensten zoals Dropbox en voor maildiensten zoals Gmail.
  • Monitoring & reporting. Ten slotte is een CSB als intermediarie partij ideaal geplaats om drie aspecten te monitoren en er eventueel over te rapporteren: data, werknemers en diensten. De CSB houdt bij welke gegevens zich waar in de publieke cloud bevinden, ze volgt de gebruikersactiviteit en verifieert of de cloud-diensten de beloofde SLA’s halen. In geval van een incident heeft de CSB zo heel wat informatie die toelaat doelgericht te interveniëren.

Een CSB kan dus op verschillende vlakken een sterk positieve impact hebben op de security binnen het bedrijf of binnen de overheidsdienst.

CSB Markt en Verwachtingen

Een logische vraag is dan ook hoe een CSB opgezet kan worden. Er zijn diverse bedrijven die daarbij ondersteuning en technologie aanbieden. Dergelijke bedrijven worden doorgaans CSB enablers genoemd. De meest visibele speler op de markt is momenteel Jamcracker, die ondersteuning en technologie biedt vanaf het opzettten van een catalogus tot en met de facturatie.

De markt van CSBs en CSB enablers is in volle expansie. Het marktonderzoeksbedrijf Markets and Markets voorspelde in maart 2013 een jaarlijkse groei van 45% en 55% tot 2018 voor respectievelijk CSBs en CSB enablers. Volgens Gartner zal tegen 2015 minstens 20% van alle clouddiensten via dergelijke CSBs afgenomen worden. Het is een markt die sterk groeit en evolueert, wat ook direct een indicatie van haar onvolwassenheid is.

Een op het eerste zicht valse noot in het hele CSB verhaal is het wantrouwen bij veel overheden, zeker sinds de onthullingen door Snowden, tegenover het gebruik van cloud-diensten waarbij de gegevens juridisch of geografisch buiten de controle van het land vallen. In vele landen zien we dat er gewerkt wordt aan de uitbouw van een eigen nationale cloud. Maar zelfs in zo’n context is er nog steeds een rol weggelegd voor CSBs. De minder gevoelige data kan naar de publieke cloud gaan, terwijl de meer gevoelige data in de nationale cloud hoort te blijven. Voor de diensten in de publieke cloud kan de CSB ten volle zijn rol spelen, maar ook voor diensten in een nationale cloud of een hybride cloud blijven een catalogus, (de)provisioning SSO, monitoring en reporting door de CSB relevant.

CSB verdient dan ook in de komende jaren de nodige aandacht, ook door onze overheden.


Dit artikel is gebaseerd op slides 8 tot 31 van de infosessie "Gevoelige Overheidsdata en de Cloud" die gegeven werd op 3 april 2014. De integrale presentatie kunt u hieronder bekijken. De presentatie met de bijhorende demofilmpjes zijn hier te downloaden.

This entry was posted in Cloud, Security by Kristof Verslype. Bookmark the permalink.
avatar

About Kristof Verslype

Kristof behaalde begin 2011 een doctoraat in de ingenieurswetenschappen aan de KU Leuven. Hij onderzocht hoe privacy m.b.v. cryptografie verbeterd kon worden. Na een klein jaar als postdoctoraal onderzoeker werd hij eind 2011 onderzoeker bij Smals. Zijn huidige domeinen zijn distributed trust, privacy & analytics, blockchain & smart contracts en toegepaste cryptografie. Hij wordt regelmatig gevraagd als spreker. Meer info op www.cryptov.net

Leave a Reply

Your email address will not be published.