Dopo il caso Binance: come verificare chi autorizza davvero un'operazione

L'analisi di TRM Labs sull'incidente che ha colpito Binance il 29 ottobre 2026 descrive trasferimenti con firme valide e considera più probabile la compromissione dell'infrastruttura di firma. Binance ha annunciato un rapporto tecnico a conclusione degli accertamenti. Per una direzione aziendale, la questione riguarda i controlli che permettono di ottenere l'esecuzione di un'operazione. La verifica può estendersi a pagamenti e servizi informatici: occorre ricostruire i poteri effettivi e accertare se le separazioni previste resistano alla compromissione di una postazione. Le applicazioni descritte qui riguardano tale verifica, senza attribuire a Binance configurazioni o carenze non accertate.

La firma e la decisione organizzativa

La specifica Ethereum Improvement Proposal 7702, "Set Code for EOAs", permette agli account Ethereum controllati tramite una chiave privata, detti Externally Owned Accounts, di eseguire il codice di un contratto nel proprio contesto. Il protocollo verifica l'autorizzazione firmata secondo le proprie regole; la delega, una volta impostata, può persistere oltre la transazione che l'ha introdotta. La specifica avverte che un'implementazione inadeguata del codice delegato può attribuire a terzi un controllo quasi totale sull'account.

Questa caratteristica richiede di distinguere il trasferimento di un valore dall'attribuzione di un potere. Il controllo su una richiesta può dover valutare che cosa quella richiesta consentirà di fare successivamente. Nella gestione aziendale il criterio è applicabile, per esempio, all'assegnazione di un privilegio amministrativo: l'oggetto dell'approvazione è il potere conferito e il suo ambito.

La validità verificata dal protocollo non consente, da sola, di ricostruire la decisione aziendale. Per farlo servono riscontri sul contenuto approvato, sui poteri dell'approvatore e sul passaggio dalla richiesta all'esecuzione. La firma presente nel registro dell'operazione è quindi un elemento da esaminare insieme agli altri.

Separare i compiti fino ai sistemi che li eseguono

Il National Institute of Standards and Technology (NIST), nella Special Publication 800-53, revisione 5, "Security and Privacy Controls for Information Systems and Organizations", tratta la separazione dei compiti nel controllo AC-5. Il controllo prevede di documentare le attività da separare e di definire autorizzazioni di accesso coerenti con tale separazione, considerando insieme sistemi e componenti.

Applicato a un processo aziendale, questo criterio comporta un esame delle dipendenze. Due persone possono approvare con credenziali distinte, ma la separazione va riesaminata se una stessa identità amministrativa può modificare le regole di entrambe le approvazioni. Analogamente, un controllo affidato a un secondo servizio richiede di conoscere chi possa cambiarne configurazione e autorizzazioni.

Per la direzione è utile chiedere una ricostruzione del processo che includa chi configura i controlli, chi può concedere privilegi e chi verifica i registri. L'esame può partire da un'operazione rilevante e seguire i passaggi necessari alla sua esecuzione, comprese le funzioni di manutenzione e di emergenza.

Da questa ricostruzione dovrebbe risultare quali azioni rimangano possibili se una delle identità coinvolte viene compromessa. Se la stessa identità può predisporre un'operazione, modificare il controllo che dovrebbe impedirla e alterare le evidenze del suo passaggio, la separazione documentata richiede una correzione. Il riscontro riguarda le autorizzazioni effettive e le dipendenze tecniche, oltre all'assegnazione formale dei ruoli.

Legare l'approvazione a ciò che sarà eseguito

Nel riesame di un pagamento, la direzione può chiedere se l'approvazione sia associata ai dati che determinano l'operazione: beneficiario, importo e conto di addebito. Una verifica successiva riguarda il trattamento delle modifiche. Se un dato cambia dopo l'approvazione, il processo dovrebbe prevedere quali modifiche richiedano una nuova decisione e impedire che l'approvazione precedente venga riutilizzata oltre il suo ambito.

