Аудит трейла в веб-приложении с использованием SQL-сервера

Мы разрабатываем веб-приложение с использованием asp.net и sql-сервера. Мы должны сделать аудиторскую проверку для приложения. Насколько я понимаю, аудиторский след будет в основном для всех вложений, обновлений и удалений в базе данных? Теперь способ приблизиться к этому заключается в том, что у меня есть таблица аудита аудита в БД, которая заполняется после запуска каждой вставки, обновления или удаления (вручную записывать script в DAL). Однако любые изменения БД, непосредственно запущенные из студии управления SQL, НЕ будут записаны (по очевидным причинам: P).

Чтобы справиться с этим, я мог бы создать триггер и заботиться обо всем. Я также сделал некоторые поисковые запросы и выяснил, что SQL-сервер имеет возможность выполнять аудиторскую проверку. Однако проблема с использованием триггеров заключается в том, что я НЕ получаю информацию пользователя, зарегистрированную на веб-сайте. Я получу пользователя sql, но я не даю двух криков об этом, меня беспокоит пользователь веб-сайта.

Решение, которое я выяснил, было либо a) Получите контрольный журнал из моего веб-приложения, а также настройте триггер. В отчете аудита я просто показываю журнал аудита из веб-приложения и журнал аудита с SQL-сервера. Очевидные проблемы с этим подходом: над головой. Запись в два разных набора таблиц на КАЖДЫЙ DB CHANGE.

b) У меня есть столбец UserId ON EVERY DB TABLE. Затем я создаю триггер для записи всех изменений БД. Я передаю этот userId для каждой таблицы, которую я меняю (вставляю, обновляю, удаляю) и получаю этот идентификатор от триггера. Очевидные неудачи: noeccesary userid столбец в каждой таблице

Я отношусь к длинному сообщению. В основном мне нужен журнал аудита, который регистрирует все изменения db (в том числе direct hack to db), но в то же время дает мне регистрационную информацию для тех изменений db, которые были сделаны из веб-приложения.

Поймите любой вклад в этом отношении.

Большое спасибо

xeshu

Ответ 1

Насколько вероятно, что будут внесены законные изменения в БД путем непосредственного выполнения SQL-запросов к базе данных либо через студию управления SQL, либо иначе. Я бы рекомендовал предположить, что все данные в данных вводятся через ваше приложение и имеют аудит в вашем BL-слое. Затем вы можете просто ограничить доступ к базе данных доверенным пользователям. В конечном счете, для изменения схемы базы данных должен быть один или несколько пользователей, если эти пользователи захотят обойти аудит, они могут просто отключить триггеры или подделать контрольный журнал. Если есть законные причины для запуска прямых SQL-запросов к БД, например, нередко импортируются данные из других систем и т.д., тогда вы можете ограничить эту активность доверенными пользователями и убедиться, что их сценарии импорта правильно заполняют таблицу аудита. Все, что помещало бы слишком большую нагрузку на ваших администраторов баз данных или того, кто бы ни доверял пользователям, все равно должен быть встроен в приложение.

Ответ 2

Спасибо всем за ваши ответы. После некоторых поисковых запросов это подход, который, по моему мнению, будет уместным: общая таблица аудита

Audit_Table ( Я бы, TableName, RecordId, (ссылка на запись, о которой идет речь) Модифицирован, ModifiedOn, Тип (I, U или D) )

Audit_Details_Table ( Я бы, AuditId, FieldName, OldValue, NewValue)

Я думаю, это должно сделать это. Любые мысли?

Ответ 3

Похоже, вы на правильных строках. Однако, как правило, у вас не будет отдельной таблицы журналов аудита, а таблица аудита для каждой таблицы. Таким образом, для каждой модификации строки в таблице А новая таблица добавляется в TableA_Audit, содержащую новое состояние в таблице A, плюс дата и имя пользователя.

Обычно для этого используется триггер, но если вы сохраняете имя пользователя веб-приложения, я не знаю, как передать эти данные в триггер (может ли кто-нибудь еще помочь?) В этом случае я могу искушаться для использования хранимых процедур. Для каждой таблицы хранятся процедуры для вставки, обновления и удаления строк. Эти хранимые процедуры будут вызывать другую хранимую процедуру, которая вставляет строку в таблицу аудита. Таким образом, вы легко передаете имя пользователя веб-приложения в хранимую процедуру, которая вставляет строку в таблицу аудита. Очевидно, что недостатком является необходимость поддерживать кучу хранимых процедур для каждой таблицы, что может быть немного утомительным, поскольку вы должны следить за тем, чтобы все они работали со столами (и уровнем доступа к данным приложений), поскольку изменения схемы неизбежно требуются.

Обратите внимание, что столбец пользователя не нужен в каждой таблице, только в каждой таблице аудита.

Надеюсь, что некоторые из них были полезны.

Приветствия

Дэвид

Ответ 4

Я согласен с обоими другими плакатами. Итог заключается в том, что если вы хотите сохранить имя пользователя вашего веб-приложения (т.е. Свою собственную аутентификацию), то триггеры НЕ собираются помочь вам в проверке того, что происходит. - Предостережение, если вы не можете использовать встроенную проверку подлинности

Это действительно важно, если вы хотите также использовать контрольные журналы для мониторинга томов активности пользователя, например. Решение этого заключается в том, чтобы либо выполнить все DDL через хранимые процедуры, либо в рамках этих хранимых процедур добавить логику аудита (если вы хотите, чтобы все записи записывались в T-SQL). Кроме того, сделайте это из приложения и посмотрите на одну из многочисленных библиотек журналов, доступных для ASP.Net, таких как NLog.