Как реализовать контекстный аудит БД? - PullRequest
Новая
       51

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

10 голосов
/ 15 июля 2011

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

  1. Веб-приложение
  2. Пользователи Direct SQL Access (я пытаюсь удалить их)
  3. Клиент-серверное приложение
  4. Пакетные входы и выходы

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

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

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

Заранее спасибо.

Ответы [ 3 ]

2 голосов
/ 08 февраля 2013

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

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

1 голос
/ 04 октября 2011

РЕДАКТИРОВАТЬ добавлена ​​контекстно-зависимая часть ответа внизу

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

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

  • Я не знаю, является ли ваше веб-приложение внутренним или нет (если оно внутреннее, отлично подойдет проверка подлинности Windows с имитацией / делегированием)
  • Если она внешняя, у вас будет системная учетная запись, которая будет проверять входы в веб-приложение (и, возможно, выполнять другие привилегированные операции), тогда вы сможете использовать собственные учетные данные пользователя для доступа к БД во время сеанса.
    • Если вы не хотите иметь группу пользователей 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

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

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
0 голосов
/ 04 октября 2011

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

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

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

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

это должно дать вам указания, с чего начать.

...