Ervaringen met het in één week tijd herstellen van ons gehele KVM-park, volgens een patchstrategie waarvan het centrale doel was om de impact op de diensten van onze klanten te minimaliseren.

Een kwetsbaarheid in het virtualisatie-subsysteem

Op dinsdag 7 juli, begin van de middag, kwam er een beveiligingswaarschuwing binnen over CVE-2026-53359, een kwetsbaarheid van het type use-after-free die het shadow-paging-subsysteem van KVM x86 in de Linux-kernel treft. Het lek, dat al van enkele jaren geleden dateert, werd op 6 juli openbaar gemaakt; blogs van andere cloudproviders verschenen vanaf de 7e.

KVM is de virtualisatie-engine waarop het overgrote deel van de bij OVHcloud gehoste instances draait. Het mechanisme is als volgt: als een Page Directory Entry (PDE) extern gewijzigd wordt, kan het RMAP-item nog steeds een verwijzing bevatten naar een reeds vrijgegeven geheugenpagina. De kernel verwijdert vervolgens de verwijzing naar deze verouderde pagina, wat kan leiden tot een crash van de hypervisor of, in de slechtste scenario's, tot privilege-escalatie op de host. De exploit is reproduceerbaar: een interne test op een niet-gepatchte host veroorzaakt binnen ongeveer twee minuten een crash.

Alle Linux x86-kernels van vóór de commit met de patch zijn getroffen, ongeacht de distributie. De officiële patch is ge-backport naar onze Debian-productiekernels.

Er moet met 3 belangrijke risico's rekening worden gehouden:

• Een VPS-klant gebruikt de exploit om de host te laten crashen waarop zijn virtuele machine draait: crash en ongecontroleerde herstart van honderden virtuele machines van klanten.
• Hetzelfde scenario bij Public Cloud-instances; de impact is vergelijkbaar, maar het aantal virtuele machines per host is kleiner en de virtuele machines zijn krachtiger en worden gebruikt voor gevoeligere systemen (databases, queue-managers, load balancers, enzovoorts). Deze systemen worden vaak gebruikt in samengestelde applicatiearchitecturen met complexe afhankelijkheden.
• De kans bestaat dat er binnenkort een hosttakeover-exploit wordt beschreven, wat onmiddellijk zou leiden tot een onacceptabel hoog risiconiveau vanwege de impact op de vertrouwelijkheid van klantgegevens en de integriteit van de infrastructuur.

Bij OVHcloud hebben tienduizenden hypervisor-hostservers, die ongeveer een miljoen virtuele machines hosten, hiermee te maken. De vraag is dus niet of er gepatcht moet worden, maar hoe deze operatie op zo'n grote schaal uitgevoerd moet worden, wetende dat nul impact op de klant niet haalbaar is.

Opties om het risico te beperken

1: Wachten op officiële gepatchte kernels

Deze optie maakte ons afhankelijk van een agenda van derden die ons voor onbepaalde tijd risico liet lopen. Gezien het risico hebben we deze optie snel verworpen.

2: Live patch

Het toepassen van een live patch vereist dat dit type operatie wordt toegestaan in de kernelconfiguratie, wat het, per definitie, mogelijk maakt om het gedrag ervan on-the-fly te wijzigen. Dat leidt daardoor weer tot een lager beveiligingsniveau en de detectiemogelijkheden zijn beperkt als de kernel gecompromitteerd raakt. Bovendien is een live patch van nature een gevoelige procedure die kan leiden tot een instabiele status voor het complete park. Dit is een optie die tijd wint in afwachting van een duurzame oplossing. Wij hebben besloten dit compromis niet te sluiten, omdat dit het risico aanzienlijk zou hebben verhoogd als er een exploit voor het overnemen van de host gepubliceerd zou worden.

3: Mitigatie door het uitschakelen van geneste virtualisatie

De exploit werkt niet meer als geneste virtualisatie op de hosts uitgeschakeld is. Wij hebben geen inzicht in het gebruik van deze functie door onze klanten, dus het is onmogelijk om de impact op de diensten van klanten te bepalen. Bovendien is deze functie nodig om een instance live te kunnen migreren van de ene fysieke host naar de andere. Wij hebben deze optie snel uitgesloten.

4: Live migratie

