Wat is de beveiliging van containerimages?

Volgens Forrester gebruikt 71% van de DevOps teams containers en microservices om applicaties te leveren. Containers zijn licht en modulair, zodat u een service kunt bijwerken zonder dat dit een ander deel van het systeem verstoort.

Containerisatie brengt echter eigen uitdagingen met zich mee. Zo moeten we problemen rond de beveiliging van containerimages aanpakken.

Elk containerimage bevat metadata over de omgeving en hardware van de containers, zoals configuratiegegevens, systeempaden en hardwaretoegang. Als deze metadata niet goed worden beheerd, kunnen gevoelige gegevens worden blootgesteld.

Ook zwakke beveiligingspraktijken, zoals slecht wachtwoordbeheer of verkeerde configuraties binnen de container, kunnen aanvallers toegang bieden. Zij kunnen deze kwetsbaarheden misbruiken om de container binnen te dringen. Daardoor kan de volledige cloudinfrastructuur in gevaar komen, met ongeautoriseerde toegang, gegevensverlies of systeemuitval tot gevolg.

Om deze kwetsbaarheden te beperken, moeten DevOps-teams beveiliging vroeg in de beheercyclus van containerimages integreren. Met een “shift-left”-aanpak—waarbij beveiligingscontroles en best practices vroeg worden ingebouwd—en door containerimages consequent te bewaken, worden potentiële zwakke plekken vóór de implementatie ontdekt. Zo blijven applicaties en infrastructuur beschermd tegen aanvallen.

Wat is de beveiliging van containerimages?

De beveiliging van containerimages is een brede aanpak die waarborgt dat de containerimages in uw omgeving afkomstig zijn van betrouwbare bronnen en vrij zijn van kwetsbaarheden, malware en andere beveiligingsrisico's.

Daarbij controleert u of het basisimage, de bibliotheken en eventuele aangepaste componenten in uw Dockerfile uit betrouwbare bronnen komen en niet zijn gemanipuleerd.

Basisimages zoals Alpine, Ubuntu en BusyBox vormen doorgaans de basislagen waaraan andere componenten worden toegevoegd. Elke toevoeging creëert een nieuwe imagelaag. Regelmatige beveiligingsscans zijn essentieel om de integriteit van deze lagen te waarborgen.

Het scannen van containerimages op beveiligingsrisico's is hierbij een van de belangrijkste taken. Gespecialiseerde tools scannen images op bekende kwetsbaarheden en zoeken specifiek naar verouderde bibliotheken, onveilige configuraties en andere kwetsbaarheden die in een productieomgeving kunnen worden misbruikt.

Beveiligingsscans voor Docker-images richten zich specifiek op Docker-images. Omdat Docker veel wordt gebruikt, zijn deze scans bijzonder belangrijk. Ze zoeken naar kwetsbaarheden door verouderde software of onveilige instellingen, die uiteindelijk de Docker-runtimeomgeving in gevaar brengen.

Waarom is imagebeveiliging cruciaal voor containers?

In een containeromgeving vormt imagebeveiliging de basis voor de integriteit en betrouwbaarheid van uw applicaties.

Een containerimage bevat alles wat een applicatie nodig heeft om te draaien. Als het image wordt gecompromitteerd, kan dat leiden tot een ernstig beveiligingsincident dat uw volledige infrastructuur raakt.

1. CVSS-scores

Het Common Vulnerability Scoring System (CVSS) is een veelgebruikt raamwerk om de ernst van kwetsbaarheden in containerimages en andere softwaresystemen te beoordelen.

CVSS-scores bieden organisaties een gestandaardiseerde risicomaatstaf om de aanpak van kwetsbaarheden te prioriteren. De scores worden berekend op basis van verschillende factoren, waaronder de mate waarin een kwetsbaarheid kan worden misbruikt, de impact op het systeem en de mogelijke schade. De CVSS-score loopt van 0 tot 10. Hoe hoger de score, hoe ernstiger de kwetsbaarheid.

Een kwetsbaarheid met een CVSS-score van 9.8 wordt als kritiek aangemerkt. Een aanvaller zou daarmee mogelijk op afstand willekeurige code kunnen uitvoeren met minimale tussenkomst van een gebruiker. Deze ernst vereist vaak onmiddellijk herstel om misbruik te voorkomen. Een kwetsbaarheid met een lagere score kan minder kritiek zijn, maar moet nog steeds worden aangepakt om het totale risico te verminderen.

