Privacy & security in de cloud een verkenning van tools en technieken

Transcriptie

1 Privacy & security in de cloud een verkenning van tools en technieken Project : SURFworks Projectjaar : 2012 Projectmanager : Jocelyn Manderveld Auteur(s) : Wouter Bokhove, Maarten Wegdam Reviewer(s) Opleverdatum : 27 juni 2012 Versie : 1.0 : Joost van Dijk, Jocelyn Manderveld, Marieke de Wit, Bas Zoetekouw, Xander Jansen Samenvatting Dit document beschrijft een verkenning van tools en technieken die de beveiliging en privacy van clouddiensten ondersteunen. Het betreft hier zowel tools en technieken die vandaag de dag al toepasbaar zijn, als onderwerpen die in de (nabije) toekomst relevant kunnen worden. Dit rapport gaat in op onderwerpen als authenticatie, autorisatie en account manaqement. Standaarden spelen hierbij een belangrijk rol. Dit rapport biedt instellingen voor hoger onderwijs en onderzoek handvatten om op een veilige wijze diensten uit de cloud af te nemen Deze publicatie verschijnt onder de Creative Commons licentie Naamsvermelding 3.0 Nederland. Meer informatie over de licentie is te vinden op

2 Colofon Programmalijn Onderdeel Activiteit Deliverable Toegangsrechten Externe partij : Samenwerkingsinfrastructuur : Adoptie : Stimuleren van privacy awareness bij instellingen, gebruikers en service providers : Onderzoek naar tools en methodieken die beveiliging en privacy van publieke clouddiensten verbeteren en ondersteunen (Q2) : Publiek : Novay Dit rapport is tot stand gekomen met steun van SURF, de organisatie die ICT vernieuwingen in het hoger onderwijs en onderzoek initieert, regisseert en stimuleert door onder meer het financieren van projecten. Meer informatie over SURF is te vinden op de website ( 2

3 Factsheet 6 Dingen die je moet weten over Privacy & security in de cloud een verkenning van tools en technieken. Context Wat is het? Het uitbesteden van diensten naar de cloud biedt allerlei risico s rond veiligheid en privacy. Juridische maatregelen dekken een deel van het probleem. Technische maatregelen zijn echter ook mogelijk en noodzakelijk. Een verkenning van tools, technieken en standaarden die de veiligheid en privacy van clouddiensten kunnen ondersteunen. Voor wie is het? Hoe werkt het? Wat kan je ermee? Extra (Bijlagen, Thema, Gerelateerde thema s) Onderwijs- en onderzoekstinstellingen die al dan niet via SURFconext clouddiensten willen afnemen. Hoofdstuk 2 schetst de achtergrond op basis waarvan de focus van deze verkenning wordt gekozen: authenticatie, autorisatie, gebruikersbeheer, services en personal clouds. Deze onderwerpen worden in hoofdstuk 3 beschreven. Hoofdstuk 4 vat de belangrijkste punten samen. Inzicht krijgen in de problemen die het uitbesteden van diensten naar de cloud voor instelling met zich mee kunnen brengen op het gebied van authenticatie, autorisatie en gebruikersbeheer en de tools en technieken en standaarden die door de instelling of de cloud leverancier toegepast kunnen worden om deze problemen op te lossen. 3

4 Inhoud 1 Inleiding Achtergrond Tools, technieken en standaarden Authenticatie Federatieve authenticatie Social login Betrouwbaarheidsniveaus en sterke authenticatie Autorisatie Policies Oplossingen Gebruikersbeheer (De-)Provisioning standaarden Privacy Encryptie Anonieme credentials As-a-Services De volgende generatie: Personal (Storage) Clouds Samenvatting Appendix A. CSA s 14 domains involved in governing or operating the cloud Appendix B. Maturity models, Richtlijnen, Certificaten en Standaarden

5 1 Inleiding Onderwijs- en onderzoeksinstellingen ontdekken de mogelijkheden van cloud computing: studenten maken gebruik van webmail, onderzoekers ontmoeten elkaar op een samenwerkingsplatform, wetenschappelijke data worden gedeeld via opslagruimte in de cloud en administratieve medewerkers houden gegevens bij met een tool in de cloud. Gegevens die in de cloud worden opgeslagen, zijn niet meer onder volledige controle van de instelling. Cloud Computing roept bij veel onderwijsinstellingen de vraag op hoe de beveiliging van gegevens en de bescherming van de privacy geregeld kan worden. Deze vraag kan bekeken worden vanuit juridisch oogpunt, maar instellingen kunnen ook op technisch vlak zaken zelf regelen of eisen van leveranciers van clouddiensten. Dit rapport verkent tools en technieken die de beveiliging van cloud services ondersteunen, met name op het gebied van authenticatie, autorisatie, gebruikersbeheer en privacy. Hierbij wordt een onderscheid gemaakt tussen tools en technieken die op dit moment reeds beschikbaar en toepasbaar zijn en tools en technieken die in de (nabije) toekomst relevant zouden kunnen worden. SURFnet biedt SURFconext aan, een infrastructuur die online samenwerking mogelijk maakt. Via SURFconext zijn allerlei clouddiensten (zoals Google Apps for Education) aangesloten. SURFconext gebruikt diverse van de in dit document beschreven tools en technieken om het voor onderwijsinstellingen mogelijk te maken om op een veiligere en betrouwbaardere manier diensten in de cloud af te nemen. Niet alle clouddiensten zijn echter via SURFconext beschikbaar, en niet alle instellingen maken gebruik van SURFconext. Dit document biedt een overzicht van tools en technieken ten aanzien van beveiliging en privacy waar onderwijsinstellingen rekening mee moeten houden op het moment dat zij een dienst in de cloud afnemen. Deze verkenning geeft de instellingen daarmee handvatten om te bepalen of leveranciers van clouddiensten de benodigde bescherming van gegevens en privacy bieden. Daar waar SURFconext gebruik maakt van de genoemde tools en technieken, wordt dit aangegeven. 5

6 2 Achtergrond Het gebruik maken van clouddiensten heeft allerlei voordelen, zowel voor onderwijsinstellingen als voor studenten, onderzoekers en medewerkers. Deze voordelen zitten vaak in de schaalbaarheid, flexibiliteit, beschikbaarheid en de kosten van cloudiensten. Daar tegenover staat een aantal uitdagingen en onzekerheden, zowel op technisch, operationeel als juridisch vlak. In het SURFnet/Kennisnet Innovatieprogramma Cloud Computing Project zijn veel van deze juridische en operationele uitdagingen beschreven 1. Twee belangrijke aspecten die steeds naar voren komen, zijn de beveiliging van clouddiensten en de mate waarin persoonsgegevens beschermd kunnen worden. Binnen de muren van een onderwijsinstelling worden allerlei maatregelen genomen die ongeautoriseerde toegang tot diensten en (persoonlijke) gegevens moeilijk maken. Zodra deze diensten en de gegevens in de cloud worden geplaatst, moet de instelling erop vertrouwen dat de cloud leverancier middels certificaten, audits door derden en contracten ervoor zorgt dat de gegevens veilig zijn. Naast deze noodzakelijke contractuele maatregelen is het ook nodig om technische maatregelen te nemen. Maatregelen voor de bescherming van gegevens en privacy bij clouddiensten kunnen op een aantal verschillende fronten worden genomen. De Cloud Security Alliance (CSA 2 ) verdeelt Cloud Computing over 14 verschillende domeinen [zie Appendix A] op drie verschillende terreinen: 1. cloudarchitectuur; 2. cloudbeleid en toezicht; 3. operationele zaken. Ook andere organisaties, zoals Microsoft 3, de Duitse BSI 4 (Federal Office for Information Security) en ENISA 5 maken vergelijkbare onderverdelingen in cloud focus gebieden. Binnen het eerder genoemde innovatieprogramma zijn richtlijnen opgesteld over afspraken die met cloud leveranciers gemaakt moeten worden over beleid en toezicht. Binnen het operationele domein komen vanzelfsprekend onderwerpen met betrekking tot digitale identiteiten, toegangscontrole en encryptie aan bod. Dit rapport focust zich op de volgende operationele aspecten, waarbij het onderwerp van digitale identiteiten en toegangscontrole wordt beschreven volgens drie van de vier A s van Cloud Identity 6 : 1. authenticatie; 2. autorisatie; 3. account management; 4. audit logging. De vierde A, Audit logging, blijft grotendeels buiten beschouwing. Appendix B geeft wel een overzicht van enkele voor clouddiensten relevante auditkaders, richtlijnen, standaarden en certificaten Securing Microsoft s Cloud Infrastructure, mei Security Recommendations for Cloud Computing Providers, juni ENISA, cloud computing, 6 Ping Identity, The 4 A s of Cloud Identity, 6

7 Daarbij wordt in de rapport aandacht besteed aan encryptie. Encryptie wordt toegepast om de confidentialiteit en integriteit van gegevens te garanderen en wordt beschreven als onderdeel van de maatregelen die genomen kunnen worden om de privacy van gebruikers te beschermen. Ook de gegevens die in de cloud worden opgeslagen kunnen beschermd worden met behulp van encryptie. Dit rapport besteedt ook aandacht aan de trend dat beveiligingstools zelf als clouddienst afgenomen worden. Tenslotte wordt kort ingegaan op de volgende stap waarin ook de data uit de clouddienst wordt gehaald middels personal clouds, personal data stores, etc. Dit rapport beperkt zich tot het beschrijven van zaken die relevant zijn voor Software-as-a- Service (Saas) die afgenomen wordt uit een publieke cloud. Het rapport gaat dus niet in op de overige cloudleveringsmodellen als Infrastructure-as-a-Service (IaaS) en Platform-as-a- Service (PaaS), of op afnamemodellen, zoals private, hybrid of communityclouds. Er wordt geen onderscheid gemaakt naar de verschillende diensten die een onderwijsinstelling af zou kunnen nemen, zoals beschreven in de Functionaliteitenkaart voor clouddiensten die ontwikkeld is binnen het SURFnet/Kennisnet Innovatieprogramma. 7. Dit rapport is een verkenning, en pretendeert niet compleet of in detail alle tools en technieken te beschrijven. Er is bewust gekozen voor leesbaarheid en bondigheid boven compleetheid of nuance. 7 SURFnet/Kennisnet Innovatieprogramma, Cloud Functionaliteiten, 7

8 3 Tools, technieken en standaarden Dit hoofdstuk beschrijft tools en technieken voor authenticatie, autorisatie, gebruikersbeheer en privacy die de beveiliging en privacy van clouddiensten ondersteunen. Bij elk onderwerp worden de belangrijkste standaarden genoemd en wordt aangegeven of deze nu al beschikbaar en toepasbaar zijn, dan wel mogelijk in de (nabije) toekomst relevant zullen worden. In een enkel geval wordt een standaard beschreven die op dit moment wel beschikbaar is, maar niet meer relevant lijkt te zijn. Instellingen zullen met veel verschillende cloudleveranciers zaken doen. Het is daarom van groot belang dat deze leveranciers allemaal gebruik maken van dezelfde (open) standaarden op het gebied van authenticatie, autorisatie, gebruikersbeheer en privacy. Het gebruik van open standaarden zorgt ervoor dat diensten snel en eenvoudig aangesloten kunnen worden. Ook draagt het gebruik van open standaarden bij aan het voorkomen van een lock-in bij een specifieke cloudprovider. In dit hoofdstuk worden de volgende iconen gebruikt om de relevantie en actualiteit van de verschillende standaarden weer te geven. De term tomorrow moet hierbij breed worden geïnterpreteerd en is zowel van toepassing op onderwerpen die in de nabije toekomst als onderwerpen die in de verdere toekomst relevant worden. De term yesterday wordt gebruikt bij onderwerpen die niet meer actueel zijn of lijken te zijn. Deze indeling is onder andere gebaseerd op de lijst van open standaarden die door het Forum Standaardisatie 8 wordt beheerd en die voor overheidsinstellingen leidend is. De beschreven onderwerpen authenticatie, autorisatie en gebruikersbeheer passen in een concept waarin onderwijsinstellingen gebruik willen maken van diensten in de cloud, maar waarin zij de controle over bepaalde aspecten (zoals authenticatie, autorisatie en gebruikersbeheer) niet bij de cloud leveranciers willen onderbrengen (bijvoorbeeld om efficiëntie-, flexibiliteits-, veiligheids- of privacyredenen). De volgende figuur illustreert het onderbrengen van authenticatie, autorisatie en gebruikersbeheer vanuit de cloud provider bij de instelling

9 Figuur 1. Decentraal (links) en centraal (rechts) beheer van authenticatie, autorisatie en gebruikersbeheer De linker figuur toont de situatie waarin een instelling gebruik maakt van twee clouddiensten. Als beide clouddiensten hun eigen processen organiseren, betekent dat dat op drie verschillende plaatsen toegangsrechten gedefinieerd moeten worden en op drie verschillende plaatsen de gebruikers aangemaakt (en gewijzigd en verwijderd) moeten worden en dat een gebruiker drie verschillende authenticatiemiddelen krijgt om toegang te krijgen tot de verschillende diensten. De rechter figuur toont de situatie waarin deze zaken alleen centraal geregeld worden en de clouddiensten gebruik maken van de processen en systemen van de instelling. 3.1 Authenticatie Voor veel clouddiensten is het noodzakelijk dat bekend is wie de gebruiker is, zodat de dienst aangepast kan worden aan de voorkeur of de rol van de gebruiker. Authenticatie is het proces waarbij gecontroleerd wordt of de gebruiker daadwerkelijk is wie deze zegt te zijn. Een gebruikelijke manier om dit te verifiëren is door een gebruikersnaam en wachtwoord uit te delen aan de gebruiker en deze combinatie te laten opgeven voordat toegang wordt verleend tot de dienst. De authenticatie wordt in dit voorbeeld gebaseerd op wat iemand weet. Authenticatie kan ook plaats vinden op wat iemand heeft (bijvoorbeeld een smartcard) of wat iemand is (bijvoorbeeld gebaseerd op een vingerafdruk). Als een gebruiker voor elke dienst een apart wachtwoord heeft, wordt gesproken van een digitale sleutelbos. Een dergelijke digitale sleutelbos biedt niet alleen een slecht gebruikersgemak, maar is ook onwenselijk vanuit een beveiligingperspectief aangezien dit het hergebruik van wachtwoorden stimuleert, wat weer kan leiden tot onacceptabele beveiligingsrisico s. Als deze gebruikersaccounts door de clouddienst worden beheerd, brengt dit dus niet alleen extra beheerslast (o.a. in de vorm van extra gebruikersbeheer) met zich mee, maar ook extra veiligheids- en privacyrisico s Federatieve authenticatie Een veel gebruikte oplossing om deze authenticatieproblemen te voorkomen is federatieve authenticatie. Door gebruik te maken van een bestaande authenticatie-infrastructuur moeten gebruikers zich met één identiteit kunnen authenticeren voor verschillende diensten, ook in de cloud. 9

10 SURFfederatie De SURFfederatie van SURFnet is opgezet volgens een hub-and-spoke-architectuur waarbij zowel dienstverleners als instellingen aansluiten op de SURFfederatie hub. Deze hub verzorgt de communicatie tussen de dienstverleners en de instellingen waarbij de authenticatie-infrastructuur van de instellingen gebruikt kan worden om toegang te verlenen tot de diensten. Hierdoor hoeven medewerkers en studenten van de instellingen dus niet voor elke dienst een aparte gebruikersnaam en wachtwoord aan te vragen, maar hergebruiken ze hun instellingsaccount op een veilige manier. De SURFfederatie biedt een technische infrastructuur met verschillende koppelvlakken voor federatieve authenticatie: SAML 2.0. WS-Federation en A-Select. De dienst SURFfederatie is onderdeel van SURFconext. De SURFfederatie ondersteunt de mogelijkheid om de authenticatie-infrastructuur van een onderwijsinstelling te hergebruiken (zie kader) en gebruikers zich met hun instellingsidentiteit te laten authenticeren bij verschillende aangesloten cloud leveranciers, die via SURFconext zijn ontsloten. Ook als onderwijsinstellingen clouddiensten willen afnemen die nog niet zijn aangesloten via SURFconext zijn er verschillende mogelijkheden voor federatieve authenticatie. In de eerste plaats kan de onderwijsinstelling de dienstverlener doorverwijzen naar SURFnet om zich aan te sluiten op de SURFconext, maar daarnaast kan de SURFconext (dan wordt alleen SURFfederatie deel gebruikt) ook alleen gebruikt worden voor de authenticatie zonder dat de dienst volledig is aangesloten. Als alternatief kan ook de bestaande authenticatieinfrastructuur van een instelling zelf hergebruikt worden door de dienst te laten koppelen met een koppelvlak voor authenticatie dat door zowel de instelling als de dienstverlener wordt ondersteund. Een federatie maakt niet alleen veilige en gebruikersvriendelijk hergebruik van authenticatiemiddelen mogelijk, maar maakt het ook mogelijk attributen door te geven, bijvoorbeeld de naam en het adres van een student. Federatieve authenticatie opent ook de deur voor SSO (Single Sign On), de mogelijkheid om gebruik te maken van verschillende online diensten zonder opnieuw in te loggen als dit eenmaal is gebeurd. De belangrijkste techniek voor federatieve authenticatie is SAML 2.0 (Security Assertion Markup Language 9 ). Daarnaast kan ook gebruikt worden van socialloginstandaarden, die hieronder besproken worden

11 Google Apps for Education Instellingen die gebruik maken van Google Apps kunnen gebruik maken van federatieve authenticatie op basis van SAML 2.0 om toegang te krijgen tot persoonlijke , documenten en agenda s. Google Apps for Education is één van de clouddiensten die beschikbaar is via SURFconext en waarvoor een instelling dus geen additionele maatregelen hoeft te nemen om gebruik te kunnen maken de bestaande authenticatie-infrastructuur Social login Naast traditionele federatieve authenticatie kan authenticatie ook plaatsvinden op basis van de identiteitsinfrastructuur van sociale netwerken. Er zijn verschillende authenticatieoplossingen in gebruik door de verschillende sociale netwerken. De identiteitsinfrastructuur van Google, Yahoo en Hyves kan gebruikt worden voor authenticatie naar clouddiensten door gebruik te maken van OpenID OpenID is een protocol dat decentrale authenticatie mogelijk maakt. De gebruiker kan met OpenID een bestaand account hergebruiken om toegang te krijgen tot andere diensten. Afhankelijk van de OpenID provider kunnen onder controle van de gebruiker verschillende attributen worden meegegeven tijdens het authenticatieproces. Facebook maakt gebruik van Facebook Connect, een eigen oplossing. Twitter en LinkedIn maken gebruik van OAuth 12 (Open Authorization). OAuth is oorspronkelijk ontwikkeld voor autorisatie, maar is ook zeer goed bruikbaar voor authenticatie Betrouwbaarheidsniveaus en sterke authenticatie Onderwijsinstellingen doen er goed aan om een risicoanalyse uit te voeren om te bepalen welke eisen gesteld moeten worden bij het uitbesteden van diensten in de cloud. Die eisen kunnen invloed hebben op het gewenste niveau van authenticatie. Waar een combinatie van gebruikersnaam en wachtwoord voor toegang tot een HRM-pakket binnen het relatief veilige eigen netwerk van de instelling wellicht voldoende veilig is, kan het voor een clouddienst de voorkeur hebben om meer zekerheid te hebben over de identiteit van de gebruiker en is een twee-factor authenticatie vereist. Ook bij toegang tot clouddiensten vanaf smartphones of tablets moeten wellicht andere eisen gesteld worden aan de (mobiele) authenticatie. Ook de trend dat deze apparaten ook nog eens eigendom van de eindgebruikers zelf zijn (Bring Your Own Device) en de instelling dus geen controle meer heeft over de veiligheid van het apparaat, is relevant voor de authenticatie. Op het gebied van sterke authenticatie heeft OATH 1314 (Initiative for Open Authentication) zich tot doel gesteld om oplossingen te leveren die het mogelijk moet maken dat gebruikers zich op alle apparaten en binnen alle netwerken op een betrouwbare manier kunnen authenticeren middels sterke authenticatie Of de nieuwe versie van OpenID, genaamd OpenID Connect 12 Niet te verwarren met OATH Niet te verwarren met OAuth 11

12 Hiermee kan op een standaard manier bijvoorbeeld een extra of andere factor (bijvoorbeeld iets wat iemand heeft in de vorm van een token) worden geïntroduceerd in het authenticatieproces. tiqr tiqr 1, ontwikkeld door SURFnet en beschikbaar als open source, maakt het mogelijk om zonder codes over te typen toch een extra factor te introduceren in het authenticatieproces. Door tijdens het inlogproces een QR-code te scannen met een smartphone (die wel eerst gekoppeld moet worden aan de gebruiker), te bevestigen dat inderdaad ingelogd gaat worden en door een persoonlijke pincode in te toetsen, wordt meer zekerheid verkregen over de identiteit van de gebruiker (de gebruiker heeft namelijk toegang tot de mobiele telefoon en kent de pincode). tiqr maakt onder andere gebruik van OATH Autorisatie Autorisatie behelst het bepalen wat een gebruiker binnen een applicatie of dienst allemaal wel en niet mag doen. Om de privacy en de veiligheid te beschermen is het van belang dat de toegangsrechten dusdanig kunnen worden gedefinieerd dat gebruikers gedurende de kortst mogelijke tijd zo min mogelijk rechten hebben om hun taak uit te voeren (least privilege). Hiervoor moet het mogelijk zijn om gedetailleerde policies op te stellen. Een ander principe relevant voor de beveiliging van clouddiensten en de privacy van betrokkenen is functiescheiding (separation/segregation of duties). Autorisaties kunnen op verschillende niveaus worden bekeken: op hoog niveau kunnen policies beschreven worden die bepalen wie wanneer waar toegang toe krijgt. Op laag niveau kan beschreven worden hoe deze policies kunnen worden geïmplementeerd en toegepast Policies Aangezien het niet schaalbaar is om voor elke clouddienst opnieuw policies te definiëren, is het handig als beslissingen over autorisaties centraal (buiten deze clouddienst) gedefinieerd of gehandhaafd kunnen worden. Om het beheer van toegangsrechten te vereenvoudigen worden autorisaties vaak niet direct aan gebruikers gekoppeld, maar worden policies gedefinieerd. Policies worden soms gedefinieerd op basis van rollen, waarbij autorisaties gekoppeld worden aan een bepaalde functionele rol binnen de instelling (RBAC; Role Based Access Control). Binnen federatieve omgevingen worden policies vaak op basis van attributen gedefinieerd (ABAC; Attribute Based Access Control), waarbij autorisaties worden verleend op basis van bepaalde kenmerken. Het definiëren van rollen, zoals in RBAC, maakt het aan de ene kant mogelijk om makkelijker functiescheiding en het principe van least privilege te implementeren en dus de veiligheid te vergroten. Aan de andere kant blijkt RBAC te leiden tot interoperabiliteits- en beheersproblemen: rollen kunnen in verschillende domeinen, tussen en binnen bedrijven, afdelingen of toepassingen een andere betekenis hebben. Doordat functies binnen een organisatie vaak slecht gedefinieerd en afgebakend zijn, neemt het aantal rollen snel toe. 15 SURFnet, Federated Authorisation and Group Management in e-science,

13 ABAC is daarentegen minder statisch en laat het toe om op een dynamische manier autorisaties te definiëren op basis van attributen. Attributen kunnen eenvoudiger worden hergebruikt bij verschillende clouddiensten, maar vereisen wel een bepaalde betrouwbaarheid van deze attributen. SURFfederatie Binnen de SURFfederatie zijn afspraken gemaakt over de semantiek en het gebruik van attributen en wordt de eduperson-standaard gebruikt. Op basis van deze attributen (is de gebruiker student of medewerker? Bij welke instelling zit deze gebruiker?) kunnen autorisatiebeslissingen worden genomen Oplossingen Voor de technische implementatie van het communiceren van policies en autorisatiebeslissingen in de cloud bestaan verschillende standaarden 16. XACML 17 (extensible Access Control Markup Language) is een OASIS standaard die ontwikkeld is als taal om policies voor toegangscontrole te beschrijven en als protocol voor beslissingen over toegang. SAML (Security Assertion Markup Language) kan gebruikt worden om XACML berichten te transporteren. XACML wordt nog op beperkte schaal gebruikt, maar het gebruik en de volwassenheid lijken toe te nemen. SAML zelf kan ook gebruikt worden om tijdens het authenticatieproces attributen uit te wisselen, op basis waarvan de applicatie autorisatiebeslissingen kan nemen. De gebruiker kan met behulp van OAuth 1819 toegangstokens verstrekken aan clouddiensten, waarmee toegang tot API s kan worden verkregen. Met behulp van deze API s worden vervolgens gegevens opgehaald. De toegangstokens geven toegang tot specifieke API s en zijn slechts voor beperkte tijd geldig en kunnen ook door de gebruiker zelf worden ingetrokken. SURFconext SURFconext is ontwikkeld op basis van open standaarden, waaronder SAML en OpenSocial. Om toegang te krijgen tot de API van SURFconext maakt een clouddienst ook gebruik van OAuth. De gebruiker wordt gevraagd om toestemming te geven en weet welke informatie door de dienst opgevraagd kan worden. Het gaat hier onder andere om de volgende attributen: voornaam, achternaam, adres, user-id en (onderwijs)instelling. 16 SURFnet, Federated Authorisation and Group Management in e-science, Niet te verwarren met OATH (zie sectie 3.1.3) 13

14 LinkedIn Om nieuwe connecties toe te voegen aan LinkedIn kan gebruik worden gemaakt van de functionaliteit waarbij een gebruiker kan kijken of mensen met wie al eens per contact is geweest ook lid zijn van deze netwerksite. De traditionele wijze om dit te doen is een export te doen van contactgegevens uit de client en vervolgens een import van die gegevens in LinkedIn, danwel door de logingegevens voor de te delen met het desbetreffende sociale netwerk. Er is echter ook een methode die gebruik maakt van OAuth. Deze is handiger en veiliger. Middels OAuth kan LinkedIn (tijdelijk) toegang krijgen tot de contactgegevens van de webmail (bijvoorbeeld Gmail) zonder dat de inloggegevens voor Gmail worden gedeeld met LinkedIn en zonder dat LinkedIn toegang krijgt tot , agenda of andere gegevens die aan dit account zijn verbonden. Bouwend op OAuth (versie 2) maakt UMA (User Managed Access 20 ) het mogelijk om de daadwerkelijke autorisatiebeslissing te centraliseren bij een derde partij die de gebruiker hiervoor heeft gekozen. Dit zorgt ervoor dat de autorisatie niet meer gefragmenteerd is over de vele cloud providers waar een gebruiker mee te maken heeft. Als een gebruiker een bepaalde partij niet meer vertrouwt, kan deze op één plek alle autorisaties intrekken die in verleden aan die partij gegeven zijn. 3.3 Gebruikersbeheer Een belangrijk aspect van het werken in de cloud is het beheer van gebruikers en gebruikersgroepen. Met name het toevoegen van nieuwe gebruikers (provisioning) en het verwijderen van oude gebruikers (deprovisioning) kan voor beheerders een groot probleem opleveren als dit niet op een gestandaardiseerde manier gedaan wordt. Het proces van (de)provisioning is erg gecompliceerd doordat informatie over gebruikers (in de vorm van attributen) door verschillende diensten anders wordt opgeslagen. Ook ontbreekt het aan (het gebruik van) standaarden om deze attributen uit te wisselen. Deze attributen zijn ook niet statisch, maar kunnen veranderen op het moment dat een gebruiker een andere rol krijgt, in een ander team komt te werken of zelfs verandert van werkgever. Elke verandering kan leiden tot een wijziging van de rechten van een gebruiker voor wat betreft het gebruik maken van een clouddienst. Hierbij is het belangrijk te beseffen dat gebruikers nieuwe rechten kunnen krijgen, maar ook bestaande rechten moeten kunnen inleveren. Vanuit het oogpunt van de veiligheid en privacy is het verwijderen van (rechten van) gebruikers belangrijker dan het toevoegen daarvan, omdat gebruikers die geen rechten hebben nu eenmaal geen toegang hebben tot persoonlijke gegevens en weinig schade kunnen toebrengen. Het is daarom van groot belang dat attributen op een eenvoudige wijze up-to-date gehouden kunnen worden. Voor deprovisioning is het overigens niet triviaal welke actie ondernomen moet worden op het moment dat een gebruiker wordt verwijderd uit een bronbestand: bij sommige diensten kan de gebruiker inclusief alle opgeslagen gegevens van deze gebruiker volledig worden verwijderd, terwijl in andere gevallen de data moet blijven bestaan, maar de gebruiker daar geen toegang meer toe mag hebben (of misschien wel toegang, maar geen schrijfrechten)

15 3.3.1 (De-)Provisioning standaarden Voor de (de-)provisioning van gebruikers bestaat een aantal standaarden 21. Daarnaast is er ook een aantal grote cloud leveranciers die eigen oplossingen hebben gedefinieerd. De laatste versie van SPML 22 (OASIS Service Provision Markup Language), versie 2.0, is een open standaard opgesteld in 2006 en expliciet bedoeld voor het uitwisselen van gebruikers informatie tussen organisaties. Ondanks het feit dat SPML jarenlang de enige open standaard op dit gebied is geweest, is SPML nooit een groot succes geworden en zal dat nu waarschijnlijk ook niet meer worden. De (vermeende) complexiteit van de standaard en het gebrek aan producten die de standaard geïmplementeerd hebben, zijn hier mede debet aan. Een recente ontwikkeling op het gebied van provisioning is SCIM (Simple Cloud Identity Management 23 ), een standaard die gesteund wordt door onder andere cloud leveranciers (Google, SalesForce.com, VMWare, Cisco) en software leveranciers (Cisco, Ping Identity). Deze standaard is gericht op het reduceren van kosten en complexiteit en het voorbouwen op bestaande protocollen. SCIM heeft als doel om gebruikers snel, goedkoop en eenvoudig in, uit en tussen clouddiensten te brengen. Op dit moment zijn de eerste interoperabiliteitstesten (op basis van versie 1.0 van de specificatie) tussen verschillende partijen achter de rug. Deze testen hebben veel verbeterpunten opgevelverd die in de komende tijd worden verwerkt. Het lijkt er echter op dat SCIM een standaard is geworden om rekening mee te houden. Terwijl Google en SalesForce.com zich actief bezig houden met de ontwikkeling van SCIM hebben beide reuzen ook nog hun eigen oplossing voor provisioning. Ook SAML, OpenID en OAuth kunnen gebruikt worden voor de provisioning. Zo bevatten de informatie verkregen uit SAML-authenticaties (zie sectie 3.1.1) vaak voldoende attributen om (just-in-time) provisioning (en autorisatie) te verzorgen. Daarnaast is het met SAML ook mogelijk om deze attributen los van de authenticatie apart op te vragen. Ook OAuth (zie sectie 3.1.1) kan gebruikt worden om een API bedoeld voor provisioning te implementeren. Het is afhankelijk van de specifieke clouddienst of provisioning via bovenstaande manier kan werken. 21 Provisioning scenarios in identity federations, SURFnet, juli Hernoemd (31 mei 2012) door de IETF naar 15

16 Filesender Filesender 1 is een dienst waarmee gebruikers (grote) bestanden kunnen versturen naar andere gebruikers. Om gebruik te maken van deze dienst moeten gebruikers wel geauthentiseerd worden. SURFnet heeft deze dienst experimenteel beschikbaar gemaakt waarbij de SURFfederatie gebruikt kan worden voor de authenticatie 2. De provisioning gebeurt hier just-in-time. Oftewel tijdens de authenticatie wordt met behulp van SAML de benodigde attributen opgevraagd om een nieuw account aan te maken. Deprovisioning vindt automatisch plaats na verloop van tijd. Als deze dienst via SURFconext wordt gebruikt, moet de gebruiker eerst toestemming geven, voordat de attributen die door de instelling worden beheerd, vrijgegeven worden aan de dienst. Als deze toestemming niet wordt gegeven, kan de gebruiker geen gebruik maken van de dienst Naast de reeds genoemde methoden voor provisioning bestaat natuurlijk ook nog de meer traditionele oplossing die gebaseerd is op een centraal register (of directory) met identiteiten en bijbehorende attributen: LDAP (Light-Weight Directory Access Protocol) en de XML variant DSML 24 (Directory Service Markup Language). Deze methode gaat ervan uit dat clouddiensten rechtstreeks toegang hebben tot zo n register en de relevante informatie over gebruikers. Deze methode heeft wel enkele schaalbaarheids- en veiligheidsproblemen. Als de LDAPserver slecht of niet beschikbaar is, heeft dit direct impact op de aangesloten clouddiensten. Bovendien vereist het gebruik van een LDAP-server voor clouddiensten goede afspraken over schema s en hiërarchieën, en meer vertrouwen in de cloud provider dan bovenstaande methodes. Ten slotte zal de verbinding met en de toegang tot de LDAP-server goed beveiligd moeten worden, waarbij het geen triviale taak is om dit voor ieder van de aangesloten clouddiensten in te stellen en te onderhouden. Zoals in de introductie van deze paragraaf geschreven, is vanuit veiligheidsoogpunt deprovisioning belangrijker dan provisioning, omdat gebruikers zonder rechten nu eenmaal minder schade kunnen berokkenen dan gebruikers die om wat reden dan ook eigenlijk geen toegang meer zouden mogen hebben tot gegevens. LDAP, SAML, OpenID en OAuth bieden helaas geen goede oplossing voor het deprovisionen van gebruikers. SPML en SCIM 25 ondersteunen wel deprovisioning. Een gerelateerd onderwerp is dataretentie. Als een gebruiker wordt verwijderd en daarmee ook de gegevens die over een gebruiker door de clouddienst zijn opgeslagen verwijderd mogen (of moeten) worden, moet de cloud leverancier een oplossing beschikbaar hebben die deze informatie ook verwijdert uit back-ups. Hetzelfde geldt overigens voor gegevens die door een gebruiker verwijderd worden

17 Google Apps for education Een onderwijsinstelling die aan wil sluiten bij Google Apps kan met behulp van de applicatie Google Apps Directory Sync (GADS) gebruikers toevoegen, aanpassen en verwijderen op basis van een LDAP-directory. GADS zorgt ervoor dat aanpassingen in de LDAP-directory automatisch worden doorgevoerd voor Google Apps. Dat wil zeggen dat nieuwe gebruikers binnen een instelling automatisch worden aangemaakt als gebruiker van Google Apps, wijzigingen automatisch worden doorgevoerd en verwijderde medewerkers geen toegang meer hebben tot Google Apps of zelfs dat alle gegevens van een uit de LDAP verwijderde medewerker direct worden verwijderd. GADS biedt tevens de mogelijkheid om attributen te synchroniseren en biedt daarvoor ook een tool om attributen te mappen. 3.4 Privacy Een goede schriftelijke overeenkomst 26 met de leverancier van een clouddienst kan de zorg voor privacyproblemen voor een deel al wegnemen. Daarnaast kan een goed proces rond gebruikersbeheer, authenticatie en autorisatie ervoor zorgen dat persoonlijke informatie niet toegankelijk is voor onbevoegden. Het kan echter noodzakelijk zijn om nog additionele maatregelen te nemen, bijvoorbeeld door het versleutelen van (persoonlijke) gegevens of door gebruik te maken van anonimisatie of pseudonomisatie. Het is goed om te beseffen dat het zowel kan gaan om de bescherming van de privacy van de gebruikers van de clouddiensten (bijvoorbeeld bij het gebruik maken van Gmail) als om de bescherming van de privacy van personen van wie informatie door een clouddienst wordt opgeslagen of verwerkt (bijvoorbeeld bij het gebruik maken van SalesForce.com) Encryptie Versleuteling van gegevens heeft als doel de confidentialiteit en integriteit van gegevens te borgen. Bij de versleuteling van gegevens zijn drie fasen relevant: 1. De versleuteling van gegevens tijdens transport (van de gebruiker naar de clouddienst en omgekeerd of tussen twee clouddiensten) 2. De versleuteling van gegevens bij de clouddienst 3. De versleuteling van gegevens tijdens de bewerking door de clouddienst. De versleuteling van gegevens tijdens het transport is voor gevoelige (persoonlijke) gegevens altijd belangrijk, maar versleuteling bij de clouddienst en tijdens de verwerking van gegevens is gecompliceerder, bijvoorbeeld als andere clouddiensten gebruik moeten maken van de opgeslagen gegevens of als er gecompliceerde bewerking uitgevoerd moeten worden met de opgeslagen gegevens. 26 Cloud Computing & Privacy : Checklist privacy afspraken, SURFnet/Kennisnet innovatieprogramma Cloud Computing,

18 De internetverbinding waarover (persoonlijke) gegevens van of naar een clouddienst worden gecommuniceerd moet altijd beschermd worden om te voorkomen dat kwaadaardige software de gegevens onderschept, tijdens het transport aanpast of kan doen alsof het zelf de verzender is. TLS 27 (Transport Layer Security) is de opvolger van SSL 28 (Secure Socket Layers). TLS maakt meestal gebruik van certificaten gebaseerd op PKI (Public Key Infrastructure), waarbij een certificaatautoriteit de certificaten uitgeeft en beheert. TLS verzorgt op deze manier een veilig communicatiekanaal. Daarnaast kunnen de gegevens die over dit kanaal worden gecommuniceerd ook zelf versleuteld worden. Hiervoor is een voldoende sterke versleuteling nodig, bijvoorbeeld AES Versleuteling moet in ieder geval altijd plaatsvinden volgens open, gevalideerde methoden. Eigen methoden moeten worden vermeden. Voor zover de toepassing het toestaat, is versleuteling van de gegevens die worden opgeslagen bij de clouddienst ook aan te bevelen. Deze versleuteling kan enerzijds gedaan worden door de clouddienst en anderzijds door de gebruiker zelf. Als de gebruiker de gegevens zelf versleuteld én de sleutel zelf beheert, kan alleen de gebruiker toegang krijgen tot de onversleutelde gegevens. Als de versleuteling door de clouddiensten wordt uitgevoerd, heeft deze dienst vaak ook toegang tot de sleutels. Dit zorgt ervoor dat er een risico blijft bestaan dat beheerders van de clouddienst (of hackers) toegang krijgen tot de opgeslagen gegevens. Functiescheiding is hier een voorwaarde: (super) gebruikers die toegang hebben tot encryptiesleutels moeten geen toegang hebben tot de gegevens, waarop deze sleutels van toepassing zijn. Dit geldt zowel voor de beheerders van de clouddienst als voor de beheerders van de onderwijsinstelling die de clouddienst gebruiken. Een ander aspect van sleutelbeheer zijn de gevolgen van het verlies van sleutels. In dat geval zijn vaak ook de beschermde gegevens niet meer toegankelijk. Sleutelbeheer is een belangrijk onderdeel van de encryptie. Voor clouddiensten die gegevens moeten bewerken, is het meestal niet mogelijk om de gegevens versleuteld op te slaan. Er zijn echter wel alternatieven die de privacy van betrokkenen kunnen beschermen: Middels integratie van een publieke cloud met een private cloud kan ervoor gezorgd worden dat de gevoelige informatie in de private cloud wordt opgeslagen, terwijl de publieke cloud alleen een referentie naar deze gegevens bevat. Als de clouddienst voldoende fijnmazige toegangscontrole toelaat, kan door functiescheiding worden voorkomen dat gebruikers ongewenst toegang krijgen tot teveel informatie. Hiervoor is het natuurlijk ook noodzakelijk om persoonlijke gegevens te scheiden van de overige inhoud. Door het anonimiseren (of pseudonimiseren) van persoonlijke gegevens wordt de privacygevoeligheid van de gegevens beperkt en daarmee de privacy van betrokkenen beter beschermd

19 Overigens is het voor de bescherming van de privacy niet alleen noodzakelijk om de (persoonlijke) gegevens goed te versleutelen, maar moeten ook logbestanden, metagegevens, tijdelijke bestanden en back-ups worden versleuteld en waar mogelijk geanonimiseerd worden door de clouddienst. Dropbox in combinatie met TrueCrypt Dropbox was de eerste veelgebruikte clouddienst waarmee gebruikers bestanden in de cloud kunnen opslaan en delen. Dropbox slaat bestanden echter niet versleuteld op, waardoor het voor medewerkers 1 en bij een incident in 2011 onbekenden 2 ook toegang hebben tot deze gegevens. Dropbox kan echter ook gebruikt worden in combinatie met TrueCrypt 3, een gratis open-source encryptie oplossing, die bestanden of folders on-the-fly versleutelt. Door zo n versleutelde folder in de Dropbox te plaatsen, wordt het beveiligingsprobleem opgelost, maar is het niet meer mogelijk om op individuele basis bestanden uit deze versleutelde folder te delen met anderen. Er verschijnen de laatste tijd steeds meer oplossingen die net als Dropbox cloud opslag aanbieden, maar waarbij de gegevens standaard versleuteld worden Filesender Filesender (zie ook sectie 3.3.1) kan gebruikt worden om (grote) bestanden te versturen van de ene gebruiker naar de andere gebruiker. Tijdens het transport kunnen deze bestanden beveiligd worden door gebruik te maken van TLS/SSL, maar om de gegevens optimaal te beschermen zal de gebruiker de bestanden vooraf moeten versleutelen (met bijvoorbeeld TrueCrypt). Als de ontvangende partij de juiste sleutel heeft, kan deze de bestanden achteraf weer ontcijferen. Een versleutelfunctionaliteit is overigens wel gepland voor een toekomstige versie. Nieuwe ontwikkelingen op het gebied van encryptie maken het mogelijk om in versleutelde gegevens te zoeken (searchable encryption) of zelfs bewerkingen uit te voeren met versleutelde gegevens (homomorphic encryption) Anonieme credentials Zoals beschreven in de vorige paragraaf kan anonimisatie van gegevens gebruikt worden om de privacy te beschermen van betrokkenen, bijvoorbeeld van studenten in een studentenadministratie. Daarnaast kan anonimisatie ook gebruikt worden om anoniem toegang te krijgen tot gegevens en zo de privacy van de gebruiker te beschermen. Met behulp van anonieme credentials kan een gebruiker toegang krijgen zonder z n identiteit vrij te geven. Idemix 29 en U-Prove 30 zijn de twee belangrijkste technieken om anonieme credentials te realiseren waarbij, met behulp van IBM s Idemix bewezen kan worden dat er credential is zonder deze te laten zien en met behulp van Microsofts U-Prove telkens een nieuw credential wordt gebruikt

20 Beide oplossingen hebben voor- en nadelen 31 op het gebied van privacy en performance. De huidige toepasbaarheid van beide standaarden is nog beperkt. Stemmen Anonieme credentials kunnen bijvoorbeeld goed worden gebruikt bij het uitvoeren van een anonieme stemming in de cloud. In een dergelijk scenario is het belangrijk om te weten dat iemand niet al eens eerder heeft gestemd, maar aan de andere kant is het van belang dat niet bekend is (of kan worden) wie waarop heeft gestemd. Anonieme credentials kunnen hier goed voor zorgen. 3.5 As-a-Services Behalve het afnemen van diensten in de cloud is het ook mogelijk om de veiligheid en privacy van clouddiensten te ondersteunen door andere clouddiensten te gebruiken. Het gaat hier om onderwerpen, zoals beschreven in de eerdere paragrafen van dit rapport die zelf als clouddienst worden aangeboden, zoals Identity-as-a-Service. De volgende figuur geeft weer hoe de situatie er uit zou zien als clouddiensten gebruik maken van een centrale authenticatie, autorisatie en accountmanagement oplossing, die zelf als clouddienst aangeboden wordt. In de praktijk zal dit wellicht door verschillende clouddiensten gedaan kunnen worden. Figuur 2. Authenticatie, autorisatie en gebruikersbeheer-as-a-service Gartner 32 voorspelt een sterke toename van dergelijke cloud-gebaseerde diensten, maar laat tevens zien dat deze diensten op dit moment nog maar beperkt beschikbaar zijn. Beveiligingstools die nu wel al afgenomen worden als dienst in de cloud zijn onder andere gateways die e- mail en webverkeer beveiligen door middel van malwaredetectie en spamfilters en diensten die kwetsbaarheden in het netwerk detecteren en bescherming bieden tegen DDoS-aanvallen. Security-as-a-Service (SecaaS) is een term die gebruikt wordt voor clouddiensten die zich richten op de veiligheid van clouddiensten en de gegevens die in de cloud worden opgeslagen, bijvoorbeeld in de vorm van een virusscanner of spamfilter. SecaaS kent vele mogelijke verschijningsvormen, bijvoorbeeld op het gebied van identiteiten en toegangscontrole, weben beveiliging, encryptie en netwerkbeveiliging. Identity-as-a-Service (IDaaS) is de naam voor een dienst die het proces van het beheren van identiteiten en het authenticeren van gebruikers op zich neemt. Voorbeelden van dienst- 31 Zie en 32 The Growing Adoption of Cloud-Based Security Services, Gartner, 3 mei