Dit houdt het organiseren van een live migratie van virtuele machines in, vanaf kwetsbare hosts naar lege hosts die ondertussen gepatcht zijn. Deze optie is zeer geschikt qua continuïteit van dienstverlening, omdat de migratie plaatsvindt zonder impact op de virtuele machines, met uitzondering van lagere prestaties tijdens de migratie. Deze optie kost veel tijd vanwege het kopiëren van virtuele machines van host naar host. Het is niet realistisch bruikbaar voor een compleet park aan machines, met tevens het streven om onze klanten binnen enkele dagen in plaats van enkele maanden te beschermen. Wij hebben besloten deze optie alleen voor bepaalde kritieke virtuele machines te behouden, aangezien elke live migratie tot een aanzienlijke vertraging leidt in het uitvoeren van batches.

5: Backport van de patch naar onze kernels en reboot van alle hosts

Dit is de optie waarvoor we uiteindelijk hebben gekozen en die in het vervolg van dit artikel zal worden toegelicht.

Dinsdagmiddag: activering en organisatie van het crisisteam

Zodra de kwetsbaarheid bevestigd was, was onze prioriteit om een gestructureerde en gecoördineerde respons samen te stellen. De analisten die verantwoordelijk waren voor deze eerste analyse begrepen heel snel wat er de komende dagen op het spel stond. De informatie werd begin van de middag intern verspreid. Er werden verschillende coördinatieruimtes geopend: één voor technische coördinatie, één voor crisiscoördinatie, één voor VS-operaties, één voor klantcommunicatie en ondersteuning. Tegelijkertijd bereidden de Kernel-teams de patch voor en backportten ze deze; de eerste gepatchte kernel werd 's avonds opgeleverd.

Validatietests werden 's avonds in de testomgeving uitgevoerd. De patch werd bevestigd, de exploit liet de gepatchte hypervisors niet langer crashen en QA-tests slaagden met de gepatchte kernel.

Het crisisteam ging vervolgens de implementatie monitoren en werd daarbij aangestuurd door het NOC (Network Operations Center), dat de rol van operationeel coördinator op zich nam: algemene voortgang vervolgen, prioriteiten tussen regio's en diensten afwegen, het algehele overzicht houden. De uitvoering was in handen van de Public Cloud- en VPS-experts, die de reboots, live migraties en anti-affiniteitsbeperkingen realiseerden. De scheiding tussen coördinatie en uitvoering was bewust: het NOC coördineerde, de operationele teams handelden en rapporteerden de statistieken en technische gebeurtenissen die nodig waren voor de coördinatie.

De synchronisatie met Support (realtime voortgangsstatus om getroffen klanten te antwoorden) en de Security-teams (monitoring van de kwetsbaarheid, validatie van de scope en de criteria voor het beëindigen van de operatie) werd continu gewaarborgd.

Aangezien de operatie volgens het 'follow the sun'-principe verliep, werkte het team 24/7 en roteerde het door geografische zones. Er werden elke dag drie synchronisatiemomenten gehouden, die de overgangen tussen de zones dekten. Deze brachten het NOC, de operationele experts, Support en Security samen om: de voortgang per regio te delen, het stokje over te dragen tussen zones (wat heeft gewerkt, procedurele aanpassingen op basis van feedback uit het veld) en prioriteiten voor de volgende reeks te bepalen.

Het volledige team bracht, via een 24/7 rotatie, de volgende groepen bijeen: de teams Kernel & Virtualization (analyse van de patch, backport, validatie), VPS en Public Cloud (implementatie), NOC (aansturing), Run & SRE (orkestratie, anti-affiniteit, live migratie), Datacenter Operations (hardware-interventies), Support (klantvragen), Security (monitoring, scope, einde operatie) en Communicatie (transparantie, gerichte meldingen).

Het einddoel was helder: de betreffende hosts zo snel mogelijk patchen en herstarten om het kwetsbaarheidsvenster te verkleinen, met minimale impact op de diensten. De belangrijkste beperking was de schaal: tienduizenden machines die moesten worden behandeld, verspreid over alle continenten, wetende dat een individuele aanpak bij dit volume materieel onmogelijk is.

