Chi tiene la chiave?
Ogni sistema on-chain in produzione dipende da poche chiavi private. Dove vivono, chi può usarle e cosa succede quando qualcuno se ne va sono decisioni di architettura, non note di passaggio di consegne.
Un contratto auditato dà una garanzia precisa: il codice fa quello che dice. Non dice nulla sull'altra metà del sistema, cioè su chi può firmare. Ogni applicazione on-chain in produzione dipende da almeno una chiave privata che conta — quella che firma le transazioni di ancoraggio, quella col ruolo di amministratore, quella che può mettere in pausa, aggiornare o emettere. Chi controlla quelle chiavi controlla il sistema, per quanto buono sia il codice.
Dove vive di solito la chiave
Nella maggior parte dei progetti la chiave nasce durante la demo. Finisce in una variabile d'ambiente o in un file di configurazione sul server, perché è il modo più rapido per far passare la prima transazione. Poi la demo diventa produzione, il server viene clonato in staging, si fa un backup, un collega copia il file per un debug, e nessuno torna indietro.
Una chiave privata non è una password. Non c'è un link di reset. Se esce, chi la ha possiede esattamente la tua autorità, e la catena non ha modo di distinguere voi due. La rotazione, dove il contratto la prevede, è una transazione firmata proprio dalla chiave che ti preoccupa.
La custodia è un progetto operativo
Le domande utili non sono crittografiche. Riguardano ruoli, limiti e persone.
Separare le chiavi per quello che possono fare. La chiave calda che firma le operazioni di routine non deve essere quella che cambia le regole. Le va dato il ruolo più piccolo che il contratto consente, e solo i fondi che servono per il prossimo periodo.
Mettere il ruolo potente dietro più di una persona. Il ruolo di amministrazione o di upgrade va dietro un multisig, o dentro un KMS o un HSM da cui la chiave non si esporta, con l'approvazione di più persone. Un portatile non è un modello di custodia.
Scrivere la procedura di rotazione prima che serva. Quale chiave sostituisce quale, chi firma il cambio, per quanto resta valida la vecchia, come si avvisano i partner. Scritta e provata, non improvvisata durante un incidente.
Prevedere che le persone se ne vadano. Chi ha configurato tutto prima o poi cambierà lavoro. Se l'unica conoscenza operativa delle chiavi se ne va con lui, il sistema ha un punto di rottura con il preavviso.
Perché va nella revisione di progetto
Per una software house .NET che consegna a una PMI, la custodia è la parte che il cliente non vede e che eredita. Chi fa due diligence — una banca, un revisore, un partner estero — chiederà chi può muovere fondi o cambiare il contratto prima di chiedere qualcosa sul codice. Per chi rientra in NIS2, la gestione delle chiavi è già tra le misure di sicurezza da documentare. In entrambi i casi la risposta deve esistere prima della domanda.
La custodia fa parte dell'architettura. Se compare solo nelle note di consegna, non è stata progettata.
La chiave che controlla il vostro contratto oggi dove vive, e chi altro potrebbe firmare con essa?