Как реализовать аудит на основе контекста?

У меня есть текущее приложение с ведомым БД, которое имеет несколько методов для доступа к данным.

  • Веб-приложение
  • Прямые пользователи SQL Access (я пытаюсь удалить их)
  • Приложение Client Server
  • Пакетные входы и выходы

Мне нужно реализовать аудит на основе контекста, поскольку текущий аудит данных недостаточен для ретроспективной идентификации того, какие процессы вызвали изменения данных.

В настоящее время я думаю о скрытии модели данных за XAPI (Transactional API), и каждое действие в модели данных должно будет предоставить некоторую форму идентификации связанного действия или причины изменения данных, которые будут храниться вместе с самими проверенными данными.

Может ли кто-нибудь предложить мне лучший метод для проведения аудита на основе контекста, который будет охватывать весь доступ к базе данных? Или даже указать какие-либо очевидные недостатки в моем текущем подходе, который я пропустил?

Спасибо заранее.

ОТВЕТЫ

Ответ 1

Это более старая должность, но я все же хочу предоставить решение, возможно, это будет полезно для кого-то.

Oracle предоставляет переменные "контекст" для каждого сеанса. В приложении, использующем пул соединений для подключения к базе данных, Oracle предоставляет пространство имен по умолчанию, называемое "CLIENTCONTEXT". В этом пространстве имен вы можете создавать такие переменные, как USER ID, и убедиться, что эта переменная задана, когда соединение передается на веб-запросы сервера. Таким образом, внутри базы данных вы можете определить, какой запрос пользователя "веб-пользователь" (или приложение для пользователя) обрабатывается внутри базы данных. например dbms_session.set_context ('CLIENTCONTEXT', user_id,); Надеюсь, что это поможет.

Ответ 2

EDIT добавила контекстную часть ответа на снизу

  • Каждый пользователь имеет вход в систему.
  • Свяжите эти входы с пользователями SQL Server.
  • Используйте SYSTEM_USER (например: выберите SYSTEM_USER) для вашего аудита.

Единственное место, где вышеизложенное становится сложным, - это веб-приложение.

  • Я не знаю, является ли ваше веб-приложение внутренним или нет, (если оно внутренне, использование аутентификации Windows с олицетворением/делегией будет работать отлично)
  • Если он внешний, у вас будет определенная система, которая будет проверять вход в веб-приложение (и, возможно, выполнять другие привилегированные операции), тогда вы можете использовать собственные учетные данные пользователя для доступа к db во время сеанса.
    • Если вы не хотите иметь группу пользователей SQL Server, вы можете самостоятельно управлять сеансом и создавать/удалять пользователей "на лету" (например, при входе/выходе из системы).

Здесь некоторые T-SQL для иллюстрации

-- AFTER SUCCESSFUL LOGIN
BEGIN
-- You would already have the user name and password
DECLARE @user varchar(32)
SET @user = 'tester'
DECLARE @pw varchar(32)
SET @pw = 'SuperTest123'
-- if the user logs in from 2 different sessions
-- keep the name more unique
SELECT @user = @user + REPLACE(NEWID(), '-', '')
-- build the dynamic sql to create a user
DECLARE @sql varchar(8000)
SELECT @sql = 'CREATE LOGIN [' + @user + '] WITH PASSWORD = ''' + @pw + '''; '
SELECT @sql = @sql + 'USE MyDatabase; CREATE USER [' + @user + '] FOR LOGIN [' + @user + '] WITH DEFAULT_SCHEMA = db_datareader; '
EXEC(@sql)
-- use these credentials for web apps sql connections
SELECT @user [UserName], @pw [Password]
END

-- AFTER LOGOUT / SESSION EXPIRATION
BEGIN
-- You would already have the user+guid used by the sql server
DECLARE @login varchar(32)
SET @login = 'tester3C8DA60B996C4E5881774D1FE4'
-- build the dynamic sql to drop user
DECLARE @sql varchar(8000)
SELECT @sql = 'DROP LOGIN [' + @login + ']; '
SELECT @sql = @sql + 'USE MyDatabase; DROP USER [' + @login + ']; '
EXEC(@sql)
-- user gone until next session
END

Контекстные ограничения могут быть достигнуты непосредственно в триггерах аудита.

  • Таблица: TEMP_AUDITREASON
    • [Пользователь] VARCHAR (128) DEFAULT SYSTEM_USER
    • [Причина] VARCHAR (512)
  • Trigger

Это может быть немного glib, но...

IF EXIST(SELECT [Reason] FROM [TEMP_AUDITREASON] WHERE [User] = SYSTEM_USER AND [Reason] IS NOT NULL)
BEGIN
 SELECT @REASON = [Reason] FROM [TEMP_AUDITREASON] WHERE [User] = SYSTEM_USER
 -- clear it for the next transaction
 DELETE FROM [TEMP_AUDITREASON] WHERE [User] = SYSTEM_USER
END
ELSE
BEGIN
 -- SOUND THE ALARM!!! no reason was given
END

Ответ 3

у нас был проект, в котором нам требовалась подробная информация аудита о том, что было изменено, когда и кем.

в нашем случае, что мы сделали, улучшено наше решение MVC, чтобы сохранить контрольный след, когда все изменилось. в этой ситуации нам удалось сохранить вспомогательную информацию, такую ​​как веб-пользователь, ip и т.д.

кроме того, мы включили двоичное ведение mysql, поэтому при необходимости мы можем отбросить всю историю, а также предоставить дополнительные журналы, хранящиеся в доступе, чтобы отличить источник изменений.

в вашем случае это будет несколько сложнее, если у вас нет слоя между базой данных и фактическим доступом к базе данных. поэтому я бы предложил создать api для операций с данными, которые будут работать в качестве промежуточного уровня и предоставят вам весь необходимый элемент управления.

это должно дать вам указания для начала работы.