Met CVSS-scores kunnen organisaties onderbouwd bepalen welke kwetsbaarheden voorrang krijgen op basis van hun potentiële impact. Zo stroomlijnen ze patchbeheer en richten ze middelen op de dringendste beveiligingsrisico's.

2. Interne opslag van images

Containerimages opslaan in private, interne registers is een belangrijke maatregel om de containerbeveiliging.

Anders dan openbare registers, die voor iedereen op internet toegankelijk zijn, bieden private registers een gecontroleerde omgeving waarin de toegang strikt kan worden beheerd. Dit is cruciaal om gevoelige of bedrijfseigen containerimages te beschermen tegen ongeautoriseerde toegang en mogelijke manipulatie.

Private registers, zoals Docker Trusted Registry (DTR) of andere producten voor ondernemingen, bieden verschillende voordelen ten opzichte van openbare repositories. Organisaties kunnen strenge toegangscontroles afdwingen, zodat alleen bevoegde gebruikers containerimages kunnen uploaden, downloaden of wijzigen. Dit verkleint het risico dat schadelijke code in de images terechtkomt.

Private registers bevatten vaak ook ingebouwde beveiligingsfuncties, zoals het digitaal ondertekenen van images. Daarmee kunt u de authenticiteit en integriteit van images verifiëren. Met digitale handtekeningen kunnen organisaties controleren of images uit betrouwbare bronnen komen en sinds hun creatie niet zijn gewijzigd.

Private registers ondersteunen ook scans op kwetsbaarheden, zodat beveiligingsproblemen kunnen worden opgespoord en verholpen voordat images worden geïmplementeerd.

3. Beveiligingsproblemen in productie- en niet-productieomgevingen

In containeromgevingen is het belangrijk om onderscheid te maken tussen productie- en niet-productieomgevingen voor effectief beveiligingsbeheer.

Productieomgevingen bevatten actieve applicaties en gevoelige gegevens. Ze vereisen strenge beveiligingsmaatregelen tegen dreigingen, waaronder krachtige toegangscontroles, regelmatige beveiligingsaudits en voortdurende monitoring om potentiële kwetsbaarheden te detecteren en erop te reageren.

In niet-productieomgevingen, zoals ontwikkel-, test- en stagingomgevingen, zijn beveiligingsmaatregelen vaak minder streng omdat snel experimenteren en bijsturen nodig is. Dat betekent echter niet dat beveiliging mag worden verwaarloosd.

Kwetsbaarheden die in niet-productieomgevingen worden ontdekt, kunnen ook productiesystemen treffen als ze niet goed worden beheerd. Daarom moeten beveiligingspraktijken in niet-productieomgevingen aansluiten op de normen voor productieomgevingen.

Ook in niet-productieomgevingen moet u bijvoorbeeld veilig programmeren, testgegevens correct verwerken en scans op kwetsbaarheden uitvoeren. Gevonden kwetsbaarheden moeten snel worden verholpen, zodat ze niet in productie terechtkomen.

Een effectieve scheiding tussen productie- en niet-productieomgevingen verkleint het risico dat kwetsbaarheden actieve systemen treffen. Bovendien zorgt dit ervoor dat beveiligingspraktijken in elke fase van de levenscyclus van een applicatie consequent worden toegepast.

4. Integriteit en verificatie van images

De integriteit van containerimages behouden is cruciaal om applicaties veilig en zoals bedoeld te laten draaien. Digitale ondertekening en cryptografische hashing zijn twee belangrijke technieken om de authenticiteit en integriteit van containerimages te verifiëren.

Digitale ondertekening van images

Bij digitale ondertekening krijgen containerimages een digitale handtekening. Die bevestigt dat de images uit betrouwbare bronnen komen en sinds hun creatie niet zijn gemanipuleerd. Dit proces gebruikt een public key infrastructure (PKI) om handtekeningen te maken en te verifiëren, zodat kan worden vastgesteld dat images authentiek zijn.

Door deze handtekeningen te valideren, kunnen organisaties voorkomen dat gecompromitteerde of schadelijke images worden geïmplementeerd.

Cryptografische hashing

Cryptografische hashes, zoals SHA-256, voegen een extra beveiligingslaag toe door voor elk image een unieke hashwaarde te genereren. Met deze hashwaarde kunnen ongeautoriseerde wijzigingen of beschadigingen worden gedetecteerd.

