Post-quantum beveiliging: begin niet met nieuwe encryptie

Een accountantskantoor bewaart dossiers tien jaar. De eigenaar weet welke applicatie de dossiers toont, maar niet welke verbindingen en back-ups ze onderweg beschermen. Dan is nieuwe encryptie niet de eerste klus. De eerste klus is uitzoeken waar de huidige cryptografie zit en wie haar kan vervangen.

Cloudflare beschrijft hoe het AI inzet om cryptografie te ontdekken als voorbereiding op een migratie naar post-quantum beveiliging. Dat is interessant nieuws, maar voor het MKB ligt de les niet in de AI. Mijn stelling: wie zijn sleutels, certificaten en afhankelijkheden niet kan aanwijzen, kan ook niet verantwoord migreren.

Bron: https://blog.cloudflare.com/ai-driven-cryptography-discovery/. Het bericht gaat over de aanpak van Cloudflare, niet over een kant-en-klare routekaart voor ieder bedrijf. De vragen hieronder zijn daarom een praktische vertaling naar een kleinere organisatie.

Waarom de haast verkeerd wordt begrepen

Bij post-quantum cryptografie denken veel ondernemers aan een toekomstig moment waarop een aanvaller met een krachtige quantumcomputer een verbinding kraakt. Dat beeld leidt tot een begrijpelijke reactie: wacht tot die computer er is en vervang dan de beveiliging. Voor gegevens met een lange bewaartermijn is dat te simpel.

Een aanvaller kan versleutelde gegevens onderscheppen en bewaren in de hoop ze later te ontsleutelen. Dat maakt de vraag niet alleen of je verkeer op dit moment beschermd is, maar ook hoelang dat verkeer geheim moet blijven. Een afspraak voor volgende maand heeft een ander risicoprofiel dan een medisch dossier, een overnamedocument of een kopie van een identiteitsbewijs.

Tegelijk is paniek geen migratieplan. Niet elke versleutelde verbinding is even kwetsbaar voor dezelfde toekomstige ontwikkeling, en niet elk systeem kun je eigenhandig aanpassen. Wie nu blind certificaten vervangt of een product koopt met een post-quantum label, kan compatibiliteit breken zonder de belangrijkste gegevens beter te beschermen.

Je hebt waarschijnlijk meer cryptografie dan je denkt

Een webshop kan prima weten waar de klantdatabase staat en toch geen volledig beeld hebben van de bescherming eromheen. Denk aan de verbinding tussen browser en website, de verbinding van de website naar een betaaldienst, toegang voor beheerders, versleutelde back-ups en de uitwisseling met een verzendpartner. Dat zijn verschillende plekken, met verschillende eigenaren.

Het verraderlijke deel zit vaak buiten het zicht van de ondernemer. Een leverancier beheert een certificaat. Een oude koppeling vertrouwt op een vaste instelling. Een archief is jaren geleden versleuteld, maar niemand weet nog waar de sleutel wordt bewaard. Een inventaris van applicaties is dus geen inventaris van cryptografie.

Neem een installatiebedrijf met 35 medewerkers. Monteurs sturen foto's en rapporten vanaf hun telefoon, de planning staat in een bedrijfsapplicatie en offertes gaan naar klanten en onderaannemers. De eigenaar hoeft niet zelf de cryptografische instellingen van elk apparaat te lezen. Hij moet wel kunnen vragen: welke gegevens reizen waarheen, wie beheert de beveiliging van die verbinding en wat gebeurt er als de gebruikte methode moet veranderen?

Maak een kaart die een beslissing mogelijk maakt

Begin niet met een lijst van alle technische afkortingen. Begin met vijf gegevensstromen die voor je bedrijf het meest gevoelig of langdurig zijn. Voor een accountantskantoor zijn dat bijvoorbeeld klantdossiers, loonbestanden, identiteitsdocumenten, back-ups en toegang op afstand. Teken per stroom de bron, bestemming en externe partijen.

Voeg daarna per stroom vier velden toe:

• Bewaartermijn: moet de inhoud maanden, jaren of langer vertrouwelijk blijven?

• Beschermingspunt: gaat het om transport, opslag, toegang of meerdere daarvan?

• Eigenaar: kun je de instelling zelf wijzigen of beheert een leverancier haar?

• Vervangbaarheid: kun je een wijziging testen zonder de dienstverlening stil te leggen?