Het grootste risico in deze fase was het misbruik van de kwetsbaarheid, wat tot een crash van de niet-gepatchte host zou leiden. Het crisisteam besloot om de patch wereldwijd voor de herstartfase toe te passen. Als de kwetsbaarheid geëxploiteerd zou worden, dan zou de crash van een host resulteren in een herstart en de automatische verwerking van de patch. Daarnaast bestond er een risico dat de CVE misbruikt zou worden voor een kwaadwillige overname van de host. Er was geen exploitcode publiekelijk beschikbaar, maar we wisten dat het slechts een kwestie van tijd zou zijn voordat een onderzoeker erin slaagde de kwetsbaarheid te gebruiken om de controle over de host over te nemen. Aangezien dit een catastrofaal scenario is, wisten we dat elke minuut telde.

Een weloverwogen besluit: eenzijdige patching met gecontroleerde impact

Het Executive Committee valideerde 's avonds de Go/No-Go: de eerste regio wordt de volgende ochtend behandeld. Voor dit aantal machines bestaat er geen scenario zonder impact. Een onderhoudsvenster onderhandelen met elke klant, elke afhankelijkheid controleren, elke reboot individueel orkestreren — stuk voor stuk stappen die materieel onverenigbaar zijn met een acceptabele termijn gezien het beveiligingsrisico.

Het crisisteam nam daarom een weloverwogen besluit: eenzijdige patching met gecontroleerde impact, toegepast zonder te wachten op de individuele toestemming van elke klant, wetende dat sommige diensten onderbroken zullen worden. De redenering berustte op drie punten:

• niet patchen stelt het gehele park bloot aan een zeer ernstige kwetsbaarheid;
• iedereen apart afhandelen zou de doorlooptijden verlengen en de meeste hosts zouden wekenlang kwetsbaar blijven;
• een snelle en alomvattende actie beschermt het merendeel, zelfs als dit een minderheid tijdelijk treft.

De prioriteit is dan niet langer om impact te vermijden, maar om deze te minimaliseren, te spreiden en voorspelbaar te maken. Deze lijn structureerde de gehele operatie: follow the sun, prioritering van regio's en anti-affiniteitsplanning.

Woensdag 8 juli: start vanaf Sydney

De keuze voor Sydney om de implementatie te testen was triviaal: het aantal hosts is beperkt en het uitrolvenster buiten lokale kantooruren (tijdens de nacht) komt overeen met de werkuren van de teams in Europa. Beginnen bij de meest oostelijke regio maakt het mogelijk om:

• te werken in de minst belaste zone;
• de procedure onder reële omstandigheden te valideren, op kleinere schaal, vóór industrialisatie;
• om de eerste feedback te verzamelen voordat met de Europese en Noord-Amerikaanse regio's wordt begonnen.

De eerste golven van patch + reboot werden toegepast op de VPS-hosts in Australië. De regio SYD2 was begin van de middag (Midden-Europese tijd) zonder incidenten afgerond. De procedures werden aangepast op basis van feedback uit het veld.

Zodra de procedure stabiel was, werd het follow the sun-principe toegepast: elke regio nam het stokje over, tijdens de lokale ochtend, waarbij de context werd doorgegeven aan de volgende. De eerste Europese golf (RBX, GRA6, WAW, DE, SBG, MIL, UK) werd dezelfde avond gestart, om 18.30 uur Midden-Europese tijd.

Twee scopes, twee blootstellingen: Eerst VPS, daarna Public Cloud

De implementatie was niet uniform. VPS en Public Cloud verschillen zowel qua architectuur als qua klantblootstelling. Het aantal virtuele machines op VPS-hosts is groter en veel bedrijven en particulieren gebruiken VPS voor testinfrastructuren. De waarschijnlijkheid dat een klant de exploitatiecode op zijn virtuele machine test is zeer hoog en de impact is dat ook, vanwege het aantal virtuele machines op elke host.

Op een VPS is de scope per host beperkt en blijft de impact per reboot voor de klant beperkt. De batches kunnen snel na elkaar worden uitgevoerd, waardoor een groot deel van het park al in de eerste 24 uur kan worden beveiligd.

Public Cloud heeft een blootstelling van een andere orde. Een regio concentreert duizenden klanten en een host kan kritieke instances hosten. De grootste regio's tellen honderden tot zelfs duizenden hosts met complexe virtuele klantinfrastructuren. We besloten prioriteiten te stellen:op regiogrootte

