Как убедиться, что таблица не была подделана в SQL Server 2008?

Question

Мне нужен простой, но надежный механизм, чтобы таблица не была подделана в SQL Server 2008. Предполагается, что хакер может получить доступ и контролировать только один из серверов (приложение или база данных), но не может получить доступ к обоим. Любые ссылки или предложения будут с благодарностью.

Разъяснение. «Подделка» здесь означает возможность обновления / удаления строки после ее вставки в таблицу. Защищаемая таблица является своего рода журналом бизнес-транзакций.

Answer 1

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

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

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

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

Answer 2

Если вы действительно хотите пойти дальше, я бы предложил следующее:

• Запретить любой прямой доступ для записи в таблицу. Обновления вообще не разрешены, вставки выполняются с помощью хранимой процедуры.
• Часть данных журнала представляет собой контрольную сумму полей MD5 (не включая идентификатор записи).
• После записи журнала отправьте идентификатор записи и контрольную сумму на внешний сервер ведения журнала. Сделайте это через трансляцию TCP. Таким образом, даже если злоумышленник знает, что данные отправляются на внешнюю машину, он не будет знать, какой (или сколько). Сервер регистрации просто записывает идентификаторы записей и контрольные суммы, обновления и модификации не допускаются. Получение дублированного идентификатора должно привести к срабатыванию тревоги. Вы также можете убедиться, что идентификаторы записей получены в монотонно возрастающей последовательности, но это может вызвать проблемы в среде с высокой пропускной способностью.

Answer 3

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

• Количество элементов в файле и количество строк в таблице совпадают
• Для каждой строки в таблице вычисленное значение хеша (однако вы определяете это) соответствует значению, сохраненному в файле для этой строки

Answer 4

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

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

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

В-четвертых, в SQL Server 2008 у вас могут быть триггеры ddl, которые сообщают вам, кто изменил структуру таблицы, а не данные.

Answer 5

Убедитесь, что ваш сервер правильно заблокирован - это первое, что вы должны сделать.

Возможным решением для обнаружения ошибочных изменений является то, что вы можете вычислить какую-либо контрольную сумму для всех полей в строке и сохранить ее в строке в виде длинной непонятной строки; Если хранимая процедура выполняет команды вставки / обновления, она может пересчитать эту контрольную сумму при каждой вставке / обновлении. Если кто-то напрямую редактирует данные, то есть через Access или Management studio и непосредственно редактирует поля, контрольная сумма будет отключена, и при следующем доступе вы сможете обнаружить это и предпринять действия.

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

Answer 6

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

Answer 7

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