Kryptographie ist meistens Schlüsselverwaltung.
ISO 27001:2022 A.8.24 (Verwendung von Kryptographie) behandelt die wirksame Nutzung von Kryptographie zum Schutz von Informationen, einschließlich der Schlüsselverwaltung. Im Code reduziert sich dies meist auf drei Punkte: Werden Schlüssel sicher verwaltet, sind die Algorithmen stark und ist die Konfiguration korrekt. Alle drei Punkte sind Entscheidungen im Pull Request, und der Fehler, der im Code auftritt, ist oft ein Schlüssel am falschen Ort und nicht ein schwacher Algorithmus.
The shapes the same control failure takes.
A.8.24 wird geschwächt, wenn ein Schlüssel falsch behandelt oder ein primitives Verfahren herabgestuft wird. Die wiederkehrenden Muster:
Ein Schlüssel landet im Code
Ein Geheimnis oder privater Schlüssel wird hartcodiert oder committed, anstatt aus einem verwalteten Secret Store ausgelesen zu werden, sodass er im Repository und in dessen Verlauf existiert.
Ein schwaches primitives Verfahren wird eingeführt
Eine Änderung verwendet einen gebrochenen oder schwachen Hash- oder Verschlüsselungsalgorithmus (z. B. für Passwort-Hashing oder Signaturen), wo ein starker erforderlich wäre.
Die TLS-Mindestanforderung sinkt
Eine Mindestversion des Protokolls oder eine Verschlüsselungsanforderung wird herabgesetzt, wodurch die Kryptographie, die den Transport schützt, geschwächt wird.
Die Überprüfung wird deaktiviert
Die Zertifikats- oder Signaturüberprüfung wird abgeschaltet, sodass ein verschlüsselter Kanal oder ein signiertes Artefakt nicht mehr tatsächlich vertrauenswürdig ist.
Rotation oder Gültigkeitsbereich eines Schlüssels wird gelockert
Die Lebensdauer eines Schlüssels wird unbegrenzt verlängert oder ein Schlüssel wird über Grenzen hinweg wiederverwendet, die er nicht überschreiten sollte.
Ein Signaturschlüssel wird hartcodiert, um ein Deployment zu reparieren.
Ein Schlüssel für die Token-Signatur wurde aus einem Secret Store ausgelesen, aber der Store war in einer neuen Umgebung nicht konfiguriert, und das Deployment scheiterte. Die schnelle Lösung bestand darin, den Schlüssel direkt einzufügen, damit der Dienst startet. Das funktionierte, und der private Schlüssel befindet sich nun im Repository und in dessen Verlauf.
- const SIGNING_KEY = await secrets.get("jwt-signing-key")+ const SIGNING_KEY = "<the PEM private key, pasted inline>"const token = sign(claims, SIGNING_KEY)Ein Signaturschlüssel in der Quelle existiert im Repository, in dessen Verlauf sowie in jedem Clone und CI-Cache, was die Schlüsselverwaltung, die A.8.24 erwartet, untergräbt. Stellen Sie ihn aus dem Secret Store wieder her, konfigurieren Sie den Store in der neuen Umgebung und rotieren Sie den Schlüssel, da ein committed Schlüssel als kompromittiert behandelt werden muss.
Schlüsselverwaltung ist der Teil, der stichprobenartig geprüft wird.
Ein Prüfer, der A.8.24 betrachtet, interessiert sich weniger dafür, welchen Algorithmus Sie gewählt haben, sondern mehr dafür, wie Schlüssel generiert, gespeichert, rotiert und außer Dienst gestellt werden. Ein im Quellcode gefundenes Geheimnis, ein Schlüssel ohne Rotation oder eine stillschweigend deaktivierte Überprüfung sind die Art von Befunden, die auftreten, und sie gelangen meist über eine Änderung, die etwas blockieren sollte. Der Pull Request ist der Ort, an dem die entscheidende Entscheidung getroffen und am kostengünstigsten korrigiert wird.
Eine Überprüfung, kein Krypto-Audit.
heygrc markiert Änderungen, die A.8.24 betreffen, und verweist auf die Kontrolle, sodass die Korrektur im Pull Request erfolgt. Es entwirft nicht Ihr Schlüsselverwaltungsschema und führt keine Bewertung durch. Es erkennt den Moment, in dem ein Schlüssel falsch behandelt oder ein primitives Verfahren geschwächt wird, direkt im Diff.