In molti dei progetti su cui abbiamo lavorato, i clienti ci hanno chiesto di registrare più azioni degli utenti nel database. Vogliono conoscere tutte le azioni eseguite dagli utenti nell'applicazione, ma acquisire e registrare tutte le interazioni umane può essere difficile. Abbiamo dovuto registrare tutte le modifiche ai dati eseguite tramite il sistema. Questo articolo descrive alcune delle insidie che abbiamo incontrato e gli approcci che abbiamo utilizzato per superarle.
Introduzione
Lavoro come architetto di soluzioni nei servizi finanziari. È importante conservare un record dell'ultimo utente che ha modificato una riga. Nei casi più semplici basta registrare il timestamp della modifica per avere la tracciabilità di cambiamenti. Ecco un semplice esempio di tabella che memorizza gli accordi con i clienti che includono last_changed colonne per utente e timestamp.
Eppure, in alcuni casi, questo non basta. Spesso dobbiamo avere la piena tracciabilità (compresi prima e dopo le "immagini" dei dati). In alcuni casi, abbiamo anche bisogno di verificabilità (chi, cosa, quando).
Sfortunatamente, molti dei nostri sistemi non sono stati progettati per fornire tracciabilità e verificabilità. Avevamo bisogno di reverse engineering questi requisiti delle operazioni aziendali nei sistemi.
Tracciabilità
In alcuni casi, abbiamo riscontrato che la tracciabilità è facile da ottenere. Mentre, in altri, lo abbiamo trovato difficile o addirittura impossibile. A seconda del tuo sistema, la soluzione potrebbe essere semplice. L'accesso ai dati potrebbe consentire una semplice iniezione di registrazione delle immagini prima e dopo dei dati. Questa registrazione può essere implementata in modo tale che i risultati vengano archiviati in una tabella di database anziché in un file di registro. In alcuni prodotti, abbiamo raggiunto questo obiettivo in modo semplice grazie alla persistenza strato. Ad esempio, questo è stato possibile con Sospensione .
Qui puoi vedere una voce per ogni elemento dell'audit trail, inoltre ci saranno valori prima e dopo per ogni colonna che è stata modificata. Inoltre, nel caso in cui una riga venga eliminata, salviamo tali informazioni con il functioncode indicando cancella. Abbiamo scelto di utilizzare varchar(1) per memorizzare il codice della funzione (C, R, D) specificando il tipo di modifica, piuttosto che il nome o la descrizione dell'“operazione” (Crea, Aggiorna, Elimina) che è stata eseguita . Il instance_key contiene la chiave primaria dell'elemento che è stato aggiunto, modificato o eliminato, per la tracciabilità.
Tuttavia, è possibile che il tuo livello di accesso ai dati non fornisca le funzionalità necessarie per te. Per altri prodotti, il nostro livello di accesso ai dati non lo faceva. In quei casi, la tracciabilità necessitava di modifiche complesse. Ad esempio, potresti aver bisogno del recupero e registrazione di qualsiasi dato prima della modifica. Come ho scritto, questo è possibile ma può essere complesso da mettere in atto. Gli sviluppatori dovrebbero creare un recupero di ogni riga prima di modificare una riga. Non sarebbe possibile eseguire un aggiornamento senza una selezione.
Come puoi aggirare la tracciabilità? Una possibile soluzione è assicurarsi di conoscere la situazione iniziale di tutti i dati, ovvero la situazione iniziale creata da qualsiasi dato statico caricato nel sistema. Quindi, dovresti registrare tutte le modifiche. In altre parole, cosa sono tutte le immagini "dopo" dei dati? In questo modo, sarebbe possibile "andare avanti ” dai dati statici caricati. Tutti gli aggiornamenti effettuati fino a quel momento vengono applicati. Questa è una situazione tutt'altro che ideale, ma potrebbe essere accettabile.
Una semplice tabella può essere utilizzata se l'unica informazione disponibile è il nuovo valore e non il valore precedente.
Verificabilità
In alcune situazioni, dobbiamo garantire che tutte le azioni intraprese nel sistema siano completamente controllabili . Chi ha effettuato l'accesso a che ora? Quali azioni ha intrapreso ciascun utente nel sistema, inclusa la sola visualizzazione dei dati? Questo è importante perché potrebbe essere significativo se un utente ha esaminato un pagamento.
Per ottenere un tracciamento a grana fine può essere difficile guardare solo l'accesso al database. Spesso dobbiamo guardare a un livello superiore ed esaminare le azioni oi servizi prestati. In alcuni casi, siamo stati in grado di tracciare ogni chiamata di servizio per sapere cosa ha fatto un utente a che ora. Con un controller di input/output del servizio Web, la registrazione delle richieste di servizio è stata abbastanza semplice.
Ecco un esempio di un semplice registro di controllo utente in cui registriamo l'azione eseguita da ciascun utente. Discuterò alcune questioni su questo approccio nella prossima sezione "Prova".
Di seguito viene fornita una breve descrizione della tabella:
Il user_audit la tabella contiene voci di controllo dei dati con timestamp. La chiave primaria è costituita da audit_entry_time timbro più user_id e bank_id più il nome dell'action eseguita. I campi hanno significati che corrispondono ai loro nomi. La tabella di controllo memorizza il result dell'azione, più la class effettiva che ha eseguito l'azione, i suoi parameters di input ed eventuali errors .
Ecco un altro esempio di audit trail in cui registriamo le immagini prima e dopo dei dati che sono stati modificati in una tabella particolare (insieme all'azione eseguita, alle credenziali dell'utente e al timestamp).
Il audit_trail la tabella contiene voci di controllo delle immagini precedenti e successive dei dati. La chiave primaria è costituita da audit_gen_key questa è una chiave generata dall'applicazione. I campi hanno significati che corrispondono ai loro nomi. Il nome della tabella del database per la quale è registrata questa voce dell'audit trail è memorizzato in modified_table , più l'immagine "prima" è archiviata in prev_value e l'immagine "dopo" in new_value . Il module che sta eseguendo la modifica e il funct_type di modifica (Crea, Aggiorna, Elimina). Infine, le informazioni di controllo di user_id (e il corrispondente bank_id ) più il timestamp della modifica (date_last_changed ).
Poi abbiamo lanciato una sfida. Quando si registrano sia le informazioni sulla tracciabilità che le informazioni sulla verificabilità, la registrazione avviene due volte. Dal punto di vista dell'audit, questo è fastidioso. I revisori devono assicurarsi che le informazioni siano le stesse tra questi due registri.
Prova
Un'altra sfida era garantire la registrazione di tutte le azioni degli utenti . Ciò è spesso richiesto dai revisori dei conti nel settore dei servizi finanziari.
Ora abbiamo una vera sfida. La nostra soluzione era garantire la tracciabilità centrale e la registrazione dell'audibilità. Le "interfacce" centrali assicurano che tutte le implementazioni di tale interfaccia includessero la registrazione. È stato semplice assicurarsi che tutte le classi appropriate stessero implementando l'interfaccia.
Naturalmente, questo non garantisce una prova di registrazione al 100%. È un forte controllo di sicurezza che tutte le classi appropriate siano state registrate come richiesto.
Conclusione
Il reverse engineering di nuove funzionalità aziendali in un sistema esistente è sempre una sfida. Questo può essere ancora più vero quando la funzionalità implementata va al centro.
