De multi-cloud beveiligen: hoe doe je dat? 6 aandachtspunten om naar te kijken

Veel organisaties worstelen met beveiligingsvraagstukken wanneer ze hun ontwikkelomgeving – door middel van cloudoplossingen – naar een hoger niveau willen tillen. Elke variatie van de cloud heeft haar voor- en nadelen. Volgens onderzoek vinden organisaties dat het gebruik van multi-cloud riskanter is dan het gebruik van één specifieke cloudprovider. Maar waarom is dat het geval?

Voordelen van de multi-cloud

Organisaties overwegen steeds vaker een multi-cloudstrategie. Dit betekent dat applicaties niet op één cloudplatform, maar bij meerdere cloudproviders worden geïmplementeerd. Hoewel dit multi-cloudmodel extra complexiteit op het gebied van beveiliging en beheer met zich meebrengt, zijn er zeker ook voordelen: zo kun je een applicatie ontwikkelen en testen in je eigen geïsoleerde omgeving die draait in een private cloud. Vervolgens kun je de nieuwe toepassing publiceren in de productieomgeving op een public cloud. Denk hierbij aan Microsoft Azure of Amazon Web Services (AWS). Deze benadering geeft ontwikkelaars flexibiliteit en kan kostenbesparend zijn. Ook vermindert een multi-cloudaanpak afhankelijkheidsrisico’s. Je vermijdt dus een lock-in bij een bepaalde cloudprovider.

Belangrijk om te weten: de overstap naar een multi-cloudstrategie is niet inherent meer of minder veilig dan een ‘single-cloud-strategie’. Het is alleen zo dat je een aantal vraagstukken extra zorgvuldig moet overwegen als je kiest voor een multi-cloudimplementatie. Hieronder hebben we een zestal aandachtspunten uitgelicht.

‍

1. Authenticatie en autorisatie

Ervoor zorgen dat gebruikers, beheerders en systeemcomponenten de juiste toegangsrechten hebben tot de verschillende delen van je applicaties is ongetwijfeld een belangrijk onderdeel van je IT-beleid. In een multi-cloudomgeving is deze taak vaak wat complexer dan in een single-cloud. Kies daarom een framework dat wordt ondersteund op verschillende cloudomgevingen. Er is namelijk geen garantie dat de gekozen oplossing van cloudprovider A in de toekomst ook zal blijven werken op cloudprovider B of cloudprovider C tijdens de gehele levensloop van je applicatie.

Verschillende applicatiecomponenten kunnen zich ook verplaatsen gedurende de levenscyclus van je applicatie. Zorg er daarom voor dat je een beleid maakt op basis van de behoefte van de applicatie. Hiermee zorg je ervoor dat je ontwikkelt volgens jouw eisen en blijf je altijd ‘in control’. Je bent dus nooit afhankelijk van de eisen en verwachtingen van de infrastructuur van een bepaalde cloudprovider.

2. Blijf up-to-date

Of je nu virtuele machines (VM’s), containers of een serverless gebruikt; zorg er altijd voor dat je workloads up-to-date zijn. Met andere woorden, verzeker je ervan dat ze de meest recente versie van alle beschikbare afhankelijke bibliotheken, kernels of services gebruiken. Voor sommige ontwikkelplatformen betekent dit upgraden of patchen, terwijl voor een container het herbouwen met de nieuwste containerafbeelding genoeg kan zijn. Voor anderen services hoef je wellicht alleen de recente dependencies te herladen.

Natuurlijk nemen ook de gevaren van downtime af wanneer je een multi-cloudstrategie toepast. Je bent tenslotte niet afhankelijk van de risico’s van één bepaalde cloudinfrastructuur. De keerzijde is dat je er bij een multi-cloudomgeving wel rekening mee dient te houden dat kwetsbaarheden bij elke cloudinfrastructuur anders zijn. Je zult dus meer zorg moeten dragen voor het beschermen van jouw applicaties tegen deze verschillende kwetsbaarheden op infrastructureel vlak.

