Post-Quantum Cryptografie (PQC) vs Klassieke Cryptografie: Complete Gids voor de Hybride Overgang in 2025 - Deel 1
Post-Quantum Cryptografie (PQC) vs Klassieke Cryptografie: Complete Gids voor de Hybride Overgang in 2025 - Deel 1
- Segment 1: Inleiding en Achtergrond
- Segment 2: Diepgaande Inhoud en Vergelijking
- Segment 3: Conclusie en Uitvoeringsgids
Post-Quantum Cryptografie (PQC) vs Klassieke Cryptografie: De Complete Gids voor de Hybride Overgang van 2025 — Deel 1 / Sectie 1 (Inleiding + Achtergrond + Probleemdefinitie)
Wat neem je mee als je op camping gaat? Een oude, maar vertrouwde brander, of een nieuwe ultralichte kookplaat? Afhankelijk van of je gaat bikepacken of auto-campen, verschilt de keuze van de uitrusting en verandert de aanpak aanzienlijk. Digitale beveiliging is precies hetzelfde. Tot nu toe heeft de encryptie, zoals een "auto-camping", comfortabel gereden met een ruime kofferbak (rekenkracht) en betrouwbare uitrusting (klassieke cryptografie). Maar aan het einde van de weg komt er een quantumstorm aan. Tijd om je rugzak licht te herschikken en je koers te veranderen. 2025 is het jaar van die overgang, het jaar waarin hybride overgang de norm wordt.
Dit artikel eindigt niet met een verhaal over cryptografie dat alleen door experts wordt begrepen. Het biedt een uitgebreide gids voor wanneer, wat en hoe je moet veranderen in alledaagse en concrete situaties zoals smartphonebankieren, messaging met je familie, contracten ondertekend met elektronische handtekeningen en cloudback-ups van bedrijven. In dit deel 1 wordt eerst besproken waarom Post-Quantum Cryptografie (PQC) nu zo relevant is, welke beperkingen de bestaande systemen, vertegenwoordigd door RSA en ECC, ondervinden en welke veranderingen jouw diensten en data te wachten staan in de inleiding en achtergrond.
Kernsignalen in één oogopslag
- In 2024 bevestigt NIST de kernalgoritmes voor PQC als FIPS: ML-KEM (voorheen Kyber), ML-DSA (voorheen Dilithium), SLH-DSA (voorheen SPHINCS+). 2025 wordt het jaar van de daadwerkelijke invoering.
- Browser-, cloud- en OS-leveranciers gaan van experimenten met hybride handshakes (TLS 1.3 + X25519 + Kyber, enz.) naar commercialisering.
- De toename van de dreiging "nu verzamelen en later ontsleutelen (Harvest Now, Decrypt Later)" versnelt de klok voor langdurige gevoelige data.
Inleiding: Het is tijd om beveiligingsapparatuur niet te 'vervangen', maar te 'evolueren'
Beveiliging wordt bepaald door "dreigingen en levensduur" in plaats van door de pracht van de tools. Je stopt niet elke levering die je thuis krijgt in een kluis, maar als het gaat om zaken zoals paspoorten, onroerend goed en medische dossiers, moet je het beschermingsniveau verhogen. Evenzo zijn er online data die na 10 of 20 jaar nog steeds gevoelig blijven. Denk aan langdurige huurcontracten, medische beelden, logboeken van autonome voertuigen, en studentendossiers van onderwijsinstellingen. Ook al worden de vandaag verzonden gegevens morgen niet ontsleuteld, met de opkomst van quantumcomputers over een paar jaar kan onrechtmatige toegang met vertraging mogelijk worden.
Het onderwerp van vandaag is niet "volledige vervanging", maar "hybride configuratie". Dit betekent dat we PQC combineren met de al stevig gevestigde klassieke cryptografie (bijv. RSA, ECC), zodat zelfs als een van beide systemen faalt, de veiligheid wordt gehandhaafd met een dubbele veiligheidsgordel. Het is vergelijkbaar met het overdekken van je gebruikelijke tent met een waterdichte tarp tijdens het kamperen. Idealiter zou je de hele uitrusting in één keer willen vervangen, maar gezien het brede en onderling verbonden ecosysteem is een gefaseerde overgang logischer.
Achtergrond: Waarom is PQC nu 'de realiteit' geworden?
In de afgelopen tien jaar heeft de industrie de mogelijkheden van het quantumtijdperk, waarvan werd gezegd dat het "ooit" zou komen, alleen als labnieuws beschouwd. Er zijn echter enkele indicatoren dat de situatie is veranderd. In 2024 sluit NIST de volgende generatie openbare sleutelstandaard af als FIPS en verstevigt het de rechtvaardiging voor "commerciële invoering". Nu de kernstructuren zoals ML-KEM (voorheen Kyber, sleuteluitwisseling/encryptie), ML-DSA (voorheen Dilithium, handtekening), en SLH-DSA (voorheen SPHINCS+, handtekening) zijn vastgesteld, zijn browsers, CDN's en cloudproviders begonnen om zich van de testfase naar de productielijn te verplaatsen. Het sleutelwoord voor 2025 is niet experimenteren, maar distribueren; niet voorzichtig beginnen, maar "absorberen als basisoptie".
Nieuwe standaarden worden echter niet onmiddellijk in elke app geïntegreerd. Apparatuur zoals netwerken, firmware, smartcards, beveiligde HSM's en certificaatuitgiftesystemen moeten ook meebewegen in het 'ecosysteem'. Daarom is een hybride configuratie, waarbij verschillende algoritmes samen worden gebruikt, een veiligheidsmaatregel in de vroege stadia. Met de leiderschap van de NIST-standaard, en de richtlijnen van IETF, CA/browserforum en grote cloudproviders die met elkaar verweven zijn, kunnen we 2025 beschouwen als het jaar waarin de "mix" in werking treedt.
“Harvest Now, Decrypt Later” — Aanvallers proberen nu communicatie te onderscheppen en op te slaan om later met sterkere quantumcomputers alles tegelijk te ontsleutelen. Hoe langer jouw data wordt gebruikt, hoe ontoereikend de huidige cryptografische sterkte wordt.
Terminologie: PQC is niet hetzelfde als Quantum Cryptografie (QKD)
- PQC (Post-Quantum Cryptography): Een op software gebaseerde openbare sleutelcryptografie die is ontworpen om veilig te blijven, zelfs met de komst van quantumcomputers. Kan worden geïntegreerd in bestaande internetprotocollen.
- Quantum Cryptografie (QKD): Gebruikt de quantumkenmerken van fysieke kanalen, zoals fotonen, om sleutels te distribueren. De infrastructuur is zwaar en heeft beperkingen qua afstand en apparatuur. Moeilijk te integreren in het algemene internet.
- Hybride overgang: Een strategie waarbij bestaande klassieke cryptografie (RSA, ECC) samen met PQC wordt gebruikt voor wederzijdse aanvulling.
De essentie van het probleem: De veronderstelling dat klassieke cryptografie 'kan breken'
De huidige HTTPS, VPN en e-mailhandtekeningen zijn voornamelijk gebaseerd op twee assen. Ten eerste worden ECC (bijv. X25519, P-256) of RSA gebruikt voor sleuteluitwisseling en authenticatie, en ten tweede wordt symmetrische encryptie (zoals AES) gebruikt voor data-encryptie. Hier is de dreiging van quantumcomputers fataal voor de openbare sleutelzijde. Als de Shor-algoritme draait op een voldoende krachtige quantumapparaat, zullen de huidige RSA en ECC structureel ineenstorten. Symmetrische sleutels zullen door de invloed van het Grover-algoritme een 'effectieve sleutelgrootte' verliezen, maar kunnen worden verlicht door de sleutelgrootte te vergroten.
Dit betekent niet de vrees dat "alles morgen wordt gekraakt", maar eerder dat "de levensduur van data en het tijdstip van ontsleuteling uit elkaar kunnen lopen", wat een risico-beheerprobleem is. Gegevens die eenmaal openbaar zijn, kunnen niet meer worden teruggedraaid; bijvoorbeeld genetische informatie of permanente identificatie-informatie blijven gevoelig, ongeacht hoe de tijd verstrijkt, en moeten nu worden beschermd door een PQC-beschermlaag. Hoewel klassieke cryptografie in de praktijk nog steeds robuust is, is het cruciale punt dat het 'lange termijn veiligheid' een rood licht heeft gekregen.
Wat is precies de hybride overgang?
Hybride is als twee veiligheidsgordels. Een typisch voorbeeld in praktische protocollen zoals TLS is de sleuteluitwisselingscombinatie "X25519 (of P-256) + ML-KEM (Kyber)". Zelfs als een van beide theoretisch of praktisch faalt, blijft de andere als een beschermende laag functioneren. Het handtekeningensysteem werkt op een vergelijkbare manier. Een representatieve strategie is het combineren van bestaande RSA/ECDSA met ML-DSA (voorheen Dilithium) in codehandtekeningen of documenthandtekeningen. Hierdoor kan je de legacy-compatibiliteit behouden terwijl je geleidelijk een nieuwe vertrouwensketen uitbreidt.
Een sleutelterm die vaak door professionals wordt genoemd, is "crypto agility". Dit verwijst naar de mogelijkheid om algoritmes gemakkelijk te wijzigen en toe te voegen door vanaf de ontwerpfase abstractieniveaus te scheiden en de mogelijkheden om sleutels, certificaten en beleid centraal te herschikken. Elke keer dat een nieuwe alfa-algoritme wordt gestandaardiseerd, is het cruciaal dat bedrijven niet de hele codebasis hoeven te herschrijven om te overleven.
Consumentenperspectief: welke veranderingen kunnen we verwachten in ons dagelijks leven
Deze veranderingen zijn subtiel, maar ze dringen overal door. Wanneer de browser op een smartphone verbinding maakt met een bankwebsite, vindt er op de achtergrond een hybride handdruk plaats, die voor het blote oog onzichtbaar is. De snelheid van inloggen zal vrijwel hetzelfde blijven, maar in de achtergrond wordt de TLS 1.3 handdruk versterkt met een combinatie van ECC + PQC. Wanneer we documenten ondertekenen met een elektronische handtekening-app, kan er een nieuw type certificaat opduiken en kan de grootte van de handtekening toenemen. Firmware-updates (OTA) van IoT-apparaten worden ook geverifieerd met PQC-handtekeningen, waardoor een langdurig vertrouwen in voertuigen of slimme apparaten behouden blijft.
Cloudback-up en langdurige opslag zijn bijzonder belangrijk. Foto's en video's zijn misschien op korte termijn minder gevoelig, maar medische, juridische en onderzoeksdata zijn een ander verhaal. Wat als de encryptiemethoden die ziekenhuizen of advocatenkantoren momenteel gebruiken, over 7 tot 10 jaar worden gekraakt? Dan is het al moeilijk om terug te keren. Veel organisaties willen vanaf 2025 PQC-gebaseerde encryptie en sleutelbeheer toepassen voor langdurige opslag van gegevens, en dat is de reden hiervoor.
Waarschuwing: “Decryptie na oogst” wordt realiteit
De aanvaller is nu jouw versleutelde verkeer aan het opslaan en plant langzaam om het in de toekomst met krachtigere rekencapaciteiten te kraken. Als er ‘data is die zijn waarde behoudt, ongeacht de tijd’, zoals medische, juridische of overheidsdocumenten, is het moeilijk om je veilig te voelen met de encryptie van vandaag. Voor langdurige gegevens moet je nu denken aan een PQC beschermingslaag.
Tijdlijn 2025: waar we nu staan
Laten we een praktische snapshot van dit jaar schetsen. Belangrijke cloud- en CDN-providers hebben al grootschalige hybride TLS-tests uitgevoerd en sommige kanalen hebben geleidelijk aan commerciële beschikbaarheid aangekondigd. Besturingssystemen en browsers introduceren nieuwe sleuteluitwisselings- en handtekening suites in experimentele kanalen. Het certificaat ecosysteem heeft nog tijd nodig voor de universele uitgifte van ‘volledig PQC-certificaten’, maar kruislingse handtekeningen, hybride handtekeningen en strategieën rond tussenliggende CA's worden besproken terwijl de infrastructuur wordt opgeknapt. Dit jaar is het daarom noodzakelijk om een “slot voor hybride integratie” in je architectuur te reserveren.
Beveiligingshardware (HSM, TPM) evolueert ook. Sommige modellen versnellen PQC-sleutelgeneratie en handtekeningen, terwijl andere modellen ondersteuning beloven via firmware-updates. Lichte edge-apparaten moeten de afweging tussen handtekeninggrootte en verificatietijd oplossen, dus een mappingstrategie van “welke PQC waar” is essentieel. Dit alles zal niet in één keer op hun plaats vallen, maar daarom is de hybride configuratie van 2025 de veiligste praktische brug.
Probleemdefinitie: zeven vragen die je vandaag moet beantwoorden
- Wat zijn “de gegevens of diensten die meer dan 10 jaar gevoelig blijven”?
- In welk segment van de huidige communicatieroutes (TLS, VPN, messenger) vertrouw je uitsluitend op klassieke encryptie?
- Welke encryptie- en sleutelbeheer systemen worden gebruikt voor back-up, archivering en logopslag, en is er een migratietraject naar PQC voorbereid?
- Wanneer je hybride handtekeningen introduceert voor codehandtekeningen, documenthandtekeningen of elektronische identiteitscertificaten, hoe ga je de toegenomen grootte en verificatiekosten absorberen?
- Heeft de interne en servicearchitectuur crypto-agility, of wordt het vervangen van algoritmes een ‘grote operatie’?
- Hebben partners/leveranciers (gateway, WAF, CDN, HSM, IAM) een NIST-standaard gebaseerde PQC roadmap gepubliceerd?
- Hoe ga je de balans vinden tussen consumentenervaring (snelheid, batterij, app-grootte) en beveiligingskracht?
Een metafoor voor de keuze: bikepacking vs. autokamperen
Bikepacking is licht en wendbaar. Maar elke keuze voor apparatuur heeft directe gevolgen voor de veiligheid van de hele reis. De hybride transitie is vergelijkbaar. De bestaande RSA/ECC “autokampeeruitrusting” is ruim en comfortabel, maar er is een onvoorspelbare quantumstorm in aantocht. Het is tijd om een eenvoudige maar krachtige PQC tarp op te zetten en alleen op de plekken waar duurzaamheid nodig is stevige haringen te gebruiken. Dit is de hybride aanpak: zonder alles omver te gooien, de juiste stevigheid op de juiste plekken toevoegen.
De symfonie van technologie en beleid: standaardisering en regelgeving versnellen de verandering
Standaarden leggen de basis, terwijl regelgeving duwt vanuit de achtergrond. Overheids- en publieke instellingen moeten snel de privésector volgen. De adoptie van technologie wordt altijd bepaald door de laagste gemeenschappelijke noemer in het ecosysteem. Net zoals TLS alleen werkt als browsers en servers elkaar begrijpen, is gelijktijdige afstemming van partnernetwerken, toeleveringsketens en klant-apps noodzakelijk. De taal van die afstemming is de NIST-standaard, en dit jaar wordt die taal een wereldwijde lingua franca.
De snelheid kan variëren afhankelijk van de grootte van het bedrijf. Startups kunnen snel hybride suites aan experimentele kanalen toevoegen, terwijl grote bedrijven meer tijd nodig hebben voor goedkeuringen van HSM, sleutelbeheer en beleid. Daarom is het goed om de roadmap in twee fasen te splitsen. Fase 1 is “hybride voorbereiding en crypto-agility verzekeren”, fase 2 is “selectie van kandidaten voor volledige PQC-overgang en pilots”. Door deze volgorde aan te houden, kunnen budgetten en risico's worden beheerst terwijl de snelheid toeneemt.
Zichtbare en onzichtbare veranderingen voor de consument
Laten we eerst de zichtbare veranderingen bespreken. In elektronische handtekening-apps kunnen nieuwe typen certificaten verschijnen, en sommige verouderde apparaten kunnen vaker om updates vragen. De grootte van certificaten kan toenemen, waardoor een subtiele vertraging bij de initiële verbinding voelbaar kan zijn. Aan de andere kant is de onzichtbare verandering veel groter. De algoritmische combinaties voor server-side handshakes, de methoden voor de afgeleide sessiesleutels, het sleutelbeheerbeleid en de rotatiecycli worden allemaal opnieuw ingericht. Gebruikers profiteren van een sterker beschermingsmechanisme zonder veel ongemak.
Voor eindgebruikers is het ook eenvoudig. Zorg ervoor dat je op tijd de nieuwste browser- en besturingssysteemupdates toepast en let op beveiligingsmeldingen van financiële en publieke service-apps. Bedrijfsklanten moeten de PQC-roadmap van hun leveranciers opvragen en de hybride ondersteuning in de SLA laten opnemen. Onzichtbare beveiliging is uiteindelijk het resultaat van afgesproken standaarden en oprechte updates.
Belangrijke SEO-zoekwoorden
Belangrijke concepten die in deze gids herhaaldelijk worden behandeld: quantumveilige encryptie, PQC, hybride transitie, klassieke encryptie, RSA, ECC, NIST-standaard, quantumcomputer, crypto-agility, TLS 1.3
Wat deze tekst probeert te beantwoorden: strategische punten van ‘nu’
In deel 1 wordt de achtergrond en het kader van risicobewustzijn geschetst, en wordt een goed onderbouwd antwoord gegeven op de vraag “waarom hybride?”. In het volgende segment 2 worden we dieper ingegaan op praktische voorbeelden, technische keuzepunten en architectuurpatronen met behulp van vergelijkende tabellen. In het laatste segment 3 worden de conclusies van deel 1 samengevat en wordt er een voorproefje gegeven van een checklist die direct kan worden uitgevoerd. In het vervolg, deel 2, zullen we richtlijnen voor implementatie en best practices per operationele structuur bieden, zodat jouw organisatie en diensten ‘door kunnen gaan’ met de transitie.
Vandaag heb je één houding nodig: wees niet bang, maar wees ook niet gehaast, en houd het structureel. Net zoals je je kampeerspullen voorbereidt, is het belangrijk om te plannen “waar je welke tent opzet en waar je welke haringen plaatst” van het netwerk tot het sleutelbeheer. Dat is de eerste stap naar de hybride transitie van 2025.
Deel 1 · Segment 2/3 — Diepe Analyse: Waarom de hybride overgang van 2025 de oplossing is en hoe deze in de praktijk toe te passen
Kun je er zeker van zijn dat je gegevens morgen nog geheim zijn? De bedreiging van 'Harvest Now, Decrypt Later', waarbij gegevens vandaag worden afgetapt en opgeslagen, en later worden ontsleuteld wanneer kwantumcomputing praktisch is geworden, is al een realiteit. Op dit punt wordt kwantumveilige cryptografie (PQC) en de coëxistentie van klassieke cryptografie, oftewel hybride overgang, in 2025 geen "optie" maar een "noodzaak".
Technologisch gezien is dit een omslagpunt. NIST heeft in 2024 de fundamenten voor PQC-standaarden gepresenteerd en de terminologie geüniformeerd: ML-KEM (FIPS 203, voorheen Kyber), ML-DSA (FIPS 204, voorheen Dilithium), SLH-DSA (FIPS 205, voorheen SPHINCS+). Dit, samen met de conceptversie van hybride sleuteluitwisseling in TLS 1.3 en de proefimplementatie door grote cloudproviders, CDN's en browsers, maakt van de eerste helft van 2025 een tijd om de 'test' af te ronden en over te schakelen naar 'standaardinstelling'.
Belangrijke punten — Waarom nu hybride?
- Beveiligingslevensduur afstemmen: Gegevensgevoeligheid (7-15 jaar) vs cryptolevensduur (enkele jaren). Om de "geheimhouding van morgen" te garanderen, moet je vandaag al beginnen met PQC.
- Compatibiliteitsbrug: Hybride gebruik van klassieke cryptografie en PQC maakt een geleidelijke overgang zonder onderbreking mogelijk.
- Standaard stabilisatie: NIST-standaardisering heeft een basislijn gecreëerd voor inkoop, audit en compliance.
- Prestatiebehoud: Geoptimaliseerde implementaties van ML-KEM/ML-DSA hebben een niveau bereikt dat praktisch is voor mobiel en edge.
Klassiek vs PQC, wat is er anders — van structuur tot kosten
Klassieke cryptografie bestaat grofweg uit openbare sleutels (bijv. RSA, ECDSA, X25519) en symmetrische sleutels (zoals AES-GCM). Het openbare sleutelgebied is een primair doelwit voor kwantumaanvallen, waar PQC in beeld komt. Het ontwerpparadigma van kwantumveilige cryptografie kiest voor "structuren die slecht reageren op kwantumalgoritmen (Shor/Grover)". Er zijn verschillende werkingswijzen zoals rooster (LWE), hash-gebaseerd en code-gebaseerd, en deze verschillen leiden tot variaties in sleutellengte, handtekeninggrootte en rekenkracht.
| Algoritme | Rol | Beveiligingssterkte (bij benadering) | Grootte openbare sleutel/handtekening/ciphertext | Kenmerken | Aanbevolen toepassing |
|---|---|---|---|---|---|
| RSA-2048 | Handtekening/sleuteluitwisseling (legacy) | ~112-bit | PK ~256B / Sig ~256B | Uitgebreide compatibiliteit, kwetsbaar voor kwantum | Legacy-compatibiliteit behouden, geleidelijke afschaffing |
| ECDSA P-256 | Handtekening | ~128-bit | PK ~64B / Sig ~64-72B | Kleine sleutel, snelle verificatie, kwetsbaar voor kwantum | Korte termijn hybride configuratie |
| X25519 | Sleuteluitwisseling | ~128-bit | PK ~32B | De facto standaard van TLS 1.3, kwetsbaar voor kwantum | Combinatie in hybride sleuteluitwisseling |
| ML-KEM-768 | Sleutels kapselen (KEM) | ~192-bit niveau | PK ~1.1KB / CT ~1KB | Rooster-gebaseerd, snelle snelheid, brede acceptatie | Hybride TLS 1.3 kern |
| ML-DSA-65 | Handtekening | ~128-bit+ | PK ~1.5KB / Sig ~2.7KB | Rooster-gebaseerd, hoge prestatie handtekening | TLS-certificaat, SW-handtekening |
| SLH-DSA-128s | Handtekening | ~128-bit+ | PK honderden bytes / Sig duizenden bytes | Hash-gebaseerd, traag maar gemakkelijk te verifiëren | Lange termijn verificatie, auditlogboeken |
Waarschuwing — “Grote sleutel = trage service” is slechts gedeeltelijk waar
PQC heeft de neiging tot grotere sleutels/handtekeningen/ciphertexts, maar door CPU-cache-optimalisatie, batchverificatie, sessiehergebruik en CDN-offloading kan de ervaren vertraging tot een minimum worden beperkt. Vooral ML-KEM kan, ondanks een toename in netwerkinformatie in vergelijking met ECC, de totale handshake-tijd voldoende beheersen door browser/server-optimalisatie.
Hoe ontwerp je hybride TLS 1.3
De kern van hybride is "als de ene doorbreekt, beschermt de andere". In de praktijk worden in de handshake X25519 (ECDH) en ML-KEM parallel gebruikt om een gedeeld geheim te combineren (bijv. gemengd met HKDF). Voor de handtekening van het certificaat wordt een van de dubbele keten- of dubbele handtekeningmethoden tussen ECDSA en ML-DSA gekozen.
- Sleuteluitwisseling: X25519 + ML-KEM-768 combinatie (brede compatibiliteit tussen browser/server), in hoge beveiligingsomgevingen tot -1024 overwegen
- Handtekening: ECDSA P-256 + ML-DSA-65 dubbele handtekening of SLH-DSA voor root/offline
- Sessielevensduur: kort (0-RTT vermijden), heronderhandelingen minimaliseren, sessiehergebruik actief benutten
- MTU/pakketverdeling: serverzijde TCP/TLS-recordtuning met inachtneming van initiële pakketsplitsing
Wat betreft TLS-bibliotheken worden PQC-takken zoals OpenSSL (3.2+), BoringSSL, wolfSSL en leverancierspatches gebruikt. Interne verkeersstromen worden eerst in een proefomgeving toegepast om de stabiliteit van de cryptostack te verifiëren, en externe kanalen worden geleidelijk geactiveerd op basis van SNI en User-Agent.
Case 1 — Wereldwijde commerce: 0.3%p vermindering van het winkelwagentje-verlatingspercentage
Een geïntegreerd retailbedrijf in Noord-Amerika en Azië heeft TLS 1.3 hybride in een omgeving toegepast waar 80% van het checkout-verkeer mobiel is. Concreet werden X25519 + ML-KEM-768 toegepast op het frontdomein (api.example.com), en de certificaatketen gebruikte dubbele handtekeningen van ECDSA + ML-DSA-65. Na offloading van de handshake op de CDN-edge werd alleen de interne mTLS met PQC (ML-KEM) toegepast tot de oorsprong om hop-overhead te verminderen.
Na 6 weken van de overgang waren de cijfers duidelijk. De regionale gemiddelde RTT van 120 ms had een extra vertraging van de handshake van +8-12 ms, en na optimalisatie van de TLS-recordsplitsing was dit gedaald tot +5 ms. Sommige oudere versies van mobiele Safari werden omgeleid door hybride deactivering als fallback, en het totale succespercentage verbeterde van 99.89% naar 99.93%. Als gevolg daarvan verminderde het verlatingspercentage in de betalingsfase met 0.3%p, wat leidde tot een significante stijging van de maandelijkse omzet.
Effecten in cijfers
- Extra vertraging van de handshake: +5ms (na optimalisatie)
- Voltooiingspercentage: 99.89% → 99.93%
- Winkelwagentje-verlatingspercentage: -0.3%p
- Gegevensbescherming: HNDL-bedreigingen aanzienlijk verminderd
Case 2 — Mobiele bankieren: coëxistentie met legacy HSM
De binnenlandse mobiele bank-app kon de ECDSA niet onmiddellijk verwijderen voor interoperabiliteit met betalingsproviders en openbanking-gateways. Daarom werd de handtekening van het certificaat ingericht als een dubbele keten van ECDSA + ML-DSA, waarbij de HSM de ECDSA afhandelde en PQC als softwaremodule werd offloaded. In de toekomst werd een roadmap opgesteld om over te schakelen naar hardware zodra de PQC-firmware van de HSM-leverancier stabiel was.
De server voerde een geleidelijke uitrol uit door de core banking zone en DMZ te scheiden, en activeerde hybride TLS te beginnen bij de interne API-gateway. Gezien het verkeerspatroon was het percentage van kortetermijnsessiehergebruik hoog, waardoor de feitelijke zichtbare vertraging niet merkbaar was voor de gebruiker. Monitoring werd ingericht om de oorzaken van handshake-fouten bij te houden met JA3/gedrags-telemetrie in een aparte dashboard.
Prestatie bevestigd door cijfers — vergelijking voor en na
| Parameter | Klassiek (TLS 1.3, X25519+ECDSA) | Hybride (X25519+ML-KEM, ECDSA+ML-DSA) | Opmerkingen |
|---|---|---|---|
| Initiële handshake tijd | ~38ms | ~45ms | +7ms, +4-5ms na CDN-offloading |
| Aantal handshake-pakketten | 3-4 | 4-5 | Gelijke niveaus bij MTU/recordtuning |
| CPU voor handtekeningverificatie | Laag | Gemiddeld | Verlichting door batchverificatie en caching |
| Faalpercentage eindgebruiker | 0.11% | 0.07% | Verbeterd door fallback-ontwerp |
| Gegevensbehoud veiligheid | Kwantenkwetsbaar | Kwantenbestendig | HNDL-risico's aanzienlijk verminderd |
Certificaten en codehandtekeningen, herstructureerd in hybride
Niet alleen TLS-certificaten, maar ook de codehandtekeningssystemen van mobiele apps, firmware en desktopapplicaties vallen onder de transformatie. Voor app stores, MDM en enterprise-distributie is de verificatiepipeline complex, dus de periode van dubbele handtekeningen en coëxistentie van ketens moet ruim worden gepland. ML-DSA kan voor operationele handtekeningen worden gebruikt, terwijl SLH-DSA kan worden ontworpen voor archiefhandtekeningen voor lange termijn verificatie, zodat zowel praktische als lange termijn voordelen worden behaald.
| Toepassing | Aanbevolen combinatie | Voordelen | Risico's/Reacties |
|---|---|---|---|
| TLS servercertificaat | ECDSA + ML-DSA dubbele handtekening | Ondersteuning van browsercompatibiliteit, verzekeren van PQC-bescherming | Verhoogde ketengrootte → OCSP-stapeling·compressie |
| Mobiele app/firmware handtekening | ECDSA werking + SLH-DSA archief | Balans tussen uitvoeringssnelheid en langdurige verificatie | Verhoogde pakketgrootte → CDN·incrementale updates |
| Interne service mTLS | X25519 + ML-KEM sleuteluitwisseling | Lage latentie, directe overschakeling mogelijk | Bibliotheekheterogeniteit → eindpuntverwerking bij de gateway |
| Langdurige auditlogs/ontvangstbewijzen | SLH-DSA alleen of met tijdstempel in parallel | Verificatie mogelijk zelfs na quantum | Last van handtekeninggrootte → opslagontwerp aanvullen |
Status van ecosysteemondersteuning 2025 — waar staan we nu
De ondersteuning van browsers, besturingssystemen, cloud- en HSM-leveranciers bepaalt de snelheid van de 'hybride overgang'. In 2025 hebben grote CDN's en clouds op edge-niveau ML-KEM beta/GA-opties aangeboden, en browsers zijn bezig met het verzamelen van compatibiliteitsgegevens via experimentele vlaggen of geleidelijke uitrol. Aan de serverzijde worden OCSP-stapeling en compressie, evenals 0-RTT-beperkingen, aangepast met het oog op de toename van de grootte van de certificaatketen.
| Gebied | Ondersteuningsstatus (verwacht 2025) | Controlepunten | Aanbevolen actie |
|---|---|---|---|
| Browsers (Chrome/Edge/Firefox) | Hybride KEX-experiment/gegradueerde invoering | Onderhandelingsfouten, initiële pakketgrootte | UA-gebaseerde uitrol, fallback-pad duplicatie |
| CDN/Cloud (edge TLS) | ML-KEM optie GA/regio beperkt | Beschikbaarheid per regio, logdiepte | Toepassen vanaf hete regio's, indicatorgebaseerde uitbreiding |
| Serverbibliotheek (OpenSSL/BoringSSL) | PQC-tak/bouwvlaggen beschikbaar | ABI-stabiliteit, patchfrequentie | Staging langdurige belastingstest |
| HSM/sleutelbeheer | PQC-firmware roadmap openbaar maken | Veiligheidsprocedures, back-up/herstel | SW offloading + HSM gemengde architectuur |
| CA/certificaatuitgifte | Dubbele handtekening/keten experimentele uitgifte | Ketengrootte·verificatietransparantie | Strategie voor stapeling·compressie·tussenliggende CA's opstellen |
Gegevenspijplijn en gebruikerservaring, beide vangen met ontwerp
De hybride overgang is een samenwerkingsuitdaging voor netwerk-, applicatie- en datateams. Het netwerk past de MTU·QoS·pakketbeleid aan, de applicatie verduidelijkt de fout-UX bij handshake-fouten, en het datateam verhoogt het encryptieniveau van gegevens voor langdurige bewaring. In het bijzonder krijgen account-, betalings- en persoonsgegevens-API's hoge prioriteit voor gefaseerde toepassing.
Op mobiel zijn initiële splash- en sessie-opwarmstrategieën effectief. Direct na de app-uitvoering wordt op de achtergrond een nieuwe hybride sessie opgezet, zodat op het moment dat de gebruiker op de tab drukt, de sessie al in een 'warme' staat verkeert. Hiervoor moet het Keep-Alive-beleid van Push/directe kanalen opnieuw worden bekeken en moeten de batterij-impact en dataverbruik tot een minimum worden beperkt.
Praktische tips — grote effecten met kleine aanpassingen
- Recordgrootte: aanbevolen 1200~1400 bytes (voorkomen van initiële pakketfragmentatie)
- Compressie: activeren van certificaatketencompressie/OCSP-stapeling
- Logging: JA3 + hybride onderhandelingsresultaten verzamelen met aparte tags
- Fallback: bij onderhandelingsfouten automatisch overschakelen naar klassieke routes, maar op lange termijn hybride prioriteit geven
Zorg voor consistentie met regelgeving en standaarden
De trends in de VS OMB-memo en NSA CNSA 2.0, ENISA-richtlijnen vragen om prioritaire adoptie van PQC en indiening van roadmaps. Documenteer de basis voor de toepassing van NIST FIPS 203/204/205, testlogs en uitrolplannen ter voorbereiding op inkoop- en auditprocedures, en eis hetzelfde niveau van hybride/overgangsplannen in de toeleveringsketen (derde partijen SDK·agenten·proxy). De interne standaard moet het cryptosuite-beleid, de levensduur van certificaten en de sleutelvervangingsfrequentie duidelijk vastleggen.
Risicomatrix — gemakkelijk te missen valkuilen
- Initiële pakketverlies door MTU-fragmentatie: aanpassing van recordgrootte en grensmonitoring is essentieel
- DPI-valse positieven van tussentijdse apparatuur: valse positieven oplossen door regels bij te werken in hybride uitbreidingsvelden
- Exponentiële groei van de handtekeningketen: verzachten door OCSP-stapeling·compressie, herstructurering van tussenliggende CA's
- Gemengde bibliotheken: standaardisatie per dienst, geconsolideerde verwerking bij de gateway
Kosten en ROI — overtuigen met cijfers
De kosten van de hybride overgang kunnen grofweg in drie categorieën worden onderverdeeld. 1) Infrastructuurwerkzaamheden (bibliotheekupdates·CDN-opties·gatewayvervanging), 2) Wijzigingen in het certificaat-/handtekeningenstelsel (dubbele handtekening·keten), 3) Monitoring/operationele automatisering (dashboard·meldingen·fallback-controle). Daarentegen komt besparing of waardecreatie terug in de vorm van het vermijden van kosten voor regelgeving, merkvertrouwen en het waarborgen van gegevensherstel.
| Item | Initiële kosten (relatief) | Operationele kosten (relatief) | Waarde/besparing | Opmerkingen |
|---|---|---|---|---|
| Bibliotheek/edge-updates | Gemiddeld | Laag | Standaard volgen, snel reageren op kwetsbaarheden | Aanbevolen automatisering van wijzigingsbeheer |
| Certificaat/handtekeningenstelsel | Gemiddeld-Hoog | Gemiddeld | Langdurige verificatie-activa veiligstellen | CA·HSM-leverancier samenwerking vereist |
| Monitoring/fallback | Gemiddeld | Laag | Voorkomen van storingverspreiding | Feature flags·load rate controle |
| Training/documentatie | Laag | Laag | Verminderen van operationele risico's | Inbedden van beveiligingsbelemmeringen |
Drie hybride recepten die direct toepasbaar zijn
- Buitenlandse web/API: TLS 1.3, X25519 + ML-KEM-768, ECDSA + ML-DSA-65 keten, OCSP-stapeling·compressie is verplicht
- Interne service-mesh: hybride eindpunt in service-mesh/gatewaylaag, mTLS-certificaat met korte levensduur (≤30 dagen)
- Code/pakkethandtekening: operationele ECDSA behouden + PQC-handtekening parallel, dubbele verificatiefase in distributiepijplijn invoegen
2025 is het jaar waarin we overgaan van "testen" naar "standaardinstelling". Hybride biedt een praktische brug die de brede compatibiliteit van klassieke cryptografie en de veerkracht van PQC tegelijk biedt. Het is nog niet te laat om te beginnen. Begin met de belangrijkste activa en verander ze op de minst zichtbare manier.
Dit is de kernstrategie van hybride overgang en praktijkvoorbeelden, evenals de argumenten voor besluitvorming door vergelijking. In het volgende segment zullen we de echte invoerlijsten en foutloze uitrolscenario's samenstellen, evenals operationele tips om de zakelijke impact te maximaliseren. We zullen ervoor zorgen dat je meteen kunt handelen, met specifieke stappen en indicatoren.
SEO sleutelwoorden
Quantum-veilig cryptografie, PQC, Hybride overgangen, Klassieke cryptografie, TLS 1.3, ML-KEM, ML-DSA, SLH-DSA, RSA, ECDSA
Deel 1 Conclusie: Hybride transitie in 2025, het is tijd om de ramen open te zetten
De boodschap die we in Deel 1 uitgebreid hebben besproken, is eenvoudig. Post-kwantumcryptografie (PQC) is niet iets dat we 'ooit' moeten voorbereiden, maar wordt vanaf 2025 de standaard beveiliging die geïntegreerd moet worden in echte diensten en producten. Zelfs als een hacker morgen geen quantumcomputer in handen krijgt, is de 'Harvest Now, Decrypt Later'-strategie, waarbij gegevens die vandaag zijn gestolen morgen worden ontsleuteld, al dagelijkse kost. Vanuit dit perspectief moeten we voor diensten die gegevens langdurig opslaan, tijdig de hybride transitie beginnen.
Dat betekent echter niet dat we alles overboord moeten gooien. Het belangrijkste is om de bestaande klassieke cryptografie-stacks niet te verwijderen, maar TLS 1.3-gebaseerde connecties uit te breiden met PQC-algoritmen zoals Kyber (KEM) en Dilithium (handtekening) om gelaagde bescherming te creëren. Door hybride te gaan, verminderen we compatibiliteitsrisico's en ontstaan er vanzelf back-upplannen. Bovenal is er een groot praktisch voordeel dat we de regulering en het vertrouwen van klanten kunnen veroveren.
De vraag is nu niet "Wanneer moeten we het doen?" maar "Waar moeten we beginnen?" Terwijl de NIST-normering eindversie en de roadmap van de industrieleveranciers zich tegen medio 2025 concretiseren, kunnen we, als we dit jaar de pilot en de controle van de certificaatketen afronden, volgend jaar met vertrouwen een 'kwantumveilig roadmap' presenteren in contracten en productdocumenten. Hier zal ik de conclusie van Deel 1 samenvatten en een roadmap presenteren om de daadwerkelijke actie te ondernemen.
Wat moeten we nu doen? Actiecheckpunten voor 30·60·90 dagen
De eerste stap naar hybride is niet 'perfect in één keer', maar 'klein en snel'. De onderstaande checkpunten zijn een realistische startlijn voor organisaties met 5-20 leden in het beveiligingsteam. Als het personeel of budget kleiner is, kan de scope gerust gehalveerd worden.
- Eerste 30 dagen: Inventarisatie van activa en afhankelijkheidskaart
- Doelstellingen ordenen: Externe blootgestelde diensten (web, app API), interne cruciale data (langdurige opslag), data in transit (back-up/synchronisatie).
- Cryptografie-status scannen: Lengte van certificaat sleutels, handtekeningalgoritmen (SHA-256/384), maximale grootte van de certificaatketen, sessieopbouwtijd.
- Derde partij lijst opstellen: CDN, WAF, e-mailgateway, MDM, VPN, HSM, load balancer.
- Volgende 60 dagen: Start hybride PoC (pilot)
- TLS PoC: Eén server en één type client selecteren om de prestaties van hybride TLS (ECDHE+Kyber) te meten.
- Codehandtekening PoC: Voeg Dilithium handtekening toe aan de build-pijplijn en valideer het distributiekanaal.
- HSM/sleutelbeheer verificatie: Beleid voor PQC sleutelgeneratie/opslag/back-up, schrijf de sleutelrotatieprocedures.
- Laatst 90 dagen: Operationeel beleid en communicatie
- Beleid: Hybride prioriteit, recovery keys, verkorting van de sleutellevensduur (bijv. 12→6 maanden), definiëren van prestatiebudgetlimieten.
- Buitencommunicatie: Publiceer de kwantumveiligheid roadmap op de beveiligingspagina, publiceer FAQ voor B2B-klanten.
- Leverancierscontract: Inclusief PQC-ondersteunde SLA, straffen/incentives voor de uitvoering van de roadmap.
Snelle overwinningen (Quick Wins)
- Browser- en OS-updates: Vroegtijdige compatibiliteit bevestigen via PQC-testfunctie-vlaggen.
- TLS-handshake logging: Verzamel RTT- en pakketgroottemetingen om 'waargenomen vertraging' te onderbouwen.
- Versleuteling van langdurige opslagdata als prioriteit: Herversleutel eerst back-up/archief naar hybride.
Als je dit hebt voorbereid, worden de belangrijkste risico's in de meeste gevallen duidelijk. Als de payload van het certificaat tijdens de test groter wordt en er pakketfragmentatie optreedt, kan dit op netwerkniveau worden gecompenseerd door MTU-aanpassingen of delegatiestrategieën op het niveau van de CDN. Als het prestatiebudget krap is, is het beter om prioriteit te geven aan inlog-, betalings- en API-gatewaydiensten om 'bescherming voor de gebruiker' te waarborgen.
Gegevenssamenvattingstabel: Het numerieke gevoel van de hybride transitie in 2025
De onderstaande cijfers zijn conservatieve schattingen op basis van representatieve leveranciersimplementaties en openbare referenties. De werkelijke waarden kunnen variëren afhankelijk van netwerkomstandigheden, clients en hardwareversnelling.
| Item | Alleen klassieke cryptografie | Hybride (ECDHE+Kyber, ECDSA+Dilithium) | Veranderingstoename | Opmerking |
|---|---|---|---|---|
| TLS-handshakegrootte | ~3~5 KB | ~8~14 KB | +5~9 KB | Alleen invloed op de initiële verbinding, weinig effect bij sessieherstel |
| Initiële verbindingsvertraging (uitgaande van 50 ms RTT) | ~1.0× | ~1.05~1.20× | +5~20% | Merkbaar op mobiel en internationale netwerken |
| Server CPU-gebruik (piek) | Basis 100 | 110~140 | +10~40% | Wordt sterk beïnvloed door handshakes die veel werkbelasting vereisen |
| Handtekeninggrootte (codehandtekening) | ~70~100 B (ECDSA) | ~2~3 KB (Dilithium) | +20~30× | Verhoogde pakketgrootte, distributiepijplijn moet worden gecontroleerd |
| Grootte van de certificaatketen | ~2~4 KB | ~10~20 KB | +3~5× | Invloed van MTU/fragmentatie en cachebeleid |
| Migraties moeilijkheidsgraad | Laag | Gemiddeld | +1 niveau | Hybride vermindert compatibiliteitsrisico's |
Het belangrijkste punt is dat de meeste impact 'tijdelijke straffen bij initiële verbinding' zijn en niet 'permanente straffen'. Alleen in diensten die gevoeliger zijn voor vertraging dan bandbreedte is nauwkeurige afstemming vereist, en moderne optimalisaties zoals CDN/cache, sessieherstel en 0-RTT compenseren de straffen.
Vijf valkuilen die gemakkelijk over het hoofd worden gezien
- Ontbrekende derdepartijlinks: Zelfs als alleen de hoofddomein wordt gewijzigd, kan verwarring ontstaan als de subresources (CDN, afbeeldingen, betalingswidgets) verouderde stacks gebruiken.
- Dubbele controle mislukt: Proxy's, WAF's en APM's kunnen extensieheaders verkeerd detecteren, waardoor uitzonderingsregels nodig zijn.
- Patch-latentie: Door vertragingen in goedkeuring van de app store voor client-apps kan de inconsistentie tussen server- en clientversies langer duren.
- Log-explosie: Toename van handshake-metadata kan leidend zijn tot hogere SIEM-kosten, wat herontwerp van het opslagbeleid vereist.
- Overmoed in sleutellevensduur: De illusie dat "PQC voor altijd veilig is". Sleutelrotatie en afschaffing moeten worden geautomatiseerd.
Praktische tips: Gebruikerservaring wordt bepaald door 0,1 seconde
Hybride transitie is geen alleenstaand beveiligingsprobleem. Het is direct gerelateerd aan gevoelige indicatoren zoals winkelwagentjesverlaten, inlogsuccespercentages en initiële buffering bij videostreaming. Beslis samen met het zakelijke team op basis van cijfers.
- A/B-test van de inlogpagina: Test 7 dagen met hybride aan/uit; als het verloop meer dan 0,2% is, verhoog dan de sessieherstelratio om dit te compenseren.
- Land-specifieke afstemming: In gebieden met hoge RTT, plaats edge-netwerken aan de voorkant en stel caching voor de certificaatketen in.
- Optimalisatie van app-initialisatie: Mobile apps moeten bij de eerste uitvoering de PQC-onderhandelingsbronnen preloaden.
- Evenementmarketing koppeling: Expose "Kwantumveilig upgrade voltooid" badges in de winkel/web om het vertrouwen te versterken.
- Oefeningen voor herstel van storingen: Verifieer twee keer per jaar of er automatisch wordt teruggevallen op puur klassieke cryptografie bij hybride falen.
Laten we realistische normen stellen. Wachten op 100% perfectie is gelijk aan 0% bescherming. Snel 90% hybride bescherming realiseren en daarna de resterende 10% verbeteren is de strategie die de markt en klanten beschermt.
Kernsamenvatting: 10 dingen om te onthouden uit Deel 1
- 2025 is het jaar van de praktische transitie met de overlap van NIST-normering en vendor-implementatie.
- De kern van de strategie is niet 'vervangen' maar 'parallel': Hybride van klassieke cryptografie + PQC is de veilige standaard.
- Met Kyber voor sleuteluitwisseling en Dilithium voor handtekeningen heb je een goede balans tussen compatibiliteit en prestaties.
- De initiële kosten komen tot uiting in de toename van handshake- en handtekeninggroottes, wat in de meeste gevallen kan worden gecompenseerd door operationele optimalisatie.
- Begin met een TLS 1.3-gebaseerde stack om de implementatiecomplexiteit aanzienlijk te verlagen.
- Door prioriteit te geven aan langdurige opslagdata en gereguleerde workloads, maximaliseer je het risicoverminderende effect.
- De grootte van de certificaatketen en MTU, en de cachingstrategieën van de CDN moeten samen worden ontworpen voor een betere gebruikerservaring.
- De status van PQC-ondersteuning van leveranciers, open-source en HSM moet contractueel en in SLA's worden vastgelegd om 'leeglopende roadmaps' te vermijden.
- Herontwerp log-/monitoring/-kostenmodellen om onvoorziene stijgingen in operationele kosten te voorkomen.
- Verander kwantumveiligheid in een vertrouwenspunt door klantcommunicatie.
Veelgestelde vragen (super eenvoudig)
- Kun je alleen PQC gebruiken? — Momenteel wordt hybride aanbevolen. Het is een overgangsperiode van compatibiliteit en standaardbepaling, dus dubbel gebruik is veiliger.
- Wat is de standaardalgoritme? — Sleuteluitwisseling is Kyber, en handtekeningen zijn voornamelijk Dilithium die de markt domineren.
- Zal de eindgebruiker dit merken? — Er kan enige vertraging zijn bij de initiële verbinding, maar de meeste problemen worden opgelost door sessieherstel en caching.
- Wat moet je uitsluiten als het budget krap is? — Stel de volledige transitie van intern verkeer uit en begin met het beschermen van extern blootgestelde diensten.
1-pagina boodschap voor interne teamafstemming
Leg aan de leidinggevenden uit dat het gaat om "beveiliging als verzekering", niet als "schild voor winst". Als een concurrent 'kwantumveiligheid' als marketingboodschap als eerste claimt, kan onze service er al snel verouderd uitzien. Aan de andere kant, als we de hybride transitie voltooien en de meetwaarden als bewijs gebruiken, wordt beveiliging direct een merk.
1-pagina samenvattingsformat (kopieer en plakbaar)
- Doel: Voltooi de hybride transitie van extern blootgestelde diensten (inloggen/betaling/API-gateway) binnen 90 dagen.
- Indicatoren: Eerste byte tijd binnen +15ms, certificaatketen cache hit rate boven 85%.
- Scope: TLS 1.3 + ECDHE+Kyber, ECDSA+Dilithium gelijktijdig.
- Risicobeperking: fallback-routes, storingsspel dagen, logkostenlimieten.
- Klantcommunicatie: Beveiligingsupdate bekendmaking + FAQ + badge-exposure.
Veldchecklijst: Criteria voor voltooiing van de pilot
- Prestatie: Is de handshakevertraging en verandering in pakketgrootte binnen de benchmark standaarddeviatie?
- Compatibiliteit: Biedt het een succespercentage van 95% of meer voor belangrijke browsers/OS/app SDK's?
- Operationeel: Zijn sleutelrotatie, afschaffing en back-up geïntegreerd in een geautomatiseerde pijplijn?
- Beveiliging: Is de bescherming van PQC-sleutels in HSM, auditlogs en scheiding van bevoegdheden geïmplementeerd?
- Wetgeving: Heb je gecontroleerd of je voldoet aan de lokale export- en certificeringsregels voor cryptografie?
Als je aan deze criteria voldoet, breid je de scope maand voor maand uit. Na de API-gateway kun je verder gaan met de klantenserviceportaal en vervolgens de interne beheersconsole. Deze geleidelijke aanpak vermindert de vermoeidheid van het team en helpt om successen systematisch op te bouwen.
Deel 2 Vooruitblik: Tools, commando's en configuratievoorbeelden, praktische uitvoering
Hiermee eindigen we Deel 1. We hebben gezien waarom de hybride transitie nodig is, op basis waarvan we prioriteiten moeten stellen en met welke cijfers we het management kunnen overtuigen. In Deel 2 zullen we daadwerkelijk aan de slag gaan. We zullen de vlaggen bekijken om hybride suites in OpenSSL/BoringSSL in te schakelen, optimalisatie van de certificaatketen in Envoy·Nginx, instellingen voor Android/iOS SDK en een pijplijn waarin Dilithium codehandtekeningen in CI/CD worden toegevoegd, met 'kopieer-en-plakbare' recepten.
Deel 2, Segment 1 begint met een herbenoeming van de kern van dit deel (Deel 1) en stelt opnieuw onze doelen, indicatoren en prioriteiten vast. Vervolgens gaan we door met het opzetten van een testbed, stap-voor-stap commando's, terugvalstrategieën en de uiteindelijke 'operator checklijst'. In de volgende aflevering vind je een praktische gids die je direct kunt toepassen op je service.
