Целостность данных для большой таблицы базы данных

Question

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

Моя идея состоит в том, чтобы иметь HMAC для каждой записи и вычислять инкрементный HMAC для таблицы при изменении пользователячерез пользовательский интерфейс:

1. Рассчитать HMAC для первой записи - HMAC_Current.
2. Рассчитать HMAC для новой записи - HMAC_i
3. Рассчитать новый HMAC для таблицы как HMAC_Current =HMAC (HMAC_Current + HMAC_i).

Плюсы:

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

Минусы:

1. Когда пользователь удаляет или изменяет запись, мне приходится пересчитывать HMAC для таблицы из этой записи в конец таблицы.
2. Когда я хочу проверить целостность данных, я должен проверить HMAC для каждой записи.Затем вычислите HMAC для всей таблицы сверху вниз и сравните его с HMAC_Current.

Есть ли лучший способ сделать это?

Answer 1

Я вижу ряд проблем с этим подходом:

1. Если ваша sysdba имеет доступ ко всем данным, что также мешает им связываться с HMAC? Например: они отменяют все изменения в таблице, сделанные за последний месяц. Затем они вернули HMAC с прошлого месяца. Сохраняется ли целостность данных в этом случае?

2. Что мешает им подорвать приложение, чтобы связываться с HMAC? Например: если у них нет доступа к приложению, они изменяют пароль для пользователя и получают доступ к приложению как этот пользователь, чтобы связываться с записями.

3. Даже если вы можете заставить это работать, для чего это хорошо? Скажем, вы нашли несоответствие HMAC. Теперь Кого вы считаете ответственным? Админ? Пользователь? Повреждение данных?

Лучшее решение - использовать аудит. Вы можете настроить все виды аудита в Oracle, и сохранить аудиты где-нибудь, чего не может коснуться dba. Кроме того, использование аудита дает огромное преимущество: вы можете знать, кто что изменил. С вашей схемой вы не можете этого знать.

Вы даже можете настроить FGA (детальный аудит) , чтобы он проверял только определенные столбцы, а также знал, какие значения были до и после изменения, что невозможно при стандартном аудит.

Ссылка: Настройка и администрирование аудита

Answer 2

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

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

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

В SQL Server также есть способ аудита структурных изменений в БД. Я не знаю, работает ли Oracle так же хорошо, но это также удобно для аудита.

Answer 3

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

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

В случае вашего сценария вы должны рассчитать, сохранить и проверить HMAC. Если проверка не пройдена, вы должны увеличить ее.

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

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

Answer 4

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