Panoramica dell'architettura di sicurezza: come Rexfin protegge i vostri dati finanziari

Le pagine sulla sicurezza tendono a essere un elenco di aggettivi: “enterprise-grade”, “livello bancario”. Non è utile per un team finanziario che deve decidere se far transitare bilanci reali attraverso uno strumento. Ciò che è utile è l’architettura reale: cosa è crittografato, chi può vedere cosa, cosa succede quando qualcuno sbaglia, e quale prova esiste dopo. Questo è esattamente ciò, al livello a cui un revisore di sicurezza chiederebbe davvero.

Crittografia e isolamento, detti chiaramente

I dati sono crittografati in transito con TLS e a riposo con AES-256. Le credenziali per qualsiasi sistema collegato risiedono in un archivio di segreti isolato, non nella configurazione dell’applicazione. I dati e il modello di ogni organizzazione sono logicamente isolati da quelli di ogni altra organizzazione, e nulla dei vostri dati viene usato per addestrare modelli condivisi o di terze parti: i vostri bilanci e il vostro modello restano dentro il confine della vostra organizzazione, non confluiscono in nessun set di addestramento generico da nessuna parte.

Un controllo degli accessi che fallisce chiuso, non aperto

Il principio di progettazione alla base dei permessi è semplice da enunciare e facile da sbagliare in pratica: ogni lettura di un documento, una cifra o una citazione della fonte passa attraverso un’unica decisione di accesso, e quella decisione, di default, nega l’accesso piuttosto che concederlo. Se a un utente non è stato esplicitamente concesso l’accesso a qualcosa, la risposta è no, non “non mostrato nell’interfaccia ma comunque raggiungibile sotto”. Un diniego esplicito prevale sempre su una concessione esplicita, quindi un accesso concesso tramite un percorso, come l’appartenenza a un gruppo, può comunque essere bloccato da una regola più specifica che nomina direttamente quella persona.

Questo è importante per via di una modalità di fallimento facile da trascurare: un documento può essere nascosto nell’interfaccia mentre un assistente IA lo ha ancora nel proprio contesto di lavoro e può ragionarci sopra o citarlo. Nascondere qualcosa da uno schermo lasciandolo raggiungibile sotto è una fuga di dati con un volto amichevole. Rexfin applica il controllo degli accessi allo stesso livello che decide cosa un assistente IA può recuperare e citare: se una persona non può aprire un documento, nemmeno l’assistente che risponde alla sua domanda può vederlo.

I ruoli si aggiungono sopra a quella decisione di base: chi può solo visualizzare le cifre, chi può modificare un modello all’interno delle sezioni a cui ha accesso, e chi può gestire l’accesso e l’export per conto dell’organizzazione. Nessuno di essi scavalca il controllo di accesso sottostante: una persona con ampi diritti di modifica non può comunque toccare o esportare una sezione a cui non le è mai stato concesso l’accesso.

Ogni connessione al livello dati è autenticata e delimitata

Internamente, il servizio che contiene le cifre estratte ed esegue la verifica non è mai raggiungibile direttamente: ogni richiesta porta una credenziale specifica e delimitata, e viaggia solo su una rete privata, mai su internet pubblico. Una richiesta senza una credenziale valida viene rifiutata senza eccezioni; non esiste un fallback verso una lettura aperta e non autenticata. E se un ambiente di deployment dovesse in qualche modo avviarsi con una credenziale placeholder ancora attiva, l’applicazione si rifiuta del tutto di partire, piuttosto che funzionare con controlli di sicurezza che esistono sulla carta ma non sono attivi.

Una traccia di audit che può dimostrare di non essere stata manomessa

Registrare “chi ha fatto cosa” è il minimo indispensabile; il problema più difficile è dimostrare che quel registro non è stato modificato silenziosamente in seguito. Il registro degli accessi e delle azioni di Rexfin è concatenato tramite hash: ogni voce incorpora un hash crittografico della voce precedente, quindi alterare, cancellare o inserire un record spezza la catena esattamente in quel punto, e un controllo di verifica può percorrere l’intera catena e riportare con precisione dove si è verificata l’interruzione. Questo trasforma “teniamo dei log” in qualcosa di verificabile: un’integrità che potete controllare, non una promessa da accettare sulla fiducia. Guardate come questa disciplina si estende a ogni risposta generata nel registro di audit delle risposte. Anche i tentativi di accesso negati vengono registrati, non solo le azioni riuscite, quindi anche il tentativo di raggiungere qualcosa a cui non dovreste accedere è visibile nella traccia.

Dove questo si collega al resto della piattaforma

L’architettura di sicurezza non è aggiunta al prodotto in un secondo momento: è lo stesso istinto fail-closed che emerge in come funziona la verifica, dove un controllo non risolto viene segnalato onestamente invece che indovinato, e in come funziona l’ingestion, dove un documento non classificabile viene messo in quarantena invece che processato a forza. Rifiutare invece che assumere attraversa allo stesso modo controllo degli accessi, verifica e ingestion, perché una piattaforma costruita su numeri difendibili deve applicare quello stesso standard anche a chi può vederli, non solo alla loro correttezza.

Sulla certificazione: il nostro programma di sicurezza delle informazioni è progettato secondo controlli in stile ISO/IEC 27001, lo standard che i buyer GCC e governativi chiedono davvero, e dichiariamo apertamente che la certificazione formale di terze parti non è ancora iniziata, invece di lasciar intendere che un audit sia già in corso. Consultate il trust center per lo stato completo e aggiornato di quel programma. Se i vostri requisiti di residenza dei dati GCC sono specifici, le opzioni di residenza dei dati coprono ciò che è disponibile oggi.

A chi si rivolge

A chiunque abbia una revisione di procurement che pone domande più difficili di quanto risponda una pagina di marketing: un controller che ha bisogno che un cambio di permesso sia ricostruibile a posteriori, un CFO che deve sapere che un assistente IA non può vedere ciò che il suo utente non può vedere, un responsabile IT che vuole sapere cosa succede in caso di un deploy sbagliato. Prenotate una demo e ripercorreremo insieme la gestione dei dati, i controlli di accesso e il deployment nel dettaglio richiesto dalla vostra revisione, oppure leggete il quadro più ampio nella panoramica del pilastro.