Ja, containers zijn geweldig, maar let op de beveiligingsrisico’s

Cyberbeveiliging van containers Nachrichten

Containers hebben een revolutie teweeggebracht in het ontwikkelingsproces en fungeren als een hoeksteen voor DevOps-initiatieven, maar containers brengen complexe beveiligingsrisico’s met zich mee die niet altijd duidelijk zijn. Organisaties die deze risico’s niet mitigeren, zijn kwetsbaar voor aanvallen.

In dit artikel schetsen we hoe containers hebben bijgedragen aan agile ontwikkeling, welke unieke beveiligingsrisico’s containers in beeld brengen – en wat organisaties kunnen doen om gecontaineriseerde workloads te beveiligen, die verder gaan dan DevOps om te bereiken DevSecOps.

Waarom sloegen containers zo snel aan?

Containers zijn in veel opzichten de evolutie van virtualisatie. Het doel was om het ontwikkelingsproces te versnellen en een meer flexibele route te creëren van ontwikkeling tot testen en implementatie – een methode die hoe dan ook lichter is dan het gebruik van volwaardige virtuele machines.

De kern van dit probleem is de compatibiliteit van applicaties, aangezien applicaties bepaalde versies van bibliotheken vereisen, wat kan botsen met de vereisten van andere applicaties. Containers losten dit probleem op en sloot goed aan op ontwikkelprocessen en de beheerinfrastructuur die deze processen aanstuurt.

Containers doen hun werk door virtualisatie naar een hoger niveau te tillen. Virtualisatie abstraheert de hardwarelaag, terwijl containers de besturingssysteemlaag abstraheren, waardoor in wezen de rol van het besturingssysteem wordt gevirtualiseerd. Containerisatie werkt door applicaties te verpakken in „containers“ die alle benodigde bibliotheken bevatten om een ​​applicatie te laten werken, terwijl applicaties niet van elkaar op de hoogte zijn omdat elke app denkt dat hij het besturingssysteem voor zichzelf heeft.

Functioneel zijn containers vrij eenvoudig: een container is slechts een tekstbestand met een beschrijving die aangeeft welke componenten in een instantie moeten worden opgenomen. Deze eenvoud en het lichtere karakter van een container maken het gemakkelijk om automatiseringstools (orkestratie) te gebruiken voor implementatie gedurende de ontwikkelingslevenscyclus.

DevOps voor de overwinning… maar beveiliging is ook belangrijk

Containers hebben de kracht om de ontwikkelingsefficiëntie aanzienlijk te verhogen en fungeren als de sleutels die DevOps ontgrendelen. Dat is waarschijnlijk een van de belangrijkste redenen waarom containers zo breed zijn aangeslagen, en Gartner schat dat tegen 2023, 70% van de organisaties zal gecontaineriseerde workloads uitvoeren.

Het proces van het ontwikkelen, testen en implementeren van apps zat vroeger vol obstakels, met een constant heen en weer tussen ontwikkelaars en de teams die voor de infrastructuur zorgden. Dankzij containers kunnen ontwikkelaars tegenwoordig bouwen en testen in een omgeving die werkt en eenvoudig de voltooide code verzenden naast een specificatie die die omgeving definieert.

Aan de operationele kant voeren teams deze specificatie alleen uit om een ​​passende, gebruiksklare omgeving te creëren. „Ja, maar het werkt op mijn computer…“ heeft nooit geholpen om het probleem op te lossen – maar tegenwoordig is dat een uitdrukking die ontwikkelaars niet langer hoeven te gebruiken omdat er geen omgevingsproblemen zijn om te debuggen.

Dus ja, DevOps betekent snelle ontwikkeling. Maar er ontbreekt een onderdeel: beveiliging. Dit is de reden waarom we steeds vaker over DevSecOps horen naarmate het voortkomt uit DevOps, omdat ontwikkelaars hebben gemerkt dat het DevOps-model alleen onvoldoende beveiligingsproblemen oplost.

Containers introduceren verschillende beveiligingsrisico’s

Containers vereenvoudigen het ontwikkelingsproces, maar introduceren complexiteit in het beveiligingsbeeld. Wanneer u een volledige besturingsomgeving stevig in een container verpakt om deze op grote schaal te verspreiden, vergroot u ook het aanvalsoppervlak en opent u de deur naar verschillende aanvalsvectoren. Alle kwetsbare bibliotheken die bij de container zijn verpakt, verspreiden deze kwetsbaarheden over talloze workloads.