3. Welke API’s maken je kwetsbaar?

Je moet niet alleen geregeld patchen en updaten, maar er tevens voor zorgen dat jouw applicaties beschermd zijn tegen aanvallen en het misbruiken van kwetsbaarheden. Voor een applicatie met componenten in meerdere clouds, of voor implementaties waarbij applicaties met elkaar in meerdere clouds communiceren, wordt het bijhouden van deze kwetsbaarheden in een multi-cloud alleen maar complexer.

Een API extern beschikbaar maken, zonder de juiste toegangsrechten, kan desastreuze gevolgen hebben. Daarom zul je te allen tijde moeten weten welke API’s (extern) aangesproken kunnen worden, wie welke controle hierover heeft en welke acties je kunt ondernemen als de API’s worden aangevallen. Dit zijn allemaal zaken die zorgvuldig management vereisen.

4. Houd toezicht op wat er gebeurt

Waar je in het verleden misschien blind vertrouwde op de tools van een bepaalde cloudprovider of gebruikmaakte van een oplossing die uitsluitend gericht was op je lokale implementatie, zal elke toekomstige monitoringsoplossing volledig op de hoogte moeten zijn van de totale omvang van je multi-cloudimplementatie.

Want als er zich een probleem voordoet op je applicatie, en zelfs één set gegevens van cloudprovider A niet overeenkomt met of verouderd is bij cloudprovider B, wordt het uitvoeren van analyses een stuk gecompliceerder of zelfs geheel onmogelijk. Laat staan dat je preventief actie kunt ondernemen en vroegtijdig klanten kunt informeren. Een consistente en up-to-date weergave van de infrastructuur is daarom van vitaal belang.

5. Encryptie van opslag is belangrijk

Bij het ontwerpen van cloudinfrastructuren is dataopslag al vaak een onderwerp van extra aandacht. En dat wordt zeker niet minder in een multi-cloudinfrastructuur. Toch is databeveiliging in de vorm van versleuteling (dus niet te verwarren met rechten op bestanden) niet het eerste waar mensen aan denken bij het ontwikkelen van een opslagoplossing. Maar dit zou wel een belangrijke vereiste moeten zijn.

Het waarborgen van compatibiliteit, in combinatie met dataversleuteling door middel van SSL-certificaten, kan een zeer complexe onderneming worden, zeker in een multi-cloudinfrastuctuur. Het is minstens zo belangrijk als de opslagoplossing zelf. Zorg er daarom voor dat je bij het ontwerpen van een storage-oplossing van meet af aan voldoende oog hebt voor databeveiliging.

6. Houd controle over je applicatie

Steeds meer organisaties gebruiken Openshift of Kubernetes om containers te beheren. Alle communicatie met dergelijke taakplannings-, monitorings- of routingapplicaties moet natuurlijk worden versleuteld. Tegelijkertijd moeten alle cloudserviceproviders versleutelde toegang bieden tot al hun tools. Maar hoe zit het met de beheer-, logboek- en auditfunctionaliteit van je eigen applicatie? Deze aspecten zijn net zo belangrijk. Zorg er daarom voor dat deze onderdelen niet onbewust een zwakke plek zijn en daardoor een beveiligingsrisico vormen.

Conclusie

Er zijn natuurlijk nog veel meer vraagstukken die je moet overwegen als je aan de slag gaat met een multi-cloud. Bovendien zijn de aandachtspunten die we hierboven hebben beschreven niet uniek voor multi-cloud: ze zijn net zo relevant voor lokale en hybride cloudimplementaties. De overstap naar multi-cloud vereist echter een zorgvuldigere afweging vanwege de complexiteit die een multi-cloudinfrastructuur met zich meebrengt. Beveiliging is een belangrijk onderdeel en zal ‘top of mind’ moeten zijn tijdens het bedenken, plannen en ontwikkelen van je OTAP-strategie.