Audit Trail в веб-приложении с использованием SQL-сервера

Question

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

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

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

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

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

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

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

xeshu

Answer 1

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

Answer 2

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

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

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

Надеюсь, что это было полезно.

Приветствия

Дэвид

Answer 3

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

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

Answer 4

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

Audit_Table ( Id, TableName, RecordId (ссылка на запись в вопросе) ModifiedBy, ModifiedOn, Тип (I , U или D) )

Audit_Details_Table ( Id, AuditId, Имя_поля, OldValue, Новое_значение)

Я думаю, что это должно сделать это. Есть предположения?