Door de hashwaarde van het geïmplementeerde image met die van het origineel te vergelijken, kunnen organisaties vaststellen of het image is gewijzigd. Regelmatige integriteitscontroles zorgen ervoor dat in productieomgevingen alleen veilige en ongewijzigde images worden gebruikt.

5. Isolatiemechanismen en aandachtspunten bij multitenancy

Containers zijn ontworpen om tot op zekere hoogte geïsoleerd te draaien op een hostsysteem, terwijl virtuele machines (VM) een volledige isolatielaag bieden.

VM's gebruiken hypervisors om volledig geïsoleerde omgevingen met een eigen besturingssysteem te creëren. Containers delen daarentegen de kernel van het hostsysteem. Die gedeelde kernel brengt specifieke beveiligingsuitdagingen met zich mee, vooral wanneer meerdere gebruikers of applicaties op dezelfde host werken.

Een kwetsbaarheid in één gecontaineriseerde applicatie kan een aanvaller de kans geven uit de container te ontsnappen en toegang te krijgen. Daardoor lopen de volledige applicatie—al dan niet gecontaineriseerd—en het hostsysteem risico.

Om deze uitdagingen aan te pakken, worden binnen containers verschillende isolatiemechanismen gebruikt:

• Namespaces: Linux-namespaces bieden isolatie op procesniveau. Zo werken containers in afzonderlijke namespaces voor processen, netwerkinterfaces en bestandssystemen. Namespaces beperken de zichtbaarheid en toegang van processen tot hun eigen container, maar garanderen geen volledige scheiding van het hostsysteem of andere containers.
• Controlegroepen (cgroups): Cgroups beheren en beperken de resources die aan elke container worden toegewezen, zoals CPU, geheugen en schijf-I/O. Zo kan één container niet alle systeemresources opeisen en de prestaties of stabiliteit van andere containers of het hostsysteem beïnvloeden.
• Beveiligingsmodules: Tools zoals SentinelOne handhaven aanvullende beveiligingsregels. De tool past verplichte toegangsregels toe om de toegang tot het bestandssysteem en andere mogelijkheden te beperken.

Naast isolatie en resourcebeheer is de integriteit van containerimages cruciaal voor de algehele beveiliging.

Zo beveiligt u uw containers:

• Ondertekening en verificatie van images: Gebruik digitale handtekeningen om de authenticiteit van containerimages te bevestigen. Zo weet u dat ze van vertrouwde bronnen komen en niet zijn gewijzigd.
• Cryptografische hashes: Genereer en vergelijk cryptografische hashes om te controleren of containerimages niet zijn gewijzigd of beschadigd.
• Runtimebewaking: Bewaak actieve containers voortdurend om afwijkingen of ongeautoriseerde wijzigingen te detecteren en snel op mogelijke beveiligingsincidenten te reageren.

Met deze werkwijzen beheersen organisaties de risico’s van gedeelde kernels en multitenantomgevingen, versterken ze de algehele beveiliging en beschermen ze zich tegen kwetsbaarheden.

5. Runtimebeveiliging en driftpreventie

Ook na de implementatie moet een container beveiligd blijven.

Na verloop van tijd ontstaat er enige “drift” in containers: hun actieve toestand wijkt af van de oorspronkelijke image doordat een gebruiker of applicatie de actieve instantie heeft bijgewerkt, of doordat ongeautoriseerde wijzigingen zijn aangebracht. Elke vorm van drift introduceert kwetsbaarheden die bij de oorspronkelijke implementatie nog niet aanwezig waren.

Dit kan onder meer gaan om:

• Configuratiedrift: Wijzigingen in omgevingsvariabelen, netwerkinstellingen of andere configuraties na de implementatie kunnen leiden tot verkeerde configuraties en beveiligingsproblemen.
• Softwaredrift: Updates of wijzigingen aan de software in de container kunnen nieuwe kwetsbaarheden of compatibiliteitsproblemen veroorzaken.
• Bestandssysteemdrift: Tijdelijke bestanden of logbestanden die zich tijdens runtime ophopen, kunnen de prestaties en beveiliging van de container beïnvloeden.
• Netwerkdrift: Wijzigingen in netwerkinstellingen of blootgestelde poorten kunnen nieuwe aanvalsmogelijkheden creëren of de verbinding verstoren.

