Ruoli e permessi in SSP Enterprise

La domanda che decide se la custodia condivisa funzioni davvero non è «chi comanda?». È «chi può muovere il denaro?» — e in un sistema ben costruito sono due domande diverse con risposte diverse.

SSP Enterprise risponde in due luoghi separati. L'autorità amministrativa vive nei record dell'organizzazione, dove può essere concessa e revocata come qualsiasi altro permesso. L'autorità di spesa vive nell'indirizzo del vault, dove non può. Questo articolo è la mappa completa di entrambe, compresi i casi in cui le persone si sorprendono più spesso.

Se non hai letto il quadro d'insieme su come si incastrano organizzazioni e vault, SSP Enterprise: vault multisig per i team è il pezzo che precede questo.

Due sistemi, di proposito

Un ruolo di organizzazione governa lo spazio di lavoro: invitare persone, creare vault, cambiare impostazioni, leggere il registro di audit. È un record di database. Cambialo e la modifica ha effetto immediato.

Un ruolo di vault governa un vault specifico, e uno dei suoi tre valori — firmatario — significa che la tua chiave pubblica fa parte di come l'indirizzo di quel vault è stato derivato. Non si cambia modificando nulla. Si cambia soltanto creando un vault diverso a un indirizzo diverso e spostando i fondi.

La conseguenza pratica, e la frase più importante di questo articolo: un owner dell'organizzazione che non sia firmatario di un vault non può spendere da quel vault. Non con l'accesso alla dashboard, non con l'accesso al database, non con la collaborazione di SSP. L'indirizzo non sa che cosa sia un owner.

Ruoli di organizzazione, con precisione

Quattro ruoli, rigidamente ordinati.

Capacità	Owner	Admin	Member	Viewer
Leggere vault, attività, registro di audit	Sì	Sì	Sì	Sì
Invitare nuove persone	Sì	Sì	Solo se l'organizzazione lo consente	No
Cambiare il ruolo di un member o viewer	Sì	Sì	No	No
Cambiare il ruolo di un altro admin	Sì	No	No	No
Cambiare le impostazioni dell'organizzazione	Sì	Sì	No	No
Trasferire la proprietà, eliminare l'organizzazione	Sì	No	No	No
Lasciare l'organizzazione	No — prima trasferisci	Sì	Sì	Sì

Tre dettagli di quella tabella meritano di essere estratti.

Gli admin non possono toccare altri admin. Un admin può promuovere, retrocedere e rimuovere member e viewer, ma nel momento in cui il bersaglio è un altro admin l'operazione viene rifiutata. È deliberato: significa che un singolo account admin compromesso non può smontare in silenzio il resto dello strato amministrativo.

Gli inviti dei member sono un interruttore a livello di organizzazione. Per impostazione predefinita invitare è una capacità dell'admin. Un'organizzazione può scegliere di permetterlo anche ai member — utile per team più grandi in cui l'inserimento non dovrebbe accodarsi dietro due persone, e meglio disattivato se vuoi un perimetro stretto.

L'owner non può andarsene. C'è esattamente un owner, e l'uscita consiste nel trasferire prima la proprietà a qualcun altro. Questo impedisce il guasto in cui un'organizzazione finisce senza nessuno in grado di eseguire operazioni riservate all'owner.

Ruoli di vault, con precisione

Tre ruoli, con ambito un singolo vault e non l'organizzazione.

Un admin di vault gestisce il vault: le sue politiche, le impostazioni di notifica, i suoi viewer. Un admin di vault non è necessariamente firmatario, e un admin di vault che non sia firmatario non può approvare una proposta.

Un firmatario detiene una delle chiavi nell'M su N del vault. I firmatari redigono proposte e le approvano. La loro chiave pubblica sta nell'indirizzo.

Un viewer di vault vede saldi, proposte e cronologia senza poter redigere né approvare nulla. Utile per revisori, contabili e chiunque abbia bisogno di visibilità senza autorità.

Poiché i ruoli di vault sono per vault, la stessa persona può essere firmataria sul vault operativo e solo viewer su quello di tesoreria. È un assetto normale e sano: dà autorità di spesa quotidiana a chi ne ha bisogno tenendo la riserva dietro un comitato diverso e più ristretto.

Gli inviti vanno a identità, non a caselle di posta

Un invito in SSP Enterprise è indirizzato a un'identità WK — l'identità multisig 2 su 2 derivata da SSP Wallet e SSP Key di qualcuno — e non a un indirizzo e-mail.

