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

Question

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

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

Решение, которое я нашел, было либо: а) иметь контрольный журнал из моего веб-приложения, а также настроить триггер.В отчете об аудите я просто показываю журнал аудита из веб-приложения и журнал аудита с сервера SQL.Очевидные проблемы с этим подходом: накладные расходы.Запись в два разных набора таблиц при КАЖДОМ ИЗМЕНЕНИИ БД.

b) У меня есть столбец с именем UserId ON КАЖДОЙ БД ТАБЛИЦЫ.Затем я создаю триггер для записи всех изменений в БД.Я передаю этот идентификатор пользователя в каждую изменяемую таблицу (вставка, обновление, удаление) и получаю этот идентификатор из триггера.Очевидные недостатки: столбец ненужных идентификаторов пользователей в каждой таблице

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

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

xeshu

Answer 1

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

Answer 2

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

Audit_Table (Id, TableName, RecordId, (ссылка на соответствующую запись)))

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

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

Answer 3

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

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

Answer 4

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

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

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

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

Дэвид