Als je bezig bent met een cloudmigratie, kan je behoorlijk vrolijk worden van de vooruitzichten. Eindeloze computerpower, meer flexibiliteit en alle mogelijkheden van je public cloudplatform. Maar zoals voor alles in het leven geldt, moet je in deze transformatie ook rekening houden met minder fijne dingen. Eén zo’n ding gaat over kosten, die na de overgang naar Cloud nogal eens op willen lopen (zie hiervoor dit artikel over de billshock). Het tweede ding is natuurlijk veiligheid. Een public cloudomgeving die niet voldoet aan wet- en regelgeving brengt namelijk risico’s met zich mee. Welke risico’s dat precies zijn, verschilt per sector, maar in geen enkele situatie zijn ze het waard om te negeren. Gelukkig is de implementatie van adequate public cloud security goed te doen, zolang je werkt met de 80-20 regel. Hoe deze methode werkt, lees je hier.
Public Cloud Security is niet standaard inbegrepen
Als je public clouddiensten gaat afnemen bij bijvoorbeeld Microsoft Azure of Amazon AWS, krijg je een cloudplatform dat het beste vergeleken kan worden met een casco opgeleverd huis. De fundering, muren en aansluitingen voor elektriciteit zijn aanwezig, maar de rest kan je naar wens inrichten. Dit betekent dat je ook vrij bent in de manier waarop je jouw public cloudomgeving beveiligt. Handig, want zo betaal je niet voor zaken die je niet gebruikt. Per sector geldt immers weer andere regelgeving en ook per organisatie lopen de beveiligingseisen ver uiteen. Aan jou en je team de taak om het casco opgeleverde platform zó te beveiligen dat het aan alle eisen en voorwaarden voldoet.
Vier niveaus van regelgeving
“Alle eisen en voorwaarden”- dat is natuurlijk nogal wat. Zo heb je externe regelgeving, externe normenkaders, normen van toezichthouders, opgelegde ISO-standaarden en interne control frameworks. Om overzicht te krijgen in al deze eisen, raad ik je aan om ze te verdelen in vier lagen van regelgeving:
- Wet- en regelgeving
- Sectorspecifieke regelgeving
- Zelfopgelegde normenkaders
- Interne control frameworks met interne eisen
Wet- en regelgeving (1) gaat over wetten die voor iedereen gelden, bijvoorbeeld de GDPR. Een voorbeeld van sectorspecifieke regelgeving (2) is de BIO (Baseline Informatiebeveiliging) voor overheidspartijen. Zo’n zelfde normenkader is er ook voor financiële organisaties, verzekeraars, enzovoorts. Naast regelgeving die van buitenaf wordt opgelegd, heb je ook de zelfopgelegde normenkaders (3). Een voorbeeld is de wens van de directie om aan bepaalde ISO-standaarden te voldoen. Dit is niet verplicht, maar helpt om het vertrouwen van klanten te winnen of toegelaten te worden tot een aanbestedingstraject. Het laatste niveau van regelgeving gaat over interne control frameworks (4). Deze frameworks gaan over de interne regels in de organisatie en zijn vaak een aanvulling op de externe frameworks.
De kracht van de 80-20 regel
Het verzamelen van beveiligingseisen voor alle vier de niveaus klinkt als een hoop uitzoekwerk. En dat is ook zo! Je zult flink moeten graven en de eisen, normen en voorwaarden vervolgens moeten ordenen. Maar de tijd en moeite die je nodig hebt om je public cloudomgeving daadwerkelijk te beveiligen, kan je flink inkorten met een slimme truc die ik de 80-20 regel noem. Deze regel luidt als volgt:
“Zorg voor een solide basisinrichting waarmee je de beveiliging van 80% van je data en applicaties afdekt. Zorg ervoor dat die basisinrichting zó goed is ingeregeld dat deze groep zonder problemen kan landen. Besteed vervolgens extra aandacht aan de 20% die extra maatregelen nodig heeft"
Cloud op z’n best
Het mooie aan Cloud is dat je deze 80-20 regel betrekkelijk eenvoudig kunt inrichten. Cloudproviders bieden namelijk veel oplossingen, best practices en referentie-designs waarmee je beveiliging tot aan de hoogste eisen regelt. Alles is immers al een keer gedaan, dus hoef jij het wiel niet opnieuw uit te vinden. Je bedenkt één plan waarin het overgrote deel van je cloudplatform aan alle verzamelde eisen en normen voldoet. De overgebleven 20% vraagt aanvullende maatregelen, ik noem dat de Tier I en Tier II controls (zie infographic hieronder). Die laatste categorie los je op per data/applicatie combinatie door middel van het solution design. Daarin kun je aanvullende maatregelen treffen, zoals een hoger niveau van encryptie of speciale sleutelbescherming. Door gebruik te maken van deze 80-20 regel zorg je én voor een goede beveiliging én maak je snelheid. Zo maak je optimaal gebruik van alle mogelijkheden- Cloud op z’n best!
De quick & dirty oplossing
Nu kan ik me voorstellen dat public cloud security en control frameworks niet per se binnen jouw expertise vallen. Ik raad je daarom aan om altijd hulp in te schakelen van experts die dagelijks bezig zijn met public cloudplatformen en het beveiligen ervan. Wil je toch alvast een vliegende start maken? Dan heb ik ook nog een quick & dirty oplossing voor je: leg alvast een basis door standaard beveiligingsmaatregelen uit de catalogus van je cloudprovider te halen. Zo hebben alle cloudproviders een pakket klaarliggen waarmee jij voldoet aan de ISO standaard informatiebeveiliging 27001. Deze ISO vormt ook nog eens de basis voor de BIO-richtlijn voor de overheid, waardoor je al een heel eind bent. Ook voor GDPR hebben cloudproviders standaard inrichtingen voor je klaarstaan. Implementeer deze normenkaders alvast, daarmee heb je de basis in elk geval voldoende geregeld.
Fun fact: compliance is -vreemd genoeg- bij veel cloudproviders allesbehalve een vervelende discipline. Microsoft gebruikt bijvoorbeeld Secure-Score: hiermee kunnen security specialisten punten scoren als ze nieuwe taken hebben volbracht. Compliance gamification dus!
Wie gaat jullie public cloud security regelen en wanneer?
En dan nu de hoofdvraag: wie gaat de beveiliging van jullie public cloudplatform eigenlijk regelen en wanneer? De “wanneer” vraag is snel beantwoord: zodra je weet hoe je nieuwe applicatielandschap eruit gaan zien. Cloud security is hiermee onderdeel van het high level design: stap 4 in het cloud strategy stappenplan. In dit high level design breng je onderstaande zaken in kaart:
- Tools voor applicatie- en platformbeheer
- Netwerkverbindingen
- Applicatie- en data-integratie
- Security & Compliance
De “wie” vraag ligt ingewikkelder. Omdat public cloud security zo anders is dan security in een traditionele omgeving, moet er eigenlijk een nieuwe rol worden gecreëerd: die van Cloud Security Specialist. Meestal is dat een van de bestaande security experts die aanvullende kennis gaat opdoen.
Start een Cloud Center of Expertise
Tegelijkertijd is het onverstandig om één persoon aan te wijzen die al het bovenstaande gaat regelen. Zeker als public cloud een nieuw begrip is in jullie organisatie! Wij raden onze klanten daarom altijd aan om een intern cloudteam samen te stellen dat verantwoordelijk is voor de verspreiding van kennis en expertise over de organisatie. Wij noemen dit team het Cloud Center of Expertise (CCoE). De teamleden van het CCoE kunnen de Cloud Security Specialist bijstaan in het verzamelen en structureren van informatie over wet- en regelgeving en adviseren bij belangrijke beslissingen. Zo maak je gebruik van de gebundelde kennis van het CCoE en de expertise van de Cloud Security Specialist.
Zelf een Cloud Center of Expertise opzetten?
Wil jij meer weten over de rol van het Cloud Center of Expertise in de beveiliging van jullie public cloudomgeving? Download de quick guide! Hierin lees je niet alleen wat een CCoE precies doet, maar ook hoe je er een opzet voor jouw organisatie.
