Audit Trail nell'applicazione Web che utilizza il server sql

Question

Stiamo sviluppando un'applicazione Web che utilizza asp.net e server sql. Siamo tenuti a fare un audit trail per l'applicazione. A quanto mi risulta, una traccia di controllo sarebbe fondamentalmente per tutti gli inserti, gli aggiornamenti e le eliminazioni nella base di dati giusto? Ora il modo per avvicinarsi a questo è che ho una tabella Audit Trail nel DB che popola dopo che ogni inserto, aggiornamento o cancellazione è stato attivato (Scrittura manuale dello script all'interno del DAL). Tuttavia, eventuali modifiche ai DB direttamente attivate da SQL Management studio NON verranno registrate (per ovvi motivi: P).

Per far ciò potrei creare un trigger e che si occupa di tutto. Ho anche fatto qualche ricerca su google e ho scoperto che il server SQL ha la capacità di fare audit trail. Tuttavia, il problema con l'utilizzo dei trigger è che NON otterrò le informazioni dell'utente che hanno effettuato l'accesso al sito Web. Otterrò l'utente sql ma non me ne frega niente, sono preoccupato per l'utente del sito.

Una soluzione che ho scoperto era a) Avere una traccia di controllo dalla mia applicazione Web e avere anche la configurazione del trigger. Nella relazione di controllo, mostro semplicemente un registro di controllo dall'applicazione Web e il registro di controllo dal server SQL. Problemi ovvi con questo approccio: sopra la testa. Scrivere su due diversi gruppi di tabelle su OGNI DB CHANGE.

b) Ho una colonna denominata UserId ON OGNI DB TABLE. Quindi creo un trigger per catturare tutte le modifiche del DB. Passo questo ID utente su ogni tabella che cambio (inserisci, aggiorna, cancella) e ottengo questo ID dal trigger. Ostacoli evidenti: colonna utente inutile in ogni tabella

Mi scuso per il post lungo. Fondamentalmente ho bisogno di un registro di controllo che registri tutte le modifiche db (incluso l'accesso diretto a db) ma allo stesso tempo mi fornisce le informazioni di accesso dell'utente per le modifiche db apportate dall'applicazione web.

Apprezzerà qualsiasi input in merito.

Molte grazie

xeshu

Answer 1

Quante probabilità ci sono che ci stanno per essere cambiamenti legittimi apportate al DB query SQL che eseguono direttamente contro la base di dati sia attraverso studio di gestione di SQL o di altro genere. Vorrei raccomandare assumendo che tutti i dati nei dati vengano inseriti tramite l'applicazione e abbiano il controllo nel livello BL. È quindi possibile limitare semplicemente l'accesso al database agli utenti fidati. Alla fine ci deve essere uno o più utenti con il permsion per modificare lo schema del database, se quegli utenti volevano bypassare l'auditing potevano semplicemente disabilitare i trigger o simulare la traccia di controllo. Se ci sono motivi legittimi per eseguire query SQL dirette sul DB, ad es. importazioni di dati poco frequenti da altri sistemi ecc., quindi è possibile limitare questa attività agli utenti fidati e assicurarsi che i loro script di importazione compilino correttamente la tabella di controllo. Tutto ciò che potrebbe comportare un carico di lavoro eccessivo sui DBA o su chiunque sia l'utente fidato dovrebbe comunque essere integrato nell'application.

Answer 2

suona come siete sulla strada giusta. Tuttavia, in genere non si dispone di un'unica tabella di controllo, ma piuttosto di una tabella di controllo per ogni tabella. Pertanto, per ogni modifica a una riga in TableA, una nuova riga viene aggiunta a TableA_Audit contenente il nuovo stato in TableA, oltre alla data e al nome dell'utente.

Un trigger è normalmente utilizzato per questo, ma se si sta memorizzando il nome utente dell'app Web, non so come passare questi dati in un trigger (può aiutare qualcun altro?) In questo caso, potrei essere tentato di utilizzare stored procedure. Per ogni tabella, sono memorizzate le procedure per inserire, aggiornare ed eliminare le righe. Queste stored procedure chiamerebbero ciascuna un'altra stored procedure che inserisce la riga nella tabella di controllo. In questo modo, si passa facilmente il nome utente dell'applicazione Web alla stored procedure che inserisce la riga nella tabella di controllo. Ovviamente lo svantaggio è di dover mantenere un mucchio di stored procedure per ogni tabella, che può essere un po 'noioso in quanto è necessario assicurarsi che tutti siano al passo con le tabelle (e il livello di accesso ai dati dell'applicazione) poiché le modifiche dello schema sono inevitabilmente necessarie .

Nota che non è necessaria una colonna Nome utente in ogni tabella, solo in ogni tabella di controllo.

Spero che un po 'di quello è stato utile.

Acclamazioni

David

Answer 3

Sono d'accordo con entrambi gli altri poster. In conclusione, se si desidera archiviare il nome utente dell'utente dell'app Web (ad esempio l'autenticazione personalizzata), i trigger NON consentono di verificare ciò che sta accadendo. - Avvertenza a meno che non sia possibile utilizzare l'autenticazione integrata

Questo è davvero importante se si desidera utilizzare anche le tracce di controllo per il monitoraggio dei volumi di attività da parte dell'utente, ad esempio. La soluzione a questo è di eseguire tutto il DDL tramite stored procedure e all'interno di quelle stored procedure aggiungere la logica di controllo (se si desidera tutta la registrazione scritta in T-SQL). In alternativa, esegui dall'applicazione e guarda una delle numerose librerie di registrazione disponibili per ASP.Net come NLog.

Answer 4

Grazie a tutti per le vostre risposte. Dopo un po 'googling questo è l'approccio che penso che sarebbe opportuno: Audit Generico Tabella

Audit_Table ( Id, TableName, RecordId, (link al record in questione) ModifiedBy, ModifiedOn, tipo (I , U o D) )

Audit_Details_Table ( Id, AuditId, NomeCampo, OldValue, NewValue)

Penso che questo dovrebbe farlo. qualche idea?