Журнал аудита в веб-приложении с помощью SQL-сервера
Мы разрабатываем веб-приложение с помощью asp.net и SQL-сервера. Мы обязаны делать Журнал аудита для приложения. Поскольку я понимаю это, журнал аудита в основном был бы для всех Вставок, Обновлений и Удаляет на праве базы данных? Теперь способ приблизиться к этому состоит в том, что у меня есть Таблица Журнала аудита в DB, который заполняет после каждой вставки, обновления, или удалите, запущен (Вручную запись сценария в DAL). Однако любые изменения DB, непосредственно запущенные из студии управления SQL, НЕ будут зарегистрированы (по очевидным причинам :P).
Для питания, для которого я мог создать триггер и это заботится обо всем. Я также сделал некоторый поиск с помощью Google и узнал, что SQL-сервер имеет способность сделать журнал аудита. Однако проблема с использованием триггеров состоит в том, что я НЕ получу пользовательскую информацию, которая вошла в систему веб-сайт. Я получу sql пользователя, но я не даю два крика об этом, я обеспокоен пользователем веб-сайта.
Решение, которое я выяснил, было любой a), Имеют журнал аудита из моего веб-приложения и также имеют настроенный триггер. В аудиторском отчете я просто показываю контрольный журнал из веб-приложения и и контрольный журнал от SQL-сервера. Очевидные проблемы с этим подходом: по голове. Запись в два различных набора таблиц на КАЖДОМ ИЗМЕНЕНИИ DB.
b) У меня есть столбец под названием UserId НА КАЖДОЙ ТАБЛИЦЕ БАЗЫ ДАННЫХ. Затем я создаю триггер для получения всех изменений DB. Я передаю этот идентификатор пользователя каждой таблице, которую я изменяю (вставьте, обновите, удалите), и получение этого идентификатора от триггера. Очевидные неудачи: столбец идентификатора пользователя unneccesary в каждой таблице
Я действительно приношу извинения за длинное сообщение. В основном мне нужен контрольный журнал, который действительно регистрирует все изменения дб (включая прямой взлом к дб), но в те же времена дает мне пользовательские данные для входа для тех изменений дб, которые были внесены ИЗ веб-приложения.
Будет ценить любой вход в этом отношении.
Большое спасибо
xeshu
4 ответа
Насколько вероятно, что в базу данных будут внесены законные изменения путем прямого выполнения SQL-запросов к базе данных либо через студию управления SQL, либо иным образом. Я бы порекомендовал предположить, что все данные в данные вводятся через ваше приложение и имеют аудит на вашем уровне BL. Затем вы можете просто ограничить доступ к базе данных для доверенных пользователей. В конечном итоге должен быть один или несколько пользователей с разрешением на изменение схемы базы данных. Если эти пользователи хотят обойти аудит, они могут просто отключить триггеры или подделать журнал аудита. Если есть законные причины для выполнения прямых SQL-запросов к БД, например нечастый импорт данных из других систем и т. д., тогда вы можете ограничить эту активность доверенных пользователей и убедиться, что их сценарии импорта правильно заполняют таблицу аудита. Все, что создает слишком большую нагрузку на ваших администраторов баз данных или других доверенных пользователей, в любом случае должно быть встроено в приложение.
Похоже, вы на правильных строках. Однако, как правило, у вас не будет единой таблицы аудита, а скорее таблица аудита для каждой таблицы. Таким образом, для каждого изменения строки в таблицеА добавляется новая строка в таблицуА_Audit, содержащая новое состояние в таблицеА, плюс дата и имя пользователя.
Обычно для этого используется триггер, но если вы храните имя пользователя веб-приложения, я не знаю, как передать эти данные в триггер (может ли кто-нибудь еще помочь?) В этом случае я бы склонился к использованию хранимых процедур. Для каждой таблицы есть хранимые процедуры для вставки, обновления и удаления строк. Каждая из этих хранимых процедур будет вызывать другую хранимую процедуру, которая вставляет строку в таблицу аудита. Таким образом, вы легко передаете имя пользователя веб-приложения хранимой процедуре, которая вставляет строку в таблицу аудита. Очевидно, что недостатком является необходимость поддерживать множество хранимых процедур для каждой таблицы, что может быть немного утомительным, поскольку необходимо следить за тем, чтобы все они шли в ногу с таблицами (и уровнем доступа к данным приложения), поскольку неизбежно потребуются изменения схемы.
Обратите внимание, что вам не нужен столбец Username в каждой таблице, только в каждой таблице аудита.
Надеюсь, что-то из этого было полезным.
Cheers
David
Спасибо всем за ответы. После некоторого поиска в Google это подход, который я считаю подходящим: Generic Audit Table
Audit_Table ( Идентификатор, TableName, RecordId, (ссылка на рассматриваемую запись) Модифицирован, ModifiedOn, Тип (I, U или D) )
Audit_Details_Table ( Идентификатор, AuditId, Имя поля, OldValue, NewValue)
Думаю, это должно сработать. Есть мысли?
Я согласен с обоими другими постерами. В итоге, если вы хотите хранить имя пользователя вашего веб-приложения (т.е. пользовательскую аутентификацию), то триггеры НЕ помогут вам проверить, что происходит. - Предостережение, если вы не можете использовать интегрированную аутентификацию
Это действительно важно, если вы хотите также использовать журналы аудита для мониторинга объемов активности по пользователям, например. Решением этой проблемы является либо выполнение всех DDL с помощью хранимых процедур, а внутри этих хранимых процедур добавление логики аудита (если вы хотите, чтобы все логи писались на T-SQL). В качестве альтернативы можно сделать это из приложения и воспользоваться одной из многочисленных библиотек протоколирования, доступных для ASP.Net, таких как NLog.