• : de regio's met een lagere dichtheid worden als eerste behandeld, om de robuustheid van de procedure op grotere schaal te valideren;op aantal blootgestelde klanten
• : de regio's met een hoog volume worden fijnmaziger georkestreerd, batch voor batch, om het risico te spreiden.Stopdrempels en tempocontrole

Voor elke reboot-golf gold een

stopdrempel: als het aantal gelijktijdig uitgevallen hosts een gedefinieerde drempel overschreed, werd de golf opgeschort. Deze drempel was vastgesteld op 15 hosts voor regio's met een hoge dichtheid (GRA, RBX, BHS) en op 5 hosts voor de overige. Een stop werd ook geactiveerd om 06.00 uur of op verzoek van het lokale datacenter.Door dit mechanisme werd hardware-uitval niet extra verergerd door hosts te blijven rebooten die de DC-technici nog niet hadden kunnen behandelen. Het introduceerde een afstemmingsmoment tussen de softwarematige automatisering en de fysieke realiteit in het veld.

Niet gelijktijdig twee instances van hetzelfde project rebooten: anti-affiniteit als vangnet

Het grootste risico voor onze klanten bij een dergelijke operatie is niet de reboot zelf, maar

de gelijktijdige onderbreking van meerdere instances van hetzelfde project die garant moeten staan voor robuuste applicaties en storingen bij providers op kunnen vangen. Een klant die zijn workloads over meerdere hosts heeft verdeeld om high availability te garanderen, mag niet zien dat al zijn instances tegelijk uitvallen. We besloten om verder te gaan dan het naleven van de anti-affiniteitsregels die mogelijk in klantimplementaties waren gedefinieerd.Daartoe berekenden onze orkestrators voor elk klantproject met over meerdere hosts verdeelde instances een

co-locatiegraph. Op geen enkel moment werden twee hosts met instances van hetzelfde project binnen hetzelfde venster opnieuw opgestart: er werden wederzijds uitsluitende golven gedefinieerd en een host moest weer in bedrijf zijn voordat de volgende in dezelfde anti-affiniteitsklasse werd gestart.Deze anti-affiniteit werd toegepast op

best effort-basis: het werd in de meeste gevallen gerespecteerd, maar kon niet voor 100% voor het hele park worden gegarandeerd. Het doel bleef om de impact geleidelijk te maken, zodat deze voor applicaties op te vangen was. Klanten met alle instances op één enkele host ondervonden een korte onderbreking, waarvan het venster aangekondigd werd.Prioritaire live-migratie van gevoelige services en workloads

Achter elke klant-instance bevinden zich controllers, API's, dataplannen en interne databases. Een ongecontroleerde reboot van de hosts waarop deze services berusten, zou

deadlocks creëren: een interne service die niet beschikbaar is, blokkeert het vervolg van de reboots, wat het patchen blokkeert. Bovendien berusten sommige OVHcloud-services op virtuele machines die op Public Cloud-instances worden gehost. Rekening houden met deze gevallen is essentieel om de impact voor klanten te beperken.Om deze cascade te voorkomen, werd de prioriteit omgedraaid: vóór elke reboot van een regio werd een diepgaande analyse van de afhankelijkheden van interne services uitgevoerd.

Sommige interne diensten werden live gemigreerd. Hun virtuele machines werden live verplaatst naar reeds gepatchte hosts, de afhankelijkheidsketen werd beschikbaar gehouden en vervolgens werd de host vrijgegeven voor een reboot.Deze procedure duurde lang en verbruikte intensief materiële en menselijke middelen. Deze moest worden beperkt tot een klein aantal virtuele machines om de doelstelling te halen de migratie op tijd af te ronden.

Sommige workloads vereisten bijzondere aandacht: in het bijzonder de diensten van

Cloud Databases (DBaaS), de interne Datalake en de functies voor Observability werden met één VM tegelijk gemigreerd, zonder meer dan één machine tegelijk uit te schakelen, waarbij de update van hun hosts zo lang mogelijk werd uitgesteld. Deze geleidelijke migratie hielp cascaderende storingen in de diensten te voorkomen en zorgde ervoor dat de tools die de operaties ondersteunden beschikbaar bleven.Technische incidenten en aanpassingen tijdens de operatie

Een operatie van deze omvang verloopt niet zonder incidenten. Tijdens de campagne zijn verschillende technische problemen opgetreden en opgelost.

