DNSSEC en DNS-beveiliging op uw lokale netwerk.

Informatic Digital » Middelen » DNSSEC en DNS-beveiliging op uw lokale netwerk.

Het internet is gebouwd op een handvol essentiële componenten die we bijna nooit zien, maar die er wel degelijk zijn elke keer dat we een browser openen. Een van de belangrijkste is het Domain Name System (DNS), en wanneer we het hebben over DNSSEC en beveiliging op een lokaal netwerk , hebben we het eigenlijk over het versterken van die basis om frauduleuze omleidingen, spoofing en andere ernstige aanvallen te voorkomen.

Voorheen lag de prioriteit simpelweg bij het ervoor zorgen dat alles werkte; tegenwoordig weten we dat dat niet genoeg is. DNS is in de jaren 80 ontstaan ​​zonder rekening te houden met grootschalige cyberaanvallen, maar nu moet het niet alleen namen oplossen, maar ook de authenticiteit en integriteit van elk antwoord controleren . Dat is waar DNSSEC om de hoek komt kijken, en meer recentelijk voorstellen zoals E-DNSSEC, die ook vertrouwelijkheid willen toevoegen – een cruciale factor als u zich zorgen maakt over de beveiliging van uw lokale of bedrijfsnetwerk.

Wat is DNS en waarom is het zo cruciaal voor de beveiliging?

Het Domain Name System (DNS ) is het telefoonboek van het internet: het vertaalt gemakkelijk te onthouden namen (zoals www.example.com) naar numerieke IP-adressen die computers begrijpen (bijvoorbeeld 192.168.2.15 of een IPv6-adres). Zonder dit mechanisme zouden we nummers in plaats van namen moeten onthouden, wat volstrekt onpraktisch is.

