Wat is Cloud Native Security? Alles wat je moet weten

Wat is het doel van Cloud Native security?

Het doel van Cloud Native security is om bescherming te bieden tegen bedreigingen en kwetsbaarheden die specifiek zijn voor cloudomgevingen door gebruik te maken van Cloud Native securityoplossingen. Door beveiliging in elke fase van de softwarelevenscyclus te hebben, kunnen applicaties in de cloud continu worden beschermd en veerkrachtig zijn.

Leestip: Wat is cloud security?

Traditionele Security vs Cloud Native: Hoe het verschilt

De beveiligingsaanpak voor Cloud Native-applicaties verschilt van traditionele on-premise oplossingen omdat Cloud Native-omgevingen dynamischer en schaalbaarder zijn en een "shared responsibility" hebben tussen de cloudprovider en de klant.

Cloud Native security is van binnenuit ingebouwd, waarbij applicaties continu worden gemonitord en tijdens runtime worden beschermd. 

Traditionele security is gebouwd voor statische omgevingen met vaste IP's, geïsoleerde systemen (hardware of hypervisor) en persistente workloads. Cloud Native-omgevingen zijn daarentegen dynamisch en workloads worden voortdurend op en neer bewogen. 

In plaats van problemen in productie op te lossen, moeten we beveiliging nu eerder in het ontwikkelproces integreren (shift-left). Dit komt door frequente geautomatiseerde releases in de CI- en CD-pijplijn. 

Traditionele methoden omvatten propriëtaire code en weinig open-source. Dit nieuwe model vereist echter een analyse van de samenstelling van software, het scannen op kwetsbaarheden en SBOM. SBOM geeft inzicht in de componenten van een software supply chain en is cruciaal voor het verminderen van veiligheidsrisico's in de supply chain.

Netwerkbeveiliging, die vroeger gebaseerd was op statische hardwareconfiguraties, moet zich nu aanpassen aan een dynamische omgeving. Om het netwerk te beveiligen worden permanente adressen vervangen door wisselende adressen op subnetniveau, waarbij de identiteit moet worden geverifieerd over beveiligingsgroepen, resourcegroepen en labels. Op deze manier kan het verkeer worden gecontroleerd terwijl pods worden georkestreerd.

Met de opkomst van multi-clouds moeten organisaties zich richten op de beveiligingsconfiguraties van hun cloudprovider, niet op de infrastructuur zelf. Dit verandert de manier waarop we denken over beveiliging in een Cloud Native-wereld.

De 4 C’s van Cloud Native security

Als het gaat om Cloud Native security, zijn er vier primaire lagen om te overwegen voor container security:

1. Cloud
2. Cluster
3. Container (Pod)
4. Code

De volgorde is belangrijk omdat elke laag van het Cloud Native-beveiligingsmodel voortbouwt op de volgende, buitenste laag. We noemen dit ook wel “verdediging in de diepte”. Het is een reeks defensieve mechanismen in lagen om waardevolle gegevens en informatie te beschermen. 

Stel je voor: iemand probeert toegang te krijgen tot je gegevens. Welke beschermingslagen moeten ze dan binnendringen?

1) De eerste laag is de cloudlaag (Microsoft Azure).
2) Dan hebben we de clusterlaag (Kubernetes).
3) De derde laag zijn de containers, beheerd door Kubernetes, die je applicatie en de runtime verpakken voor een consistente werking.
4) Tot slot heb je je code, die ook je gegevens of informatie kan bevatten.

We zullen ze hieronder in detail bespreken:

1. Cloud

De cloudlaag wordt ook wel de basislaag genoemd, omdat het de fundering is voor alle andere lagen. Dit is de infrastructuur waarop je clouddiensten draaien. 

Dit is de eerste laag waar je doorheen moet voordat je bij de andere lagen komt. Als deze laag zwak is (of verkeerd geconfigureerd), zijn de componenten die hierop worden gebouwd niet gegarandeerd veilig.