VM's die niet herstarten na een host-reboot

Het eerste grote incident deed zich voor tijdens de eerste Europese golf: virtuele machines herstartten niet na de reboot van hun hypervisor. Nova compute meldde "Instance shutdown by itself" zonder synchronisatie. De

achterliggende oorzaak werd op de tweede dag geïdentificeerd: de service libvirt-guests raakte in conflict met nova compute en stopte de instances bij de reboot zonder sync met de API. De correctie die werd toegepast, bestond uit het uitschakelen en maskeren van libvirt-guests.service op de hosts vóór de reboot. Na deze fix werkten de automatische herstarts van de VM's.Gegevenscorruptie bij synchrone diensten

Op de avond van de tweede dag meldde het interne monitoringsysteem

beschadigde gegevens op meerdere VM's die over 3 clusters verdeeld waren. De waarschijnlijke oorzaak: de geforceerde reboot vond plaats middenin een schrijfactie naar een schijf. De graceful shutdown werd daarop verlengd naar 60 seconden vóór de geforceerde kill, zodat de schrijfacties voldoende tijd hadden om netjes te eindigen. Er werd een script geïmplementeerd voor het automatisch herstarten van VM's die uitgeschakeld bleven.Deadlock van API's in Parijs

In de nacht van de tweede op de derde dag kwamen de Nova- en Neutron-API's in Parijs in een

wederzijdse deadlock terecht: de Neutron-API (gelimiteerd tot 10 processen) raakte verzadigd door een groot aantal verzoeken van Nova, waardoor gedurende ongeveer twee uur HTTP 503-fouten werden geretourneerd. De oplossing bestond uit het verhogen van de Neutron-workers van 10 naar 30 en de Apache-processen van 10 naar 32. De B-zones van Parijs en Milaan werden uitgesteld om de tijd te nemen voor stabilisatie.Overvraagde support in BHS

Op de BHS-locatie (Canada) bereikte het API-verkeer

10 keer het gebruikelijke maximale verkeer, wat de Manager en de Support verzadigde. Klanten ontdekten de impact voordat ze de communicatie hadden ontvangen. Dit geval illustreert concreet de kettingreacties binnen de infrastructuur.Deze bugs en problemen die werden aangetroffen, zijn tijdens de operaties allemaal opgelost, maar zullen meegenomen worden bij het doorvoeren van blijvende, passende verbeteringen.

Reboots en hardware-interventies

Een reboot van tienduizenden machines heeft ook een

hardwarekant. Er is een inherent uitvalpercentage bij elke server-reboot. Tijdens de eerste nacht kwamen ongeveer 20 tot 30 van de 6.000 hosts niet uit zichzelf terug: defecte geheugenmodules, BIOS-configuratie, inactieve netwerkinterface. In de Verenigde Staten vereisten verschillende hosts het verwijderen van de CMOS-batterij en het ontladen van de voeding voor een herstart — een terugkerend hardwareprofiel.Elke locatie beschikt over

datacentertechnici die tijdens de campagne als versterking worden ingezet. Hun rol:met spoed ingrijpen

• op de door de orkestrators gesignaleerde hosts die niet opnieuw opstarten;defecte onderdelen vervangen
• (schijven, geheugenmodules, voedingen);fysieke handelingen uitvoeren
• die geen enkel hulpmiddel kan automatiseren: harde fysieke reboot, indicatielampjes uitlezen, interventie in het rack.De datacentertechnici

kwamen prioritair tussenbeide op uitgevallen hosts, in coördinatie met de Run/SRE-teams die prioriteiten stelden op basis van de klantblootstelling van de host. Een host die kritieke instances draait en niet opnieuw opstart, gaat voor een lege host. Deze kruisprioritering — softwarematig en fysiek — hield het tempo van de operatie hoog.Communicatie en support: de getroffen klanten informeren

Eenzijdige patching met gecontroleerde impact is ondenkbaar zonder bijpassende communicatie.

Gerichte en stapsgewijze communicatie

Gezien de 'follow the sun' dynamiek zou een globale en ongedifferentieerde communicatie geen enkele zin hebben gehad. De gekozen strategie was een

gerichte en stapsgewijze communicatie: uitsluitend gericht aan klanten van wie de instances werden gehost op hosts waarvoor een reboot is gepland, en uitgestuurd naarmate de operatie vorderde, regio per regio, golf per golf.Aanvankelijk werd besloten om

