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

есть таблица аудита в нашей базе данных. Записи в эту таблицу выполняются с помощью триггеров.

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

Каковы возможные механизмы, которые могут предотвратить (или, по крайней мере, обнаружить) случаи фальсификации данных аудита?

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

РЕДАКТИРОВАТЬ:

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

 Bruce16 мая 2011 г., 20:24
Они могут использовать Management Studio только для обхода разрешений, если они входят в систему как системный администратор, явно или неявно (например, путем входа в Windows с правами администратора). Надежная безопасность SQL зависит от хороших привычек безопасности сети.
 LukeH21 янв. 2011 г., 11:17
Просто ограничьте разрешения, чтобы только определенные учетные записи имели разрешения на вставку / обновление / удаление для этой таблицы.
 CodesInChaos21 янв. 2011 г., 11:16
Как насчет того, чтобы не дать злоумышленнику права на запись в эту таблицу? Или, если вы параноик, отправьте журнал на другой компьютер, к которому мало кто имеет доступ, вместо использования таблицы в базе данных.

Ответы на вопрос(5)

чтобы у вас был вид «Аудит таблицы аудита».

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

Надеюсь это поможет.

 buhtla21 янв. 2011 г., 11:35
Спасибо за ответ. Я отредактировал свой вопрос, чтобы быть более точным. Обычный пользователь приложения, конечно, не имеет доступа к БД.

через менеджер SQL от изменения содержимого. Вы можете сделать это подделкой, хотя.

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

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

Тогда вам нужно беспокоиться об удалении первой или последней записи x. Для этого мы используем трейлер и запись заголовка, которые всегда имеют одинаковое содержимое, если их нет, то верх или низ таблицы были удалены. Объединенный HMAC заголовка использует запись после него, а не запись до (так как ранее записи не было).

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

 Can Bud06 июл. 2015 г., 11:22
Отличный ответ, спасибо. Может кто-нибудь уточнить, как рассчитать хеш для первой строки?
 Patrick21 янв. 2011 г., 12:14
Мы проводим аудит из кода. Его нельзя изменить из кода, работающего на сервере (то есть кода, который мы пишем), хотя, если злоумышленник смог запустить произвольный код на сервере и понять, как получить доступ к криптосервису и т. Д., Он мог бы написать то, что ему понравилось. таблица аудита. Конечно, если бы у злоумышленника был такой уровень доступа к серверу, и он тратил свое время на то, чтобы возиться с таблицами аудита, он потерял бы ценную возможность украсть у нас данные ...
 Bruce16 мая 2011 г., 20:21
«Ничто не может помешать кому-либо получить доступ к вашей базе данных через диспетчер SQL от изменения содержимого». Это верно только в том случае, если они входят в SQL Management Studio как системный администратор. Хотя это типично, это не обязательно. Если их логин запрещает им доступ к объекту, подключение через SQL Management Studio не даст им дополнительного доступа.
 buhtla21 янв. 2011 г., 11:44
Это выглядит как сложная, но почти пуленепробиваемая концепция :). Вы делаете аудит из кода или с помощью триггеров? Я предполагаю, что вы делаете аудит из кода. Если вы это сделаете, то нет ничего, что мешало бы пользователю изменять данные в некоторой таблице, которую вы проверяете, из кода, и это не оставило бы доказательств в вашей таблице аудита, верно?
 buhtla21 янв. 2011 г., 12:18
Да, в самом деле :). Спасибо за ваш ответ, это было очень полезно.

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

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

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

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

Вы не можете предотвратить или обнаружить вмешательство кого-либо ссисадмин (sa) разрешения. Если вы не доверяете своему системному администратору, возможно, у вас проблемы хуже, чем у этой конкретной.Трудно предотвратить или обнаружить вмешательстводомен или жеместный администратор. Такой человек может перезапустить SQL Server в однопользовательском режиме и получить доступ в качестве системного администратора с помощью SQL.Обнаружение взлома базой данныхвладелец (ДБО), вы могли бы использоватьАудит сервера в SQL Server 2008 или на стороне сервераТрассировка SQL в более ранних версиях SQL Server.Вы можете предотвратить вмешательство других пользователей, ограничив их разрешения соответствующими триггерами и таблицами аудита.
 Dan Lugg18 апр. 2012 г., 02:25
+1 на "худшие проблемы, чем этот конкретный"Я только что обсудил это сегодня.

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

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

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

Нет причин, по которым пользователь должен иметь доступ к компьютеру БД или иметь учетные данные учетной записи, которой разрешено выполнять запись в базу данных. Вы, похоже, беспокоитесь о возможности подделки аудиторской информации. Что мешает злоумышленнику удалить таблицы или изменить функциональные данные?

 buhtla21 янв. 2011 г., 11:29
Привет, я отредактировал свой вопрос, я не совсем понял терминологию. У нас есть отдельные машины для БД и бизнес-логики.

Ваш ответ на вопрос