Owner, Editor, Viewer: come funziona davvero il modello di permessi di Rexfin

I modelli di permessi nei piccoli strumenti SaaS tendono a ricadere in una di due forme sbagliate: tutti possono fare tutto perché il team è piccolo, oppure lo strumento aggiunge un sistema RBAC di livello enterprise che nessuno, in un team finance di tre persone, ha mai chiesto. Rexfin ha scelto una via di mezzo più stretta: tre ruoli, ciascuno con un compito chiaramente diverso, applicati sul server ogni volta, non semplicemente nascosti dal menu.

Tre ruoli, non una matrice di permessi

Un owner può invitare i colleghi, cambiare il ruolo di chiunque e disattivare i membri: l’unico ruolo che può farlo. Un editor può caricare documenti, revisionarli, eseguire scenari e generare export. Un viewer può vedere dashboard, bilanci e fare domande, ma non può caricare o modificare nulla. È deliberatamente vicino a ciò di cui la maggior parte dei team finance ha davvero bisogno: qualcuno che gestisce il workspace, persone che fanno il lavoro e persone che consumano l’output, grosso modo un controller, un analista e un membro del board che legge il pacchetto costruito da qualcun altro.

Una regola sta sotto tutte e tre: un workspace non può mai finire con zero owner. Se l’ultimo owner rimasto prova a retrocedersi da solo o viene disattivato da qualcun altro, il sistema lo blocca. Sembra ovvio finché non si considera la race condition che previene: due owner che si disattivano a vicenda quasi nello stesso istante potrebbero altrimenti lasciare un workspace senza nessuno al comando. Rexfin chiude questa falla a livello di transazione, non con una finestra di avviso che un clic veloce può aggirare.

Disattivazione, non cancellazione

Rimuovere qualcuno da un workspace su Rexfin è un’azione soft, non una hard delete. Disattivare un membro fa tre cose in modo atomico: lo segna come inattivo, revoca ogni sessione che detiene al momento e scrive un record di chi lo ha fatto e quando. La persona viene disconnessa immediatamente, non “prima o poi”, non “la prossima volta che il token scade”, perché le sessioni vengono verificate contro il database a ogni richiesta protetta, non solo confermate da un cookie firmato ai margini del sistema. Un account disattivato non può accedere di nuovo, e nemmeno un link di reset della password inviato a quell’account funziona.

Quello che non succede è una cancellazione a cascata silenziosa. Commenti, scenari e voci di audit creati da una persona disattivata restano esattamente dove erano, ancora attribuiti a lei, con l’interfaccia che semplicemente segnala che è stata rimossa dal team, così la storia resta intatta e nessuno deve spiegare un vuoto nel registro. Un invito in sospeso non ancora accettato può essere revocato del tutto. Uno già accettato non può essere revocato come se non fosse mai esistito; il sistema dice chiaramente di disattivare il membro invece, perché fingere che un account attivo non sia mai stato invitato è un tipo di disonestà diverso e peggiore in un audit trail.

Ogni modifica è registrata, e i tentativi cross-workspace non arrivano da nessuna parte

Ogni cambio di ruolo e ogni disattivazione scrive una riga nell’audit log del workspace: chi lo ha fatto, a chi e cosa è cambiato. Quel log è il registro che si consegna a un auditor che chiede “chi aveva accesso a questi dati e quando”, non una ricostruzione a memoria.

I controlli di accesso avvengono sul server a ogni mutazione, e sono limitati al workspace di chi effettua la chiamata prima che qualunque altra cosa venga eseguita. Prova ad agire su una risorsa di un workspace a cui non appartieni e ottieni un semplice 404, non un 403: il sistema non conferma nemmeno che la risorsa esista, invece di limitarsi a negarti l’accesso, il che è rilevante perché un 403 dice silenziosamente a chi sonda “sì, esiste, semplicemente non ti è permesso”, mentre un 404 non dice nulla.

Dove si colloca nel quadro generale

Niente di tutto questo sostituisce SSO enterprise o una gerarchia RBAC completa: è una scelta di perimetro deliberata per la dimensione di team che Rexfin serve oggi, non una svista. Per capire come questo si integra con il resto dei controlli della piattaforma, vedi la panoramica dell’architettura di sicurezza, e per vedere cosa vede davvero un nuovo collega il primo giorno sotto ciascun ruolo, leggi il percorso della prima settimana. Tutto quanto sopra fa anche parte di ciò che Rexfin mostra direttamente al team di sicurezza di un potenziale cliente: maggiori dettagli nel Trust Center, oppure sfoglia l’intero hub del pillar.