Privacy & security in de cloud – een verkenning van tools en technieken Project Projectjaar Projectmanager Auteur(s) Reviewer(s) Opleverdatum Versie
: SURFworks : 2012 : Jocelyn Manderveld : Wouter Bokhove, Maarten Wegdam : Joost van Dijk, Jocelyn Manderveld, Marieke de Wit, Bas Zoetekouw, Xander Jansen : 27 juni 2012 : 1.0
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 http://creativecommons.org/licenses/by/3.0/nl/
Colofon Programmalijn Onderdeel Activiteit Deliverable Toegangsrechten Externe partij
: Samenwerkingsinfrastructuur : Adoptie : 650 - 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 (www.surf.nl).
2
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?
Onderwijs- en onderzoekstinstellingen die al dan niet via SURFconext clouddiensten willen afnemen.
Hoe werkt het?
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.
Wat kan je ermee?
Extra (Bijlagen, Thema, Gerelateerde thema’s)
3
Inhoud 1
Inleiding ............................................................................................................................... 5
2
Achtergrond .......................................................................................................................... 6
3
Tools, technieken en standaarden ......................................................................................... 8 3.1
Authenticatie ................................................................................................................. 9
3.1.1
Federatieve authenticatie ........................................................................................ 9
3.1.2
Social login ........................................................................................................... 11
3.1.3
Betrouwbaarheidsniveaus en sterke authenticatie ................................................ 11
3.2
Autorisatie ................................................................................................................... 12
3.2.1
Policies ................................................................................................................. 12
3.2.2
Oplossingen .......................................................................................................... 13
3.3
Gebruikersbeheer ........................................................................................................ 14
3.3.1 3.4
4
(De-)Provisioning standaarden ............................................................................. 15
Privacy ......................................................................................................................... 17
3.4.1
Encryptie .............................................................................................................. 17
3.4.2
Anonieme credentials ........................................................................................... 19
3.5
As-a-Services .............................................................................................................. 20
3.6
De volgende generatie: Personal (Storage) Clouds ..................................................... 21
Samenvatting ...................................................................................................................... 24
Appendix A. CSA’s 14 domains involved in governing or operating the cloud...................... 25 Appendix B. Maturity models, Richtlijnen, Certificaten en Standaarden ................................ 26
4
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
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 Identity6: 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. 1
http://www.surfsites.nl/cloud/ https://cloudsecurityalliance.org/research/security-guidance/ 3 “Securing Microsoft’s Cloud Infrastructure”, mei 2009 4 “Security Recommendations for Cloud Computing Providers”, juni 2011 5 ENISA, cloud computing, http://www.enisa.europa.eu/activities/application-security/cloud-computing 6 Ping Identity, The 4 A’s of Cloud Identity, https://www.pingidentity.com/resource-center/authenticationauthorization-audit-logging-account-management.cfm 2
6
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-aService (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-aService (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, http://www.surfnetkennisnetproject.nl/innovatie/cloudcomputing/cloudfunctionaliteiten
7
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.
8
http://www.forumstandaardisatie.nl/open-standaarden/lijst-new/welke-standaarden/
8
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.
3.1.1 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
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 e-mailadres 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.
9
http://saml.xml.org/
10
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 e-mail, 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.
3.1.2 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 1011. 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.
3.1.3 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.
10
http://openid.net/ Of de nieuwe versie van OpenID, genaamd OpenID Connect 12 Niet te verwarren met OATH 13 http://www.openauthentication.org/ 14 Niet te verwarren met OAuth 11
11
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 tiqr1, 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. 1
http://tiqr.org/
3.2 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 15.
3.2.1 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”, 2010
12
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.
3.2.2 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, e-mailadres, user-id en (onderwijs)instelling.
16
SURFnet, “Federated Authorisation and Group Management in e-Science”, 2010 https://www.oasis-open.org/committees/xacml 18 http://oauth.net/ 19 Niet te verwarren met OATH (zie sectie 3.1.3) 17
13
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 e-mail 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 e-mailclient en vervolgens een import van die gegevens in LinkedIn, danwel door de logingegevens voor de email 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 e-mail, 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). 20
http://tinyurl.com/umawg
14
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 2010 http://www.oasis-open.org/committees/provision 23 Hernoemd (31 mei 2012) door de IETF naar 22
15
Filesender Filesender1 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 authenticatie2. 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. 1 2
http://www.filesender.org https://filesender.surfnet.nl
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.
24 25
http://www.oasis-open.org/committees/dsml http://www.simplecloud.info/
16
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).
3.4.1 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, 2011
17
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 AES256. 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.
27 28
http://datatracker.ietf.org/wg/tls/charter/ http://datatracker.ietf.org/doc/rfc6101/
18
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 medewerkers1 en – bij een incident in 2011 – onbekenden2 ook toegang hebben tot deze gegevens. Dropbox kan echter ook gebruikt worden in combinatie met TrueCrypt3, 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. 1
http://www.makeuseof.com/tag/dropbox-accused-lying-users-data-security-news/ http://www.makeuseof.com/tag/dropbox-accidently-drops-passwords-hours-news/ 3 http://www.truecrypt.org/ 2
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).
3.4.2 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.
29 30
http://www.zurich.ibm.com/security/idemix/ http://research.microsoft.com/en-us/projects/u-prove/
19
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 email 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 e-mailbeveiliging, 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 dienst31
Zie http://pomcor.com/2011/10/10/pros-and-cons-of-idemix-for-nstic/ en http://pomcor.com/2011/10/04/prosand-cons-of-u-prove-for-nstic/ 32 “The Growing Adoption of Cloud-Based Security Services”, Gartner, 3 mei 2012
20
verleners die deze dienst aanbieden zijn iWelcome en Digidentity. Ook providers van sociale logins (vaak gebaseerd op OpenID of OAuth), zoals Google, Facebook en Hyves kunnen gezien worden als Identity-as-a-Service providers, hoewel de betrouwbaarheid van de identiteiten beperkt is (dat wil zeggen, er is weinig zekerheid over de identiteit van de gebruiker die geauthentiseerd wordt) en dus eigenlijk over Authentication-as-a-Service gesproken zou moeten worden. Key-management-as-a-Service neemt een belangrijke zorg uit handen op het gebied van versleuteling, namelijk het beheer van de sleutels. Als de versleuteling in de cloud wordt uitgevoerd, is het verstandig om het sleutelbeheer daar niet plaats te laten vinden. Het zelf beheren van sleutels levert voor een instelling echter ook nieuwe uitdagingen op om dit op een voldoende veilige manier uit te voeren. Er zijn echter ook cloudleveranciers die diensten aanbieden om deze zorg uit handen te nemen. Porticor is één voorbeeld van een dienstverleners die Keymanagement als een clouddienst aanbiedt. Voor het ontsleutelen van gegevens die in de cloud zijn opgeslagen, maakt het gebruik van een hoofdsleutel die in het bezit is van een beheerder en sleutels per dataobject die door de dienst van Porticor worden beheerd. Homomorphische versleuteling zorgt ervoor dat de hoofdsleutel ook tijdens het gebruik niet ontcijferd of gestolen kan worden. Door diensten ten behoeve van security en privacy uit te besteden aan de cloud worden instellingen verder ontzorgd van de complexe problemen. Een cloudgebaseerde dienst kan email- en internetverkeer filteren op spam, phishing e-mails, virussen en malware en er zo voor zorgen dat beveiligingsrisico’s worden beperkt. Instellingen hoeven zich op deze manier geen zorgen meer te maken over het up-to-date zijn van virusdefinities of het feit dat gebruikers de lokale beveilingsmaatregelen omzeilen.
Spotify met Facebook Spotify is een clouddienst gebruikers toegang geeft tot muziek en (eigen) afspeellijsten en die het mogelijk maakt deze muziek en lijsten te delen met vrienden. Spotify heeft besloten om geen eigen identiteiten te beheren, maar volledig gebruik te maken van de identiteiten die Facebook als dienst beschikbaar stelt. Facebook wordt hier dus gebruikt als Identity-as-a-Service provider.
3.6 De volgende generatie: Personal (Storage) Clouds Bij de huidige generatie clouddiensten (SaaS) wordt software als een dienst aangeboden en kan deze software data verwerken die binnen deze dienst beschikbaar wordt gemaakt. Er is een ontwikkeling die het mogelijk maakt dat de data niet meer door de cloud leverancier worden beheerd, maar dat de gebruiker (of de onderwijsinstelling) zelf kiest waar de data worden beheerd. De volgende figuren tonen dit schematisch aan, waarbij de data overigens ook bij de instelling (of gebruiker) zelf kunnen staan.
21
Figuur 3. Gegevens worden opgeslagen bij de clouddienst
Figuur 4. Gegevens worden opgeslagen onder controle van de instelling / gebruiker
Met de introductie van Data Vaults zoals Dropbox, Microsoft Skydrive, Apple iCloud, Acers AcerCloud en recent Google Drive kunnen gebruikers toegang krijgen tot hun persoonlijke bestanden die in de cloud staan. Deze oplossingen zijn dus feitelijk implementaties van de Personal (Storage) Cloud. Gebruikers kunnen hun persoonlijke bestanden zelf beheren en in sommige gevallen anderen toegang verlenen tot deze bestanden. Uitdagingen van de publieke cloud (zoals beschreven in dit rapport) zijn zeker van toepassing op de persoonlijke cloud en oplossingen zijn nog minder beschikbaar. Personal Data Stores zijn vergelijkbaar met een Personal Cloud en hebben betrekking op de opslag, het beheer en het delen van persoonlijke gegevens. Het is ook mogelijk om clouddiensten te koppelen aan de personal cloud 33. Gebruikers van de personal cloud kunnen dan expliciet toegang verlenen aan deze diensten tot bepaalde (persoonlijke) gegevens die opgeslagen zijn binnen een personal data store. De dienst mag deze data verwerken (maar niet opslaan) en de resultaten terugkoppelen aan de gebruiker. Op deze manier houdt de gebruiker de volledige controle over z’n persoonlijke gegevens (als de personal data store en de clouddienst tenminste te vertrouwen zijn).
33
Door Kuppinger Cole wordt zo’n platform een Life Management Platform genoemd.
22
Unhosted Unhosted1 biedt een platform, waarin webapplicaties en de data die ze nodig hebben en gebruiken gescheiden worden. Zo wordt het mogelijk om als gebruiker zelf aan te geven welke databron gebruikt moet worden bij een bepaalde dienst. Diensten kunnen transparant gebruik maken van de opslagruimte die door de gebruiker wordt aangewezen. De opslagruimte kan geleverd worden door cloud providers, maar instellingen (of gebruikers) kunnen ook hun bestaande opslagruimte geschikt maken voor Unhostedtoepassingen. SURFnet voert een pilot uit met Unhosted. Binnen deze pilot wordt een clouddienst gebruikt waarbij gebruikers zelf opslagruimte meenemen in de vorm van een Unhosted Personal Cloud. Gebruikers hebben zelf volledige controle over toegang tot gegevens die hier worden opgeslagen. De opslagruimte wordt geleverd door SARA. 1
http://unhosted.org/
Qiy Ook binnen het platform van Qiy1 worden de web applicaties gescheiden van de gegevens, maar Qiy beheert zelf de (trusted) personal data store. Qiy biedt daarnaast een interface aan waarmee de opgeslagen gegevens toegankelijk gemaakt kunnen worden voor dienstverleners. De gegevens zelf worden aangeleverd door andere dienstverleners waarbij er vanzelfsprekend semantische eisen worden gesteld. De gebruiker is zelf altijd in controle en moet toestemming verlenen voordat data beschikbaar wordt gesteld aan derden. Een concrete toepassing van Qiy mis het digitaal beschikbaar stellen van salarisstrookjes aan een medewerker door (een dienstverlener die ingehuurd is door) de werkgever. De medewerker kan vervolgens een verzekeraar toegang verlenen tot deze gegevens om een passende offerte aan te vragen voor bijvoorbeeld een levensverzekering. De verzekeraar krijgt dus tijdelijk toegang tot de gegevens, maar hoeft de persoonlijke informatie van de gebruiker niet op te slaan om antwoord te kunnen geven op de vraag van de gebruiker. 1
http://www.qiy.nl/
23
4 Samenvatting Dit rapport laat zien dat het mogelijk en noodzakelijk is om naast juridische maatregelen, ook technische maatregelen te nemen om de privacy en beveiliging van clouddiensten te ondersteunen. Deze technische maatregelen zorgen ervoor dat de risico’s van het afnemen van diensten in de cloud beperkt worden. Tevens zorgen zij dat de beheerstaken efficiënter gedaan kunnen worden en zorgen ook voor meer gemak bij de gebruiker. De beschreven maatregelen richten zich met name op manieren waarop gebruik gemaakt kan worden van binnen de onderwijsinstelling gebruikte oplossingen en processen rondom authenticatie, autorisatie en gebruikersbeheer. Hergebruik van authenticatie infrastructuren voorkomt een digitale sleutelbos, beperkt daarmee de risico’s van het hergebruik van wachtwoorden en zorgt voor meer gemak bij gebruikers. Als de rechten van gebruikers binnen een clouddienst bepaald kunnen worden op basis van reeds bestaande kenmerken van deze gebruikers (bv. “ik ben student”) kunnen autorisaties gemakkelijker toegewezen, aangepast en ingetrokken worden. Hierdoor wordt het vervolgens eenvoudiger om een scheiding van functies te realiseren en om te voorkomen dat bijvoorbeeld oud-medewerkers toegang krijgen tot gevoelige (persoonlijke) gegevens. Het aanmaken en actueel houden van gebruikersaccounts voor alle mogelijke clouddiensten geeft een hoge beheerslast. Op standaarden gebaseerde tools die zorgen voor de provisioning en deprovisioning kunnen deze last minimaliseren. De privacy van studenten en medewerkers die gebruik maken van clouddienst wordt deels beschermd door bovengenoemde zaken te realiseren binnen de onderwijsinstelling. Daarnaast zorgt de versleuteling van gegevens (tijdens transport, opgeslagen en tijdens verwerking) ervoor dat de privacy verder wordt beschermd. Als clouddiensten afgenomen worden via SURFconext, de samenwerkingsinfrastructuur van SURFnet, zijn veel van deze zaken al geregeld. Als onderwijsinstellingen zelf clouddiensten afnemen, doen ze er goed aan deze onderwerpen te bespreken met de cloudleverancier. Tools die de cloudleverancier beschikbaar stelt moeten waar mogelijk gebaseerd zijn op (open) standaarden om vendorlock-in en overbodig maatwerk te voorkomen, interoperabiliteit te verbeteren, en implementatietijd te verkorten. Dit rapport beschrijft tenslotte twee nieuwe ontwikkelingen op het gebied van cloud computing, namelijk as-a-Services en Personal Clouds. As-a-Services maken het mogelijk om bovengenoemde tools en diensten in de cloud af te nemen. Identity-as-a-Service maakt het bijvoorbeeld mogelijk om gebruikers in de cloud te laten authenticeren en ook het beheer van autorisaties in de cloud te verzorgen, waarbij deze dienst kan worden gebruikt voor alle diensten die in de cloud gebruikt worden. Het gebruik van Personal Clouds zorgt er onder meer voor dat gegevens niet langer onder beheer van de cloud leveranciers gebeurt, maar onder beheer van de gebruiker. De gebruiker kan zelf aangeven welke opslagruimte gebruikt wordt en wie daar toestemming toe heeft.
24
Appendix A. CSA’s 14 domains involved in governing or operating the cloud De Cloud Security Alliance (CSA 34) definieert 14 domeinen met betrekking tot cloud computing. Deze domeinen zijn verdeeld over drie gebieden: architectuur, toezicht en operatie. Cloud Architecture 1. Cloud Computing Architectural Framework Governing in the Cloud 2. Governance and Enterprise Risk Management 3. Legal Issues: Contracts and Electronic Discovery 4. Compliance and Audit Management 5. Information Management and Data Security 6. Interoperability and Portability Operating in the Cloud 7. Traditional Security, Business Continuity and Disaster Recovery 8. Data Center Operations 9. Incident Response 10. Application Security 11. Encryption and Key Management 12. Identity, Entitlement, and Access Management 13. Virtualization 14. Security as a Service
34
https://cloudsecurityalliance.org/research/security-guidance/
25
Appendix B. Maturity models, Richtlijnen, Certificaten en Standaarden Maturity Models en richtlijnen In navolging van CMM (Capability Maturity Model), een model dat aangeeft op welk niveau de software-ontwikkeling van een organisatie zich bevindt, zijn er allerlei modellen ontwikkeld om de volwassenheid van andere processen te meten. Op het gebied van de beveiliging van software kunnen onder andere de volgende modellen worden gebruikt: • Building Security in Maturity Model (BSIMM2) • Software Assurance Maturity Model (SAMM) • Security Maturity Model (SMM) • Systems Security Engineering Capability Maturity Model (SSE-CMM) (is gelijk aan ISO 21827) • Information Security Management Maturity Model (ISM3 of ISM-cubed) Overige richtlijnen voor het ontwikkelen van veilige software zijn onder andere: • Fundamental Practices for Secure Software Development 35 van SAFECode (Software Assurance Forum for Excellence in Code) • Secure Coding Standards van CERT • FISMA (Federal Information Security Management Act of 2002) van de Amerikaanse overheid • Privacy Audit Proof gebaseerd op richtlijn 3600 'Assurance-opdrachten met betrekking tot de bescherming van persoonsgegevens (Privacy-audits) van NIVRA (Koninklijk Nederlands Instituut van Registeraccountants) en NOREA (de beroepsorganisatie van IT-auditors) Certificaten en standaarden Voor de beveiliging van clouddiensten kunnen door verschillende (onafhankelijke) instanties certificaten worden uitgereikt voor het voldoen aan verschillende standaarden. Cloudleveranciers moeten in sommige gevallen aan deze standaarden voldoen om in aanmerking te komen als leverancier voor organisaties met strikte richtlijnen rond de beveiliging van (persoons)gegevens. Noemenswaardig zijn: • SOx (Sarbanes-Oxley), de wet van de Amerikaanse overhead die het besturen van bedrijven en de financiële verslaggeving regelt. • SSAE 16, gebouwd op basis van ISAE 3402 als vervanger van SAS 70 • HIPAA (Health Insurance Portability and Accountability Act) van de Amerikaanse overheid • ISO 27001 en 27002 (Norm voor informatiebeveiliging) • PCI-DSS (Data Security Standard van de PCI [Payment Card Industry] Security Standards Council)
35
http://www.safecode.org/publications/SAFECode_Dev_Practices0211.pdf
26
