💻 computer science

From Audit Requirements to Computable Software Architecture: A Rule-Engine and Evidence-Indexing Method for Trusted Digital Infrastructure

Questo articolo propone una metodologia di motore a regole e indicizzazione delle evidenze che colma il divario semantico tra i requisiti di audit e l'architettura del software attraverso la creazione di un modello di classificazione, una matrice di mappatura e un algoritmo di verifica per integrare controlli eseguibili precocemente nella fase di progettazione, riducendo così i costi di rimedio e abilitando un'infrastruttura digitale pronta per l'audit.

Autori originali: Jinyuan Li, Ruijie Ma, Yicheng Gu

Pubblicato 2026-07-02

📖 5 min di lettura🧠 Approfondimento

CC BY 4.0

Autori originali: Jinyuan Li, Ruijie Ma, Yicheng Gu

Articolo originale sotto licenza CC BY 4.0 (https://creativecommons.org/licenses/by/4.0/). ✨ Questa è una spiegazione generata dall'IA dell'articolo qui sotto. Non è stata scritta né approvata dagli autori. Per precisione tecnica, consulta l'articolo originale. Leggi il disclaimer completo

Immagina di stare costruendo una cassaforte bancaria massiccia e ad alta sicurezza. Nel vecchio modo di fare le cose, prima costruiresti l'intera cassaforte, ci metteresti le porte e le telecamere e poi, dopo che fosse stata finita, assumeresti un ispettore che direbbe: "Oh, a proposito, serve una seconda serratura sulla porta posteriore e le telecamere devono essere collegate a un server diverso". Questo porta a demolire pareti, rifare il cablaggio e affrontare costose riparazioni.

Questo articolo propone un modo diverso: integrare le regole di sicurezza direttamente nei progetti sin dal primo giorno.

Ecco una semplice analisi di come gli autori, Jinyuan Li, Ruijie Ma e Yicheng Gu, suggeriscono di fare questo per i sistemi digitali (come quelli utilizzati per gestire asset digitali).

1. Il Problema Centrale: Il Gap del "Traduttore"

Gli autori evidenziano una barriera linguistica.

Gli Auditor parlano in termini di regole come "Abbiamo bisogno della prova che solo il manager abbia approvato questa transazione".
Gli Architetti Software parlano in termini di codice come "Abbiamo bisogno di una tabella nel database e di un endpoint API".

Di solito, questi due gruppi non si parlano finché il software non è già stato costruito. Il risultato è che la sicurezza e la conformità diventano "patch" aggiunte in seguito, il che è disordinato e costoso.

2. La Soluzione: Un "Motore di Regole" e un "Indice delle Prove"

Gli autori hanno creato un metodo per tradurre le regole degli auditor direttamente nel DNA del software prima che venga scritta una singola riga di codice. Utilizzano tre strumenti principali:

A. La "Matrice di Traduzione" (Il Libro delle Ricette)

Pensate a questo come a un enorme libro di ricette che trasforma regole vaghe in ingredienti specifici.

La Regola: "Dobbiamo sapere chi ha modificato questo dato."
La Traduzione: Il sistema sa automaticamente che deve creare un "Blocco di Versione", salvare un "Registro delle Modifiche" e generare un "Impronta Digitale" (hash) dei dati.
Il Risultato: Invece di lasciare che un essere umano indovini come programmare questo, il sistema sa esattamente quali "moduli funzionali" (come un servizio di login o un servizio di logging) devono essere attivati.

B. Il "Motore di Regole" (Il Buttafuori)

Una volta che le regole sono state tradotte, vengono caricate in un "Motore di Regole". Immaginatelo come un buttafuori all'ingresso di un club che controlla una lista di regole prima di far entrare chiunque.

Se provi ad approvare una transazione senza la firma di una seconda persona, il buttafuori (il software) lo blocca immediatamente.
Se provi ad accedere a un file a cui non sei autorizzato, il buttafuori ti blocca.
Questo avviene automaticamente come parte del flusso normale, non come un pensiero successivo.

C. L' "Indice delle Prove" (Il Archivio Digitale)

In passato, dimostrare di aver seguito le regole significava scavare tra disordinati tracciati cartacei o log informatici sparsi.

Gli autori propongono un sistema in cui ogni azione genera automaticamente una "ricevuta" (prova).
Queste ricevute sono timbrate con un ID unico, un timestamp e una firma digitale.
Vengono archiviate istantaneamente in un "Repository delle Prove" speciale.
L'Analogia: È come un archivio intelligente che, nel momento in cui firmi un documento, ne scatta automaticamente una foto, lo timbra con la data e lo ripone in un cassetto blindato che solo l'auditor può aprire. Non devi andare a cercare il documento in seguito; è già lì, organizzato e pronto.

3. Come lo hanno testato: La Piattaforma di Asset Digitali

Il team ha testato questo metodo su una "Piattaforma di Gestione di Asset Digitali" (un sistema per gestire cose come denaro digitale o token). Hanno confrontato due scenari:

Scenario A (Il Vecchio Modo): Costruire prima il sistema, poi provare ad aggiungere le regole di sicurezza in seguito.
Scenario B (Il Nuovo Modo): Costruire le regole di sicurezza nel design fin dall'inizio.

I Risultati:

Meno Correzioni: Il "Vecchio Modo" ha richiesto 24 modifiche alle interfacce del sistema (come cambiare la forma di una porta). Il "Nuovo Modo" ne ha richiesti solo 7.
Meno Riscrittura: Il "Vecchio Modo" ha richiesto di patchare 16 strutture dati (come rifare l'impianto idraulico). Il "Nuovo Modo" ne ha richiesti solo 3.
Test più Veloci: Testare il "Nuovo Modo" ha richiesto 58 ore di lavoro; il "Vecchio Modo" ne ha richiesto 143.
Prove Migliori: Il "Nuovo Modo" aveva il 95% delle prove richieste pronte automaticamente, rispetto al solo 70% del "Vecchio Modo".

4. Conclusione

L'articolo sostiene che trattando i requisiti di audit come istruzioni computabili (come il codice) piuttosto che semplici documenti di testo, è possibile costruire sistemi che siano "pronti per l'audit" per impostazione predefinita.

Invece di costruire una casa e poi rendersi conto di aver dimenticato la via di fuga, si disegna la via di fuga direttamente nella pianta. Quando la casa viene costruita, la via di fuga è già lì, perfettamente integrata e pronta per essere ispezionata. Questo risparmia denaro, riduce lo stress e rende l'infrastruttura digitale molto più affidabile.

Sintesi Tecnica: Dai Requisiti di Audit all'Architettura Software Computabile

Definizione del Problema

La traduzione dei requisiti di audit in specifiche computabili per le infrastrutture digitali affidabili rimane una sfida significativa. L'ostacolo primario è il disconnessione semantica tra i professionisti dell'audit e gli architetti di sistema durante lo sviluppo di sistemi fintech. Di conseguenza, i meccanismi di conformità vengono spesso trattati come un elemento successivo, integrati durante le fasi successive di codifica, integrazione o consegna, piuttosto che essere integrati precocemente nell'architettura del software. Questo approccio porta a far sì che i controlli di audit diventino "patch post-sviluppo" anziché vincoli nativi, comportando un aumento delle modifiche alle interfacce, dei correttivi ai dati e degli oneri di test quando sono necessarie azioni correttive. La ricerca esistente si è concentrata ampiamente sull'acquisizione delle evidenze, l'automazione dell'audit e il monitoraggio del rischio, ma ha prestato poca attenzione alla specifica relazione di mappatura tra asserzioni di audit, logica del motore di regole, macchine a stati di workflow e repository di evidenze indicizzate durante la fase di progettazione del sistema.

Metodologia

Lo studio propone un metodo basato su un motore di regole e l'indicizzazione delle evidenze per convertire i requisiti di audit in regole di controllo eseguibili, moduli funzionali di sistema ed oggetti di evidenza verificabili. La metodologia è strutturata attorno a diversi modelli e processi formali:

1. Modellazione e Mappatura Formale

Trasformazione da Asserzione a Regola: Le asserzioni di audit ( $A$ ) vengono trasformate in regole di controllo eseguibili ( $R$ ) tramite una funzione $\phi$ .
Obiettivo di Ottimizzazione: Viene definito una funzione obiettivo di verifica ( $Q = \lambda P + \mu E - \nu D$ ) per bilanciare la copertura del controllo ( $P$ ), la completezza dell'evidenza ( $E$ ) e il costo di modifica architettonica ( $D$ ).
Classificazione delle Evidenze: L'evidenza di audit è classificata in quattro categorie — processo, dato, comportamento e fiducia — ciascuna mappata a specifici corrispettivi tecnici (ad es., transizioni di stato del workflow, snapshot di versione, log API, firme digitali).
Matrice di Conversione: Una matrice ( $M_{ij}$ ) mappa le asserzioni di audit ai moduli funzionali del sistema in base ai pesi di rischio dei nodi e alle priorità funzionali. Quando la forza della mappatura supera una soglia, i controlli vengono distribuiti alle macchine a stati di workflow, ai Servizi di Controllo degli Accessi, ai Servizi di Audit Log e ai Servizi di Indice di Prova.

2. Architettura Software Affidabile

Il sistema adotta un'architettura a tre livelli:

Livello di Orchestrazione del Business: Gestisce la pianificazione delle istanze di processo e la verifica della trasformazione dello stato.
Livello di Esecuzione del Controllo: Gestisce il matching delle regole, il controllo degli accessi basato sui ruoli (RBAC) e le chiamate firmate.
Livello di Fondazione delle Evidenze: Gestisce l'aggregazione dei log, gli snapshot di rilascio e l'indicizzazione riassuntiva.
Strategia di Deployment: Gli elementi di controllo sono registrati come unità di policy con priorità e trigger specifici. I nodi transazionali chiave utilizzano la scrittura a doppio canale: il database di business memorizza i dati principali, mentre il database delle evidenze scrive simultaneamente TraceID, ID operatore, timestamp e valori hash sotto i vincoli della macchina a stati.

3. Estrazione dei Punti di Controllo e Orchestrazione delle Regole

Utilizzando il replay dei log di eventi durante la simulazione del processo, il metodo analizza campi quali gli identificatori di istanza di processo e i ruoli degli operatori per localizzare i punti di controllo ad alto rischio. Le asserzioni di audit vengono scomposte in condizione, azione e oggetti di evidenza, e poi orchestrate in catene di regole eseguibili. I nodi ad alto rischio impiegano il "doppio legame di regole", dove una regola primaria governa le transizioni di stato del servizio e una regola secondaria verifica la coerenza di firme, timestamp e indici di evidenza.

4. Ciclo di Vita delle Evidenze e Verifica

Il ciclo di vita delle evidenze include generazione, legame, archiviazione, recupero e conservazione. Viene utilizzata una strategia "repository di business + repository di evidenze + repository di indice riassuntivo", con le evidenze ad alto rischio protette da hash SHA-256 e firme Ed25519. L'efficacia del controllo viene verificata attraverso un protocollo di test a tre livelli:

Verifica della Struttura: Controlla il deployment dei punti di controllo e degli identificatori di policy.
Replay del Comportamento: Inietta eventi normali, non autorizzati, di rollback e di timeout.
Revisione delle Evidenze: Valida la coerenza di TraceID, firme e valori di digest.

Contributi Chiave

Il documento introduce un percorso pratico per l'implementazione di un'architettura di conformità integrata nelle attuali pratiche di ingegneria del software. I contributi specifici includono:

Modello di Classificazione: Un modello di classificazione dei corrispettivi tecnici che collega i tipi di evidenza di audit (processo, dato, comportamento, fiducia) alle strutture computazionali.
Matrice di Mappatura: Una matrice di conversione che traduce le asserzioni di audit (integrità, autorizzazione, tracciabilità, non ripudio) in specifici moduli funzionali di sistema e configurazioni di parametri chiave.
Algoritmo di Verifica: Un algoritmo di verifica dell'efficacia del controllo orientato alla verificabilità che quantifica la validità del controllo in base ai tassi di superamento dei test di protocollo e alla completezza delle evidenze.
Vincolo a Ciclo Chiuso: Una metodologia che crea un vincolo a ciclo chiuso tra controlli, funzioni ed evidenze durante la fase di progettazione architettonica.

Risultati

La metodologia è stata illustrata attraverso un caso di studio di una Piattaforma di Gestione di Asset Digitali che copre sei processi principali: registrazione dell'asset, verifica della proprietà, approvazione, variazione di stato, passaggio di autorità e deposito/congelamento.

È stata condotta un'analisi comparativa tra due scenari:

Scenario A (Post-Deployment): Aggiunta dei controlli di audit dopo il completamento dello sviluppo.
Scenario B (Pre-Embedded): Integrazione della mappa di controllo durante la progettazione architettonica.

Risultati Quantitativi:

Copertura del Controllo: Aumentata dal 74,8% (Post-fix) al 93,6% (Pre-embedded).
Completezza delle Evidenze: Migliorata dal 69,7% al 95,1%.
Costi Ingegneristici:
- Le modifiche alle interfacce sono diminuite da 24 a 7.
- I correttivi alle strutture dati sono scesi da 16 a 3.
- I casi di test di regressione sono stati ridotti da 143 a 58.
- Le ore di rimedio sono scese da 247 a 86.
Performance: Il tempo medio di risposta alle query di audit è migliorato da 436 ms a 182 ms, e il tasso di chiusura dei percorsi anomali è aumentato dal 68,9% al 92,4%.

I risultati indicano che l'integrazione preventiva limita le modifiche alle impostazioni di policy e alle configurazioni di indice, evitando la necessità di riscrivere i percorsi transazionali core o di eseguire estesi correttivi ai database.

Significato e Rivendicazioni

Il documento sostiene che questo approccio fornisce un percorso pratico per l'implementazione ingegneristica informatica di un design di sistema con conformità integrata e pronto per l'audit. Convertendo la semantica della conformità in motori di regole distribuibili, vincoli di macchine a stati e oggetti di evidenza indicizzati, il metodo riduce i costi associati alle azioni correttive intraprese dopo lo sviluppo. Esso colma il divario tra le asserzioni di audit e le funzioni di sistema, garantendo che i controlli siano vincoli nativi piuttosto che patch post-hoc.

Gli autori riconoscono limitazioni riguardanti la copertura degli scenari e l'adattabilità a sistemi eterogenei cross-platform. Il lavoro futuro suggerisce di estendere la ricerca verso architetture multi-cloud, preservazione delle evidenze collaborativa on-chain e off-chain e agenti intelligenti auditabili.