Che cosa ferma davvero una transazione
Ogni prodotto di custodia ha una pagina di funzionalità che elenca controlli: whitelist, limiti di spesa, blocchi temporali, flussi di approvazione, restrizioni IP. Sono tutti reali e tutti utili. Ma non sono tutti la stessa specie di cosa, e trattarli come intercambiabili è il modo in cui le organizzazioni finiscono con un modello di sicurezza più debole di quanto il marketing lasciasse intendere.
C'è una domanda che li separa con nettezza: se ogni pezzo di software nel sistema fosse sbagliato od ostile, questo controllo reggerebbe ancora?
Per la maggior parte dell'elenco la risposta è no. Per esattamente uno la risposta è sì. Questo articolo parla di come distinguerli.
Tre livelli, non uno
Tra il momento in cui qualcuno vuole muovere fondi e il momento in cui i fondi si muovono davvero, SSP Enterprise ha tre barriere distinte. Cedono in modo diverso, e sapere quale è quale è tutto il punto.
I livelli non sono ordinati per utilità. Sono ordinati per che cosa serve a sconfiggerli.
Livello 1: il livello di coordinamento
È il motore di politiche, ed è lì che vive la maggior parte delle funzionalità. SSP Enterprise supporta whitelist di indirizzi, restrizioni per tipo di destinazione, blocchi temporali che ritardano le transazioni oltre una soglia di valore, regole che richiedono l'approvazione di un admin oltre un certo importo, e restrizioni IP sull'accesso all'organizzazione. I modelli di politiche offrono preimpostazioni sensate che poi si materializzano come regole reali e modificabili.
Questi controlli fanno un lavoro vero. Una whitelist impedisce che un indirizzo digitato male diventi anche solo una proposta. Un blocco temporale dà a un team di tesoreria una finestra per accorgersi che qualcosa non va. Una regola di approvazione trasforma un bonifico grande in una conversazione a due invece che nel pomeriggio di una persona sola.
Quello che non sono è applicazione della custodia. Queste regole vivono nel software di SSP e vengono valutate dai server di SSP. Non fanno parte dell'indirizzo del vault, e la blockchain non ne ha mai sentito parlare. Se il motore di politiche venisse aggirato — per un bug, un server compromesso o un operatore ostile — le regole semplicemente non si applicherebbero.
Lo diciamo chiaramente perché l'alternativa è peggiore. Un team che crede che la propria whitelist sia una garanzia di custodia dimensionerà la soglia di conseguenza, ed è esattamente l'errore che trasforma un incidente sopravvivibile in uno che non lo è.
Livello 2: i tuoi dispositivi
La seconda barriera è la coppia di dispositivi che ogni firmatario detiene, ed è più forte della prima per un aspetto importante: non si fida nemmeno di SSP.
Quando una proposta raggiunge un firmatario, i suoi dispositivi decodificano localmente i byte grezzi della transazione e confrontano il risultato con quanto viene mostrato. Destinatario, importo, token: letti dai byte, non presi dalla descrizione del server. Su Solana questo confronto è esplicito e inflessibile: se i byte decodificati contraddicono il contenuto mostrato, la firma viene bloccata in modo netto anziché segnalata, perché una discrepanza lì indica un attacco in corso e non un difetto di visualizzazione.
I dispositivi impongono anche un proprio tetto indipendente sui rimborsi delle commissioni. Il relay propone la commissione; il portafoglio si rifiuta di firmarne una sopra un massimo fissato nel codice, qualunque cosa dichiari il relay, il che limita ogni prosciugamento veicolato dalle commissioni anche se il relay è del tutto ostile. Anche la simulazione gira prima dell'approvazione, eseguendo la proposta contro lo stato attuale della catena così che la schermata di revisione possa mostrare che cosa farebbe davvero la transazione; è arrivata con la simulazione delle transazioni e gli avvisi di rischio.
Questo livello sconfigge un server compromesso. Ciò che non può sconfiggere è un dispositivo compromesso, o un firmatario che approva senza leggere. Richiede inoltre entrambi i dispositivi del firmatario, ed è per questo che il 2 su 2 per firmatario conta: il livello 2 è forte quanto il più debole dei due dispositivi, e sono deliberatamente tipi di hardware diversi.
Livello 3: la catena
La terza barriera è l'unica che regge quando tutto il resto ha ceduto.
L'indirizzo di un vault è derivato dall'insieme dei firmatari e dalla soglia di approvazione. Una transazione che non porti il numero richiesto di firme valide non è una transazione rifiutata: è una transazione non valida. Ogni nodo della rete giunge indipendentemente alla stessa conclusione, e nessun grado di accesso all'infrastruttura di SSP cambia quell'aritmetica.
Ecco perché la soglia è il numero che merita più riflessione quando crei un vault, e perché non è modificabile dopo. Configurare il tuo primo vault aziendale copre la meccanica; 2 su 2 contro 2 su 3 contro m su n copre come scegliere il numero.
Dove cede ciascun livello
Mettere i modi di guasto fianco a fianco rende ovvio il lavoro di progettazione.
| Scenario | Livello di coordinamento | I tuoi dispositivi | La catena |
|---|---|---|---|
| Un firmatario sbaglia a digitare un indirizzo | Lo ferma | Lo ferma se legge | Non le importa |
| Un firmatario viene indotto con phishing ad approvare | Lo ferma se non è in whitelist | Mostra il vero; può comunque approvare | Non le importa |
| Il relay di SSP è compromesso | Cede | Regge — i byte sono decodificati in locale | Regge |
| Il motore di politiche di SSP ha un bug | Cede | Regge | Regge |
| Il portatile di un firmatario è compromesso | Non è progettato per questo | In parte — il telefono controlla ancora | Regge |
| Un aggressore controlla meno di M firmatari | Non è progettato per questo | Regge | Regge |
| Un aggressore controlla M firmatari o più | Cede | Cede | Cede |
L'ultima riga è il fondo onesto del modello. Il multisig protegge dal fatto che una minoranza dei tuoi firmatari venga compromessa. Non protegge da una maggioranza, e nessun prodotto può sostenere il contrario senza mentire. Ecco perché la soglia e l'indipendenza dei tuoi firmatari contano più di qualsiasi elenco di funzionalità.
Che cosa significa per come imposti le cose
Progetta il vault perché sia sicuro con il solo livello 3. Scegli soglia e insieme dei firmatari come se il motore di politiche non esistesse. Se la risposta ti mette a disagio, la correzione è una soglia diversa o firmatari diversi, non più politiche.
Poi aggiungi politiche per ciò in cui le politiche sono brave. Le whitelist intercettano l'errore umano. I blocchi temporali comprano tempo di reazione. Le regole di approvazione creano un secondo paio d'occhi sugli importi grandi. Sono miglioramenti di processo e riducono davvero gli incidenti; semplicemente non sono ciò che si frappone tra un aggressore e la tua tesoreria.
Tieni i tuoi firmatari davvero indipendenti. Due firmatari sullo stesso portatile, nello stesso edificio, con lo stesso schema di recupero, sono più vicini a un firmatario che a due. La forza del livello 3 viene dalla difficoltà di compromettere M persone distinte con M coppie di dispositivi distinte.
Fai in modo che i firmatari leggano davvero la schermata di revisione. Il livello 2 è l'unica barriera capace di intercettare una proposta dall'aria legittima ma sbagliata, e funziona solo se un essere umano si occupa di ciò che il suo dispositivo ha decodificato. Un andata e ritorno provato alla creazione del vault aiuta a costruire quell'abitudine mentre non c'è nulla in gioco.
Fai la stessa domanda agli altri fornitori di custodia. Che tu usi SSP o no, questa cornice è trasferibile: per ogni controllo nella pagina delle funzionalità, chiedi se sopravvive al software del fornitore stesso che sbaglia. Le risposte sono spesso istruttive, e un fornitore che risponde con chiarezza ti sta dicendo qualcosa di buono su come ragiona.
Sui modi in cui un assetto a più chiavi viene indebolito nella pratica, modi di guasto del multisig e come SSP li mitiga li percorre uno per uno, e SSP Enterprise: vault multisig per i team è la visione d'insieme di come si incastrano i pezzi.