Die vier velden zijn nuttiger dan een dashboard met honderd gevonden certificaten. Ze vertellen je namelijk waar je handelingsruimte hebt. Een certificaat dat volgende maand afloopt verdient onderhoud, maar is niet automatisch het grootste post-quantum risico. Een tien jaar te bewaren archief waarvan niemand de sleutelbeheerder kent, verdient waarschijnlijk eerder onderzoek.

Laat je technische beheerder vervolgens vastleggen welke protocollen, certificaten en sleutels bij de gekozen stromen horen. Noteer ook onzekerheden. ‘Onbekend’ is een bruikbare uitkomst, zolang er een eigenaar en een vervolgvraag bij staan. Een leeg vak dat voor ‘veilig’ wordt aangezien, is gevaarlijker.

Waar AI wel en niet helpt

De keuze van Cloudflare om AI bij cryptografische ontdekking te betrekken, wijst op een echt probleem: sporen van cryptografie zitten verspreid over configuraties, code en infrastructuur. Een hulpmiddel kan patronen aanwijzen en het zoekwerk versnellen. Vooral in grotere omgevingen is dat waardevol.

Maar ontdekking is geen beoordeling. Een gevonden verwijzing in oude code bewijst niet dat die code nog draait. Een niet gevonden sleutel bewijst niet dat hij niet bestaat. En een model kan uit een configuratiebestand niet afleiden of een klantdossier over acht jaar nog vertrouwelijk moet zijn. Die context komt van het bedrijf zelf.

Voor een klein bedrijf is handmatig beginnen daarom geen achterstand. Met vijf kritieke stromen en gerichte vragen aan leveranciers kun je sneller tot een verdedigbare prioriteit komen dan met een brede scan zonder eigenaar voor de uitkomsten. AI wordt pas nuttig wanneer iemand de vondsten kan controleren en er een wijziging op kan plannen.

Stel leveranciers vragen waarop je kunt sturen

Veel MKB-bedrijven beheren hun eigen cryptografie maar gedeeltelijk. Juist daarom is ‘onze leverancier regelt het’ onvoldoende. Vraag welke onderdelen de leverancier beheert, hoe wijzigingen worden getest en hoe je bericht krijgt als een gebruikte methode wordt uitgefaseerd.

Vraag ook naar de gegevens zelf. Worden back-ups versleuteld, wie beheert de sleutels en wat gebeurt ermee na beëindiging van het contract? Kun je gegevens exporteren als je moet overstappen? Een leverancier hoeft niet meteen een datum voor een volledige post-quantum migratie te beloven. Je hebt wel een aanspreekpunt en een uitlegbare aanpak nodig.

Leg de antwoorden vast naast je gegevensstromen, niet in een losse e-mail die niemand meer terugvindt. Als een leverancier een onderdeel niet kan toelichten, markeer dat als afhankelijkheid. Het is een reden om door te vragen, geen bewijs dat de beveiliging ondeugdelijk is.

Een verstandige eerste maand

Reserveer in week één een gesprek van een uur met de mensen die data, applicaties en leveranciers kennen. Kies de vijf belangrijkste stromen. Laat in week twee de technische eigenaar per stroom de beschermingspunten en onzekerheden invullen. Besteed week drie aan leveranciersvragen en gebruik week vier om één testbare wijziging of één ontbrekend bewijsstuk te kiezen.

Die wijziging kan bescheiden zijn: een verouderde koppeling documenteren, een onduidelijke sleutelbeheerder aanwijzen of controleren of een kritieke dienst configuratiewijzigingen kan verdragen. Het doel is niet om binnen dertig dagen ‘quantumveilig’ te zijn. Het doel is dat een latere cryptografische verandering geen verrassingsoperatie wordt.

Er is ook een duidelijke uitzondering. Als je alleen kortlevende, weinig gevoelige gegevens verwerkt en je infrastructuur volledig door leveranciers wordt beheerd, kan een uitgebreide eigen cryptografiekaart buitensporig zijn. Leg dan minimaal de gegevensstromen, contractuele aanspreekpunten en bewaartermijnen vast. Meer detail moet een besluit ondersteunen, niet een spreadsheet vullen.

De echte voorbereiding op post-quantum beveiliging is dus minder spectaculair dan een nieuwe versleutelingsmethode. Maak eerst zichtbaar wat je beschermt, hoelang en met wiens sleutels. Pas daarna kun je bepalen wat moet veranderen en wanneer.