Gebruik tools die containers tijdens runtime voortdurend bewaken om drift effectief te beheersen en te beperken. Deze tools detecteren afwijkingen van de oorspronkelijke configuratie en ongeautoriseerde wijzigingen, zodat u problemen snel kunt aanpakken.

Geautomatiseerde compliancecontroles handhaven beveiligingsregels en behouden de beoogde toestand van de container.

Pas daarnaast werkwijzen voor onveranderlijke infrastructuur toe—waarbij containers worden vervangen in plaats van gewijzigd—om het risico op drift verder te verkleinen en de beveiliging te versterken.

Hoe scant u containerimages op beveiligingsproblemen?

De bescherming van uw containerimages vraagt om meerdere stappen. Gebruik in de hele CI/CD-pijplijn zowel geautomatiseerde tools als goede werkwijzen.

De eerste stap is containerimages tijdens het buildproces op beveiligingsproblemen scannen. Gebruik hiervoor speciale scanners die elk onderdeel van uw containerimage onderzoeken op bekende kwetsbaarheden, waaronder veelvoorkomende kwetsbaarheden en blootstellingen (CVEs).

Deze scanners vergelijken code of onderdelen (afhankelijkheden) die risico’s kunnen opleveren. Ze controleren ook instellingen en signaleren verouderde afhankelijkheden of geheimen die in de image verborgen kunnen zitten.

De volgende stap is strenge regels voor het ondertekenen van images invoeren, zodat alleen eerder gecontroleerde images kunnen worden gebruikt. Bij deze ondertekening verifiëren codehandtekeningen waar de image vandaan komt en of niemand deze heeft gewijzigd of schadelijke code heeft toegevoegd.

Het is ook cruciaal om uw images in private containerregisters op te slaan in plaats van openbare. Het SentinelOne-platform voor bescherming van cloudworkloads (CWPP) werkt goed samen met Snyk Container, zodat gebruikers zich bij private containerregisters kunnen aanmelden.

Deze integratie vereenvoudigt de beoordeling van incidenten, voorkomt dat beveiligingsincidenten zich verspreiden in containerworkloads en pakt problemen in productie aan door ze terug te voeren naar de broncode van de applicatie. Zo verkleint u het risico op gebruik van gecompromitteerde images en gebruikt u alleen geverifieerde images.

Voeg tot slot regelmatige compliancecontroles en kwetsbaarheidsbeoordelingen toe aan uw containerbeheer. Voer deze beoordelingen op vaste tijdstippen uit. Zo voldoen alle images aan uw beveiligingsregels en eventuele wettelijke vereisten.

Veelvoorkomende kwetsbaarheden in Docker-images

Docker-images bevatten meerdere softwarelagen, elk met mogelijke kwetsbaarheden.

Dit zijn enkele van de meest voorkomende en lastigste kwetsbaarheden die kunnen optreden:

1. Verouderde en kwetsbare basisimages

Docker-images zijn vaak afhankelijk van basisimages zoals Ubuntu, Alpine of CentOS. Als deze niet worden bijgewerkt, kunnen ze bekende kwetsbaarheden bevatten.

Zo kunnen verouderde versies van glibc of openssl in basisimages containers kwetsbaar maken voor aanvallen met uitvoering van code op afstand (RCE) of escalatie van bevoegdheden.

Daarom is het cruciaal om basisimages te monitoren en bij te werken met beveiligingspatches, zodat het risico op misbruik afneemt.

2. Onveilige afhankelijkheden van derden

Applicaties in Docker-images bevatten vaak bibliotheken en afhankelijkheden van derden die de beveiliging kunnen beïnvloeden.

Neem een Node.js-app. Die kan npm-pakketten met bekende beveiligingslekken gebruiken, zoals Prototype Pollution in lodash of aanvallen met regular expression denial of service (ReDoS) in oudere versies van minimatch.

Gebruik krachtige tools voor het scannen op kwetsbaarheden om deze risico's aan te pakken. Software zoals Snyk en OWASP Dependency-Check identificeert en beoordeelt kwetsbaarheden in bibliotheken van derden.

Werk je afhankelijkheden ook regelmatig bij om de beveiliging op peil te houden. Met beveiligingspatches en nieuwere, veiligere versies van bibliotheken verklein je het risico op misbruik.

