Nu ongeveer twintig procent van de zakelijke workloads in de cloud draaien, hebben bedrijven een aantal dure lessen geleerd over waar migratie op stukloopt. Een thema dat steeds terugkeert, is dat IT’ers de bestaande processen en applicaties simpelweg overhevelen van het datacenter naar de cloud.

Waarom je traditionele aanpak faalt bij een cloudmigratie.
Een van de uitdagingen voor een IT-organisatie die van het interne serverpark overstapt op de cloud is de fundamenteel andere aanpak van beveiliging die daarbij komt kijken. Oude tactieken zoals het inspecteren van pakketjes die het interne netwerk in- en uitgaan met port-mirroring werken niet in een cloudarchitectuur, waar je simpelweg geen firewalls kunt plaatsen. Wat we meestal doen is het zoeken naar een vergelijkbare tool en aanpak in de nieuwe architectuur en daar lopen zowel informatiebeveiligers als netwerkbeheerders tegen problemen aan bij het migreren.

Kijken naar het einddoel
“Maar je moet een stapje terugdoen”, meent Barracuda’s Public Cloud-chef Tim Jefferson, “en kijken naar welke beveiliging je wilt afdwingen. Een tool is slechts een middel om het doel te bereiken.” De netwerkspecialist denkt dat IT zich soms te blindstaart op de specifieke tools en uit het oog verliest wat de bedoeling daarvan is. “Uiteindelijk is het basisdoel dat je bepaalde policy’s wilt handhaven.” Als je weet welke dat zijn, kun je de juiste beheerelementen en tools zoeken. Jefferson omschrijft in gesprek met Computerworld een typische cloudmigratie als ‘lift and shift’. Die term gebruiken we voor het proces waarin wordt gekeken naar de huidige workloads en applicaties die intern draaien om die één op één over te zetten in een cloudomgeving. Dat is op zich geen vreemde benadering, want dat is het idee achter de meeste traditionele migraties: als je bijvoorbeeld naar een nieuw besturingssysteem en deels veranderende back-end overstapt, kijk je ook naar wat er vóór de migratie draait om dat zo goed mogelijk te repliceren in de nieuwe omgeving, zodat eindgebruikers met hun bestaande workflows verder kunnen.

Schaalvegroting en security gaan mis
Dat scheelt bovendien kosten, omdat je met de huidige middelen (en vooral: de licentiëring daarvan) verder kunt gaan en specifieke cloud-native applicaties kunt laten voor wat ze zijn. Later brengt dit vaak issues met zich mee, omdat de cloudbelofte niet wordt waargemaakt als je geen gebruik kunt maken van de features die cloud zo effectief maken, terwijl je vasthoudt aan een traditioneel datacenterconcept – maar dan in de cloud.

Behalve de langetermijnproblemen die een cloudmigratie met lift and shift opleveren, kom je beveiligingsissues tegen. “Problemen ontstaan vaak bij het kopiëren van de on-prem architectuur in de cloud”, zegt de Barracuda-deskundige. “In een traditionele architectuur heb je sterk gekoppelde systemen met centrale punten waar je policy’s op toepast. In de cloud wil je juist een losjes gekoppeld systeem hebben met zo min mogelijk dependency’s.” Op die manier ben je flexibel en kun je makkelijk schalen. Met het kopiëren van de on-prem aanpak, mis je dus niet alleen de schaalbaarheidsvoordelen van de cloud, maar het je ook een traditioneel beveiligingsmodel die verkeerd wordt begrepen.

Best practices automatiseren
Dat is debet aan problemen zoals regelmatig opduiken met verkeerd geconfigureerde S3-buckets waardoor gevoelige gegevens te benaderen zijn door ongeautoriseerde gebruikers. Oftewel: een datalek. “De diensten zijn beveiligd en leveranciers geven beheerders 100 procent de ruimte om data op te slaan en te gebruiken zoals zij dat willen. Maar klanten moeten dat dan wel begrijpen en best practices leren.”

Barracuda zelf zocht naar tools om cloudbeveiliging te automatiseren voor de interne ontwikkelaars. Het idee was om een systeem in te richten om in te grijpen als er bijvoorbeeld een VM wordt ingeschakeld met kwetsbare open poorten of als er een S3 wordt ingezet met veel te ruime rechten, zodat dit probleem direct wordt afgevangen. Geen S3-bucket met klantendata die een half jaar door iedere nieuwsgierige bezoeker kunnen worden ingezien dus.

Dogfooding
Voor het bedrijf voldeden bestaande tools niet, dus voor de eigen ontwikkelaars werd precies zo’n cloudbeveiligingssysteem ontworpen. Dat project werkte intern prima voor de eigen wensen en het resultaat wordt later dit jaar uitgebracht op de markt als een tool voor cloudgebruikers. Het is volgens Jefferson een typisch geval van dogfooding: het project wordt door de ontwikkelaars van het bedrijf gebruikt om zeker te maken dat het geschikt is voor algemeen gebruik. Het hele idee is om de bestaande beveiligingstools van de cloud beter te benutten, want die tools zijn er wel degelijk, maar blijven vaak ongebruikt. Jefferson noemt bijvoorbeeld AWS die detecteert wanneer klanten afwijken van hun eigen gedefinieerde compliance-regels waaraan cloudresources moeten voldoen en Azure die in plaats van reactief preventief aan de hand van policy’s beperkingen inzet die API-calls kunnen maken.

Tussen strikt en open
Voor CISO’s en andere informatiebeveiligers is het, zoals met alle IT-security, een afweging tussen functionaliteit en beveiliging: te draconisch en je ontwikkelaars kunnen niet meer fatsoenlijk werken, maar zet het te open en je hebt last van potentiële datalekken. Het idee is dan ook dat je dit proces automatiseert. Tools als deze van Barracuda scannen de hele cloudbeveiligingsaanpak, de S3- en EC2-policy’s, sleutels, credentials, groepen en rootcertificaten aan de hand van assessments als de CIS-benchmarks voor cloudiensten, zo legt Jefferson uit. Vervolgens worden bevindingen gepresenteerd in een console die begrijpelijker moet zijn dan de hardcore gegevens die de meeste tools aanbieden, maar toch inzichten biedt aan geavanceerde admins. “We horen wel eens van informatiebeveiligers dat ze de data niet kunnen zien. Die gegevens zijn er wel, maar gebruikers zijn niet altijd in staat om ze te analyseren. De instrumenten zijn ingebouwd, maar dat zijn vaak op ontwikkelaars gerichte API-interfaces die voor een Risk Officer soms niet zo inzichtelijk zijn”, zegt de cloudbeveiligingsdeskundige.

Henk-Jan Buist