Sono criteri da adattare al servizio. Per un'identità tecnica, ossia un'identità usata da un'applicazione o da un processo software, occorre esaminare le funzioni che può eseguire senza un intervento umano. Il controllo AC-6 della pubblicazione NIST citata estende infatti il minimo privilegio ai processi che operano per conto degli utenti.

La verifica può distinguere i privilegi necessari all'attività ordinaria da quelli che consentono di cambiare beneficiari, regole o autorizzazioni. Avere un servizio autorizzato a eseguire pagamenti non chiarisce, da solo, se debba anche poter modificare i criteri con cui quei pagamenti sono accettati. Questa scelta richiede una motivazione e controlli coerenti con il rischio.

TRM Labs raccomanda, per gli operatori di criptovalute, politiche di firma che rifiutino deleghe EIP-7702 inattese. L'applicazione ad altri servizi va definita sul loro funzionamento: individuare le richieste incompatibili con l'operatività prevista e stabilire quali debbano essere fermate prima dell'esecuzione.

Provare il blocco e la revoca

La Special Publication 800-53A, revisione 5, del National Institute of Standards and Technology, "Assessing Security and Privacy Controls in Information Systems and Organizations", indica tra i metodi utilizzabili per verificare i controlli AC-05 e AC-06 l'esame di documenti e configurazioni, i colloqui e le prove dei meccanismi. Le dichiarazioni dei responsabili possono quindi essere confrontate con ciò che il sistema consente effettivamente di fare.

Per tradurre questi criteri in una verifica aziendale, si può prevedere un'esercitazione controllata, con operazioni di prova e condizioni che non espongano fondi o servizi reali. Il responsabile del processo dovrebbe concordare con la funzione tecnica il risultato atteso prima dell'esecuzione. Per un controllo di autorizzazione si possono richiedere questi riscontri:

• Una richiesta priva dell'approvazione prevista viene fermata nel passaggio individuato dal processo.
• La modifica di un dato soggetto ad approvazione impedisce il riutilizzo dell'autorizzazione precedente.
• Dopo la revoca di un'identità tecnica, la prova accerta quali richieste i servizi possano ancora eseguire, comprese quelle già avviate.
• I registri permettono di ricostruire richiesta, decisione e risultato, con accessi alla loro gestione coerenti con la separazione stabilita.

Il resoconto dovrebbe precisare il perimetro della prova, le configurazioni esaminate e le limitazioni, così da permettere di valutare quali conclusioni sostenga l'esito. Queste verifiche sono proposte applicative da adattare al sistema. In particolare, la prova della revoca dovrebbe chiarire che cosa rimanga eseguibile dopo il blocco e quali ulteriori interventi siano necessari. TRM Labs raccomanda una procedura di revoca provata e preapprovata per le deleghe EIP-7702; negli altri contesti occorre identificare il meccanismo corrispondente e i suoi limiti.

Le decisioni da portare alla direzione

Per i soggetti essenziali e importanti che rientrano nel decreto legislativo 4 settembre 2024, n. 138, l'articolo 23 attribuisce agli organi di amministrazione e direttivi l'approvazione delle modalità di attuazione delle misure e la supervisione dei relativi obblighi. L'articolo 24 richiede misure tecniche, operative e organizzative adeguate e proporzionate, secondo le modalità e i termini previsti dal decreto. Tra gli ambiti indicati figurano controllo degli accessi, crittografia e verifica dell'efficacia delle misure.

Una relazione alla direzione può pertanto collegare ogni processo esaminato al danno possibile, alle separazioni effettive e all'esito delle prove. La scelta sulle correzioni richiede di conoscere quali operazioni restino eseguibili attraverso una singola identità compromessa e quali servizi dipendano dallo stesso controllo.

La direzione può affidare il riesame al responsabile di ciascun processo, chiedendo le evidenze delle prove e le correzioni proposte. L'incarico dovrebbe richiedere, per ogni correzione, un responsabile, un termine concordato e la prova da ripetere dopo la modifica. Gli aspetti che la prova non copre restano indicati nel resoconto alla direzione.