Dit artikel is eerder gepubliceerd door AG Connect en is geschreven door Marcel Eizenga en Peter Zaat.
Dat de cloud een veilige plek is, behoeft nauwelijks nog betoog. Het veiligheidsniveau hangt echter wel in grote mate af van het encryptiebeheer. Is dat iets om aan de cloud-leverancier over te laten? Wanneer kies je voor eigen encryptiesleutels in een publieke cloudomgeving? Of ga je nog een stap verder, met een eigen fysieke sleutelkast die buiten de publieke cloudomgeving blijft? Dat hangt allemaal af van het bedrijfsrisico, concluderen Peter Zaat en Marcel Eizenga.
IT-professionals vliegen wekelijks in en uit. Bovendien zijn bij het beheer van diverse cloudomgevingen vaak meerdere partijen betrokken. In grote organisaties zijn veelal tientallen DevOps-teams tegelijk aan de slag. Vaak gaat het om software-ontwikkelaars die snel en makkelijk van team veranderen of tijdelijk deel uitmaken van een bepaald project. Dat vraagt om een gedegen versleuteling van gegevens en applicaties. Tegelijkertijd zit niet iedere IT-professional die bijvoorbeeld even snel een testomgeving wil optuigen, te wachten op de ontwikkeling van eigen sleutels voor hij of zij aan de gang kan. Dat kost geld en is vooral veel gedoe. Toch is het raadzaam om zelfs in een testomgeving waar net zo makkelijk aanspraak wordt gemaakt op gegevens uit een willekeurig datalake dat ergens in een Azure-, AWS- of bijvoorbeeld SalesForce-omgeving staat, versleuteling toe te passen. Slechts de helft van bedrijven en instellingen beheert data in de cloud met eigen encryptiesleutels. Dat blijkt uit onderzoek van Gartner. Maar ook wij ervaren in de dagelijkse praktijk dat encryptiebeheer relatief makkelijk aan de clouddienstverlener wordt overgelaten. Dat is nog altijd een beetje onbekend-maakt-onbemindterrein. Het hoeft niet per definitie een grote ramp te zijn, maar dan is het wel van belang dat precies bekend is waar data staan opgeslagen. Dat is in de meeste organisaties niet of nauwelijks het geval, en het lijkt zelfs onbegonnen werk door de vele cloud-omgevingen en beheerpartijen die vaak betrokken zijn. Daarom is het van groot belang om goed na te denken over encryptiebeheer.
Begin daarbij met het vaststellen van de bedrijfsrisico’s. Welke bedrijfsrisico’s zijn aan de orde bij het beheer van applicaties, gegevens en infrastructuur? Wie is daarbij verantwoordelijk voor de versleuteling van data in de cloud en welke bescherming wordt geboden? Op basis van de risico’s kan worden bepaald waar en wanneer gegevens versleuteld moeten worden. Voor sleutelbeheer zijn drie scenario’s van toepassing om uit te kiezen. Zo is het mogelijk om het encryptiebeheer aan clouddienstverleners over te laten. Of men kiest voor eigen sleutels in een publieke cloudomgeving. En tenslotte is er de bring-your-own-keyaanpak. Welk scenario is wanneer het geschiktst?
Encryptiebeheer aan clouddienstverleners overlaten
Als het encryptiebeheer aan een cloud-dienstverlener wordt overgelaten, is de cloudservicesprovider zelf verantwoordelijk voor de versleuteling van gegevens en applicaties in de cloud. Dat betekent dat derde partijen toegang kunnen hebben tot niet-versleutelde data, omdat zij de encryptiesleutels creëren en beheren. Uiteraard is het mogelijk met de clouddienstverlener duidelijke afspraken te maken over de versleuteling van bedrijfsgegevens. De regie aan deze partijen overlaten, betekent wel dat er geen zicht is op ongewenste toegang tot gegevens door bijvoorbeeld (buitenlandse) overheidsinstanties die daarom vragen. Het uitbesteden van de veiligheid is geen garantie op zekerheid ook al kan de cloudleverancier volledig inzage geven in het encryptiebeleid.
Eigen sleutels in een publieke cloudomgeving
De keuze voor het gebruik van eigen sleutels in een publieke cloudomgeving is veruit het meestgebruikte scenario. Het moet echter wel aan een aantal voorwaarden voldoen. In deze situatie is toegang tot data en applicaties alleen mogelijk via sleutels die specifiek ontwikkeld zijn voor toegang tot eigen bedrijfsgegevens en applicaties. Daarbij is het nog steeds mogelijk dat de externe cloudbeheerder toegang heeft tot jouw bedrijfsdata. Dan is het van groot belang dat sleutels continu veranderen. Er moet bovendien sprake zijn van zogeheten role-based access. Dat houdt in dat op basis van functies en bevoegdheden wordt bepaald wie toegang krijgt tot de sleutelkast. Hoe het roteringsproces wordt ingericht, is afhankelijk van de vereiste veiligheid. Dat kan overigens een volledig geautomatiseerd proces zijn waarbij sleutels in een vaste frequentie worden aangepast, bijvoorbeeld dagelijks, wekelijks of om de dertig dagen. Het is daarbij raadzaam om sleutelbeheer in een eigen regio te houden. Mocht er onverhoopt sprake zijn van misbruik, dan blijft dat beperkt tot een specifieke zone of regio. Daarom is een minimale boundary van een cloudregio het devies. De kans op het kwijtraken van sleutels is aanwezig in dit scenario. Om dat te voorkomen, is het zaak dat sleutels bijvoorbeeld om de zestig dagen automatisch worden verwijderd en nieuwe sleutels beschikbaar komen. Dat levert een aantal bijkomende voordelen op. Het automatisch verwijderen en aanmaken van nieuwe sleutels dwingt ook tot het inrichten van een proces. Ook wordt hiermee voorkomen dat kennis over sleutelbeheer onopgemerkt verdwijnt omdat er langere tijd niets mee wordt gedaan.
Bring-your-own-keyaanpak
Een extra fysiek slot op de deur wordt realiteit met hardware security modules (HSM’s). Dit is een relatief dure oplossing die nodig is bij de meest gevoelige data die alleen via fysieke hardwaresleutels toegankelijk worden. Zo is het voor cloudproviders onmogelijk toegang te krijgen tot gegevens. Dat vraagt wel om heldere protocollen voor sleutelbeheer. Belangrijk daarbij is dat dit op een zodanige manier gebeurt dat toegang tot de cloud niet een sta-in-de-weg wordt voor medewerkers, klanten of partners die regelmatig een beroep doen op de cloudomgeving. In deze situatie ligt regie van zowel de versleuteling van de data als het sleutelbeheer volledig bij de eigenaar van de clouddata en/of applicaties. Verschillende marktpartijen bieden HSM’s aan die speciaal ontwikkelde modules uitvoeren binnen de beveiligde behuizing van de HSM. Dat is handig bij gevallen waarin speciale algoritmen of bedrijfslogica uitgevoerd moeten worden in een hoogbeveiligde en gecontroleerde omgeving. HSM’s zijn doorgaans gecertificeerd volgens internationaal erkende normen om gebruikers onafhankelijke zekerheid te bieden dat ontwerpen en de implementatie van bijvoorbeeld cryptografische algoritmen veilig zijn. Dat komt onder andere voor bij betalingsapplicaties of in defensieomgevingen.
Voortschrijdend inzicht
Naast risicobeheer zijn tijd en voortschrijdende technologische ontwikkelingen van groot belang voor het maken van
de juiste keuze van sleutelbeheer in een cloudomgeving. Want hoe te zorgen voor sleutelbeheer voor een periode die meerdere jaren beslaat? En wat als kwantumcomputing straks gemeengoed is? Microsoft biedt bijvoorbeeld nu al kwantumtechnologie aan. Dus iedereen kan het inzetten. Met de opkomst van kwantumtechnologie is het belangrijker dan ooit om inzicht te houden in type encrypties. Als gevolg van kwantumtechnologie zullen bepaalde encrypties naar verwachting minder veilig zijn. Organisaties moeten daarop voorbereid zijn door regie te houden op eigen sleutelbeheer.
Meer weten?
Bekijk het artikel als PDF of ga direct naar onze cloud services!