È una proprietà di sicurezza, non una scomodità. Un indirizzo e-mail può essere compromesso, inoltrato o digitato male finendo in mani altrui. Un'identità WK può essere presentata solo da chi detiene entrambi i dispositivi di quella persona, il che significa che un invito non può essere accettato da chi si trova a leggere il messaggio.

Ne seguono due conseguenze. Primo, la persona che inviti ha bisogno di un SSP configurato prima di poter entrare: non esiste il percorso «registrati dall'e-mail di invito», per scelta. Secondo, gli inviti sono verificabili in un modo in cui gli inviti via e-mail non lo sono, perché l'accettazione è un atto firmato.

Gli inviti scaduti non vengono eliminati. Sono conservati indefinitamente, perché «chi è stato invitato e non è mai entrato» è esattamente il tipo di domanda che un audit pone mesi dopo. Nulla nella traccia di audit ha una durata.

Che cosa richiede di firmare di nuovo

Alcune operazioni sono troppo gravi per essere autorizzate con un cookie di sessione. Tredici di esse richiedono di firmare di nuovo con entrambi i dispositivi nel momento in cui agisci, tra cui:

• Trasferire la proprietà di un'organizzazione
• Eliminare un'organizzazione
• Rimuovere un membro
• Cambiare l'e-mail aziendale di un account

Qui conta la meccanica. È il server a generare la sfida da firmare — mai il client — e la sfida è legata all'azione specifica, al bersaglio specifico e a una marca temporale. Una firma catturata da un'operazione non può essere riprodotta in un'altra.

Ogni tentativo è registrato in modo permanente, compresi i fallimenti. Uno schema di tentativi falliti di azioni critiche è esso stesso un segnale che conviene avere agli atti.

Dove vengono registrati i cambi di ruolo

Ogni cambio di permesso viene scritto nel registro di audit dell'organizzazione: ruoli concessi e revocati, inviti emessi, accettati, rifiutati e revocati, membri che entrano ed escono, rimozioni e trasferimenti di proprietà. Le modifiche a livello di vault hanno eventi propri: firmatari e viewer aggiunti o rimossi, politiche modificate, stato del vault cambiato.

I registri di audit sono permanenti. Non c'è scadenza né processo di pulizia, perché il valore di una traccia di audit sta interamente nelle parti di cui nessuno aveva previsto il bisogno. Un'organizzazione che scopre un problema a novembre vuole il record di marzo.

Progettare la tua distribuzione dei ruoli

Alcuni schemi che tengono nella pratica.

Separa l'amministratore dai firmatari. Lascia che un responsabile operativo abbia l'amministrazione dell'organizzazione per gestire persone e impostazioni dei vault, senza mettere la sua chiave nell'indirizzo di tesoreria. Così la comodità amministrativa non porta con sé rischio di custodia.

Distribuisci con generosità i ruoli di viewer alla funzione finanziaria. L'accesso in lettura costa poco e rende possibile la riconciliazione senza allargare l'insieme di chi può spendere. Non c'è ragione perché un contabile sia firmatario.

Tieni il comitato di tesoreria più piccolo di quello operativo. Una riserva 3 su 5 e un vault operativo 2 su 3 sono una divisione comune e sensata: il denaro che toccchi ogni giorno ha una soglia di approvazione più bassa di quello che tocchi ogni anno. 2 su 2 contro 2 su 3 contro m su n spiega come ragionare sui numeri.

Decidi la procedura di uscita prima che qualcuno esca. Rimuovere qualcuno dall'organizzazione è un cambio di ruolo; rimuoverlo come firmatario è un vault nuovo e una migrazione di fondi. Metti per iscritto quale farai, e verifica che l'insieme di firmatari restante superi ancora la soglia. Che succede se una delle tue chiavi viene compromessa percorre lo scenario adiacente.

Non trattare le politiche come permessi. Whitelist, blocchi temporali e regole di approvazione modellano ciò che viene proposto, ma la soglia è l'unica cosa che la catena impone. Progetta i ruoli come se il motore di politiche non esistesse, poi aggiungi le politiche come miglioramenti di processo sopra.

La gerarchia dei ruoli è facile da azzeccare se tieni in primo piano una domanda: quali di questi cambiamenti richiedono un nuovo indirizzo e quali sono soltanto record? Tutto ciò che sta nello strato dell'organizzazione è un record. Solo l'insieme dei firmatari è un indirizzo.