Beveiliging op deze laag hangt af van beheerde of zelfbeheerde infrastructuur. Voor beheerde infrastructuur kun je denken aan Infrastructure as a Service (IaaS) van een cloud service provider (CSP) zoals Azure. Bij beheerde infrastructuur beheert de cloudprovider het grootste deel van de beveiliging, maar je moet nog steeds zelf een deel beheren. 

Veel voorkomende beveiligingsproblemen in de cloudlaag doen zich voor bij Identity Access Management (IAM). Voorbeelden hiervan zijn verkeerde configuraties, zoals onjuist ingestelde machtigingen en te tolerante rollen. Aanvallers kunnen ook misbruik maken van onbeveiligde bronnen. Geautomatiseerde tools scannen op deze kwetsbaarheden en voeren aanvallen uit.

2. Cluster

De clusterlaag bestaat uit Kubernetes-componenten, waaronder de worker nodes en de control plane. Dit is waar je je Kubernetes workloads beveiligt. Kubernetes gebruikt versleutelde communicatiekanalen zoals TLS (Transport Layer Security) om de gegevens te beschermen terwijl ze tussen de componenten bewegen.

1. Componenten van het cluster

Beveiligen van configureerbare clusteronderdelen:

• Toegang tot de Kubernetes API beheren
  • Gebruik Transport Layer Security (TLS) voor al het API-verkeer
  • API-authenticatie
  • API autorisatie
• Toegang tot Kubelet beheren
  
• De mogelijkheden van een workload of gebruiker tijdens runtime beheren
  
  • Bepalen met welke privileges containers draaien
  • Het gebruik van resources op het cluster beperken
  • Netwerktoegang beperken
  • Toegang tot cloud metadata API's beperken
  • Bepalen tot welke nodes pods toegang hebben
• Clustercomponenten beschermen tegen compromis
  
  • Toegang tot etcd beperken
  • Audit logging inschakelen
  • Beperk de toegang tot alfa- of bètafuncties
  • Draai infrastructuur referenties regelmatig
  • Controleer integraties met derden voordat je ze inschakelt
  • Versleutel secrets
  • Waarschuwingen ontvangen voor beveiligingsupdates en kwetsbaarheden melden

Als je Kubernetes gebruikt, heb je toegang tot alle componenten eronder. Maar je bent ook meer verantwoordelijk voor het beveiligen van deze componenten. Er zijn veel manieren om ze te beveiligen. Laten we eens kijken:

Het meest kritieke onderdeel van het cluster is de Kube API Server, die alle communicatie binnen het cluster beheert. Net als de voordeur van je huis, is dit het belangrijkste toegangspunt van het cluster. Met toegang tot deze server krijgt je volledige controle en kun je alles doen.

Alleen admins en geauthenticeerde gebruikers hebben toegang tot deze server. We moeten het dus beschermen. Je kunt het verder beschermen door wederzijdse TLS authenticatie en netwerk toegangscontrolelijsten te implementeren om toegang te beperken tot vertrouwde bronnen.

Je zou RBAC (role-based access control) moeten gebruiken om de toegang tot clusterbronnen te beperken. Dit zorgt ervoor dat alleen degenen die rechten nodig hebben deze krijgen.

Ook moet Pod Security Admission worden afgedwongen in Kubernetes om beveiligingseisen te definiëren voor draaiende pods en veilig netwerkbeleid om communicatie tussen verschillende clusterdelen te beperken. Dit zal het aanvalsoppervlak verkleinen. Laten we nu eens kijken hoe we applicaties die in het cluster draaien kunnen beveiligen.

2. Componenten in het cluster

Het beveiligen van de applicaties die binnen het cluster draaien:

• Role-Based Access Control (RBAC) Autorisatie - (Toegang tot de Kubernetes API)
• Authenticatie
• TLS voor Kubernetes-ingress
• Applicatiegeheimen beheren (en in rust versleutelen in etcd)
• Ervoor zorgen dat pods zich houden aan gespecificeerde podbeveiligingsstandaarden
• Kwaliteit van service (en beheer van clusterbronnen)
  Netwerkbeleid

