Все, что вы делаете на уровне сервера, администратор может отменить. Это само определение его роли, и вы ничего не можете сделать, чтобы предотвратить это.
В SQL 2008 вы можете запросить аудит упомянутого сервера SQL с событиями X, см. http://msdn.microsoft.com/en-us/library/cc280386.aspx. Это решение, совместимое с CC, которое очевидно подделано. Это означает, что администратор может остановить аудит и выполнить его злонамеренные действия, но остановка аудита фиксируется.
В SQL 2005 для аудита рекомендуется использовать инфраструктуру profiler . Это может быть очевидно, если вмешиваться правильно. Вы можете предотвратить изменения данных с помощью триггеров и ограничений, а также проверить изменения DDL. Если администратор изменяет триггеры, это видно в аудите. Если администратор останавливает аудит, это также видно в аудите.
Планируете ли вы это как одноразовое действие против мошеннического администратора или как функцию, которая будет добавлена в ваш продукт? Использование цифровых подписей для подписи всех данных вашего приложения может быть очень дорогостоящим в циклах приложения. Вы также должны разработать безопасную схему, чтобы показать, что записи не были удалены, включая последние записи (т. Е. Не простой пробел в столбце идентификаторов). Например. Вы можете вычислить CHECSUM_AGG более BINARY_CHECKSUM (*) , подписать результат в приложении и сохранить подписанное значение для каждой таблицы после каждого обновления. Надо сказать, что это замедлит работу вашего приложения, поскольку в основном вы сериализуете каждую операцию. Для отдельных строк контрольных сумм / хэшей вам потребуется вычислить всю сигнатуру в вашем приложении, и для этого потребуются возможные значения, которых ваше приложение еще не имеет (т. Е. Значение столбца идентификатора будет назначено вашей вставке) , И как далеко вы хотите пойти? Простой хеш может быть нарушен, если администратор завладеет вашим приложением и отслеживает, что вы хешируете, в каком порядке (это тривиально). Затем он может пересчитать тот же хэш. HMAC требует, чтобы вы хранили секрет в приложении, что в принципе невозможно против решительного хакера. Эти проблемы могут показаться излишними, но если это приложение, которое вы, например, продаете, то все, что нужно одному хакеру для взлома вашей последовательности хешей или секрета hmac. В конце концов, Google позаботится о том, чтобы об этом узнали все остальные.
Я хочу сказать, что вы стоите на вершине холма, сражаясь в проигрышной битве, если пытаетесь удержать admin с помощью технологии. admin - это человек, которому вы доверяете , и если в вашем случае это не работает, проблема заключается в доверии, а не в технологии.