geen openbare statuspagina te activeren, zodat de implementatievolgorde niet openlijk zichtbaar was. De communicatie verliep middels gerichte communicatie via ons Support-portaal, met het versturen van e-mails naar klanten met een Business- en Enterprise-supportniveau.Constatering: sommige berichten worden niet afgeleverd

Communicatiemiddelen hebben technische beperkingen. Voor regio's met een hoog volume zoals GRA6 (bijna 90.000 niet-gecontacteerde klanten) werd het massaal versturen van e-mails uitgesloten om teveel supporttickets te voorkomen.

Gezien deze constatering werd op de tweede dag een

draai gemaakt: het implementeren van een voorwaardelijke banner in de Manager via feature flipping — als de ingelogde gebruiker in de lijst met getroffen klantaccounts (NIC's) staat, wordt er een informatiebericht weergegeven. Het werd dezelfde dag nog ontwikkeld en de banner werd op de derde dag geïmplementeerd. Er werd op dat moment ook een Public Cloud-statuspagina gemaakt.Ondanks deze maatregelen hebben sommige berichten hun ontvangers niet bereikt: verouderde contactadressen, gefilterde meldingen, tijdsverschillen tussen de geplande reboot en het tijdstip van verzending. Klanten ontdekten de impact zonder dat zij vooraf waren gewaarschuwd. Deze knelpunten zijn na afloop van het initiële mitigatieplan geïdentificeerd als belangrijke verbeterpunten.

Support als laatste redmiddel

Voor klanten die niet waren geïnformeerd of om meer informatie vroegen, werd de

klantenservice versterkt en voorbereid: voorafgaande briefing over de context van de operatie, realtime toegang tot de voortgang per regio en per host, versnelde afhandeling van aan de campagne gerelateerde tickets via een speciaal traject.Support ving op wat de geautomatiseerde meldingen niet konden overbrengen. Het verving de communicatie niet, het compenseerde enkele tekortkomingen ervan.

Tijdlijn van de operatie

Timeline de l’opération

Perspectieven

CVE-2026-53359 bracht onze klanten en onze infrastructuren in gevaar. Het actieplan voor de mitigatie leidde tot een klantimpact — beperkt, geleidelijk, aangekondigd, maar reëel. Gedetailleerder communiceren tijdens de uitvoering van het actieplan, zolang de infrastructuur nog niet gepatcht was, zou het risico voor onze klanten aanzienlijk hebben vergroot door sommigen van hen aan te moedigen de publiekelijk beschikbare exploit te "testen".

Het opnieuw opstarten van een wereldwijd park met nul impact was geen haalbaar doel. Het doel was dus de kleinst mogelijke impact die verenigbaar was met de veiligheid van het totale park.

Het patchen en herstarten van alle Public Cloud- en VPS-hosts was nog nooit eerder onder deze tijdsdruk uitgevoerd. Deze noodprocedure werd ingevoerd vanwege het risico dat de kwetsbaarheid vertegenwoordigde. Eerdere gevallen werden altijd afgehandeld door een progressieve herstart, waarbij gebruik werd gemaakt van de natuurlijke rotatiesnelheid van de virtuele machines op de infrastructuur, gecombineerd met ad-hoc live-migraties die over een lange periode waren gepland.

De teams die bij deze operatie betrokken waren, hebben een topprestatie geleverd met een zeer redelijk aantal storingen en een beperkte impact op de klant gezien de omvang van het project. Omdat we ons echter bewust zijn van het feit dat de komende maanden nog meer publicaties over kernelkwetsbaarheden kunnen verschijnen, lijkt het vast te staan dat deze noodprocedure herhaald zal moeten worden. We zullen de volgende keer beter moeten presteren, zowel wat betreft het beheersen van de pure impact van de herstarts als wat betreft het vooraf informeren van klanten en bij de procedure voor het ondersteunen van klanten die door de operaties getroffen worden. Daarom zullen we in de komende dagen en weken de voornaamste gevolgen identificeren voor onze klanten die met complexe storingen te maken kregen. We zullen ook de problemen die tijdens de operaties zijn opgetreden intern evalueren in een post mortem, met als doel onze procedures in de toekomst te verbeteren.