Zoals je kunt zien, is er een verschil tussen het beveiligen van de onderdelen van het cluster en de applicaties die erin draaien.

Elk vereist verschillende tools en benaderingen om je Cloud Native omgeving volledig te beschermen. Leer meer over hoe je de beveiliging van je AKS cluster kan verbeteren.

3. Container

Containers zijn een fundamenteel onderdeel van Cloud Native-architecturen, maar moeten worden beveiligd. De containerlaag bevat images die kwetsbaarheden kunnen bevatten waarop je kunt scannen.

Om je containers te beveiligen, moet je ervoor zorgen dat images:

1. Vrij zijn van kwetsbaarheden
2. Up-to-date zijn
3. Beheerd worden gedurende hun levenscyclus

Een veelgemaakte fout is het gebruik van images van onbekende bronnen. Ook wordt er vaak niet gecontroleerd op verouderde of onveilige configuraties in de containers.

Een tip is om ervoor te zorgen dat je images van een vertrouwde bron komen. Als je publieke container images gebruikt, zorg er dan voor dat ze van een bekend, geverifieerd register komen.

Draai containers ook niet met te veel toegang of privileges. Containers moeten niet als “root” of toegang op hoog niveau draaien; dit kan je systeem blootstellen aan aanvallen als er iets misgaat. Draai containers altijd met beperkte rechten om het risico zo laag mogelijk te houden.

Overweeg om bevoorrechte gebruikers niet toe te staan. Gebruik een container runtime met betere isolatie voor extra beveiliging. Dit kan bijvoorbeeld het gebruik van een distroless image zijn. 

4. Code

De applicatiecode zelf is een van de primaire aanvalsoppervlakken waar je de meeste controle over hebt. In een ''shared responsibility'' model is de cloud service provider (CSP) verantwoordelijk voor het grootste deel van je infrastructuurbeveiliging (fysieke datacenters, netwerk, hypervisors etc.).

Maar als gebruiker ben je verantwoordelijk voor je applicaties, gegevens en configuraties binnen de cloudomgeving.

Tips om beveiligingspraktijken te implementeren:

• Alleen toegang via TLS: Zorg ervoor dat je alleen HTTPS gebruikt voor je app.
• Poortbereiken beperken: Zoals het beperken van databasetoegang tot alleen je IP-adres.
• Voer statische codeanalyse uit: zoek zwakke punten of slechte codeerpraktijken in de broncode zelf.
• Regelmatig patchen: blijf altijd op de hoogte van patches of updates voor open-source bibliotheken die je gebruikt, vooral degene met beveiligingslekken.
• Scannen op afhankelijkheden: gebruik tools om te scannen op kwetsbaarheden in bibliotheken van derden voordat je ze toevoegt aan je codebase.
• Minimaliseer de afhankelijkheid van open-source bibliotheken: Hoe meer code van derden je gebruikt, hoe groter je aanvalsoppervlak wordt en hoe groter het risico op kwetsbaarheden.
• Maak een SBOM: Doe dit als je open-source bibliotheken gebruikt (heel gebruikelijk in moderne apps), omdat componenten van derden beveiligingsproblemen kunnen hebben. SBOM's helpen je om componenten te identificeren die developers direct in de source code van de applicatie hebben geïntegreerd, evenals de afhankelijkheden. Het geeft je de mogelijkheid om potentiële beveiligingsrisico's te detecteren.

Cloud Native security uitdagingen

Cloud Native-architecturen bieden meer schaalbaarheid en flexibiliteit, maar brengen hun eigen beveiligingsuitdagingen met zich mee:

Efemere en dynamische aard

