12 minute read
Privacywetgeving in de public cloud: hoe zit
Privacywetgeving in de public cloud: hoe zit dat?
Facebook heeft in het verleden naar de seksuele geaardheid van gebruikers gevraagd en op basis van deze informatie gerichte advertenties getoond. Volgens de spelregels van de Nederlandse privacywetgeving is dit niet toegestaan. Maar wat als het Europese hoofdkantoor en datacenters in Ierland staan? Geldt de Nederlandse wetgeving dan nog wel?
Advertisement
De Nederlandse privacywetgeving lijkt in de meeste gevallen duidelijk: iedere in Nederland gevestigde organisatie moet zich aan de spelregels houden. Bij publieke clouddiensten met servers over de grens ontstaat echter een ingewikkelde situatie. Welke privacyspelregels gelden in de public cloud?
Bijzondere persoonsgegevens
Facebook mag volgens de Autoriteit Persoonsgegevens (AP) niet zomaar data vragen over de seksuele voorkeur van gebruikers. Het gaat hierbij namelijk om bijzondere persoonsgegevens. Deze mogen alleen onder zeer strikte voorwaarden worden verwerkt. Het tonen van gerichte advertenties is daar in ieder geval niet een van.
Facebook verweerde zich: het Europese hoofdkantoor en de datacenters staan in Ierland, buiten het bereik van de Nederlandse wetgeving. De AP zou dus helemaal geen recht van spreken hebben. Volgens de AP speelde de Nederlandse vestiging van het bedrijf echter een rol in het geheel, door Nederlandse bedrijven te adviseren over de advertentiemogelijkheden op het sociale netwerk. De kwestie heeft volgens de AP dus wel degelijk een Nederlands tintje.
Belangrijkste spelregels
Het laatste woord over de kwestie is nog niet gezegd. Wel is duidelijk dat privacywetgeving in de cloud niet altijd vanzelfsprekend is en jurisdictie absoluut een rol speelt. Daar dient u serieus rekening mee te houden als een cloudprovider namens u persoonsgegevens van uw klanten bewerkt. Gelukkig zijn er ook een aantal ‘harde’ afspraken
waar cloudproviders aan moeten voldoen. De public cloud is erg privacyvriendelijk, zolang providers zich houden aan een aantal spelregels van de Nederlandse privacywet. We zetten de belangrijkste op een rij:
Bewerkersovereenkomst
Veel public clouddiensten verwerken persoonsgegevens. Niet alleen van hun klanten, maar in veel gevallen ook van de klanten van hun klanten. Denk aan een administratiekantoor dat gebruikmaakt van een SaaS-oplossing voor onlineboekhouden, of een uitgever die een abonnementenbestand bijhoudt in Office 365.
In zo’n geval is een bewerkersovereenkomst altijd verplicht. Dat is een officieel document waarin de organisatie afspraken maakt met de cloudprovider over de gegevensbewerking. De cloudprovider belooft in zo’n overeenkomst eenvoudig gezegd dat het zijn best doet de privacy van de klanten van de organisatie waarmee het de overeenkomst sluit zo goed mogelijk te beschermen. Ook maakt u in zo’n overeenkomst afspraken over verantwoordelijkheden bij een datalek.
Serieuze beveiligingsmaatregelen
Een cloudprovider die persoonsgegevens verwerkt, is verplicht serieuze beveiligings-maatregelen te nemen. Het gaat daarbij zowel om technische securitymaatregelen als organisatorische afspraken en procedures. Denk dus aan zaken als securitysoftware, een deugdelijke firewall, IDS/IPS, maar ook aan een duidelijk gedocumenteerd privacybeleid.
Meldplicht richting verantwoordelijke
Een cloudleverancier moet zijn klanten direct op de hoogte brengen bij een datalek. Dus niet rechtstreeks melden bij de AP, die verantwoordelijkheid ligt bij de klant. Die is immers weer eindverantwoordelijk over de persoonsgegevens van zijn klanten, ook wanneer de cloudleverancier bewust of onbewust zijn mond houdt over het lek. Dat is direct een sterk argument om alleen met cloudleveranciers in zee te gaan met een goede staat van dienst.
Doorgifte naar buitenland
Het kan voorkomen dat de cloudprovider data verhuist naar een land buiten de EU. Als klant moet je dat scherp in de gaten houden en harde afspraken over maken. De privacywetgeving verbiedt namelijk het verplaatsen van persoonsgegevens naar niet-EU-landen, tenzij het land over een minstens zo hoog beschermingsniveau beschikt. Een providerwissel kan in zo’n geval noodzakelijk zijn om aan de Nederlandse privacywetgeving te blijven voldoen. Bijvoorbeeld wanneer de data verhuizen naar een land dat weinig tot geen privacyregels kent.
Die waakzaamheid geldt overigens ook wanneer de cloudprovider toegang tot persoonsgegevens op afstand verleent aan een niet-EU-land, zoals een helpdesk in India. Ook dan kan sprake zijn van verwerking van persoonsgegevens door niet-bevoegde personen en dus een overtreding van de privacywet.
De VS: een apart geval
De Verenigde Staten zijn wat betreft de cloud een vreemde eend in de bijt. Komen data van Europese burgers terecht op Amerikaanse servers, dan vallen deze onder het Privacy Shield. Het Amerikaanse cloudbedrijf moet wel zijn aangemeld op het Privacy Shieldprogramma. Is dat het geval, dan mogen persoonsgegevens door hen worden verwerkt. Het moet echter nog maar blijken hoe duurzaam deze afspraak is. De afspraak kan ieder jaar worden bijgewerkt.
De private cloud is met de enige oplettendheid absoluut geen privacyonvriendelijke plek. Goed voorwerk en duidelijke afspraken met de cloudprovider verminderen de kans op datalekken en andere ellende.
Meer informatie: www.kpn.com/zakelijk/ grootzakelijk/cloud/private-cloud
Nederlands Instituut voor de Software Industrie:
Cybersecurity wordt in veel gevallen nog altijd gezien als een set aan beveiligingsmaatregelen die aan een bestaande IT-omgeving worden toegevoegd. Bij het Nederlands Instituut voor de Software Industrie (NISI) ziet men dat anders. Begin bij het begin, is hier het motto. Anders gezegd: kijk bij het ontwikkelen van software niet alleen naar de functionaliteit, maar betrek security in alle stappen die nodig zijn om tot de gewenste functionaliteit te komen. Daarbij kunnen we minstens negen zeer nuttige maatregelen nemen, stelt Jan Vlietland van het NISI. Deel 1 in een serie artikelen over het ontwikkelen van veilige applicaties.
Applicaties vormen natuurlijk niet de enige uitdaging als het om IT-security gaat, vertelt Jan Vlietland van het Nederlands Instituut voor de Software Industrie. “Maar het vormt wel een belangrijk aspect. Wie software ontwikkelt op basis van de principes van ‘Secure Development Life Cycle’ kan grote stappen in de goede richting zetten.”
Secure Development Life Cycle
Secure Development Life Cycle ofwel SDLC bestaat uit 4 stappen die continu doorlopen worden. Wie begint met deze aanpak, zal allereerst zijn ‘requirements’ in kaart moeten brengen. Zijn die eenmaal duidelijk, dan kunnen de zogeheten ‘secure design principles’ vastgesteld worden die hier het beste bij passen. Vervolgens kan een ‘secure design’ worden geïmplementeerd. Waarna een aantal validaties dienen te worden uitgevoerd om vast te tellen in hoeverre het secure design ook daadwerkelijk aansluit bij de eerder genoemde requirements. Zijn hierbij aanpassingen nodig, dan kan dit ook weer impact hebben op de gekozen secure design principes. En zo doorlopen we continu deze ‘life cycle’.
Secure design principes
Hierbij is een cruciale rol weggelegd voor de zogeheten secure design principes. Dit zijn er negen, stelt Vlietland:
• Minimaliseer de mogelijkheden voor aanvallers om actief te worden (minimize attack surface area) • Zorg voor veilige default-instellingen
• Ga uit van het idee van ‘least privilege’ • Hanteer het principe van ‘verdediging in de diepte’ • Zorg dat eventuele fouten niet tot onveilige situaties leiden • Heb geen vertrouwen in externe services • Zorg voor scheiding tussen taken • Voorkom ‘security by obscurity’ • Hou security eenvoudig
Laten we deze negen stappen of maatregelen eens nader bekijken.
Minimize attack surface area
Iedere nieuwe feature die aan software wordt toegevoegd, levert weer extra risico’s op voor de applicatie. Terwijl het doel van ‘secure development’ nu juist is dat we het risico terugdringen door criminelen minder mogelijkheden voor een aanval of misbruik te bieden.
Een voorbeeld: een webapplicatie kan voorzien worden van een online help waaraan een zoekfunctie is gekoppeld. Die search-functie levert extra risico’s op in de vorm van SQL injectionaanvallen. Hoe kunnen we dit risico verminderen? Door de zoekfunctie bijvoorbeeld alleen voor geautoriseerde gebruikers beschikbaar te maken. Of door de zoekfunctie in te perken door een aantal routines toe te voegen waarmee de ingevoerde zoekdata kan worden gevalideerd. Daarmee kunnen we het risico dat een SQL injectionaanval met succes wordt uitgevoerd drastisch terugbrengen.
Veilige default-instellingen
Als uitgangspunt geldt dat default configuratie-instellingen de meest veilige instellingen vormen die mogelijk zijn. Dat is natuurlijk niet direct hetzelfde als de meest gebruiksvriendelijke instellingen. Maar ga uit van het idee dat het aan de gebruiker zelf is om zijn veiligheidsniveau eventueel te verlagen. Dit dient dan een bewuste keuze en een bewust uitgevoerde actie te zijn. Mits we een dergelijke verlaging van het securityniveau natuurlijk überhaupt willen toestaan.
Ook hier weer een voorbeeld: stel per default in dat wachtwoorden na verloop van tijd verlopen en stel bovendien eisen aan de samenstelling van het gebruikte wachtwoord. We kunnen natuurlijk overwegen dat gebruikers beide features
mogen uitschakelen. Dit levert een vereenvoudiging van het gebruik op, maar tevens een verlaging van het securityniveau.
Let overigens op dat werken met ‘secure defaults’ niet hetzelfde is als het uitzetten van alle netwerkverbindingen, sockets en services en dergelijke. Omgekeerd betekent het ook niet dat met secure defaults een 100% veilige omgeving is gecreëerd.
Least privilege
Werken met minimale privileges betekent dat iedere module - een proces, een gebruiker of een programma - alleen toegang heeft tot die informatie en IT-middelen die nodig zijn voor het uitvoeren van de taak waar het om gaat. Een user account krijgt hierbij dus uitsluitend die rechten die essentieel zijn voor de beoogde functie.
Neem als voorbeeld een user account dat bedoeld is voor het maken van back-ups. Die ‘user’ behoeft dan bijvoorbeeld geen software te kunnen installeren. Er dient dus enkel sprake te zijn van rechten om back-ups te maken en back-up-software te starten.
Hetzelfde voor een eindgebruiker met een normaal user account. Beperk het aantal situaties waarin deze gebruiker privileged en met een wachtwoord beschermde superuser-rechten nodig heeft tot het absolute minimum.
Defensie in de diepte
‘Defense in depth’ is een concept waarbij de verdediging uit meerdere lagen wordt opgebouwd. Hierbij kijken we niet alleen naar de applicatie zelf, maar naar de gehele IT-omgeving. Denk hierbij aan firewalls, ‘demilitarized zones’ (DMZ), antivirus software, ‘patching’, ‘secure coding’, versleuteling van files en data, ‘intrusion detection’ en dergelijke.
Het gebruik van meerdere lagen heeft tot doel redundantie aan te brengen. Daarom is het belangrijk dat deze meerdaagse defensie tal van maatregelen omvat die variëren van personele maatregelen, procedures, technische en fysieke bescherming.
Veilig fouten maken
Stel duidelijk vast dat authenticatiemaatregelen zodanig zijn ontwikkeld dat een aanvaller niet kan inloggen. Kijk hierbij dus heel nadrukkelijk naar de ‘error handling’ bij authenticatie. Veel frameworks regelen dit weliswaar voor een developer, maar check dit altijd goed. Bijvoorbeeld door te controleren in hoeverre het mogelijk is dat een foutieve input bij authenticatie de gehele authenticatieprocedure uitschakelt? Of haal als test eens de gehele database met authenticatiegegevens offline en onderzoek wat er gebeurt als dan alsnog geprobeerd wordt in te loggen.
Vertrouw geen services
Een externe service gebruiken intro-
Over het NISI
Het Nederlands Instituut voor de Software Industrie (NISI) is een initiatief van de Universiteit Utrecht. Het NISI ondersteunt de software-industrie met kennis, innovatie en netwerk. Het instituut verzorgt voor de software-industrie hoogwaardige postacademische opleidingen, faciliteert intervisie en praktijkbijeenkomsten, en verbindt software-universiteiten met het bedrijfsleven.
duceert per definitie risico’s. Want wellicht hanteren zij andere security policies, zonder dat we hier invloed op kunnen uitoefenen. We kunnen er simpelweg niet impliciet vanuit gaan dat een externe service veilig is en vertrouwd kan worden. Maak hierbij bovendien geen onderscheid tussen soorten externe services. Maar behandel alle externe services op dezelfde manier.
Ook hier weer een voorbeeld. Een aanbieder van een royalty-programma levert data die gebruikt wordt bij internetbankieren. Deze partij levert bijvoorbeeld het aantal spaarpunten van een gebruiker aan of berekent de korting die de gebruiker hiermee krijgt. Hierbij zal deze data gecontroleerd dienen te worden voordat deze aan de gebruiker getoond wordt.
Geen security by obscurity
Security by obscurity is geen goed idee, zeker niet als dit de enige security control is. Hiermee bedoelen we dat het niet verstandig is allerlei details onzichtbaar te houden. Voorbeeld: ga niet uit van het idee dat zolang de broncode van een applicatie geheim wordt gehouden er bij aanvallers geen kennis over de werking van de software kan ontstaan. Security zal gebaseerd moeten zijn op een aantal maatregelen, variërend van deugdelijke procedures rond wachtwoorden, defensie in de diepte, beperkingen die we aan transacties stellen, een weldoordachte netwerkarchitectuur en dergelijke.
Hou security eenvoudig
De twee fenomenen ‘attack surface area’ en ‘eenvoud’ gaan hand-in-hand. Hou ook waar veel organisaties voor staan: security controls implementatie daarvan plaats
de programmacode eenvoudig en zo efficiënt mogelijk. Sommige developers schrijven zeer uitgebreide code, met alle risico’s van dien op fouten en zwakheden. Het kan daarnaast erg modern zijn om tal van ‘entity beans’ op een middlewareserver te gebruiken, maar vaak is het veiliger en sneller om ‘global variables’ toe te passen met een mutexmechanisme (‘mutual exclusive’) die bescherming biedt tegen dubbelzinnige multithreading-condities.
Continue authenticatie Authenticatie speelt bij secure coding een hoofdrol. Steeds vaker wordt in applicaties de optie van two-factor authentication toegepast. Maar er is nog een andere optie die in het kader van dit artikel erg relevant kan zijn: ‘continuous authentication’. Hierbij wordt de identiteit continu geverifieerd. Hierbij kan gebruik worden gemaakt van biometrische input, maar bijvoorbeeld ook een smartphone of context. Denk bij dit laatste bijvoorbeeld aan GPS-data voor het vaststellen van de locatie van een gebruiker of gegevens over het tijdstip van het gebruik van de applicatie of het doen van een transactie.
Met continue authenticatie is het mogelijk de beveiliging verder te verbeteren. Wordt deze maatregel toegepast dan is het voor een aanvaller bijvoorbeeld veel lastiger geworden om een sessie over te nemen of om misbruik te maken van gestolen apparatuur. Denk aan een smartphone in het geval van two-factor authentication.
In een volgend artikel gaan we nader in op het proces van authenticatie. Maar kijken we ook naar role-based access control en encryptie.
ROBBERT HOEFFNAGEL is hoofdredacteur van CloudWorks en
Top-10 cybersecurity-uitdagingen
Cybersecurity heeft betrekking op tal van aspecten binnen een IT-omgeving. Dit zijn de tien belangrijkste uitdagingen
• De organisatie beschikt niet over een (adequaat) security-programma • Er is recent geen security-scan gedaan om de risico’s in kaart te brengen • Er heeft met het oog op wet- en regelgeving geen evaluatie plaatsgevonden van security-issues of gebreken in • De organisatie beschikt niet over een formeel proces voor het patchen van software of er vindt geen systematische Infosecurity Magazine • Er is geen sprake van een zogeheten ‘insider threat’-programma • De organisatie heeft geen contacten met of in de cybersecurity-wereld • Er is geen sprake van een goed georganiseerd configuratiebeheer • Er is geen sprake van een goed georganiseerd beheer rond ‘remote access’ • Er wordt geen of onvoldoende gebruik gemaakt van de beschikbare data rond cybersecurity • Er is geen plan van aanpak beschikbaar hoe gereageerd dient te worden op een incident