Beoordeel daarnaast welke bibliotheken van derden je project echt nodig heeft. Door hun aantal te beperken, verminder je mogelijke kwetsbaarheden aanzienlijk. Kies goed onderhouden, betrouwbare pakketten om het aanvalsoppervlak te verkleinen. Controleer deze afhankelijkheden regelmatig op nieuwe beveiligingsrisico's.

3. Fouten in de Dockerfile-configuratie

Fouten in de Dockerfile-configuratie kunnen containers kwetsbaar maken voor beveiligingsdreigingen.

Een veelgemaakte fout is standaard de rootgebruiker gebruiken. Daardoor kunnen aanvallers meer rechten krijgen dan bedoeld. Gevoelige gegevens, zoals API-sleutels of wachtwoorden, in de Dockerfile of omgevingsvariabelen opnemen kan onbevoegden toegang geven als ze het image kraken.

Beperk deze risico's met best practices zoals:

• Gebruik waar mogelijk gebruikers zonder verhoogde rechten om mogelijke aanvalsroutes te beperken
• Bouw images in meerdere fasen, zodat gevoelige informatie niet in het uiteindelijke image terechtkomt
• Stel gevoelige informatie niet bloot via omgevingsvariabelen en beheer inloggegevens op een veilige manier

4. Niet-gepatchte CVEs in de applicatiecode

De applicatiecode in Docker-images kan niet-verholpen kwetsbaarheden (CVEs) bevatten. Zo kunnen aanvallers door CVE-2022-23307, een ernstige kwetsbaarheid in de Log4j-bibliotheek, willekeurige code uitvoeren met speciaal vervaardigde logberichten.

Scan regelmatig op CVEs met tools voor de beveiliging van containerimages, zoals SentinelOne om deze kwetsbaarheden te vinden en te verhelpen voordat aanvallers ze misbruiken.

5. Te veel lagen en onnodige omvang

Docker-images met te veel lagen of onnodige software kunnen aanvallen vergemakkelijken. Elke extra laag kan een zwakke plek zijn en overbodige softwarepakketten kunnen beveiligingsproblemen introduceren.

Een volledige JDK in plaats van een JRE in een productie-image kan bijvoorbeeld extra aanvalsmogelijkheden creëren zonder noodzakelijke functies toe te voegen. Minimale basisimages met alleen de noodzakelijke afhankelijkheden beperken dit risico.

Kies daarom minimale basisimages en voeg alleen de afhankelijkheden toe die je applicatie nodig heeft. Door je Docker-images compact te houden, verminder je de complexiteit én het aantal mogelijke beveiligingsproblemen. Een gestroomlijnd image met alleen noodzakelijke componenten beperkt de mogelijkheden voor aanvallers om kwetsbaarheden uit te buiten.

6. Verkeerd geconfigureerde netwerkopties

Docker-images kunnen onnodige poorten openzetten of onveilige netwerkprotocollen gebruiken. Aanvallers kunnen daarmee toegang krijgen tot containers of zich binnen een netwerk verplaatsen.

Een open SSH-poort op een container zonder goede beveiliging kan bijvoorbeeld een doelwit worden voor bruteforceaanvallen. Voorkom zulke zwakke plekken met best practices voor netwerkbeveiliging. Gebruik bijvoorbeeld firewalls, netwerknaamruimten en streng beveiligde open poorten.

Bijvoorbeeld,

• Configureer firewalls om ongeautoriseerde toegang te blokkeren
• Gebruik netwerknaamruimten om je containers te isoleren en te beveiligen
• Beperk het aantal open poorten zorgvuldig

Door netwerkconfiguraties veilig in te richten, verklein je de kans op ongeautoriseerde toegang aanzienlijk en versterk je de algehele beveiliging van je Docker-omgeving.

Beveilig de basis van containerapplicaties

De beveiliging van containerimages speelt een sleutelrol bij de ontwikkeling en implementatie van moderne applicaties. Nu meer bedrijven containers gebruiken, wordt de bescherming van deze bouwstenen cruciaal. Volg deze best practices om containerimages te beveiligen:

