La crittografia riguarda soprattutto la gestione delle chiavi.
ISO 27001:2022 A.8.24 (uso della crittografia) riguarda l'uso efficace della crittografia per proteggere le informazioni, inclusa la gestione delle chiavi. Nel codice questo si traduce principalmente in tre aspetti: le chiavi sono gestite in modo sicuro, gli algoritmi sono robusti e la configurazione è corretta. Tutte e tre sono decisioni prese durante la pull request, e il fallimento che emerge nel codice è spesso una chiave nel posto sbagliato piuttosto che un algoritmo debole.
The shapes the same control failure takes.
A.8.24 si indebolisce quando una chiave viene gestita in modo errato o un algoritmo viene declassato. Le forme ricorrenti:
Una chiave finisce nel codice
Una chiave segreta o privata viene codificata o committata invece che letta da un archivio segreto gestito, quindi risiede nel repository e nella sua cronologia.
Viene introdotto un algoritmo debole
Una modifica utilizza un hash o un cifrario rotto o debole (ad esempio per l'hashing delle password o la firma) dove è richiesto uno robusto.
Il livello minimo TLS viene abbassato
Viene ridotta la versione minima del protocollo o il requisito del cifrario, indebolendo la crittografia che protegge il trasporto.
La verifica viene disabilitata
La verifica del certificato o della firma viene disattivata, quindi un canale crittato o un artefatto firmato non è più effettivamente attendibile.
La rotazione o l'ambito della chiave viene allentato
La durata di una chiave viene estesa a tempo indeterminato, o una chiave inizia a essere riutilizzata oltre i confini che non dovrebbe superare.
Una chiave di firma codificata per risolvere un deploy.
Una chiave per la firma dei token veniva letta da un archivio segreto, ma l'archivio non era configurato in un nuovo ambiente e il deploy è fallito. La soluzione rapida è inserire la chiave direttamente nel codice per far partire il servizio. Il servizio parte, e ora la chiave privata è nel repository e nella sua cronologia.
- const SIGNING_KEY = await secrets.get("jwt-signing-key")+ const SIGNING_KEY = "<the PEM private key, pasted inline>"const token = sign(claims, SIGNING_KEY)Una chiave di firma nel codice sorgente risiede nel repository, nella sua cronologia e in ogni clone e cache CI, il che vanifica la gestione delle chiavi che A.8.24 richiede. Ripristinatela dall'archivio segreto, configurate l'archivio nel nuovo ambiente e ruotate la chiave, poiché una chiave committata deve essere considerata esposta.
La gestione delle chiavi è la parte che viene campionata.
Un auditor che esamina A.8.24 si preoccupa meno di quale cifrario avete scelto e di più di come le chiavi vengono generate, memorizzate, ruotate e dismesse. Una chiave trovata nel codice sorgente, una chiave senza rotazione o una verifica disabilitata silenziosamente sono il tipo di riscontro che emerge, e tendono a entrare attraverso una modifica che cercava di sbloccare qualcosa. La pull request è il luogo in cui viene presa la decisione sulla chiave e il punto più economico per correggerla.
Una revisione, non un audit crittografico.
heygrc segnalerà le modifiche che interessano A.8.24 e citerà il controllo in modo che la correzione avvenga nella pull request. Non progetta il vostro schema di gestione delle chiavi né esegue la vostra valutazione. Intercetta il momento in cui una chiave viene gestita in modo errato o un algoritmo viene indebolito, al livello del diff.