Er zijn verschillende risico’s. Een daarvan is een „supply chain-aanval“ waarbij een kwaadwillende actor een aanval uitvoert, niet door te knoeien met uw applicatie, maar door een van de pakketten of componenten te wijzigen die bij uw applicatie zijn geleverd. Teams die zich bezighouden met ontwikkelingsinspanningen, moeten dus de applicatie die ze ontwikkelen beoordelen en elke bibliotheek die door de containerconfiguratie als een afhankelijkheid wordt ingeschakeld.

De risico’s voor containerbeveiliging hebben ook betrekking op de tools die containers mogelijk maken – van Dockers tot orkestratietools zoals Kubernetes, omdat deze tools moeten worden gecontroleerd en beschermd. U moet bijvoorbeeld niet toestaan ​​dat sysadmins Docker-containers als root uitvoeren. Evenzo moet u uw containerregisters nauwlettend in de gaten houden om ervoor te zorgen dat deze niet worden aangetast.

Kernelbeveiliging vormt de kern van containerbeveiliging

Sommige containergerelateerde veiligheidsrisico’s zijn minder zichtbaar dan andere. Elke container heeft toegang tot een kernel nodig – containers zijn immers slechts een soort geavanceerde procesisolatie. Maar het is gemakkelijk om het feit te missen dat alle containers op dezelfde kernel vertrouwen – het maakt niet uit dat de applicaties in de containers van elkaar gescheiden zijn.

De kernel die apps in een container zien, is dezelfde als de kernel waarop de host vertrouwt om te werken. Het brengt een aantal problemen met zich mee. Als de kernel op de host die de container ondersteunt kwetsbaar is voor misbruik, kan dit beveiligingslek worden misbruikt door een aanval te starten vanuit een app in een container.

Het feit dat de kernel door alle containers op de host wordt gedeeld, betekent dat een defecte kernel snel moet worden gepatcht, anders kunnen alle containers snel worden getroffen door de kwetsbaarheid.

Nogmaals, het komt neer op patchen

Het up-to-date houden van de host-kernel is daarom een ​​belangrijke stap in het verzekeren van veilige en beveiligde containeroperaties. En het is niet alleen de kernel die moet worden gepatcht, patches moeten worden toegepast op de bibliotheken die door een container worden binnengehaald. Maar zoals we weten, is consequent patchen makkelijker gezegd dan gedaan. Dat is waarschijnlijk waarom één onderzoek wees uit dat 75% van de geanalyseerde containers een kwetsbaarheid bevatte dat is geclassificeerd als kritiek of hoog risico.

Deze kwetsbaarheden kunnen bijvoorbeeld leiden tot breakout-aanvallen waarbij een aanvaller vertrouwt op een gebrekkige bibliotheek in een container om code buiten de container uit te kunnen voeren. Door één container te doorbreken, kan de aanvaller uiteindelijk het beoogde doel bereiken, of dat nu het hostsysteem is of een toepassing in een andere container.

In de context van containers kan het onderhouden van veilige bibliotheken een echte hoofdpijn zijn – iemand moet nieuwe kwetsbaarheden volgen, evenals wat er is gepatcht en wat niet. Het proces is arbeidsintensief, maar het vereist ook specialistische vaardigheden, iets wat uw organisatie zou moeten verwerven als het deze nog niet heeft.

Gezien de waarde van regelmatig, consistent patchen, zouden deze redenen niet voldoende moeten zijn om het soort hit-and-miss patching-routines te veroorzaken dat we zien, maar – vooral als we denken aan de OS-kernel – de verstoring van de vereiste herstart en de bijbehorende noodzaak om downtime-vensters te behouden, kan het patchen aanzienlijk vertragen. Live kernel patchen helpt dit probleem te verminderen, maar wordt nog niet door alle organisaties geïmplementeerd.

Neem altijd beveiligingsdoelen op in uw containerops

Het is gebruikelijk dat geavanceerde technologie nieuwe complicaties introduceert als het gaat om informatiebeveiliging. Nieuwe tools leiden vaak tot nieuwe en nieuwe exploits. Dat geldt ook voor containers en hoewel het de algehele waarde van het gebruik van containers in uw workloads niet ondermijnt, betekent het wel dat u de risico’s van containers in de gaten moet houden.

Het is een begin om uw ontwikkelaars en systeembeheerders voor te lichten over de veelvoorkomende fouten in containerbeveiliging en de best practices om deze fouten te verhelpen. Patchen is een ander belangrijk aspect. Zoals altijd zal het nemen van de juiste stappen om cyberbeveiligingsfouten te verminderen, uw organisatie helpen beschermen – en uw team laten profiteren van die geavanceerde technologie zonder slapeloze nachten te krijgen.

David
Rate author
Hackarizona