• Grondig scannen en controles voor continue integratie en implementatie (CI/CD): Beveiligingsexperts benadrukken het belang van krachtige scantools in de hele CI/CD-pijplijn. Zo spoor je kwetsbaarheden vroeg in de ontwikkelcyclus op en pak je ze aan, waardoor je mogelijke risico's beperkt.
• Best practices toepassen: Met minimale basisimages en strikte toegangscontroles beperken bedrijven het aanvalsoppervlak en versterken ze de algehele beveiliging.
• Privéregisters en ondertekening van images: Privéregisters en ondertekening van images beveiligen de toeleveringsketen. Zo worden containerimages gecontroleerd en beschermd tegen ongeautoriseerde wijzigingen.
• Doorlopende monitoring: Doorlopende monitoring van zowel de build- als de runtime-omgeving is noodzakelijk. Door mogelijke kwetsbaarheden en nalevingsproblemen nauwlettend te volgen, behouden organisaties een veilig containerecosysteem.

Door de beveiliging van containerimages prioriteit te geven, verkleinen bedrijven hun kwetsbaarheden, voldoen ze aan voorschriften en leggen ze een solide basis voor hun gecontaineriseerde applicaties.

Bescherm uw Docker-containers met Cloud Workload Security for Containers van SentinelOne

Cyberaanvallen worden steeds geavanceerder. Traditionele beveiligingsmaatregelen zijn daardoor vaak niet meer voldoende. Cloud Workload Security van SentinelOne (CWS) voor containers, onderdeel van het Singularity™-platform, biedt geavanceerde bescherming tegen deze moderne dreigingen. Zo versterkt SentinelOne de beveiliging van containerimages:

• Realtime bescherming tegen dreigingen: Singularity CWS bewaakt en beschermt uw gecontaineriseerde workloads voortdurend tegen dreigingen zoals ransomware en onbekende kwetsbaarheden. AI-gestuurde technologie detecteert dreigingen snel en reageert direct. Zo blijven uw omgevingen beschermd op AWS, Azure, Google Cloud en in particuliere datacenters.
• Incidentonderzoek en threat hunting: Met Singularity Data Lake biedt SentinelOne uitgebreid inzicht in de activiteit van uw workloads. Daarmee onderzoekt u incidenten en spoort u dreigingen op. Workload Flight Data Recorder™ ondersteunt het herstel na incidenten door problematische workloads te verwijderen en financiële verliezen en schade te beperken.
• Brede compatibiliteit: SentinelOne ondersteunt uiteenlopende gecontaineriseerde workloads, waaronder 14 grote Linux-distributies, drie populaire container-runtimes en zowel beheerde als zelfbeheerde Kubernetes-services.
• Krachtige dreigingsdetectie: Het platform van SentinelOne detecteert dreigingen en reageert er in realtime op. Daarmee versterkt het een gelaagde strategie voor cloudbeveiliging. Het biedt ook diverse opties voor gegevensopslag en ingebouwde Kubernetes-informatie. Zo krijgen beveiligingsteams samenhangend inzicht en middelen om op dreigingen te reageren. Dat verbetert de afhandeling van incidenten en de jacht op dreigingen, nu Linux een steeds groter doelwit voor aanvallers wordt.

Wilt u een uitgebreide audit van uw containerimagebeveiliging en SentinelOne in actie zien? Boek vandaag een gratis demo en ontdek hoe SentinelOne uw strategie voor containerbeveiliging versterkt.

Conclusie

Zoals bij de meeste beveiligingsvraagstukken bestaat er voor containerbeveiliging geen aanpak die voor iedereen werkt. De technische, operationele en organisatorische aspecten van de bescherming van uw containerimages raken vaak meerdere teams en verantwoordelijkheden. Dat maakt de beveiliging complexer. Laat die complexiteit uw werk niet vertragen. Kies tools die samenwerking bevorderen en inzicht geven in waar doelen, risico's en prioriteiten samenkomen.

Kies tools voor containerbeveiliging die duidelijk zijn over hun mogelijkheden en ook ondersteuning bieden buiten hun kernfunctionaliteit. Singularity Cloud Workload Security van SentinelOne for Containers biedt uitgebreide bescherming, sluit vanzelfsprekend aan op uw DevOps-omgeving en levert helder inzicht en geautomatiseerde verdediging afgestemd op uw behoeften.

Of u nu net begint met containerbeveiliging of al jaren ervaring hebt, SentinelOne begeleidt u naar een veiligere en stabielere omgeving.

Boek vandaag een demo op maat en ontdek hoe SentinelOne uw containerimages beter beveiligt!

"