Cryptografie draait vooral om sleutelbeheer.
ISO 27001:2022 A.8.24 (gebruik van cryptografie) gaat over het effectieve gebruik van cryptografie om informatie te beschermen, inclusief sleutelbeheer. In code komt dit vooral neer op drie zaken: worden sleutels veilig beheerd, zijn de algoritmes sterk en is de configuratie correct. Al deze drie aspecten zijn beslissingen die in een pull request worden genomen, en de fout die in code opduikt is vaak een sleutel op de verkeerde plek in plaats van een zwak algoritme.
The shapes the same control failure takes.
A.8.24 verzwakt wanneer een sleutel verkeerd wordt beheerd of een primitief wordt verlaagd. De terugkerende patronen:
Een sleutel belandt in de code
Een geheim of private sleutel wordt hardcoded of gecommit in plaats van gelezen uit een beheerde geheime opslag, waardoor deze in de repository en de geschiedenis blijft bestaan.
Een zwak primitief wordt geïntroduceerd
Een wijziging gebruikt een gebroken of zwakke hash of cipher (bijvoorbeeld voor wachtwoordhashing of ondertekening) waar een sterke vereist is.
De TLS-basis daalt
Een minimale protocolversie of ciphervereiste wordt verlaagd, waardoor de cryptografie die een transport beschermt verzwakt.
Verificatie is uitgeschakeld
Certificaat- of handtekeningsverificatie wordt uitgeschakeld, waardoor een versleuteld kanaal of ondertekend artefact niet langer daadwerkelijk vertrouwd wordt.
Sleutelrotatie of -scope wordt versoepeld
De levensduur van een sleutel wordt onbeperkt verlengd, of één sleutel begint te worden hergebruikt over grenzen heen waar dit niet zou mogen.
Een ondertekeningssleutel hardcoded om een deploy op te lossen.
Een token-ondertekeningssleutel werd gelezen uit een geheime opslag, maar de opslag was niet geconfigureerd in een nieuwe omgeving en de deploy mislukte. De snelle oplossing was om de sleutel inline te plaatsen, zodat de service start. Dat lukte, en de private sleutel staat nu in de repository en de geschiedenis.
- const SIGNING_KEY = await secrets.get("jwt-signing-key")+ const SIGNING_KEY = "<the PEM private key, pasted inline>"const token = sign(claims, SIGNING_KEY)Een ondertekeningssleutel in de broncode blijft bestaan in de repository, de geschiedenis en elke clone en CI-cache, wat het sleutelbeheer dat A.8.24 verwacht tenietdoet. Herstel deze uit de geheime opslag en configureer de opslag in de nieuwe omgeving, en roteer de sleutel, omdat een gecommitte sleutel als blootgesteld moet worden beschouwd.
Sleutelbeheer is het onderdeel dat wordt beoordeeld.
Een auditor die naar A.8.24 kijkt, hecht minder waarde aan welke cipher je hebt gekozen en meer aan hoe sleutels worden gegenereerd, opgeslagen, geroteerd en buiten gebruik gesteld. Een geheim dat in de broncode wordt gevonden, een sleutel zonder rotatie of verificatie die stilletjes is uitgeschakeld, zijn het soort bevindingen die naar voren komen, en deze komen meestal binnen via een wijziging die iets probeerde te ontblokkeren. De pull request is de plek waar de sleutelbeslissing wordt genomen en de goedkoopste plek om deze te corrigeren.
Een review, geen crypto-audit.
heygrc markeert wijzigingen die A.8.24 raken en verwijst naar de controle, zodat de correctie in de pull request plaatsvindt. Het ontwerpt niet je sleutelbeheerschema of voert je beoordeling uit. Het vangt het moment op waarop een sleutel verkeerd wordt beheerd of een primitief wordt verzwakt, op het niveau van de diff.