Предотвратить подделку таблицы аудита

Question

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

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

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

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

EDIT:

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

Answer 1

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

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

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

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

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

Answer 2

Вот некоторые возможности:

• Вы не можете предотвратить или обнаружить вмешательство кого-либо с разрешениями sysadmin (sa).Если вы не доверяете своему системному администратору, возможно, у вас проблемы хуже, чем у этого конкретного.
• Трудно предотвратить или обнаружить вмешательство с помощью домена или локального администратор.Такой человек может перезапустить SQL Server в однопользовательском режиме и получить доступ в качестве системного администратора с помощью SQL.
• Чтобы обнаружить вмешательство базы данных владелец (dbo), вы можете использовать Аудит сервера в SQL Server 2008 или на стороне сервера Отслеживание SQL в более ранних версиях SQL Server.
• Вы можете предотвратить вмешательство других пользователей, ограничив их разрешения соответствующими триггерами.и таблицы аудита.

Answer 3

вы можете включить отслеживание изменений, чтобы у вас был вид «Аудит таблицы аудита».

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

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

Answer 4

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

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

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

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

Answer 5

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

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

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

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