Cloud Native introduceert nieuwe beveiligingsuitdagingen vanwege het efemere en dynamische karakter. In tegenstelling tot traditionele omgevingen waar applicaties op langlevende virtuele machines (VM's) draaien, brengen Cloud Native-omgevingen (containers en serverless) meer verandering met zich mee. Containers komen en gaan op basis van applicatie-updates of belasting en vraag, dus er is meer verandering in de omgeving.

Meer complexiteit

Cloud Native-applicaties zijn kwetsbaarder vanwege hun complexiteit en schaal. Een traditionele 3-tier app op een paar VM's bevat nu honderden microservices. En die hebben allemaal beveiliging nodig. Het beveiligen van meerdere lagen, zoals cloud, clusters en code, is complex. Een verkeerde configuratie in een van deze lagen kan een kwetsbaarheid vormen.

Verhoogd aanvalsoppervlak

In Cloud Native-applicaties is er niet één beveiligingsperimeter. In plaats daarvan zijn er veel losjes verbonden componenten, zoals microservices en containers. Elk van deze componenten kan een manier zijn om het systeem aan te vallen of binnen te dringen.

Met meer microservices en containers in productie, wordt het aanvalsoppervlak groter. Aanvallers kunnen veel onderdelen van de architectuur tegelijkertijd aanvallen, waardoor het moeilijker te beveiligen is dan een gecentraliseerd systeem.

Niet-beveiligde defaults

Containers, serverloze functies, virtuele machines en Kubernetes-clusters zijn standaard niet beveiligd. Ze moeten voor gebruik worden geconfigureerd met beveiliging.

Een enkele verkeerde configuratie, onveilige container of serverless functie-implementatie kan ernstige kwetsbaarheden veroorzaken. Dit kan leiden tot datalekken of systeemstoringen. Je moet applicaties in alle omgevingen monitoren om ervoor te zorgen dat beveiligingsconfiguraties worden ingesteld en onderhouden.

Maar de risico's van menselijke fouten in de cloud zullen altijd aanwezig zijn. 

Dynamische applicatietopologieën

Je kunt je applicatie in de cloud op elk moment schalen van een paar containers naar honderden, zo niet duizenden. Wanneer je dat doet, moet je nadenken over het beveiligen van je applicatie wanneer deze op- en afschaalt en van vorm verandert, zoals wanneer je nieuwe clusters toevoegt.

Een deel daarvan moet gebeuren op het niveau van de containerafbeelding. Denk aan het beveiligen van de image. Het mag geen kwetsbaarheden, verouderde bibliotheken of ongebruikte componenten bevatten.

Continue ontwikkeling en implementatie

De industrie is overgestapt op continue ontwikkeling en implementatie. Dit introduceert meer beveiligingsuitdagingen. Met CI/CD-pijplijnen worden wijzigingen voortdurend naar productie geduwd en is er vaak niet genoeg tijd voor grondige beveiligingscontroles. Dit tempo van veranderingen verhoogt het risico op het introduceren van kwetsbaarheden.

Shift naar developers

Een grote uitdaging in Cloud Native beveiliging is dat ontwikkelaars nu verantwoordelijk zijn voor het beveiligen van apps. In traditionele omgevingen zorgde het operations-team voor updates en beveiligingspatches. In Cloud Native-omgevingen moeten ontwikkelaars de container-images maken en bijwerken.

Ontwikkelaars moeten zich meer bewust zijn van beveiligingslekken in hun frameworks en bibliotheken.

Culturele en operationele veranderingen

Dit is een grotere culturele en operationele shift in de manier waarop organisaties beveiliging benaderen. In een Cloud Native-wereld is beveiliging geen bijzaak of een laatste controle voor implementatie.

Dit betekent een nieuwe mindset waarbij beveiliging in elke ontwikkelingsfase wordt ingebouwd, niet alleen aan het einde. Ontwikkelaars, operators en beveiligingsteams moeten samenwerken.

Cloud Native security best practices

Nu steeds meer organisaties migreren naar Cloud Native-omgevingen, veranderen beveiligingsbenaderingen.

Traditionele beveiligingsbenaderingen werken voor on-premises systemen. Maar ze schalen vaak niet en passen zich niet aan de voor de cloud.

Hier zijn enkele best practices voor Cloud Native-beveiliging:

1. Shared Security Responsibility

Je deelt de security responsibility met de cloud service providers. Deze (gedeelde) verantwoordelijkheden voor het beheer van infrastructuur, platforms en applicaties variëren. Het hangt ervan af welke cloud service je gebruikt – IaaS, PaaS of SaaS.

Omdat een deel van de verantwoordelijkheid echter bij hen ligt, heb je deels geen controle. Traditionele netwerkgebaseerde of hostgebaseerde beveiligingsmethoden schieten mogelijk ook tekort.

Gebruik daarom de first-party tools van je cloudprovider om beveiligingsproblemen te controleren en op te lossen.

2. Shift Security Left

In Cloud Native-omgevingen moeten ontwikkelaars beveiliging al vroeg in de ontwikkelingscyclus integreren. Dit wordt ook wel 'shifting security left' genoemd. Een voorbeeld is een kwetsbaarheidsscan.

Pas een DevSecOps-benadering toe. Het vereist dat de dev, ops en security teams nauw samenwerken. Ze moeten beveiligingspraktijken in de hele softwarelevenscyclus integreren. Het gaat erom problemen te voorkomen voordat ze zich voordoen en beveiliging niet als een bijzaak of laatste stap voor implementatie te beschouwen.

Dit betekent dat alle onderdelen (code, containers, serverloze functies en infrastructuur) worden gebouwd met beveiliging als topprioriteit.

3. Automatiseer beveiliging

Automatisering is cruciaal om het snelle tempo van Cloud Native-omgevingen bij te houden. Samen met technologie zorgt het voor snellere ontwikkeling en het handhaven van continue beveiliging. Het vermindert menselijke fouten en verbetert de schaalbaarheid. Het geeft beveiligingsteams de ruimte om zich te richten op bedreigingsmodellering en risicobeheer.

Automatiseer beveiligingstaken zoals kwetsbaarheidsscans en patchbeheer waar mogelijk.

4. Securing Dependencies

Je app-code heeft waarschijnlijk open-source-afhankelijkheden. Om deze te beveiligen, raden we aan om geautomatiseerde tools te gebruiken met volledige kwetsbaarheidsdatabases.

Je hebt ook orkestratietools nodig die applicatiebeveiligingsactiviteiten activeren tijdens de ontwikkeling. Zorg ervoor dat deze tools continu worden uitgevoerd. Ze moeten kwetsbare afhankelijkheden detecteren en voorkomen in containers of serverloze functies die toegang hebben tot je productieomgeving.

5. API vulnerabilities

API's vormen de ruggengraat van Cloud Native-apps. Zwakke punten in API-beveiliging kunnen gevoelige gegevens blootstellen of ongeautoriseerde toegang toestaan.

Zorg er dus voor dat API's HTTPS gebruiken voor veilige communicatie om gegevens tijdens het transport te beschermen. De beste manier om API's te beveiligen, is door stateless API's te gebruiken. 

6. Maak gebruik van Security as Code

Security as Code is een aanpak waarbij beveiligingsconfiguraties en -beleid worden gedefinieerd en beheerd als onderdeel van de codebase. Dit betekent consistente beveiligingsconfiguraties in alle ontwikkelings-, fase- of productieomgevingen. Infrastructure as Code (IaC)-tools kunnen de provisioning van veilige cloudbronnen automatiseren. 

Conclusie

In dit artikel werd besproken hoe we beveiliging moeten opsplitsen in kleinere taken en deze in de hele ontwikkeling moeten integreren. Beveiligingsarchitectuur en testen moeten continu zijn (en, waar van toepassing, automatisch).

Cloud Native-beveiliging is een voortdurende inspanning, geen eenmalige oplossing die je aan het einde toepast (zoals in traditionele apps).

Door Cloud Native-beveiligingsmaatregelen te implementeren, kun je  je Cloud Native-apps en -gegevens beschermen tegen beveiligingsrisico's en een veilige en conforme cloudomgeving hebben.