Deze infrastructuur is georganiseerd als een gedistribueerde database in een boomstructuur , met een rootzone bovenaan, gevolgd door topdomeinen (TLD's zoals .es, .com, .org), en daaronder domeinen en subdomeinen. Elk deel van deze database wordt een " zone " genoemd en wordt gehost op een of meer gezaghebbende naamservers, die de "officiële" informatie voor elk domein publiceren.

Wanneer uw computer, mobiele telefoon of ander apparaat een website wil bezoeken, begint het met een query naar een stub-resolver , die deel uitmaakt van het besturingssysteem. Deze resolver stuurt de query door naar een recursieve DNS-server (meestal die van uw internetprovider, uw bedrijf of een openbare server zoals Google Public DNS , OpenDNS of Quad9). Deze recursieve server zoekt vervolgens naar het antwoord door verschillende gezaghebbende servers te raadplegen totdat het het juiste IP-adres vindt.

Recursieve resolvers cachen de ontvangen antwoorden om volgende query's te versnellen. Dit is zeer efficiënt, maar het biedt een aanvaller ook de mogelijkheid om de DNS-cache te manipuleren en valse gegevens in te voegen , waardoor veel volgende verzoeken met deze gemanipuleerde informatie worden afgehandeld zonder dat de gebruiker het merkt.

Het grootste probleem is dat DNS, in zijn oorspronkelijke ontwerp, geen robuuste manier heeft om de authenticiteit van antwoorden te verifiëren . De resolver controleert in feite of het antwoord afkomstig lijkt te zijn van hetzelfde IP-adres dat is opgevraagd, maar dat bron-IP-adres kan relatief gemakkelijk worden vervalst. Dit maakt stille redirect-aanvallen naar frauduleuze sites mogelijk die bijvoorbeeld de website van uw bank nabootsen.

Beveiligingsbeperkingen van traditionele DNS

Het DNS-protocol is ontwikkeld in een tijdperk waarin beveiliging geen prioriteit had. Daarom weten we nu dat DNS-query's en -antwoorden in platte tekst , zonder versleuteling, worden verzonden en dat recordgegevens kunnen worden vervalst zonder extra bescherming.

Dit opent de deur voor verschillende soorten aanvallen, met name DNS-cachevergiftiging en man-in-the-middle-aanvallen. In beide gevallen injecteert de aanvaller onderweg vervalste antwoorden, waardoor gebruikers op websites terechtkomen die onder hun controle staan ​​zonder iets ongewoons te merken, aangezien de domeinnaam die in de browser wordt weergegeven legitiem blijft.

Stel je voor dat je de website van je bank bezoekt: je computer vraagt ​​het domein-IP-adres van de bank op bij de server, maar een aanvaller heeft de server misleid om een ​​nepantwoord te accepteren met het IP-adres van een identieke website die door hen wordt beheerd . De gebruiker voert zijn inloggegevens in, in de veronderstelling dat alles normaal is, en de cybercrimineel ontvangt deze in platte tekst om ze later op de echte website te gebruiken.

Mechanismen zoals transactiesignaturen (TSIG) , gedefinieerd in RFC 2845, dienen ter bescherming van bepaalde bewerkingen tussen DNS-servers (bijvoorbeeld zonetransfers tussen master- en slave-servers en dynamische updates). TSIG stelt twee machines die een geheime sleutel delen in staat om de identiteit van de andere partij en de integriteit van berichten tijdens de overdracht te verifiëren.

TSIG heeft echter een zeer beperkte reikwijdte: het authenticeert niet de "echte" oorsprong van DNS-gegevens ; het zorgt er alleen voor dat de uitwisseling tussen twee specifieke servers niet is gemanipuleerd. Als de oorspronkelijke informatie in een zone al was gecompromitteerd of gemanipuleerd voordat deze de servers bereikte, zal TSIG dit niet detecteren. Hoewel het dus vaak wordt gebruikt voor zonetransfers, lost het het onderliggende probleem van de authenticiteit van gepubliceerde DNS-gegevens niet op.

Wat is DNSSEC en wat is de bijdrage ervan aan de beveiliging?

Als reactie op al deze zwakheden werden Domain Name System Security Extensions (DNSSEC) ontwikkeld . DNSSEC vervangt het klassieke DNS niet, maar breidt het uit met een extra beveiligingslaag die verificatie mogelijk maakt van de legitieme en ongewijzigde ontvangst van de gegevens.

DNSSEC is gebaseerd op publieke-sleutelcryptografie (asymmetrische cryptografie) . Elke DNS-zone heeft een sleutelpaar: een privésleutel, die geheim wordt gehouden, en een publieke sleutel, die op de DNS-server zelf wordt gepubliceerd. De eigenaar van de zone gebruikt de privésleutel om de records in die zone digitaal te ondertekenen; de publieke sleutel wordt gebruikt om die handtekeningen te verifiëren.

Wanneer een recursieve server een domein opvraagt ​​met behulp van DNSSEC, ontvangt deze naast de gebruikelijke informatie (bijvoorbeeld het IP-adres dat aan een naam is gekoppeld) ook de digitale handtekeningen en openbare sleutels die nodig zijn voor validatie . De recursieve server valideert de handtekeningen aan de hand van de gepubliceerde openbare sleutels; als de verificatie succesvol is, worden de gegevens als authentiek en ongewijzigd beschouwd sinds ze werden ondertekend.

Als de validatie mislukt, begrijpt de resolver dat er iets mis is (bijvoorbeeld een poging tot vervalsing of manipulatie tijdens de overdracht) en stuurt een foutcode naar de client, meestal SERVFAIL . Op deze manier ontvangt de gebruiker geen potentieel schadelijke gegevens, hoewel hij of zij vanuit het perspectief alleen ziet dat de pagina "niet laadt" of een foutmelding weergeeft.

DNSSEC introduceert ook het concept van een vertrouwensketen , die gebruikmaakt van de bestaande DNS-hiërarchie. De rootzone ondertekent de sleutels van topdomeinen (zoals .es, .com), deze ondertekenen op hun beurt de sleutels van hun subdomeinen, enzovoort, zodat elk domein kan worden gevalideerd met behulp van één enkel vertrouwenspunt: de publieke sleutel van de rootzone.

KSK- en ZSK-sleutels, -gegevens en de vertrouwensketen

Om de beveiliging beter te organiseren, gebruikt DNSSEC twee verschillende soorten sleutels: de Key Signing Key (KSK) en de Zone Signing Key (ZSK) . Hoewel ze technisch gezien (cryptografisch gezien) hetzelfde zijn, hebben ze een verschillende functie binnen het systeem.

De ZSK-sleutel wordt gebruikt om alle resource-records in de zone te ondertekenen (A, AAAA, MX, enz.). Deze wordt doorgaans regelmatig geroteerd om het risico te minimaliseren, aangezien een eventuele inbreuk op deze sleutel gevolgen zou hebben voor alle records in de zone. De KSK daarentegen wordt voornamelijk gebruikt om de zonesleutel (ZSK) zelf te ondertekenen, en de hash ervan wordt gepubliceerd als het DS-record (Delegation Signer) in de bovenliggende zone.

Dankzij deze scheiding van rollen is het wijzigen van de ZSK eenvoudiger: genereer een nieuwe ZSK, onderteken deze met de KSK, publiceer deze in de DNSKEY-records van de zone en laat de resolvers hun informatie bijwerken. Het is niet nodig om de bovenliggende zone aan te passen, aangezien de DS naar dezelfde KSK blijft verwijzen, die langer stabiel blijft.

DNSSEC voegt verschillende soorten specifieke records toe aan het DNS-protocol, ontworpen om gegevensondertekening en -validatie te ondersteunen. Tot de belangrijkste behoren DNSKEY, RRSIG, DS, NSEC/NSEC3 en NSEC3PARAM . Al deze records stellen u in staat authenticatielogica te bouwen zonder de basiswerking van query's te wijzigen.

Het DNSKEY-record bevat de openbare sleutel van de zone , die nodig is om handtekeningen te verifiëren. Het RRSIG-record bevat de digitale handtekening die is gekoppeld aan een specifieke set records (een "Resource Record Set"). Het DS-record is een hash van de DNSKEY van de onderliggende zone, die in de bovenliggende zone wordt gepubliceerd en als schakel in de vertrouwensketen fungeert.

NSEC- en NSEC3-records worden gebruikt om een ​​geauthenticeerde ontkenning van het bestaan ​​te bieden ; dat wil zeggen, om cryptografisch te bewijzen dat een domeinnaam of record niet bestaat, waardoor aanvallen worden voorkomen die proberen valse antwoorden te geven die aangeven dat iets niet bestaat terwijl het dat wel doet (of omgekeerd).

Keten van vertrouwen en DNSSEC-antwoordvalidatie

De zogenaamde vertrouwensketen in DNSSEC wordt opgebouwd door DNSKEY- en DS-records te koppelen van de root naar het domein dat we willen valideren . Het startpunt is de publieke sleutel van de rootzone, die fungeert als vertrouwensanker en meestal direct in de recursieve resolvers is geconfigureerd.

Als u bijvoorbeeld een domein zoals mywebsite.es wilt valideren, verloopt het logische proces als volgt: de resolver vertrouwt de publieke sleutel van de root, die de .es-sleutel ondertekent; de .es-zone publiceert een DS-record dat overeenkomt met de KSK-sleutel van mywebsite.es; door die DS te valideren met de .es-sleutel, vertrouwt de resolver de DNSKEY van mywebsite.es en kan vervolgens de RRSIG's op al zijn records verifiëren.

Als er ergens in de keten een geldige handtekening ontbreekt, of als de DS (Data Signature) niet aanwezig is waar deze zou moeten zijn, is de vertrouwensketen verbroken. In dat geval beschouwt de recursieve server die de validatie uitvoert de gegevens niet als veilig en zal, afhankelijk van de configuratie, ofwel de gevraagde gegevens niet terugsturen, ofwel het antwoord als ongeldig markeren.

Deze hiërarchische relatie betekent ook dat, wil DNSSEC echt effectief zijn, het niet voldoende is om alleen je eigen zone te ondertekenen : de bovenliggende zone (bijvoorbeeld .es) en de rootzone moeten ook ondertekend zijn en hun DNS-records moeten correct gepubliceerd zijn. Momenteel zijn de DNS-rootzone en vrijwel alle generieke top-leveldomeinen (gTLD's) en veel landcode-top-leveldomeinen (ccTLD's) al ondertekend.

Wanneer een recursieve server met ingeschakelde DNSSEC-validatie detecteert dat de handtekening niet overeenkomt of dat een link ontbreekt, wordt het antwoord dat naar de client wordt teruggestuurd meestal vergezeld van de foutcode RCODE SERVFAIL. Dit kan verwarrend zijn voor de eindgebruiker ("de website werkt niet"), maar vanuit een beveiligingsperspectief is het een beschermingsmaatregel tegen mogelijk gemanipuleerde gegevens.

DNSSEC introduceert ook twee belangrijke functies: authenticatie van de gegevensbron , waarmee kan worden geverifieerd of de records daadwerkelijk afkomstig zijn uit de verwachte zone, en integriteitsbescherming , die ervoor zorgt dat de informatie niet is gewijzigd sinds deze door de zone-eigenaar met zijn privésleutel is ondertekend.

Aanvallen die door DNSSEC worden tegengegaan en hun relatie tot TLS/HTTPS

Het implementeren van DNSSEC helpt beschermen tegen verschillende veelvoorkomende bedreigingen. Ten eerste maakt het DNS-spoofing extreem moeilijk , omdat de aanvaller geldige handtekeningen zou moeten genereren zonder de privésleutel van de zone te kennen, wat cryptografisch onmogelijk is als de sleutels correct worden beheerd.

Bovendien verkleint DNSSEC het risico op cachevergiftiging op recursieve servers door te voorkomen dat gemanipuleerde antwoorden die de handtekeningvalidatie niet doorstaan, worden geaccepteerd. Het bemoeilijkt ook man-in-the-middle (MITM)-aanvallen op DNS-verkeer, waarbij een aanvaller antwoorden tijdens de overdracht wijzigt: als het antwoord de validatie niet doorstaat, wordt het door de resolver verworpen.

Het is echter belangrijk om te begrijpen wat DNSSEC níét doet. Deze extensies zijn niet ontworpen om de inhoud van query's of antwoorden te versleutelen . Al het DNS-verkeer, zelfs met DNSSEC, wordt nog steeds in platte tekst verzonden, tenzij u andere complementaire technologieën gebruikt (zoals DoT, DoH of E-DNSSEC-achtige oplossingen). DNSSEC is erop gericht ervoor te zorgen dat wat u ontvangt authentiek is en niet is gewijzigd, niet om te verbergen wat u opvraagt.

Dit onderscheidt het duidelijk van protocollen zoals TLS en HTTPS . Terwijl HTTPS het verkeer tussen de browser en de webserver versleutelt om te voorkomen dat derden de communicatie afluisteren of wijzigen, ondertekent DNSSEC alleen DNS-gegevens om spoofing te detecteren. Een site kan HTTPS zonder DNSSEC of DNSSEC zonder HTTPS hebben, maar de combinatie van beide biedt een veel uitgebreidere bescherming tegen spoofing en spionage.

Organisaties zoals ICANN en de IETF promoten al jaren de wijdverspreide invoering van DNSSEC door registers, registrars, internetproviders en netwerkbeheerders. Het doel is dat steeds meer zones worden ondertekend en dat steeds meer resolvers deze actief valideren, zodat de gemiddelde gebruiker kan profiteren van deze cryptografische garanties zonder daarvoor speciale actie te hoeven ondernemen.

DNSSEC in .es-domeinen en de verplichtingen van de eigenaar.

In het specifieke geval van Spanje heeft de door Red.es beheerde ".es"-domeineenheid al lange tijd extra technologieën en procedures geïntegreerd om de kwaliteit en veiligheid van de DNS-service onder de .es-landcode te verbeteren. Een van deze maatregelen is de implementatie van een DNSSEC-beveiligingsprotocol conform de IETF-specificaties.

De .es-domeinen zijn verantwoordelijk voor het ondertekenen van de .ES-topzone en het verkrijgen van autorisatie van de DNS-root, waardoor ze deel uitmaken van de wereldwijde vertrouwensketen. Dit betekent dat als u een .es-domein bezit, u deze infrastructuur kunt gebruiken om uw eigen domein te beveiligen met DNSSEC.

Als domeineigenaar omvat de algemene procedure voor het inschakelen van DNSSEC het ervoor zorgen dat uw gezaghebbende DNS-servers de ondertekende zone publiceren. Dit houdt doorgaans in dat u een publieke sleutel voor uw zone genereert, de records ondertekent, de DNS-sleutel publiceert en vervolgens het sleutelmateriaal (of het DS-record zelf) naar de registry of uw registrar stuurt, zodat zij het corresponderende DS-record in de parent zone kunnen aanmaken.

In de praktijk bieden veel DNS-hostingproviders en registrars al een vrij eenvoudige optie om DNSSEC in te schakelen, soms zo simpel als het aanvinken van een vakje in het controlepaneel. Aan deze functionaliteit kunnen echter wel kleine jaarlijkse kosten verbonden zijn, afhankelijk van de provider en het gekozen abonnement.

Zodra de zone is ondertekend en het Domain Name System (DNS) succesvol is gepubliceerd, wordt uw domein onderdeel van de DNSSEC-vertrouwensketen. Vanaf dat moment kunnen DNS-resoluties voor uw domein cryptografisch worden gevalideerd door resolvers die DNSSEC-validatie hebben ingeschakeld, waardoor het vertrouwen van gebruikers toeneemt en het risico op spoofing-aanvallen afneemt.

DNSSEC op het lokale netwerk: validatie aan de gebruikerszijde

Vanuit het perspectief van een eindgebruiker of een bedrijf dat zich zorgen maakt over de beveiliging van zijn lokale netwerk, is de belangrijkste vraag: wat is er nodig om te profiteren van DNSSEC? Het goede nieuws is dat u niets op elke computer afzonderlijk hoeft te configureren , zolang uw recursieve DNS-server (de server die uw computers gebruiken) DNSSEC valideert.

Om dit te doen, hoeft uw DNS-provider (uw internetprovider, een openbare resolver of de interne DNS van uw organisatie) alleen maar te beschikken over een recursieve server met DNSSEC-validatie ingeschakeld en correct geconfigureerd . Vrijwel alle moderne resolvers ondersteunen DNSSEC al jaren; het inschakelen ervan vereist meestal slechts een paar wijzigingen in het configuratiebestand en het toevoegen van het root trust anchor.

Zodra validatie is ingeschakeld, controleert de recursieve resolver alle handtekeningen en de vertrouwensketen wanneer een van uw computers in het lokale netwerk een ondertekend domein opvraagt, voordat het antwoord wordt teruggestuurd. Als er iets niet overeenkomt, worden er geen records geretourneerd en ziet de gebruiker een foutmelding, waardoor hij of zij effectief wordt belet verbinding te maken met een mogelijk frauduleuze site.

Om te controleren of uw domein beschermd is door DNSSEC, zijn er verschillende online tools beschikbaar, zoals DNSSEC Analyzer en andere validatieprogramma's . Wanneer u uw domein invoert, ziet u records zoals RRSIG (cryptografische handtekeningen), DNSKEY (openbare sleutels) en DS (hash van de DNSKEY in de bovenliggende zone). Als de tool aangeeft dat er geen digitale handtekening aan de records is gekoppeld, wordt uw domein beschouwd als 'niet ondertekend' of 'onveilig'.

Als na deze controle blijkt dat uw domein of de DNS-servers die u op uw lokale netwerk gebruikt geen gebruik maken van DNSSEC, is het raadzaam contact op te nemen met uw serviceprovider of internetprovider om de activering ervan aan te vragen. Als zij deze optie niet aanbieden, is het wellicht een goed moment om te overwegen over te stappen naar een provider die DNSSEC-validatie wel ondersteunt, waardoor de beveiliging voor zowel uw bedrijf als uw klanten wordt verbeterd.

Beperkingen van DNSSEC: privacy en andere aspecten

Ondanks alle voordelen is DNSSEC geen wondermiddel voor alle DNS-beveiligingsproblemen. Een belangrijk probleem is dat het geen vertrouwelijkheid van query's garandeert . DNS-pakketten, zelfs met DNSSEC, worden nog steeds in platte tekst verzonden, waardoor iedereen met toegang tot het verkeer (bijvoorbeeld op een onbeveiligd openbaar wifi-netwerk ) kan zien welke domeinen worden opgevraagd.

Het biedt ook geen toegangscontrole of specifieke bescherming tegen denial-of-service (DoS of DDoS) aanvallen . Sterker nog, door meer data toe te voegen (signatures, sleutels, extra records), vergroot het de omvang van DNS-reacties, wat kan worden misbruikt bij versterkingsaanvallen als de infrastructuur niet correct is geconfigureerd en beveiligd.

Aan de andere kant brengt DNSSEC ook operationele complexiteit met zich mee: sleutelparen moeten worden beheerd, ZSK en KSK moeten worden geroteerd, de DS-publicatie in de bovenliggende zone moet worden gecoördineerd en er moet worden gewaarborgd dat er geen inconsistenties zijn die de vertrouwensketen verbreken. Een fout in deze procedures kan ertoe leiden dat een domein niet langer correct wordt gevalideerd, wat ogenschijnlijk serviceonderbrekingen veroorzaakt.

Binnen het DNSSEC-proces zelf bevinden zich controlebits in de berichten (zoals de CD-bit in query's en de AD-bit in antwoorden) die bepalen hoe de validatie wordt uitgevoerd en gerapporteerd. Een aanvaller die deze bits in een onveilige omgeving zou kunnen manipuleren, zou kunnen proberen de bescherming van een recursieve resolver te ondermijnen . Daarom wordt aanbevolen dat de communicatie tussen resolvers en clients die DNSSEC gebruiken, via beveiligde kanalen verloopt.

Ondanks deze beperkingen blijft DNSSEC een essentieel onderdeel voor het versterken van de authenticiteit en integriteit van DNS. Om echter een stap verder te gaan en ook de vertrouwelijkheid van query's te garanderen, is het nodig om het te combineren met andere technologieën of te evolueren naar meer geavanceerde oplossingen.

E-DNSSEC: Op weg naar een geauthenticeerde en versleutelde DNS

Om de privacykloof die DNSSEC achterlaat te dichten, is het concept van E-DNSSEC (DNSSEC encrypted) voorgesteld . Het idee achter deze aanpak is om encryptie toe te voegen aan DNSSEC-query's, zodat ze, naast authenticatie en ondertekening, ook beschermd zijn tegen inspectie door derden tijdens de overdracht via internet of het lokale netwerk.

Het doel van E-DNSSEC is om de eigenschappen van DNSSEC (authenticiteit en integriteit) te combineren met encryptiemechanismen die de vertrouwelijkheid garanderen van query's tussen de DNSSEC-client en de DNSSEC-server . Dit verhoogt de algehele beveiliging van de DNS-service en voorkomt dat externe waarnemers kunnen zien welke domeinnamen worden opgelost.

Het conceptuele proces zou inhouden dat de query op de recursieve server wordt geanalyseerd, versleuteld voordat deze naar de gezaghebbende server wordt verzonden, en vervolgens op de normale wijze wordt ontsleuteld en verwerkt met behulp van DNSSEC . Het antwoord zou vervolgens ondertekend en versleuteld teruggestuurd kunnen worden naar de recursieve server of de client, waardoor de vertrouwelijkheid gedurende het hele proces gewaarborgd blijft.

Deze combinatie zorgt ervoor dat het DNS-bericht van begin tot eind van het resolutieproces beveiligd is: geauthenticeerd en met behoud van integriteit dankzij DNSSEC, en beschermd tegen nieuwsgierige blikken dankzij extra encryptie. In een lokale of bedrijfsnetwerkcontext kan een dergelijke aanpak worden geïntegreerd met andere perimeterbeveiligingsoplossingen.

Voorstellen zoals E-DNSSEC maken tegenwoordig deel uit van een bredere inspanning om de privacy van DNS te versterken , samen met technologieën zoals DNS over TLS (DoT) en DNS over HTTPS (DoH). De onderliggende richting is duidelijk: de DNS van de toekomst moet zowel authentiek als vertrouwelijk zijn, en het is niet voldoende om namen snel te kunnen oplossen; het moet ook veilig gebeuren.

In een omgeving waar cyberaanvallen, identiteitsfraude en bedreigingen gericht op basisinfrastructuren steeds geavanceerder worden, is DNSSEC al een belangrijke beveiligingsvereiste voor elk serieus domein. De overstap naar versleutelde oplossingen zoals E-DNSSEC of vergelijkbare methoden lijkt dan ook een logische volgende stap om de bescherming van netwerken, inclusief lokale netwerken, verder te versterken.

Dit hele ecosysteem – van klassieke DNS tot DNSSEC en versleutelde oplossingen zoals E-DNSSEC – laat zien dat DNS-beveiliging geen optionele extra is, maar een kernonderdeel van de internetarchitectuur en elk modern lokaal netwerk. Resolvers die valideren, ondertekende zones, goed onderhouden vertrouwensketens en, in de toekomst, versleutelde kanalen voor query's, maken het verschil tussen een kwetsbaar netwerk en een infrastructuur die is voorbereid op huidige en toekomstige uitdagingen.